Coffee & Cake: Tokens, contexto y memoria

Lo que cabe en el mostrador

Seguro te ha pasado. Llevas media hora conversando con un asistente, la charla va bien, incluso parece que te conoce: sabe que prefieres respuestas breves, retoma un ejemplo que mencionaste hace un rato. Y de repente ignora algo que le pediste al principio. Que no usara listas, que hablara en tercera persona, que se refiriera a tu proyecto por su nombre. La sensación es incómoda, casi personal. Uno piensa que el asistente se distrajo, o que se volvió menos inteligente a media conversación, o que simplemente no le importa lo que uno dice.

La explicación es bastante menos dramática, y para llegar a ella hay que separar tres cosas que en el uso diario se confunden todo el tiempo. Los tokens, que son las piezas en las que se mide todo. El contexto, que es lo que está sobre el mostrador ahora mismo, en esta petición concreta. Y la memoria del producto, que es material guardado en otro lado y que alguien puede decidir traer de vuelta. Son capas distintas, con reglas distintas. Casi todo lo que parece caprichoso en un asistente se vuelve predecible cuando uno sabe en cuál de esas tres capas está ocurriendo el problema.

Empecemos por las piezas. Antes de que un modelo de lenguaje procese un texto, ese texto se corta en unidades llamadas tokens. No son palabras, aunque a veces coincidan. Una palabra frecuente puede ser un token; una palabra larga o rara puede partirse en tres o cuatro; los signos de puntuación y los espacios también cuentan. La regla de corte la define un componente llamado tokenizador, y no hay una sola: distintos modelos usan esquemas y vocabularios diferentes. Por eso el mismo párrafo puede medir cantidades distintas de tokens según el sistema, y por eso un texto con tildes, un fragmento de código o una lista de nombres propios pueden dividirse de maneras distintas.

Esto tiene una consecuencia práctica que conviene desactivar temprano. Cuando alguien dice que un millón de tokens equivale a tantas páginas de libro, está dando una estimación aproximada, no una equivalencia. Depende del idioma, del tipo de texto y del tokenizador. Sirve para hacerse una idea de la escala. No sirve para calcular con precisión si tu documento va a caber.

El contexto es otra cosa. La ventana de contexto es la capacidad máxima de tokens disponible para una sola invocación del modelo, para un solo turno de trabajo. Y ahí adentro compite todo: las instrucciones del sistema que el producto pone antes de que tú escribas nada, el historial de la conversación, los documentos que se hayan recuperado, los resultados de las herramientas que se hayan usado, tu pregunta nueva y también la respuesta que se está escribiendo. En algunos modelos, además, el razonamiento interno consume de esa misma bolsa. La ventana no es una memoria. Es una superficie de trabajo: el mostrador donde caben los ingredientes de hoy, y nada más.

Y aquí viene la pieza que más cuesta creer. Una conversación no se recuerda: se vuelve a armar. Una petición básica de generación no guarda estado. La continuidad entre turnos se construye enviando otra vez los mensajes anteriores, o con un servicio que mantiene por ti un estado equivalente. Cada vez que escribes, alguien reconstruye el plato completo y lo pone delante del modelo. El modelo no evoca lo que dijiste hace veinte minutos: lo lee de nuevo, porque venía incluido. Si no venía incluido, para el modelo sencillamente no existe.

De ahí sale el olvido que nos desconcertaba al principio. A medida que la conversación crece, puede dejar de caber. Entonces el producto tiene que hacer algo: recortar lo más antiguo, seleccionar solo algunos fragmentos, o resumir tramos enteros para que ocupen menos. Por eso puede desaparecer una instrucción del primer mensaje mientras sobrevive una preferencia de hace tres turnos. No es desinterés ni deterioro. Es selección, y normalmente ocurre sin avisarte.

La memoria del producto es una función aparte, y vive fuera de la invocación del modelo. Un producto puede guardar ciertos datos, resúmenes o conversaciones pasadas en un almacén propio y, más adelante, insertar lo que considere relevante dentro de una petición nueva. Si el contexto es el mostrador, esto es la libreta con etiquetas o la despensa: algo de lo que se puede ir a buscar una cosa concreta cuando hace falta. Cómo se guarda, qué se guarda y cuánto control tienes sobre ello cambia muchísimo de un producto a otro. Algunos te dejan ver y borrar lo almacenado; otros seleccionan material en segundo plano; otros no tienen nada parecido.

