Escenario ilustrativo. Un cliente le pregunta dos veces en una misma mañana al agente de soporte si puede devolver un pedido a los 40 días. A las 9:10 el agente responde: «Sí, tienes 60 días». A las 11:30, con las mismas palabras, responde: «Según tu pedido, el plazo es de 30 días; contacta con un asesor». Las dos respuestas suenan razonables, las dos las ha generado el mismo sistema y una de ellas está a punto de convertirse en una reclamación. Nadie ha tocado nada entre una y otra.
La tesis en una línea: la variabilidad de un modelo no es un fallo que se arregla, es una propiedad que se acota. Decides qué partes del proceso no pueden variar nunca, cuáles toleran variación y cómo la mides antes de que la vea un cliente.
¿Por qué la IA responde distinto a la misma pregunta?
Porque un modelo de lenguaje no recupera una respuesta guardada: la calcula cada vez. En cada paso reparte probabilidades entre las palabras posibles y elige una, y esa elección lleva un componente de azar por diseño; el parámetro que lo regula se llama temperatura. Por eso la misma pregunta puede dar redacciones distintas y, cuando la pregunta deja huecos, conclusiones distintas.
Hay tres fuentes más de variación que se suelen olvidar. La primera es lo que rodea a la pregunta: el orden en que el sistema recupera documentos, la fecha, el historial o la memoria cambian el contexto y, con él, la respuesta. La segunda es el servidor: incluso con la temperatura a cero, la mayoría de los servicios de inferencia no garantizan resultados idénticos, porque el cálculo numérico depende de la carga que tenga el servidor en ese momento (Thinking Machines, 2025). La tercera es el proveedor: un cambio de versión del modelo o de sus ajustes mueve el comportamiento sin que tú toques nada, el mismo efecto que explicamos en por qué empeora un agente con el tiempo si nadie ha cambiado nada.
¿Se puede eliminar la variabilidad bajando la temperatura?
A medias, y tampoco conviene del todo. Bajar la temperatura reduce la dispersión en la redacción, pero no la elimina (la fuente de arriba explica por qué), y no cambia ni lo que el modelo sabe ni lo que le llega. Tampoco corrige el error: a temperatura baja, un modelo equivocado se equivoca de forma más consistente. Lo desarrollamos en reducir alucinaciones de IA en producción. Además, cierta variación es justo lo que quieres: es lo que permite que un resumen o una respuesta se adapte al caso en lugar de sonar a plantilla.
La pregunta útil no es «¿cómo consigo que responda siempre igual?», sino «¿en qué puntos del proceso no puede responder distinto?».
¿Qué partes de un proceso deben ser deterministas y cuáles toleran variación?
La regla: lo que el cliente puede citar, y lo que mueve dinero o compromisos, no sale de la generación libre. Sale de una regla, de un dato o de una plantilla; el modelo, como mucho, lo redacta.
| Parte del proceso | ¿Tolera variación? | Dónde debe vivir |
|---|---|---|
| Plazos, importes, condiciones, fechas | No | En un dato de tu sistema o en una regla de código; el modelo lo cita, no lo calcula |
| Decisión de enrutado o clasificación | Poca | Salida cerrada (una lista de categorías), umbral de confianza y revisión de los casos dudosos |
| Redacción, tono, resumen | Sí | En las instrucciones y los ejemplos; el modelo tiene margen dentro de ellos |
| Acciones con efecto (enviar, cobrar, borrar) | No | En una validación determinista antes de ejecutar y en permisos acotados |
Si casi todo tu proceso cae en las filas del «No», quizá no necesitas un agente: un flujo clásico es más barato y más fácil de auditar, como explicamos en cómo automatizar procesos con agentes, no con chatbots. Y lo que sí le dejas al modelo se define en sus instrucciones: qué debe citar, qué no puede afirmar y qué hace cuando no tiene el dato.
¿Cómo se mide la variabilidad de un agente antes de ponerlo en producción?
Con una prueba aburrida y repetible. Es un método, no una cifra mágica:
- Reúne casos reales. Un conjunto de entradas de tu operación, con las ambiguas y las raras incluidas, no las de la demo.
- Repítelos. Pasa cada entrada varias veces por el sistema completo (con su recuperación de documentos, no solo el modelo) y guarda cada salida.
- Compara lo que importa. En los campos de decisión (categoría, importe, sí o no), exige coincidencia exacta. En el texto, compara con una rúbrica: ¿dice lo mismo en lo sustancial?
- Fija un umbral por campo. Un campo que mueve dinero tolera cero discrepancias; un resumen interno tolera más. Decide los umbrales antes de mirar los resultados.
- Repite la prueba con cada cambio. Modelo nuevo, instrucciones nuevas, fuente de documentos nueva: se vuelve a pasar.
Esa prueba es una eval, y diseñarla y mantenerla es parte de evaluar la calidad de los agentes de IA. Una vez el agente está en marcha, el siguiente paso es medir el rendimiento de tus automatizaciones, para que la variación no se te cuele de noche.
¿Qué haces si dos respuestas contradictorias ya han llegado a un cliente?
Primero, reconstruye qué pasó: sin el registro de la entrada, el contexto recuperado, la versión del modelo y la salida, no puedes saber cuál de las dos fue la correcta. Después, cierra el hueco:
- Saca el dato del texto libre. Si la contradicción era un plazo o una condición, deja de generarlo: que lo lea de una fuente única.
- Haz que el sistema se contraste a sí mismo. Para las respuestas de riesgo, genera dos veces y, si no coinciden en lo sustancial, no se envía: pasa a una persona. Cuesta más por respuesta, así que resérvalo para donde el error sale caro.
- Ajusta la autonomía al riesgo. Lo que no puede variar y no puedes validar automáticamente, que lo revise un humano antes de salir. Para eso sirven los niveles de autonomía de un agente y el humano en el bucle.
¿Cuándo no merece la pena perseguir la consistencia?
Cuando la salida es un borrador que una persona va a leer y retocar, cuando el error es barato y reversible, o cuando la variación es el valor (ideas, variantes de un texto). Exigir cero variación ahí encarece el sistema sin proteger a nadie. Gasta el rigor donde una respuesta distinta cuesta dinero o confianza, y deja respirar el resto.
La línea para llevarte: no le pidas al modelo que sea siempre igual; diseña el proceso para que lo que no puede cambiar no dependa de él.
Fuentes (consultadas el 29 de octubre de 2026): «Defeating Nondeterminism in LLM Inference», Thinking Machines Lab (10 de septiembre de 2025), usada de forma cualitativa. El escenario de apertura es ilustrativo.