Cómo funcionan los chatbots de IA: tokens, contexto y olvido

Un chatbot no lee tus palabras tal como las escribiste, y no recuerda una conversación como lo hace una persona. Lee pequeños fragmentos llamados tokens (unidades de texto en que se divide la entrada), mantiene un número limitado de ellos en una ventana de contexto y construye cada respuesta de token en token. La mayor parte del comportamiento extraño en los chats largos, desde instrucciones que se pierden hasta un dato que pasa inadvertido en un documento, se deriva de esos tres hechos.

Tokens: las piezas que un modelo lee realmente

Antes de que un modelo procese una instrucción (prompt), un programa llamado tokenizador divide el texto en tokens. OpenAI describe un token como la unidad que utilizan sus modelos para procesar texto. Un token puede representar un carácter, parte de una palabra, una palabra entera o un signo de puntuación, y los espacios afectan a cómo se divide el texto.

Esa división no equivale a un recuento de palabras. Las palabras cortas comunes suelen caber en un token. Las palabras más largas o menos frecuentes se rompen en varios. En una explicación para los modelos de OpenAI, “apple” es un token, mientras que “hamburger” son tres: “ham”, “bur” y “ger”. Las mayúsculas y el espaciado también importan. OpenAI señala que “red”, “Red” y una versión con un espacio inicial pueden representarse de forma diferente. Google ofrece la misma imagen para los modelos Gemini: un token puede ser un único carácter como “z” o una palabra entera como “cat”, y el conjunto completo de tokens que un modelo puede usar es su vocabulario.

Para una planificación aproximada en inglés, las dos empresas ofrecen reglas prácticas similares:

• OpenAI: 1 token equivale a unos 4 caracteres, a unas tres cuartas partes de una palabra, y 100 tokens equivalen a unas 75 palabras.
• Google, para los modelos Gemini: 1 token equivale a unos 4 caracteres, y 100 tokens equivalen a unas 60 a 80 palabras en inglés.

Ambas empresas subrayan que son estimaciones. El mismo texto puede producir recuentos diferentes en modelos distintos, y otros idiomas difieren. Los tokens no son solo texto. Google señala que toda la entrada y salida de Gemini se tokeniza, incluidas las imágenes a 258 tokens para una imagen de hasta 384 píxeles en ambas dimensiones (las imágenes más grandes se dividen en mosaicos de 258 tokens por mosaico de 768 por 768), el vídeo a 263 tokens por segundo y el audio a 32 tokens por segundo. Un archivo grande puede, por tanto, usar mucha más parte de una ventana de lo que sugieren las palabras visibles.

De token en token: cómo se construye una respuesta

Un chatbot no recupera de una base de datos una respuesta terminada. La genera, token a token.

En cada paso, el modelo considera los tokens que tiene hasta el momento y produce posibles tokens siguientes con pesos asociados. Se muestrea un token de esa lista, y los tokens con mucho peso tienen más probabilidades de ser elegidos que los que tienen poco peso. Ese nuevo token se añade a la secuencia, y todo el proceso se repite. La generación se detiene cuando se alcanza un límite de longitud o cuando el modelo produce un token especial de parada.

Este bucle explica dos rasgos familiares. Las respuestas pueden diferir entre ejecuciones de la misma instrucción, porque el muestreo no siempre escoge el único token con mayor peso. Y un tono seguro no es prueba de exactitud: el proceso selecciona en favor de una continuación plausible, de modo que la salida puede sonar fluida y seguir siendo errónea. OpenAI también distingue los tokens de entrada (suministrados en una solicitud), los tokens de salida (generados por el modelo) y los tokens de razonamiento, que algunos modelos usan internamente antes de una respuesta visible. Los tokens de razonamiento no se muestran, pero cuentan para el uso de salida, así que una respuesta corta puede usar más tokens de lo que sugiere su texto.

La ventana de contexto: memoria de trabajo con un borde duro

La ventana de contexto es el límite de cuántos tokens puede manejar un modelo en una solicitud. OpenAI lo dice con claridad: la ventana limita los tokens en una solicitud, y los modelos también tienen un límite de salida separado. La ventana debe albergar las instrucciones del sistema, la conversación hasta el momento, cualquier archivo suministrado, los resultados de herramientas y espacio para la respuesta, incluidos los tokens de razonamiento.

El tamaño varía según el modelo y el producto. La página de soporte de Anthropic, actualizada el 7 de octubre de 2026, dice que, fuera de sus modelos más recientes enumerados, la ventana de contexto de Claude en los planes de chat de pago es de 200,000 tokens, unas 500 páginas de texto o más. Muchos modelos más recientes enumerados allí se muestran con 500,000 o 1 millón de tokens, dependiendo de si la superficie es el chat, Claude Code o Claude Cowork. Por tanto, una cifra destacada para un producto no se aplica automáticamente a otro.

