¿Qué ocurre cuando el contexto del chatbot llega al límite de tokens?
Cada LLM tiene un context window finito. A medida que la conversación crece, se llega al límite. ¿Qué ocurre entonces y cómo diseñar el sistema para que no rompa en producción?
El límite que muchos ignoran hasta que lo golpean
"200K tokens". Suena a mucho. Y en la mayoría de conversaciones, lo es. Pero en sistemas de producción con conversaciones largas, tool calls con outputs voluminosos y chunks RAG en cada turno, ese límite llega antes de lo esperado. Y cuando llega, si el sistema no está diseñado para manejarlo, la conversación simplemente rompe.
El context window es la memoria de trabajo del LLM durante una sesión. Todo lo que el modelo "ve" tiene que caber ahí: el system prompt, el historial de la conversación, los documentos recuperados por RAG, los resultados de las herramientas y el mensaje actual del usuario. Cuando suma más de lo que cabe, hay que elegir qué descartar — y esa elección tiene consecuencias directas en la calidad de las respuestas.
Qué ocupa el context window y en qué orden
Para diseñar un sistema que gestione el contexto correctamente, primero hay que entender qué piezas lo componen y cuáles crecen durante la sesión:
1. System prompt
FijoSe carga en cada llamada. Contiene el rol, las reglas y los guardrails del agente.
~1.000–5.000 tokens típicos
2. Historial / memoria
CreceLos mensajes anteriores de la conversación. Es la fuente de crecimiento principal.
Crece con cada turno de conversación
3. Chunks RAG
VariableLos top-K fragmentos de documentación recuperados por la query actual.
3–10 chunks × 200–500 tokens cada uno
4. Outputs de tools
VariableEl resultado de cada tool call: resultados de API, consultas a base de datos, etc.
Depende de la herramienta (puede ser muy grande)
5. Input del usuario
VariableEl mensaje actual del usuario.
Normalmente pequeño; puede ser grande en uploads
El culpable habitual del agotamiento del contexto es la capa 2: el historial de la conversación. Cada turno añade tokens que se acumulan. En conversaciones cortas (un asistente de reservas con 5–8 intercambios de Q&A estructurado), 50K tokens son más que suficientes. En conversaciones abiertas y largas, el crecimiento es lineal y predecible — y hay que planificarlo.
La compactación: qué es y cuándo activarla
Cuando el contexto se llena, la solución es la compactación: reducir el volumen de la memoria activa conservando la información más relevante. Hay tres estrategias principales, con diferente nivel de control y complejidad de implementación:
Librerías automáticas
LangChain, LlamaIndex y otros frameworks incluyen gestores de memoria que compactan automáticamente cuando se acerca al límite. Mantienen los mensajes más recientes y los más relevantes semánticamente.
Compactación manual con umbral de coseno
Comparar cada mensaje almacenado contra la query actual mediante distancia coseno en el vector store. Conservar solo los bloques por encima de un umbral de relevancia definido.
Resumen progresivo
En lugar de descartar mensajes, resumirlos con el propio LLM cuando superan cierta longitud. El resumen ocupa menos tokens que el original y preserva la esencia semántica.
Cómo funciona la compactación manual: para cada mensaje almacenado en el historial, se calcula la distancia coseno entre su embedding y el embedding de la query actual. Los mensajes por encima del umbral de relevancia (por ejemplo, distancia coseno > 0.75) se conservan; los que están por debajo se descartan. El resultado es una memoria adaptativa que retiene contexto relevante para la query actual.
Principio de diseño: dimensiona desde el caso de uso
La regla de oro para gestionar el context window: no sobre-provisionas si no lo necesitas. Un bot de reservas para una clínica veterinaria tiene conversaciones estructuradas y predecibles. La mediana de la conversación —sistema + 6–8 intercambios de Q&A + 3 chunks RAG por turno— raramente supera los 50K tokens. Diseñar para 200K porque "total, el modelo lo soporta" es malgastar presupuesto de tokens en cada llamada.
El proceso de dimensionado correcto:
- 1Analiza conversaciones reales (o simula un conjunto representativo) para conocer la distribución de longitudes.
- 2Identifica el percentil 95: el 95% de las conversaciones cabe en X tokens. Diseña para ese límite.
- 3Implementa compactación para el 5% de conversaciones largas (outliers).
- 4Monitoriza el consumo de tokens en producción y ajusta.
Sobre-provisionar el context window no es gratis: en LLMs como GPT-4 o Claude, el coste se calcula por token consumido, incluyendo los tokens del contexto de entrada. Una ventana innecesariamente grande en miles de conversaciones diarias puede multiplicar el coste de infraestructura sin ningún beneficio funcional.
Resumen rápido
El context window es la memoria de trabajo del LLM
Todo lo que el modelo ve en una sesión debe caber ahí: system prompt, historial, chunks RAG, tool outputs y el mensaje actual. El historial es el componente que más crece.
La compactación es inevitable en conversaciones largas
Cuando el contexto se llena, hay que decidir qué descartar. Las librerías automáticas lo hacen sin configuración; la compactación manual con distancia coseno da más control.
Dimensiona desde tu caso de uso, no desde el máximo del modelo
Conoce la longitud mediana de tus conversaciones. Diseña para el percentil 95. El sobre-provisionamiento desperdicia presupuesto de tokens en producción.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.