La ventana de contexto es el conjunto de tokens que un modelo puede recibir y considerar en una petición. Puede incluir instrucciones, mensaje del usuario, historial, documentos recuperados y resultados de herramientas. Su límite obliga a decidir qué información merece ocupar espacio antes de generar una respuesta.
No debe confundirse con la memoria permanente de una aplicación. Un modelo no conserva automáticamente todas las conversaciones entre peticiones; el backend debe seleccionar y enviar el historial o recuperar datos desde otro sistema.
Qué entra en el contexto
La aplicación puede construir la petición con un mensaje de sistema, instrucciones de tarea, conversación reciente, contenido externo y la pregunta actual. El orden y las prioridades deben estar definidos por el sistema. Un documento recuperado no obtiene autoridad para cambiar las reglas solo por aparecer dentro de la ventana.
Los resultados de herramientas también consumen tokens. Una consulta a una base de datos puede devolver campos innecesarios y desplazar información relevante. Limitar y transformar esos resultados antes de incorporarlos suele mejorar control y coste.
Presupuesto y recorte
El límite se reparte entre entrada y salida, aunque la forma exacta depende del modelo y del servicio. Si el historial crece, la aplicación puede eliminar mensajes antiguos, resumirlos o conservar solo hechos estructurados. Un recorte silencioso es peligroso cuando borra una condición que cambia el sentido de la tarea.
Un diseño más claro separa lo que debe estar siempre presente de lo que se recupera bajo demanda. Las instrucciones de seguridad, los permisos y el objetivo pueden tener prioridad; una conversación antigua puede resumirse si ya no contiene decisiones vigentes.
Historial frente a memoria de aplicación
El historial es una representación textual de intercambios anteriores. La memoria de aplicación puede guardar preferencias, estados o identificadores en una base de datos y recuperar únicamente lo necesario. Mantener esa información fuera del prompt facilita actualizarla, aplicar permisos y corregir errores.
Por ejemplo, una aplicación puede guardar el estado de una incidencia en campos estructurados y enviar al modelo solo los eventos relevantes. Así evita repetir una conversación completa y reduce el riesgo de que un comentario antiguo se interprete como una instrucción actual.
Contexto largo no equivale a mejor respuesta
Una ventana grande permite incluir más información, pero también más ruido, duplicados y contradicciones. El modelo puede prestar atención desigual a distintas partes y la generación puede ser más lenta o cara. La relevancia y el orden suelen importar más que llenar todo el límite.
La recuperación selectiva puede ser preferible a introducir una colección completa. Un sistema RAG busca fragmentos relacionados y aplica filtros de versión o permisos antes de enviarlos. Aun así, la recuperación no garantiza que el contexto sea suficiente ni correcto.
Truncamiento y control de calidad
El truncamiento debe ser observable. Registra qué política se aplicó, cuánto contenido se descartó y si la petición se degradó a una respuesta parcial. Para documentos, conserva fuente y versión; para herramientas, valida que el resultado no excede el tamaño esperado.
Prueba conversaciones cortas y largas, preguntas con información al principio y al final, documentos repetidos y casos en los que la respuesta correcta es reconocer falta de evidencia. Las pruebas revelan pérdidas que no aparecen en una demostración breve.
Coste, latencia y concurrencia
Una petición con más tokens requiere más procesamiento y puede aumentar el tiempo hasta el primer token. En una aplicación con muchas solicitudes simultáneas, el contexto largo incrementa consumo de memoria y presión sobre colas o límites del proveedor. El presupuesto debe considerar entradas, salidas, reintentos y documentos recuperados.
Una caché puede evitar repetir contexto estable, pero debe invalidarse cuando cambian permisos o documentos. Reducir coste no justifica reutilizar información fuera de su ámbito de autorización.
Qué información merece ocupar el contexto
Prioriza instrucciones vigentes, datos necesarios para la decisión, fuentes autorizadas y resultados verificables. Mantén fuera los textos irrelevantes, duplicados y secretos que la tarea no necesita. La mejor ventana no es la más llena: es la que entrega al modelo suficiente evidencia sin perder control sobre origen, vigencia y permisos.
Ordenar la información que entra
El contexto puede organizarse por prioridad: instrucciones vigentes, datos de la tarea, fuentes recuperadas y conversación de apoyo. Si todo se añade como un bloque indistinto, una nota antigua puede competir con una regla actual. Los encabezados y la separación de fuentes ayudan a la aplicación y facilitan revisar qué recibió el modelo.
La selección debe respetar permisos. Un documento recuperado por similitud no debe entrar en el contexto si el usuario no está autorizado para verlo. La decisión de acceso se toma antes de ensamblar la petición y no se delega en las instrucciones que acompañan al texto.
Resumir sin perder decisiones
Un resumen puede reducir tokens, pero debe conservar condiciones, excepciones y referencias importantes. Para estados críticos es mejor almacenar campos estructurados y reconstruir un contexto breve que resumir indefinidamente una conversación. El resumen también debe tratarse como información que puede contener errores.
Medir el contexto que realmente se usa
Registra tokens de entrada, salida, tiempo hasta el primer token, recortes y fuente de cada fragmento. Compara tareas con historial corto y largo para saber si el aumento de contexto mejora la respuesta o solo incrementa consumo. La evaluación debe incluir preguntas cuya evidencia aparezca al principio, al final y fuera de la colección.
En una aplicación concurrente, los contextos largos ocupan recursos aunque las respuestas sean breves. Limitar tamaño, seleccionar documentos y liberar estado antiguo puede mejorar estabilidad sin reducir la información necesaria.