¿Qué es una ventana de contexto y por qué se agota?
La ventana de contexto es todo lo que un modelo puede ver de una vez — tu solicitud, la conversación, los documentos recuperados y su propia respuesta. Aquí se explica cómo se mide, por qué más largo no es automáticamente mejor y qué hacer cuando alcanzas el límite.
Respuesta rápida
¿Qué es una ventana de contexto en un modelo de IA?
Una ventana de contexto es la cantidad máxima de texto, medida en tokens, que un modelo puede considerar en una sola solicitud. Contiene las instrucciones del sistema, la conversación hasta el momento, cualquier documento que pegues y la respuesta que se está generando. Cuando el total supera el límite, algo debe ser descartado o resumido.
Claves
- La ventana se mide en tokens, no en palabras — aproximadamente 0.75 palabras por token en inglés, y muchos menos caracteres por token en coreano o japonés.
- Todo comparte el mismo presupuesto: instrucciones, historial, archivos adjuntos, definiciones de herramientas y la salida.
- Los modelos utilizan de manera confiable el principio y el final de un contexto largo mejor que el medio, por lo que la ubicación importa.
- El costo y la latencia escalan con los tokens que realmente envías, por eso el almacenamiento en caché y la recuperación suelen ser mejores que pegar todo.
Cada conversación con un modelo de lenguaje tiene un límite máximo de lo que puede ver a la vez. Ese límite es la ventana de contexto, y casi todos los comportamientos extraños que la gente reporta —el modelo "olvidando" lo que dijiste, ignorando un archivo adjunto, perdiendo el hilo a mitad de camino— se remontan a ella.
Tokens, no palabras
Los modelos no leen caracteres ni palabras. El texto se divide primero en tokens: fragmentos comunes que el tokenizador ha aprendido. En inglés, un token promedia unos cuatro caracteres, por lo que 1.000 tokens son aproximadamente 750 palabras.
Esa proporción no es universal. Los scripts que caen fuera de la distribución de entrenamiento del tokenizador se fragmentan más:
| Texto | Tokens aproximados |
|---|---|
The quick brown fox (19 caracteres, inglés) | ~4 |
안녕하세요 반갑습니다 (11 caracteres, coreano) | ~10 |
こんにちは、はじめまして (12 caracteres, japonés) | ~11 |
| Una línea de código con sangría de 4 espacios | 1 token por nivel de sangría |
La consecuencia práctica: un documento en coreano o japonés consume notablemente más de la ventana que un documento en inglés de la misma longitud visible, y cuesta proporcionalmente más por solicitud.
Qué compite por el espacio
Es tentador pensar en la ventana como "cuánto documento puedo pegar". En realidad, es un presupuesto compartido:
- El prompt del sistema — las instrucciones que definen el comportamiento del asistente.
- Definiciones de herramientas, si el modelo puede llamar a herramientas. Una docena de herramientas con esquemas detallados pueden sumar miles de tokens antes de que hayas dicho nada.
- El historial de la conversación, que generalmente se reenvía completo en cada turno.
- Documentos adjuntos o recuperados.
- La salida. Los tokens generados salen del mismo presupuesto en la mayoría de las APIs, por lo que una entrada muy larga puede no dejar espacio para una respuesta larga.
Si alguna vez has adjuntado un PDF grande y has recibido una respuesta truncada, esta es la razón.
Largo no significa uniformemente bueno
La investigación sobre el comportamiento de contexto largo —siendo Lost in the Middle la más influyente— encontró un patrón consistente: los modelos recuperan hechos colocados cerca del inicio o del final de una entrada larga de manera mucho más confiable que los hechos enterrados en el medio. La curva tiene forma de U, y no se aplana completamente a medida que las ventanas se hacen más grandes.
Tres reglas se derivan directamente:
- Pon las instrucciones primero y la pregunta inmediata al final. Las dos posiciones a las que el modelo presta mejor atención.
- No rellenes. Veinte páginas relevantes vencen a doscientas páginas que contienen las mismas veinte.
- Prueba a una longitud realista. Un prompt que funciona a 5.000 tokens puede degradarse silenciosamente a 100.000.
Los puntos de referencia de los proveedores "aguja en un pajar" —ocultar una oración en un documento largo y pedirle al modelo que la encuentre— miden el caso fácil. Recuperar un único hecho distintivo es mucho más simple que razonar sobre material distribuido en toda la entrada.
Costo, latencia y caché
Pagas por los tokens que envías, en cada solicitud. Un contexto de 100.000 tokens reenviado a lo largo de una conversación de 20 turnos son dos millones de tokens de entrada, incluso si el usuario escribió veinte preguntas cortas.
Dos mecanismos alivian la presión:
- Caché de prompts. Los proveedores pueden almacenar en caché el prefijo sin cambios de una solicitud —prompt del sistema, definiciones de herramientas, un documento largo— y cobrar mucho menos por los aciertos de caché. Solo funciona si el prefijo es idéntico en bytes, así que pon el material estable primero y el material volátil (marcas de tiempo, nombres de usuario) al final.
- Agrupación (Batching). Para trabajos que no son interactivos, las APIs de grupo suelen costar significativamente menos a cambio de resultados retrasados.
La latencia sigue una forma similar: el tiempo hasta el primer token aumenta con la longitud de la entrada, por lo que un chat que se siente instantáneo con un prompt corto se vuelve lento una vez que adjuntas un archivo grande.
Qué hacer cuando alcanzas el límite
Recupera en lugar de pegar. Indexa tus documentos, obtén el puñado de pasajes que se relacionan con la pregunta y envíalos. Las solicitudes se mantienen pequeñas, baratas y precisas. Este es todo el argumento para generación aumentada por recuperación.
Resume el historial. Reemplaza los giros antiguos con un resumen compacto de las decisiones y hechos establecidos hasta el momento. Mantén los giros más recientes literales —ahí es donde vive el hilo inmediato.
Divide la tarea. Dos solicitudes enfocadas suelen superar a una solicitud enorme. Extracción y luego análisis; por documento y luego combinar.
Recorta tus herramientas. Si el modelo solo necesita tres herramientas para esta tarea, no envíes treinta.
Mide antes de optimizar. Cuenta los tokens en una solicitud real. Los equipos se sorprenden habitualmente al descubrir que el prompt del sistema o un esquema de herramienta no utilizado, no el documento del usuario, está consumiendo la mayor parte de la ventana.
La ventana de contexto no es una característica a maximizar. Es un presupuesto para gastar deliberadamente.
Preguntas frecuentes
- ¿Cuántas palabras caben en una ventana de contexto de 200.000 tokens?
- Aproximadamente 150.000 palabras en inglés, o unas 500 páginas de prosa ordinaria. El texto en coreano, japonés y chino utiliza más tokens por carácter, por lo que se esperan sustancialmente menos páginas para el mismo límite.
- ¿Elimina una ventana de contexto más grande la necesidad de RAG?
- No. Una ventana grande hace que la recuperación sea menos engorrosa, pero enviar 500 páginas en cada solicitud es lento y costoso, y la precisión todavía se degrada en medio de entradas muy largas. La recuperación mantiene las solicitudes pequeñas y específicas.
- ¿Qué sucede cuando una conversación excede la ventana?
- La aplicación tiene que intervenir —normalmente descartando los turnos más antiguos, resumiéndolos o trasladándolos a un almacén de recuperación—. El modelo en sí simplemente no puede ver nada fuera de la ventana.
- ¿Por qué mi conversación larga se vuelve más cara con el tiempo?
- La mayoría de las API reenvían toda la conversación en cada turno, por lo que la entrada crece con cada intercambio. El almacenamiento en caché de prompts reduce el costo del prefijo repetido, pero los tokens aún se están procesando.