¿Por qué una IA me da respuestas distintas cada vez que le hago la misma pregunta?

Un cliente me escribió hace unas semanas casi indignado: le había pedido a ChatGPT que le resumiera el mismo documento dos veces, con la pregunta copiada y pegada, letra por letra, y le había dado dos resúmenes distintos. Pensaba que la herramienta estaba rota. No lo está. Funciona así por diseño, y a mí también me costó asumirlo la primera vez que montamos una integración con un modelo para un cliente y los resultados no salían repetibles en las pruebas.

Un programa normal es determinista: misma entrada, misma salida, siempre. Una hoja de cálculo no tiene días buenos ni malos. Un modelo de lenguaje no funciona así por dentro. Cuando genera texto, en cada paso calcula una lista de palabras candidatas con una probabilidad asignada a cada una, y elige una de entre las más probables, no siempre la más probable, sino una muestreada al azar dentro de ese abanico. Eso se controla con un parámetro que casi todas las APIs exponen, llamado “temperature”: más alto, más variedad (y más riesgo de irse por las ramas); más bajo, o directamente a cero en algunos modelos, respuestas mucho más parecidas entre sí, aunque casi nunca al cien por cien idénticas. En una frase: una IA da respuestas distintas a la misma pregunta porque no elige siempre la palabra más probable, sino que muestrea entre varias candidatas según ese parámetro de aleatoriedad, así que cierta variación no es un fallo, es parte del diseño.

¿Por qué diseñarlo así, si genera esta sensación de poca fiabilidad? Porque el mismo mecanismo que hace que dos resúmenes salgan distintos es el que permite que el modelo no suene siempre igual, que complete una frase de forma natural en vez de repetir la combinación de palabras estadísticamente más plana una y otra vez. Sin esa aleatoriedad un chatbot sonaría a máquina de verdad, no a algo que imita una conversación con soltura.

El problema aparece cuando alguien, nosotros incluidos la primera vez, usa un modelo para una tarea que sí necesita ser determinista. Montamos para un cliente una automatización que leía facturas en PDF y extraía importe, fecha y proveedor con un LLM. En las pruebas funcionaba bien. En producción, de vez en cuando el mismo tipo de factura, con el mismo formato exacto, daba un campo mal leído que la vez anterior había salido perfecto. No era un bug de nuestro código: era el modelo siendo modelo. Bajamos la temperatura al mínimo y añadimos una validación posterior con reglas fijas, que el importe tenga formato numérico, que la fecha exista de verdad, y el problema mejoró mucho. No desapareció del todo. Con estas herramientas, “casi siempre bien” es distinto de “siempre bien”, y hay que diseñar sabiendo cuál de las dos necesitas de verdad para cada pieza del proceso.

Para un uso normal, preguntar algo, pedir ideas, que te ayude a redactar un correo, esta variabilidad no importa nada, incluso ayuda. El problema es cuando alguien monta un proceso automático de negocio dando por hecho que un LLM se comporta como una fórmula de Excel. No lo hace. Cuanto antes lo tengas claro al diseñar la automatización, menos sustos con datos raros vas a llevarte seis meses después de haberla puesto a funcionar sola.