Por qué dos ejecuciones del mismo prompt difieren

Envía a un modelo exactamente el mismo prompt dos veces y a menudo obtendrás dos respuestas distintas. Para quien está acostumbrado al software ordinario, donde la misma entrada produce de forma fiable la misma salida, esto se siente como una avería. No lo es. La variación es una característica diseñada de cómo estos modelos generan texto, y la mayor parte del tiempo está haciendo algo útil. Pero tiene consecuencias reales para las pruebas, para la fiabilidad y para cualquier función que necesite comportarse de forma predecible, así que el objetivo no es alarmarse por ella sino entender de dónde viene y cuánta puedes bajar cuando lo necesites.

Este artículo explica por qué la salida varía, qué perilla la controla, por qué incluso esa perilla no compra una repetibilidad perfecta, y cómo diseñar en torno a la variación en lugar de pelear contra ella.

La generación es una serie de elecciones

Un modelo produce texto un token cada vez. En cada paso, no elige un único token siguiente predeterminado. En su lugar, calcula una distribución: un conjunto de probabilidades sobre muchos posibles tokens siguientes. Un token podría ser muy probable, unos pocos moderadamente probables, y una larga cola improbable. El modelo entonces muestrea de esta distribución: hace una extracción aleatoria ponderada, donde los tokens más probables tienen más probabilidad de ser elegidos pero los menos probables aún tienen una oportunidad.

Ese paso de muestreo es la raíz de la variación. Como cada token es una extracción en lugar de una selección fija, dos ejecuciones pueden divergir, y una vez que divergen en un solo token, todo lo posterior se condiciona a una historia distinta, así que las salidas pueden ramificarse por completo. Una palabra distinta al principio de una frase lleva a una frase distinta, que lleva a un párrafo distinto. Una pequeña aleatoriedad temprana se acumula en grandes diferencias después.

Por qué la aleatoriedad es una característica, no un defecto

Sería técnicamente posible elegir siempre el único token más probable en cada paso, produciendo la misma salida cada vez. Los modelos normalmente no usan esto por defecto, y por buena razón. El texto que siempre toma el camino más probable tiende a ser plano, repetitivo y extrañamente sin vida. Esa pizca de aleatoriedad es lo que permite a un modelo expresar las cosas de forma distinta, encontrar una continuación menos obvia pero mejor, y evitar quedar atascado en bucles repetitivos.

Para el trabajo creativo y conversacional, esta variación es justo lo que quieres. Pide tres eslóganes y te molestaría obtener el mismo tres veces. La aleatoriedad es el modelo explorando su espacio de buenas respuestas en lugar de devolver mecánicamente la que puntuó más alto. Así que la variación no es el modelo siendo poco fiable; es el modelo al que se le da margen para ser interesante. La única pregunta es si tu tarea concreta quiere ese margen.

La perilla que la controla

La cantidad de aleatoriedad es ajustable, lo más común a través de un ajuste a menudo llamado temperatura. La intuición es simple: la temperatura controla cuánto favorece el modelo sus mejores opciones frente a repartir sus apuestas. Una temperatura baja agudiza la distribución hacia los tokens más probables, haciendo la salida más enfocada, más predecible y más repetitiva. Una temperatura alta aplana la distribución, dando a los tokens menos probables más oportunidad y haciendo la salida más variada, más sorprendente y más propensa a divagar.

Baja la temperatura del todo y el modelo se inclina con fuerza a elegir siempre su mejor opción, lo que hace la salida mucho más consistente entre ejecuciones. Súbela e invitas a más diversidad. Esta única perilla te permite situar una tarea donde corresponde: baja cuando necesitas la misma respuesta estructurada cada vez, más alta cuando quieres rango y creatividad. La mayor parte del control práctico que tienes sobre la variación vive aquí.

Por qué una temperatura baja aún no es perfectamente repetible

Aquí está la sutileza que despista a la gente: incluso con la aleatoriedad al mínimo, aún puedes ver diferencias ocasionales entre ejecuciones. Reducir la aleatoriedad del muestreo elimina la mayor fuente de variación, pero no necesariamente todas las fuentes.

Dos cosas mantienen viva una rendija de imprevisibilidad. Primero, cuando dos tokens candidatos están extremadamente cerca en probabilidad, diferencias minúsculas en el cómputo pueden inclinar la elección hacia un lado u otro, y desde esa bifurcación las salidas divergen. Segundo, los sistemas que ejecutan modelos grandes son complejos y pueden introducir un no determinismo minúsculo propio a través de cómo se programan y combinan los cómputos. Ninguno de los dos es algo que normalmente controles desde fuera. El encuadre honesto es que bajar la aleatoriedad hace la salida mucho más consistente y normalmente lo bastante consistente, pero tratar cualquier llamada a un modelo como una función garantizada y repetible bit a bit es un error. Planifica para "altamente consistente", no para "perfectamente determinista".

Qué significa esto para las pruebas y la fiabilidad

La variación cambia cómo tienes que evaluar un modelo, e ignorarlo lleva a conclusiones falsas. Si pruebas un prompt una vez y funciona, has aprendido que puede funcionar, no que funcionará cada vez. Una sola buena ejecución es una muestra de una distribución de ejecuciones posibles. Para entender de verdad el comportamiento, ejecuta la misma entrada varias veces y observa la dispersión de las salidas. La variación que ves es información: un prompt que produce respuestas muy distintas es frágil, mientras que uno que produce respuestas estables entre ejecuciones es robusto.

Esto también replantea la depuración. Cuando una función se comporta mal de vez en cuando, la causa puede no ser un fallo fijo que puedas reproducir a voluntad, sino una rama de baja probabilidad que el muestreo toma ocasionalmente. Perseguirla como si fuera determinista es frustrante; reconocerla como una cola de la distribución te apunta hacia las soluciones reales: un prompt más claro, una temperatura más baja, o salvaguardas que atrapen la mala rama cuando ocurre.

Diseñar para la variación en lugar de pelear contra ella

El enfoque maduro es ajustar tus configuraciones y tu diseño a tu tarea. Para cualquier cosa que necesite un resultado consistente y estructurado —una clasificación, una extracción de datos, un formato fijo— baja la aleatoriedad y valida la forma de la salida en lugar de confiar en ella a ciegas. Para cualquier cosa que se beneficie del rango —redacción, lluvia de ideas, conversación— permite más variación y abraza la diversidad como el objetivo.

Donde la corrección es crítica, no confíes en que una sola llamada sea correcta. Construye comprobaciones a su alrededor: valida que la salida cumple tus requisitos, y reintenta o recurre a una alternativa cuando no lo haga. Y siempre que decidas si un prompt es lo bastante bueno para desplegar, júzgalo por múltiples ejecuciones, no por un resultado afortunado. La variación es una propiedad del medio; los sistemas que aguantan son los diseñados teniéndola en cuenta en lugar de sorprenderse por ella.

En resumen

Dos ejecuciones del mismo prompt difieren porque la generación muestrea cada token de una distribución de probabilidad en lugar de elegir una respuesta fija, y las pequeñas diferencias tempranas se acumulan. Esa aleatoriedad es deliberada: hace la salida menos plana y más útil para el trabajo creativo. La temperatura es la perilla que la sube o la baja, pero incluso en su mínimo, la repetibilidad perfecta bit a bit no está garantizada. Así que prueba con múltiples ejecuciones, baja la aleatoriedad cuando necesites consistencia, valida las salidas críticas en lugar de confiar en una sola llamada, y diseña las funciones en torno a la variación en lugar de contra ella. El comportamiento no es un fallo que eliminar; es una propiedad que gestionar.