Cuando un proveedor de IA te dice que un modelo tiene "una ventana de contexto de 128.000 tokens", es una cifra que suena impresionante pero que resulta difícil de traducir a algo útil si no sabes qué es exactamente un token. Ya hemos explicado en este blog qué es la ventana de contexto de un modelo de IA desde el punto de vista del impacto en el negocio y las preguntas que hacer a un proveedor. Este artículo se centra en la unidad concreta que hay detrás de esa cifra: el token, y en cómo se va consumiendo la ventana a lo largo de una conversación larga con un agente de IA.
Entender esta mecánica te sirve para algo muy práctico: poder calcular, con tus propios documentos y conversaciones reales, si el context window de un LLM propuesto por un proveedor realmente encaja con tu volumen de trabajo, en lugar de fiarte de una cifra grande sin más contexto.
Qué es un token exactamente
Un token es la unidad mínima de texto que procesa un LLM (modelo de lenguaje de gran tamaño). No equivale exactamente a una palabra: puede ser una palabra corta completa, un fragmento de una palabra larga, un signo de puntuación o incluso un espacio. Como referencia aproximada, en español un token suele equivaler a algo menos de una palabra completa, así que un texto de cien palabras puede convertirse en unos ciento treinta o ciento cuarenta tokens, dependiendo de la longitud de las palabras usadas.
El context window de un LLM se mide en la suma de tokens de entrada (lo que le envías: la pregunta, el documento, el historial de la conversación) más los tokens de salida (lo que el modelo genera como respuesta). Todo eso junto no puede superar el límite del modelo. Si tu documento y tu pregunta ya ocupan el noventa por ciento del límite, al modelo le queda muy poco margen para generar una respuesta completa.
Cómo se va llenando la ventana de contexto en una conversación
En una conversación de varios turnos con un agente de IA, cada nuevo mensaje no sustituye al anterior: se añade a todo lo que ya se había enviado antes, porque el modelo necesita "releer" toda la conversación previa para mantener la coherencia. Esto significa que el consumo de tokens no crece de forma lineal y previsible para el usuario, sino que se acumula turno tras turno, muchas veces sin que la persona que escribe sea consciente de ello.
Imagina una conversación de soporte que empieza con una pregunta corta y se va alargando durante veinte o treinta mensajes, con el cliente pegando capturas de pantalla en texto, fragmentos de correos anteriores y aclaraciones. Cada uno de esos mensajes se suma al total acumulado. Llegado un punto, la conversación completa puede ocupar una parte muy grande del context window disponible, dejando cada vez menos margen para que el modelo razone y responda con la calidad esperada.
Qué pasa cuando se supera el límite de tokens?
Cuando una conversación o un documento supera el límite de tokens del context window, ocurre una de dos cosas, según cómo esté configurado el sistema: o bien la petición falla directamente con un error, o bien el sistema recorta automáticamente parte del contenido, normalmente los mensajes más antiguos de la conversación, para hacer sitio a lo nuevo. En ambos casos, el resultado práctico es el mismo: información que el usuario cree que el sistema todavía "recuerda" desaparece sin previo aviso.
Este comportamiento explica un fallo muy habitual en agentes de atención al cliente basados en IA: un cliente da un dato importante al principio de una conversación larga (un número de pedido, una fecha, una condición especial) y, muchos mensajes después, el agente actúa como si nunca se lo hubiera dicho. No es un fallo de "inteligencia" del modelo, sino una consecuencia directa de haber superado, en algún punto, el límite de su context window.
Estrategias para no quedarte sin ventana de contexto
Hay varias formas de gestionar este límite en un sistema bien diseñado, y conviene preguntar a tu proveedor cuál de ellas aplica en tu proyecto:
- Resumen progresivo: el sistema resume automáticamente los tramos más antiguos de la conversación en lugar de descartarlos sin más, conservando la información esencial en menos tokens.
- Ventana deslizante: se mantienen solo los últimos mensajes relevantes, descartando el resto, adecuado para conversaciones donde el histórico lejano importa poco.
- Recuperación selectiva (RAG): en lugar de meter todo el historial o todo un documento largo dentro del context window, el sistema busca solo los fragmentos relevantes para la pregunta actual y los añade puntualmente, algo que explicamos en detalle en qué es RAG.
- Memoria externa persistente: los datos importantes (nombre del cliente, historial de pedidos, preferencias) se guardan fuera del context window, en una base de datos, y se inyectan solo cuando hacen falta, en lugar de arrastrarlos en cada turno de la conversación.
Cómo calcular si un LLM tiene suficiente context window para tu caso?
Para calcularlo con algo de precisión, toma el documento o la conversación más larga que necesitas que el sistema maneje de una sola vez, y estima su número de tokens (como referencia rápida, cuenta las palabras y multiplícalas por 1,3 para español). Súmale un margen razonable para la respuesta que esperas que genere el modelo, y compara ese total con el límite de context window que ofrece el LLM propuesto.
Es importante no calcularlo solo con el caso típico, sino con el caso más exigente que puede darse en tu negocio: el contrato más largo, la conversación de soporte más enrevesada, el histórico de cliente más extenso. Un sistema que funciona bien en la demo con ejemplos cortos puede fallar en producción justo con los casos reales más complejos, que suelen ser también los más importantes para el cliente.
Por qué el español consume más tokens que el inglés
Un detalle que sorprende a muchas empresas es que un mismo texto no siempre ocupa el mismo número de tokens en distintos idiomas. La mayoría de los modelos se entrenan con una proporción muy alta de contenido en inglés, y el proceso interno que divide el texto en tokens tiende a estar más optimizado para ese idioma. Como resultado, un texto en español puede consumir más tokens que su equivalente exacto en inglés, simplemente por cómo se fragmentan las palabras con tildes, eñes o construcciones gramaticales propias del castellano.
Esta diferencia, aunque parezca menor, tiene un efecto acumulativo real: si tu empresa trabaja exclusivamente en español, el context window efectivo del que dispones puede rendir algo menos, en número de palabras reales, de lo que sugiere la cifra de tokens anunciada por el proveedor. Merece la pena tenerlo en cuenta al comparar modelos, y no limitarse a comparar el número de tokens anunciado sin traducirlo a palabras reales de tu idioma de trabajo.
Por qué esto le importa a una empresa
El context window de un LLM no es solo una especificación técnica de una ficha de producto: determina directamente qué tipo de trabajo puede automatizar tu empresa sin fricciones. Un despacho que necesita que un agente revise contratos largos, un servicio de atención al cliente con conversaciones que se alargan durante días, o un sistema que tiene que cruzar varios documentos a la vez, necesitan un context window generoso y, sobre todo, una estrategia clara para gestionarlo cuando se acerque al límite.
Además, el coste por consulta suele crecer con la cantidad de tokens procesados, así que un sistema mal diseñado que reenvía todo el historial completo en cada turno, cuando solo hacía falta una parte, no solo arriesga perder información: también encarece la factura de IA de forma innecesaria, mes tras mes.
Cómo lo trabajamos en MG Solutions
En MG Solutions dimensionamos el context window necesario para cada proyecto a partir de tus documentos y conversaciones reales, no de una demo genérica, y diseñamos estrategias de resumen, recuperación selectiva o memoria externa cuando el volumen de tu negocio lo requiere. Si quieres que revisemos si el LLM que estás valorando encaja con tu caso de uso real, puedes contarnos tu proyecto en nuestro apartado de contacto.