Una ventana más grande ayuda a hacer caber un documento o una conversación larga en una solicitud. No crea memoria permanente. Cuando empieza un chat nuevo, la conversación anterior no está en la nueva ventana a menos que el producto la traslade, por ejemplo como un resumen. Lo que parece memoria entre turnos dentro de un chat es que los turnos anteriores se suministran de nuevo como contexto para la siguiente respuesta.

Cuando una conversación se acerca al límite, los productos gestionan el desbordamiento de manera diferente. Anthropic dice que, para los planes de pago con ejecución de código activada, Claude resume automáticamente los mensajes anteriores para hacer sitio, y que el historial completo se conserva como referencia tras el resumen. Un resumen es una compresión, sin embargo: los nombres, los números exactos y las condiciones pequeñas corren riesgo cuando un intercambio largo se convierte en una recapitulación breve. OpenAI ofrece un consejo similar para entradas demasiado grandes: acorta la instrucción, elimina el contexto repetido, divide las entradas grandes o resume el material primero.

Por qué los chats largos olvidan, y por qué importa el medio

El olvido dentro de un chat largo suele tener una de tres causas. El material inicial salió de la ventana o fue sustituido por un resumen. Sigue presente, pero una instrucción posterior entra en conflicto con él. O está presente y no se contradice, pero el modelo no lo usa bien.

Esa tercera causa tiene un nombre medido: perdido en el medio (lost in the middle). En una investigación de Liu y colegas, publicada en TACL en 2024, se dio a los modelos una pregunta junto con 10, 20 o 30 pasajes recuperados, de los que solo uno contenía la respuesta. Los investigadores movieron ese único pasaje a diferentes posiciones y no cambiaron nada más.

La exactitud formó una U. Con 20 documentos, GPT-3.5-Turbo respondió correctamente alrededor del 75.8% de las veces cuando el pasaje de la respuesta iba primero, el 63.2% cuando iba el último y el 53.8% cuando estaba en el medio. Su puntuación sin ningún documento fue del 56.1%, de modo que en la posición central, suministrar el pasaje de la respuesta produjo un resultado ligeramente peor que no suministrar nada. En ese estudio, unas ventanas de contexto más grandes no corrigieron el patrón para entradas que cabían en ambas versiones, y aumentar el conjunto de 20 a 50 documentos mejoró ese modelo solo en aproximadamente un 1.5%.

Los modelos más recientes lo hacen mejor en pruebas sencillas de recuperación, y el efecto varía según la tarea. La lección práctica sigue configurando las orientaciones de los proveedores. Los consejos de Anthropic para contextos largos, tal como se resumen en la cobertura del estudio, recomiendan colocar los documentos largos por encima de la consulta, y señalan que una consulta al final puede mejorar la calidad hasta en un 30% en las pruebas de Anthropic con entradas complejas de varios documentos.

Cómo trabajar con la ventana en lugar de contra ella

Algunos hábitos se derivan directamente del mecanismo:

• Coloca las instrucciones clave al inicio de una instrucción larga, y repite la tarea y la restricción clave de nuevo al final, cerca de la pregunta.
• Mantén la instrucción tan breve como permita la tarea. Elimina los antecedentes repetidos, los borradores antiguos y los documentos que la respuesta no necesita.
• Para un documento largo, pregunta por secciones específicas y cita el pasaje al que te refieres, en lugar de suponer que se usará un dato enterrado en el medio.
• En un chat muy largo, repite los nombres, números y decisiones que importan en lugar de confiar en que un mensaje inicial o un resumen automático los conserven exactamente.
• Empieza un chat nuevo para una tarea nueva. Arrastrar un historial largo y sin relación desperdicia espacio de ventana y añade instrucciones competidoras.
• Comprueba la salida importante frente a una fuente externa. La generación produce texto fluido, no texto verificado.

Conclusión

Un chatbot lee tokens, no palabras, a razón de aproximadamente 4 caracteres o tres cuartas partes de una palabra por token en inglés. Escribe muestreando de token en token, y solo puede usar lo que cabe en su ventana de contexto para esa solicitud. Cuando un chat largo parece olvidar, la causa suele ser una ventana llena, un resumen que dejó caer un detalle o un dato clave situado en el medio de una instrucción larga. Unas instrucciones más breves, unas restricciones repetidas y el material clave colocado cerca del principio o del final trabajan con ese diseño en lugar de contra él. Y como todo lo que hay en la ventana se envía al servicio, un chat nunca es privado frente a ese propio servicio; una VPN cambia quién puede observar la conexión, no lo que recibe el servicio.