Ya viste el número en cada anuncio de lanzamiento de modelos. 128K tokens. 200K tokens. 1M tokens. La implicación siempre es la misma: más grande es mejor, más contexto significa outputs más inteligentes, y eventualmente esta limitación desaparece por completo.
Ese enfoque es incompleto. Entender cómo los límites del LLM context window afectan los sistemas que construyes no se trata de seguir el número; se trata de entender qué restricciones estás diseñando y qué te obligan a hacer diferente. Eso sigue siendo cierto incluso con ventanas muy grandes.
El modelo mental que la mayoría de los ingenieros tiene mal
El modelo mental por defecto trata el context window como RAM: tienes una cantidad fija, la llenas, y obtienes un error o rendimiento degradado cuando la superas. Eso es parcialmente correcto, pero omite algo importante.
La capacidad del context window y la efectividad del context window no son lo mismo. Los modelos no procesan todos los tokens por igual. El contenido al principio y al final de un contexto largo generalmente se recupera de forma más confiable que el contenido enterrado en el medio, un fenómeno documentado en investigaciones y conocido comúnmente como "lost in the middle." Esto significa que una ventana de contexto de 200K tokens no te da 200K tokens de recuperación igualmente confiables. Te da un gradiente.
Lo segundo que los ingenieros suelen subestimar: el costo y la latencia escalan con el contexto. Enviar 100K tokens a un modelo en cada request tiene una economía real asociada. Si tu sistema procesa miles de requests por hora, la eficiencia de contexto de cada request no es una optimización; es un modelo de costos. Los ingenieros que aprenden esto de una factura de uso en lugar de un primer principio generalmente desearían haberlo pensado antes.
Lo tercero: el prompt caching. La mayoría de los proveedores principales ahora ofrecen prompt caching para contexto repetido. Si estás estructurando tus prompts de forma descuidada, mezclando instrucciones del sistema con contenido dinámico, reconstruyendo el contexto desde cero en cada llamada, estás pagando el precio completo por tokens que podrías estar cacheando. Esta es una decisión de ingeniería que tiene un impacto significativo en el costo por request.
Cómo los límites del context window te afectan en producción (no solo en demos)
En demos, los límites de contexto rara vez aparecen. El input es limpio, pequeño y curado. Los sistemas en producción son diferentes.
Los lugares donde los límites de contexto causan problemas reales:
Documentos largos: si estás construyendo un sistema que procesa contratos, papers de investigación, repositorios de código o transcripciones, vas a chocar con los límites de contexto con inputs reales. La pregunta es qué pasa cuando eso ocurre. ¿El sistema trunca en silencio? ¿Falla explícitamente? ¿Usa una estrategia de retrieval? Lo que decidas acá afecta tanto la experiencia del usuario como la calidad del output, y es una decisión que necesitas tomar de forma deliberada.
Conversaciones multi-turn con memoria: cada turno de una conversación agrega tokens. Si estás incluyendo el historial completo en cada request, una conversación larga choca con los límites de contexto rápidamente. Los ingenieros que no piensan en esto construyen sistemas que funcionan perfecto para conversaciones de 10 mensajes y se rompen o degradan para las de 50. Las estrategias de comprensión, el historial selectivo y la summarización son patrones reales que necesitas implementar, no edge cases.
RAG y calidad del retrieval: retrieval-augmented generation es el patrón dominante para darle a los LLMs acceso a más información de la que cabe en su contexto. Pero la calidad del RAG depende en gran medida de la calidad del retrieval, y la calidad del retrieval depende de cómo fragmentas, embebidas, indexas y recuperas tu contenido. Volcar documentos mal fragmentados en un sistema de retrieval y esperar que el modelo lo resuelva solo es un antipatrón común. El contexto que provees es un artefacto de ingeniería y merece la misma atención de diseño que el resto de tu sistema.
Sistemas agénticos con resultados de herramientas: cuando los LLMs llaman herramientas, bases de datos, APIs o ejecución de código, los resultados vuelven como tokens que consumen contexto. Un agente que llama múltiples herramientas en secuencia puede agotar su context window en resultados de herramientas antes de producir output útil. Estructurar las respuestas de las herramientas para que sean densas y relevantes, en lugar de verbosas y completas, es una consideración de ingeniería subestimada.
Estrategias que usan los ingenieros senior para trabajar con los límites de contexto, no en su contra
- Contexto selectivo, no contexto máximo. Más contexto no siempre es mejor. Contexto relevante es mejor. Si estás respondiendo una pregunta sobre una función específica en un codebase, enviar todo el codebase no es más inteligente que enviar los archivos relevantes; es más ruidoso. Diseña tu selección de contexto para que sea deliberada, no exhaustiva.
- Summarización jerárquica. Para documentos largos, el chunking jerárquico, resúmenes de resúmenes, te permite preservar la estructura y la información clave de un documento largo sin que todo quepa en un único contexto. Esto es más trabajo de implementar que el chunking naive, pero maneja longitudes de documentos reales mucho mejor.
- Gestión de contexto con estado. No reconstruyas el contexto desde cero en cada llamada. Mantén un objeto de contexto en tu sistema que se actualice, comprima e incluya de forma selectiva. Trátalo como el estado que gestionas, no como algo que reconstruyes desde datos crudos en cada request.
- Estructura tus prompts para el caching. Pon las partes estables de tu prompt (instrucciones del sistema, contexto recuperado, estructura del documento) al principio, y las partes dinámicas (la query específica del usuario, el estado actual) al final. Esto maximiza las tasas de cache hit si tu proveedor soporta prefix caching.
- Instrumenta tu uso real. Si no estás trackeando el consumo de tokens por request en producción, estás volando a ciegas. Instrumenta esto desde temprano. Conoce tus token counts en p50, p95 y p99. Vas a encontrar sorpresas: inputs que no esperabas que fueran largos, resultados de herramientas verbosos, y hilos de conversación que crecen de forma inusualmente rápida.
Cuando el tamaño del context window no es tu problema real
Hay una clase de problemas que se atribuyen a los límites del context window, pero que en realidad son problemas de retrieval, de diseño de prompts o de capacidad del modelo.
Si tu modelo está ignorando instrucciones de partes anteriores del contexto, hacer ese contexto más grande no lo va a solucionar; tienes un problema de atención, y la solución es una mejor ubicación de las instrucciones, un formato más sólido o una estrategia de prompting diferente.
Si tu sistema de RAG está devolviendo resultados irrelevantes, una ventana de contexto más grande no te va a ayudar a encontrar los documentos correctos; solo te va a permitir incluir más irrelevantes. El problema es la calidad del retrieval, no el tamaño del contexto.
Si tu modelo no puede razonar sobre un documento complejo aunque todo quepa en el contexto, el problema puede ser la complejidad de la tarea o la capacidad del modelo, no los límites de contexto.
Los ingenieros que le atribuyen al context window problemas que en realidad tienen otra causa tienden a ser los que piden ventanas más grandes como solución a todo. Los que entienden la mecánica del contexto tienden a resolver los problemas en la capa correcta.
Qué cambia a medida que los modelos tienen ventanas de contexto más grandes
La tendencia es clara: las ventanas de contexto son cada vez más grandes y más baratas de usar. GPT-4o, Claude 3.5 Sonnet y Gemini 1.5 Pro han expandido significativamente en los últimos dos años, y el costo por token para contextos grandes ha bajado. La pregunta obvia es si la ingeniería de contexto se vuelve menos importante a medida que las ventanas crecen.
La respuesta honesta es: en parte, pero no de las formas que la mayoría espera.
Las ventanas más grandes sí reducen genuinamente algunas clases de problemas. El procesamiento de documentos que antes requería chunking muchas veces cabe ahora en un único contexto. Las conversaciones multi-turn pueden incluir más historial antes de llegar a los límites. Algunos patrones de retrieval se simplifican cuando puedes incluir más candidatos y dejar que el modelo elija.
Lo que no desaparece: el problema de distribución de atención. Empíricamente, los contextos muy largos no distribuyen la atención de forma pareja. Incluso con una ventana de 1M de tokens, la información enterrada en un contexto largo se recupera con menos confiabilidad que la información en los extremos. La investigación sobre esto sigue en curso, pero la implicación práctica es que "meter todo en el contexto y dejar que el modelo lo resuelva" no es tan confiable como "poner la información más relevante donde más importa."
El costo y la latencia tampoco desaparecen como problemas; se desplazan. Las llamadas con contextos muy grandes son costosas en términos absolutos, incluso cuando son más baratas por token. A la escala de millones de requests, la eficiencia del contexto sigue siendo una decisión económica. Y la latencia para llamadas con contextos muy largos es real: el time-to-first-token con 100K+ tokens es medible y afecta la experiencia del usuario en sistemas interactivos.
La habilidad de la ingeniería de contexto no se vuelve irrelevante con ventanas más grandes. Se trata cada vez más de calidad, qué entra y cómo está organizado, y menos de cantidad, si entra o no.
La decisión de diseño que no puedes evitar
Todo sistema que usa LLMs tiene que responder la pregunta: ¿qué va en el contexto, y por qué?
En una implementación simple, la respuesta es "todo lo que tengo." En un sistema en producción, la respuesta es más deliberada. ¿Qué necesita realmente el modelo para hacer bien esta tarea? ¿Qué es ruido? ¿Qué es costoso de incluir? ¿Qué necesita estar fresco versus cacheado?
La ingeniería de contexto, el diseño deliberado de qué información entra en una llamada al modelo y cómo está estructurada, es cada vez más una de las habilidades que separa a los ingenieros que construyen sistemas LLM que realmente funcionan de los que construyen sistemas que funcionan en demos.
El número del context window va a seguir creciendo. La habilidad de usar el contexto de forma deliberada no va a volverse irrelevante cuando eso pase.
