Definición
La context window (ventana de contexto) es la cantidad máxima de tokens que un modelo de lenguaje puede procesar en una sola petición de inferencia. Incluye todo lo que ve el modelo: el system prompt, el historial de conversación, el contexto recuperado por RAG, los ejemplos few-shot, y la respuesta que va generando.
Es la "memoria de trabajo" del modelo: solo puede razonar sobre lo que cabe ahí. Si se supera, el modelo recibe error o se trunca el contexto, perdiendo información.
A mediados de 2026 los modelos top tienen ventanas de:
| Modelo | Context window |
|---|---|
| Claude Opus 4 / Sonnet | 200.000 tokens |
| GPT-5 | 400.000 tokens (rumor) |
| Gemini 2 Pro/Ultra | 1.000.000 - 2.000.000 tokens |
| Llama 3.1 / 4 | 128.000 tokens |
| Qwen 2.5 / 3 | 128.000 - 1.000.000 tokens |
| Mistral Large | 128.000 tokens |
| DeepSeek-V3 | 128.000 tokens |
| Modelos pequeños abiertos | 8.000 - 32.000 tokens típico |
1 millón de tokens ≈ un par de novelas de 400 páginas. Estas cifras eran impensables hace 2 años. La carrera por contextos cada vez más largos sigue activa.
Por qué importa
La context window define qué puedes hacer técnicamente:
- Procesar documentos enteros: PDFs, contratos, repositorios de código, transcripciones.
- Mantener conversaciones largas: historial completo en memoria.
- RAG eficiente: meter mucho contexto recuperado sin recortar.
- Multi-modal con vídeo/imagen masiva: una imagen consume 1.000-3.000 tokens, un vídeo decenas de miles.
- Few-shot con muchos ejemplos: 10-50 ejemplos completos como guía.
Cuando el caso de uso requiere más contexto del que cabe, hay que aplicar técnicas: resumir, RAG, chunking. Pero cuanto más cabe nativamente, menos hackeo de ingeniería necesitas.
Cómo se construye el contexto en producción
En una llamada API típica el contexto se compone de:
- System prompt: instrucciones generales (rol, tono, restricciones). Típico 200-2.000 tokens.
- Few-shot examples: si los usas, 500-5.000 tokens.
- RAG context: chunks recuperados de bases de conocimiento. 1.000-50.000 tokens según uso.
- Historial de conversación: turnos anteriores. Crece con la conversación.
- Pregunta actual del usuario: 50-500 tokens típico.
- Buffer para respuesta: el modelo necesita "espacio" para responder; típicamente reservas 1.000-8.000 tokens.
Suma todo y debe caber en la ventana. Si te acercas al límite, hay que recortar o resumir alguno de los componentes.
El problema del "needle in a haystack"
Tener una ventana grande no garantiza que el modelo use bien todo el contexto. El test clásico llamado "needle in a haystack" mete un dato específico (la "aguja") en algún punto de un contexto enorme (el "pajar") y pregunta sobre ese dato.
Resultados:
- Modelos modernos top (Claude Opus 4, Gemini 2 Ultra, GPT-5) recuperan datos casi perfectamente en sus ventanas declaradas.
- Modelos open weights tienden a degradarse en la mitad del contexto largo (efecto "lost in the middle").
- En ventanas extremas (1M+), incluso los mejores modelos pierden algo de precisión.
Recall ≠ comprensión. Un modelo puede recuperar un hecho del contexto pero no integrarlo bien con el razonamiento general. Por eso evaluar "uso efectivo del contexto largo" es más complejo que medir tamaño máximo.
Coste y latencia del contexto largo
Ventana grande no es gratis:
- Coste de tokens: pagas por cada token de input. 200k tokens en Claude Sonnet 4.6 = ~0,60€ solo en input.
- Latencia de prefill: procesar el prompt completo crece linealmente (con Flash Attention) o cuadráticamente (atención estándar). Un prompt de 200k puede tardar 5-30 segundos en prefill antes de empezar a responder.
- Memoria GPU: la KV cache consume RAM proporcional al contexto. Ventana de 1M de tokens puede requerir 50-100 GB de VRAM solo para la cache.
Por eso los proveedores tienen prompt caching: cachean el prefill de prompts que se repiten (system prompts, contexto estático) → coste / 10, latencia / 5.
Ejemplo práctico
En antonioecheverria.es, nuestro bot RAG potencial podría tener este reparto típico por consulta:
- System prompt (instrucciones y persona): 600 tokens.
- Few-shot examples (3 conversaciones): 1.200 tokens.
- RAG context (top 5 chunks del diccionario): 2.500 tokens.
- Historial conversación (últimos 4 turnos): 800 tokens.
- Pregunta usuario: 100 tokens.
- Buffer respuesta: 1.000 tokens.
Total ≈ 6.200 tokens por consulta. Cabe holgadamente en cualquier modelo moderno (8k+ tokens).
En AE Works para un cliente que necesita un asistente legal sobre contratos largos:
- Sistema: 1.000 tokens.
- Contrato completo del cliente (input): 60.000 tokens.
- Histórico jurisprudencia relevante: 30.000 tokens.
- Pregunta del abogado: 200 tokens.
- Buffer respuesta: 4.000 tokens.
Total ≈ 95.000 tokens. Solo cabe en modelos de 128k+ ventana. Y la latencia será notable (10-20s prefill).
Técnicas cuando el contexto no cabe
- RAG: en lugar de meter todo, recuperar solo lo relevante. La técnica más usada.
- Chunking + map-reduce: trocear el documento, procesar cada trozo por separado, combinar.
- Resumen progresivo: resumir partes ya procesadas para liberar espacio.
- Sliding window con resumen: mantener solo los últimos N tokens + resumen comprimido de lo anterior.
- Caching de prefill: el contexto fijo se cachea, no se procesa cada vez.
- Modelos de razonamiento: a veces resuelven con razonamiento interno problemas que un LLM con contexto enorme no.
Errores comunes al hablar de context window
- "Más es siempre mejor": más caro, más lento, y no garantiza mejor calidad si el modelo no usa bien el contexto.
- Confundir tamaño con uso efectivo: 1M de ventana es inútil si el modelo se confunde en la mitad.
- Olvidarse de la respuesta: el output también ocupa tokens del contexto. Si pides una respuesta de 5.000 tokens, tienes que reservar ese espacio.
- No cachear lo cacheable: system prompts grandes que se repiten en cada llamada son la principal forma de tirar dinero a la basura.
- Asumir que "el modelo recuerda": cada llamada API es independiente. La "memoria" debe venir del prompt completo en cada turno.
- Subestimar tokens de imagen/vídeo: una imagen 1024×1024 puede ser 1.500 tokens; un vídeo de un minuto, 20-50k tokens.
Cuándo importa optimizar la ventana
Sí, gestiónala cuidadosamente cuando:
- Trabajas con documentos largos.
- Las conversaciones se alargan y van perdiendo contexto.
- El coste de tokens empieza a ser visible en la factura.
- La latencia del prefill afecta UX.
Es menos crítico cuando:
- Tu caso de uso es transaccional simple con prompts cortos.
- El modelo elegido tiene ventana 10× más grande de lo que necesitas.
Referencias
- Anthropic · 200k context release notes — uno de los primeros saltos modernos en ventana de contexto
- Gemini 1.5 Technical Report — referencia técnica de cómo se logró el millón de tokens
- Liu et al. · Lost in the Middle paper — análisis del problema de uso desigual del contexto largo