Conviene marcar bien esta frontera, porque de aquí nacen dos malentendidos muy comunes. El primero es pensar que una ventana de contexto enorme es lo mismo que memoria a largo plazo. No lo es: una es un límite por petición, la otra es una función externa de guardar y seleccionar. Un sistema con una ventana gigantesca y sin memoria empieza de cero cada vez que abres una conversación nueva. Uno con una ventana modesta y buena memoria puede parecer que te conoce desde hace meses. El segundo malentendido es creer que, si se lo dijiste una vez, el modelo ya lo aprendió. Lo que suele ocurrir es que el producto guardó ese dato y lo vuelve a enviar. Los parámetros del modelo, lo que aprendió durante su entrenamiento, normalmente no cambian porque tú le cuentes algo.

La recuperación de información es otra puerta de entrada al mismo mostrador. El sistema busca en una colección externa, un conjunto de documentos, tus archivos, una base de conocimiento indexada, elige los pasajes que parecen pertinentes y los añade a la consulta. El modelo trabaja con ese texto en esta invocación y puede responder sobre él. Pero no lo aprende. Cierras la conversación y ese conocimiento no se quedó en el modelo: se quedó en la colección, esperando a que alguien vuelva a encontrarlo. Y mientras está sobre el mostrador, ocupa espacio, igual que todo lo demás.

Lo cual lleva a una idea que va contra la intuición: más contexto no es automáticamente mejor. Un contexto relevante y bien organizado rinde más que una ventana llena hasta el borde. Cuando metes cincuenta páginas para que se conteste una pregunta que dependía de un párrafo, la instrucción que de verdad importaba puede quedar diluida entre material irrelevante. Un mostrador donde has vaciado la despensa entera no es un mostrador más útil.

Vale la pena mencionar el almacenamiento en caché, porque también se malinterpreta. Cuando muchas peticiones empiezan igual, con las mismas instrucciones y los mismos documentos, el sistema puede evitar recalcular esa parte repetida. Eso reduce la latencia y suele reducir el precio. Lo que no hace es agrandar la ventana: los tokens en caché siguen ocupando su lugar dentro de la petición. Cambia el trabajo y la factura, no la capacidad, y desde luego no entrena a nadie.

Junta todo y sigue una sola pregunta tuya. Escribes una frase. El producto arma el paquete: sus instrucciones internas, tal vez un par de datos sacados de la memoria guardada, una selección del historial que quizá venga resumido, quizá unos pasajes recuperados de tus documentos, y tu frase al final. Todo eso se convierte en tokens y tiene que caber. El modelo genera la respuesta, que también consume capacidad. Y cuando el turno termina, el mostrador se despeja. Lo único que sobrevive es lo que el producto haya decidido guardar en otro sitio.

Imagina ahora tres productos construidos sobre el mismo modelo. El primero reenvía el historial completo hasta que deja de caber, y entonces corta lo más viejo en silencio. El segundo resume los tramos antiguos: conserva el sentido general y pierde la letra pequeña, así que tu petición de un formato muy específico sobrevive convertida en algo vago, como que el usuario prefiere respuestas concisas. El tercero tiene memoria persistente y busca en tus archivos: parece que te conoce, y de vez en cuando insiste en un dato tuyo que guardó hace medio año y que ya no es cierto. Mismo modelo, tres personalidades. La diferencia no está en la inteligencia, está en la gestión del contexto.

Así que la próxima vez que un asistente olvide algo, cambia la pregunta. En lugar de preguntarte si se volvió tonto, pregúntate tres cosas: si ese dato llegó a guardarse en alguna parte fuera de la conversación, si alguien lo seleccionó para esta petición concreta, y si además cupo. Casi siempre la respuesta está ahí. De paso, eso sugiere hábitos sencillos: repetir la instrucción importante cerca de la pregunta actual en vez de confiar en que sobrevivió veinte turnos, abrir una conversación nueva cuando la vieja está saturada, y decir explícitamente qué quieres que se recuerde cuando el producto ofrezca esa función.

Al final, el cambio de perspectiva es este. Un modelo de lenguaje no es alguien que recuerda o se olvida de ti. Es algo que lee, muy bien, lo que le han puesto delante en ese momento. Lo que llamamos memoria es, en buena medida, el trabajo de quien decide qué poner sobre el mostrador. Y saber eso no vuelve la herramienta menos impresionante. La vuelve mucho más fácil de usar.