Le mandás el mismo texto dos veces a un modelo y las respuestas no coinciden. O le pegás un documento larguísimo y, más adelante, se "olvida" de una instrucción que le diste al principio. Ninguna de las dos cosas es un fallo raro: salen de cómo está construido. Con unas pocas ideas se entiende bastante.
Todo empieza por los tokens
Un modelo no lee letras ni palabras completas. Antes de procesar tu texto, un componente lo corta en tokens: fragmentos que pueden ser una palabra corta, parte de una palabra larga, un signo de puntuación o un espacio. Una palabra común del idioma suele ser un solo token; una poco frecuente, un nombre propio o un identificador de código se parten en varios.
Esto tiene consecuencias concretas. El límite de lo que podés enviar y recibir se mide en tokens, no en caracteres. El costo y la velocidad de las llamadas suelen depender de esa misma cuenta. Y cosas que a una persona le parecen triviales, como contar las letras de una palabra, se vuelven difíciles para el modelo, porque él nunca vio la palabra letra por letra sino como piezas.
Como regla práctica, el mismo contenido ocupa más tokens en español que en inglés, porque los modelos suelen estar optimizados para este último. No hace falta saber el número exacto, alcanza con saber que existe esa diferencia.
Predecir el próximo fragmento
El mecanismo central es sencillo de enunciar: dado el texto que hay hasta ahora, el modelo calcula qué token es más probable que venga después. Elige uno, lo agrega al texto y repite. Una respuesta de varios párrafos es esa operación aplicada muchas veces seguidas.
Pensalo como el autocompletado del teclado del celular, pero entrenado con una cantidad enorme de texto y con una capacidad muchísimo mayor de tener en cuenta lo que dijiste antes. No hay una base de hechos consultada por debajo. Hay una distribución de probabilidades sobre qué viene después, y de ahí sale todo, lo correcto y lo inventado.
Por qué la misma pregunta da respuestas distintas
Si el modelo eligiera siempre el token más probable, la respuesta sería idéntica cada vez. Pero se suele muestrear entre varias opciones plausibles, y eso se controla con un parámetro llamado temperatura.
- Con temperatura baja, el modelo se queda casi siempre con las opciones más probables. Las respuestas son más previsibles y repetibles. Sirve para extraer datos o clasificar.
- Con temperatura alta, da más lugar a opciones menos probables. Las respuestas varían más y suenan menos rígidas. Sirve para proponer nombres o redactar variantes.
Incluso con temperatura en cero, algunos servicios no garantizan salidas idénticas bit a bit, así que si necesitás consistencia estricta, no la des por hecha: validá la salida.
La ventana de contexto
El modelo solo "ve" lo que cabe en su ventana de contexto: el conjunto de tokens que le llegan en una llamada, contando tus instrucciones, los documentos que adjuntes, el historial de la conversación y la respuesta que está generando. Lo que queda afuera no existe para él.
Imaginalo como un escritorio de tamaño fijo. Podés apilar papeles hasta que se llene; si seguís agregando, algo tiene que salir. En una conversación larga, las versiones más viejas del historial se recortan o se resumen, y por eso a veces parece que "se olvidó". En realidad nunca lo recordó: cada llamada empieza de cero con lo que vos (o tu aplicación) le reenviás.
Incluso dentro del límite, no todo el contexto pesa igual. Con textos muy largos, los detalles perdidos en el medio pueden tener menos influencia que lo que está al principio o al final. Conviene poner las instrucciones importantes en un lugar visible y repetirlas si hace falta.
Lo posterior a su entrenamiento
El modelo aprendió de textos hasta cierta fecha de corte. Lo que pasó después no está en sus parámetros: una librería que cambió de interfaz, una norma nueva, el resultado de un partido de la semana pasada. Si se lo preguntás, puede responder con lo último que conoce, o con una invención verosímil.
La solución habitual no es reentrenarlo sino pasarle la información actual dentro del contexto: pegás el fragmento de documentación vigente y le pedís que responda en base a eso. El modelo es muy bueno para trabajar con lo que tiene adelante y bastante peor para recordar lo que no.
Qué te llevás para trabajar
Medí en tokens, no en palabras. Esperá variación y diseñá para tolerarla. Mandá todo lo que el modelo necesite saber en cada llamada, porque no guarda memoria entre una y otra. Y recordá que sigue siendo, por debajo, un predictor de texto muy bueno: cuando le das buen material para continuar, rinde mucho más que cuando le pedís que adivine.