Por que unha IA me dá respostas distintas cada vez que lle fago a mesma pregunta?

Un cliente escribiume hai unhas semanas case indignado: pedíralle a ChatGPT que lle resumise o mesmo documento dúas veces, coa pregunta copiada e pegada, letra por letra, e deralle dous resumos distintos. Pensaba que a ferramenta estaba rota. Non o está. Funciona así por deseño, e a min tamén me custou asumilo a primeira vez que montamos unha integración cun modelo para un cliente e os resultados non saían repetibles nas probas.

Un programa normal é determinista: mesma entrada, mesma saída, sempre. Unha folla de cálculo non ten días bos nin malos. Un modelo de linguaxe non funciona así por dentro. Cando xera texto, en cada paso calcula unha lista de palabras candidatas cunha probabilidade asignada a cada unha, e escolle unha de entre as máis probables, non sempre a máis probable, senón unha mostreada ao chou dentro dese abano. Iso contrólase cun parámetro que case todas as API expoñen, chamado “temperature”: canto máis alto, máis variedade (e máis risco de irse polas ramas); canto máis baixo, ou directamente a cero nalgúns modelos, respostas moito máis parecidas entre si, aínda que case nunca ao cen por cen idénticas. En unha frase: unha IA dá respostas distintas á mesma pregunta porque non escolle sempre a palabra máis probable, senón que mostrea entre varias candidatas segundo ese parámetro de aleatoriedade, así que certa variación non é un fallo, é parte do deseño.

Por que deseñalo así, se xera esta sensación de pouca fiabilidade? Porque o mesmo mecanismo que fai que dous resumos saian distintos é o que permite que o modelo non soe sempre igual, que remate unha frase de forma natural en vez de repetir a combinación de palabras estatisticamente máis plana unha e outra vez. Sen esa aleatoriedade un chatbot soaría a máquina de verdade, non a algo que imita unha conversa con soltura.

O problema aparece cando alguén, nós incluídos a primeira vez, usa un modelo para unha tarefa que si precisa ser determinista. Montamos para un cliente unha automatización que lía facturas en PDF e extraía importe, data e provedor cun LLM. Nas probas funcionaba ben. En produción, de cando en vez o mesmo tipo de factura, co mesmo formato exacto, daba un campo mal lido que a vez anterior saíra perfecto. Non era un bug do noso código: era o modelo sendo modelo. Baixamos a temperatura ao mínimo e engadimos unha validación posterior con regras fixas, que o importe teña formato numérico, que a data exista de verdade, e o problema mellorou moito. Non desapareceu de todo. Con estas ferramentas, “case sempre ben” é distinto de “sempre ben”, e hai que deseñar sabendo cal das dúas precisas de verdade para cada peza do proceso.

Para un uso normal, preguntar algo, pedir ideas, que che axude a redactar un correo, esta variabilidade non importa nada, ata axuda. O problema é cando alguén monta un proceso automático de negocio dando por feito que un LLM se comporta como unha fórmula de Excel. Non o fai. Canto antes o teñas claro ao deseñar a automatización, menos sustos con datos raros vas levar seis meses despois de poñela a funcionar soa.