En 2026 existen ventanas de contexto de 1M de tokens. Gemini, GPT-5 y Claude —con pensamiento extendido— las admiten. Las demostraciones muestran modelos que leen libros completos de una sola vez. Parece que basta con incluirlo todo y dejar que el modelo lo resuelva.
La realidad es más compleja. 1M de tokens es una capacidad técnica, no una garantía de rendimiento. Los modelos funcionan mejor con 5-50K tokens de contexto. A 100K+ aparecen problemas sutiles de calidad; a 500K+ se pierde información importante de forma sistemática; y a 1M el modelo se satura.
Este fenómeno —la degradación del contexto— es real, está bien documentado y aparece en las evaluaciones. No puedes volcarlo todo en el prompt y dar el trabajo por terminado. Necesitas tomar decisiones deliberadas sobre qué incluir, qué resumir, qué recuperar dinámicamente y cómo estructurar el resultado.
Este artículo cubre los patrones y la disciplina de una ingeniería del contexto efectiva para sistemas de producción serios.
Qué es la degradación del contexto
La degradación del contexto es la reducción empírica del rendimiento de un LLM a medida que crece el contexto, incluso sin superar su límite técnico.
Modos específicos de falla:
Perdido en el medio (Liu et al., 2023). Los modelos prestan más atención al contenido al inicio y al final del contexto. La información en el medio se usa menos confiablemente. Un hecho colocado en la posición 50K de un contexto de 100K es más probable que se pierda que el mismo hecho en la posición 1K o 99K.
Sesgo por recencia. Los modelos sobreponderan el contenido reciente. En la historia de conversaciones, el contexto antiguo se vuelve efectivamente invisible.
Sensibilidad a los distractores. El contenido irrelevante perjudica el rendimiento incluso cuando la tarea no lo necesita. El modelo debe filtrarlo y parte del ruido termina influyendo.
Disminución de la calidad de razonamiento. El razonamiento en múltiples pasos se vuelve menos confiable a medida que crece el contexto. El modelo tiene más que seguir; la calidad del seguimiento sufre.
Costo y latencia. Independientemente de la calidad: contextos grandes son costosos (precios por token) y lentos (lineales en el número de tokens para muchos modelos).
Estos no son preocupaciones teóricas. Las implementaciones de producción con contextos grandes y naive suelen rendir peor que las implementaciones con contextos curados.
El principio: menos es más
La idea central: el contexto es un recurso valioso y degradable. Úsalo estratégicamente.
Un contexto de 30K de tokens con contenido cuidadosamente seleccionado suele superar a un contexto de 300K de tokens con todo volcado. La calidad, el coste y la latencia favorecen al contexto más pequeño.
Esto cambia el trabajo de ingeniería. En lugar de “encontrar una manera de meter más en el contexto”, se trata de “decidir qué realmente necesita estar en el contexto y colocarlo bien allí”.
El presupuesto de contexto
Piensa en el contexto como un presupuesto que asignas.
Una asignación típica para un agente de soporte al cliente:
Total context budget: 30K tokens
- System prompt: 1500 tokens (5%)
- Tool descriptions: 1000 tokens (3%)
- User profile / context: 500 tokens (2%)
- Conversation history summary: 1000 tokens (3%)
- Recent conversation turns (full): 4000 tokens (13%)
- Retrieved relevant knowledge: 12000 tokens (40%)
- User's current message: 500 tokens (2%)
- Output token budget (response): 10K tokens (33%)
Cada componente compite por espacio. A medida que crece el contexto, tomas decisiones de equilibrio.
La disciplina: sé explícito sobre la asignación. No dejes que ningún componente crezca sin límites.
Patrón 1: Memoria de conversación en capas
Para conversaciones de múltiples turnos, la historia completa crece sin límites. La mayoría de los sistemas de producción usan memoria en capas:
Capa 1: Turnos recientes en su totalidad. Últimos 5-10 intercambios, textualmente.
Capa 2: Resumen de turnos antiguos. Más temprano en la conversación, comprimido en un resumen corto.
Capa 3: Hechos extraídos. Información clave de la conversación (nombre del usuario, preferencias, decisiones tomadas) almacenada como hechos estructurados.
Implementación:
On each turn:
1. Take the conversation history.
2. The last 10 turns are kept verbatim.
3. Turns 11-30 are summarized into 200 words ("Earlier, the user discussed X and we agreed Y").
4. Turns 31+ are reduced to extracted facts ("User prefers Python. User is on enterprise tier.").
5. Total memory: ~2K tokens regardless of conversation length.
Este patrón es fundamental para cualquier conversación prolongada. Sin él, las conversaciones se degradan a medida que crecen.
Una sutileza: el resumen debe preservar información que el agente necesitará. Si el usuario mencionó un número de cuenta en el turno 5 y el agente no lo lleva a la memoria a largo plazo, para el turno 50 el número de cuenta se pierde.
Realiza el resumen con instrucciones explícitas sobre qué preservar:
Summarize the conversation so far. Preserve:
- All facts about the user (name, role, preferences, account info).
- All decisions made.
- All open commitments or follow-ups.
- The current goal of the conversation.
Discard:
- Pleasantries.
- Repeated information.
- Detailed reasoning that's been resolved.
Patrón 2: Recuperación justo a tiempo
En lugar de cargar previamente el contexto, recupera lo relevante cuando sea relevante.
Un patrón contraproducente consiste en incluir todos los documentos de un usuario «por si el modelo los necesita». La mayoría de las consultas solo requiere un subconjunto pequeño; el resto desperdicia contexto y perjudica el rendimiento.
Mejor: recuperar documentos basados en la consulta actual. Consultas diferentes obtienen documentos diferentes. El contexto total por llamada se mantiene pequeño; la relevancia se mantiene alta.
Esto es simplemente RAG, aplicado con disciplina. La clave: no te dejes tentar a “simplemente incluir todo porque se puede”. Incluso los equipos experimentados lo hacen cuando están disponibles modelos con contexto largo.
Patrón 3: Representaciones comprimidas
Para información que necesita persistir en el contexto, usa representaciones comprimidas.
Original (detallado):
The user has been working in software engineering for 8 years. They started at a small startup called Acme Corp where they worked on backend systems. After 3 years they moved to a larger company called Beta Inc where they did frontend work. They're currently at Gamma LLC working on machine learning systems.
Comprimido:
User: SWE, 8 years, currently ML at Gamma LLC. Prior: backend@Acme (3yr), frontend@Beta.
La versión comprimida conserva los hechos pertinentes con menos tokens. En la mayoría de los casos, el modelo puede utilizar ambas versiones con la misma eficacia.
Aplica esta técnica a:
- Perfiles de usuario.
- Resúmenes de documentos.
- Contexto de conversaciones anteriores.
- Entradas de bases de conocimiento (cuando no se necesita el contenido completo).
El equilibrio: la compresión pierde matices. Usa texto completo cuando importen los matices; comprime cuando no.
Patrón 4: Recuperación jerárquica
Para bases de conocimiento muy grandes, recupera jerárquicamente.
Paso 1: Recupera categorías amplias o resúmenes de documentos basados en la consulta.
Paso 2: Dentro de las categorías más relevantes, recupera fragmentos específicos.
Paso 3: Incluye solo los fragmentos seleccionados en el paso 2 en el contexto final.
Esto evita el enfoque «tengo 10K documentos; voy a incluirlos todos en el contexto». El embudo jerárquico mantiene el contexto acotado.
Variante: una llamada pequeña a un LLM selecciona qué fragmentos son más relevantes antes de incluirlos en la llamada principal. Esto agrega un pequeño coste pero reduce significativamente la inflación del contexto.
Patrón 5: Reflexión sobre el contexto
Para agentes en tareas prolongadas, reflexiona periódicamente sobre qué está en el contexto y qué debería estar.
Every 10 steps, the agent does:
1. Reviews its current context.
2. Identifies what's relevant to ongoing work.
3. Summarizes or drops anything no longer needed.
4. Notes what additional context might help.
5. Replaces the old context with the curated version.
Equivale a una «recolección de basura» del contexto. Sin ella, los agentes acumulan información obsoleta que desplaza a la nueva y pertinente.
La implementación requiere orquestación personalizada, pues la mayoría de los frameworks no la admite de forma nativa. Entre pasos, el agente ejecuta una fase de «consolidación de memoria» que selecciona el contexto.
Patrón 6: Ventanas de contexto dinámicas
Diferentes partes de la ejecución de un agente pueden tener tamaños óptimos de contexto diferentes.
- Pasos de decisión: contexto pequeño, enfocado en la decisión inmediata.
- Pasos de síntesis: contexto más grande, incluyendo muchos orígenes.
- Pasos de generación: contexto mediano, con referencias de estilo y formato.
Un patrón: cada paso en el flujo de trabajo del agente usa una forma diferente de contexto. La orquestación gestiona qué contenido va a cada paso.
Esto requiere dividir el trabajo del agente en pasos explícitos en lugar de un solo bucle grande. La elección del marco importa aquí (LangGraph maneja esto naturalmente; la API directa requiere trabajo manual).
Patrón 7: Colocación con conciencia de posición
Dado que los modelos prestan más atención al inicio y al final del contexto, coloca contenido importante allí.
Menos efectivo: instrucción crítica enterrada en el medio de un largo prompt del sistema.
Más efectivo: instrucción crítica al comienzo y repetida cerca del final.
Para RAG con múltiples documentos recuperados: el documento más relevante al inicio, el segundo más relevante al final, menos relevantes en el medio.
Es una optimización táctica, pero produce un efecto medible en los resultados.
Patrón 8: Resumen selectivo
No todo el resumen es igual. Personaliza el resumen según lo que necesiten las tareas posteriores.
Malo: resumen genérico que omite preferencias del usuario.
Mejor: resumen que explícitamente preserva preferencias del usuario relevantes para la tarea posterior.
Summarize this document focusing on:
- Technical decisions made.
- Stakeholders mentioned.
- Open questions or risks.
Drop:
- General context already known to the team.
- Repeated points.
El prompt de resumen se diseña específicamente para el uso posterior.
Patrón 9: Contexto estructurado
El texto plano es una opción. El contexto estructurado (JSON, XML o marcado específico) puede ser mucho más denso.
Prosa detallada:
The customer's name is John Smith. He's been a customer since March 2023. His current plan is Pro, billed monthly at $29. He has 3 active integrations: Slack, Notion, and Linear. His usage in the last 30 days has been moderate — 1,250 API calls.
Estructurado:
{
"customer": {
"name": "John Smith",
"since": "2023-03",
"plan": "Pro",
"billing": "monthly $29",
"integrations": ["Slack", "Notion", "Linear"],
"usage_30d": {"api_calls": 1250, "tier": "moderate"}
}
}
La versión estructurada es más corta y (a menudo) más fácil de usar para el modelo. El modelo puede encontrar rápidamente hechos específicos.
Caveat: no todos los modelos manejan igual de bien la entrada estructurada. Prueba ambos formatos para tu caso de uso.
Patrón 10: Capas de contexto
Capa el contexto por prioridad. Lo de alta prioridad siempre se incluye; lo de prioridad media se incluye cuando sea relevante; lo de baja prioridad se recupera bajo demanda.
Siempre:
- Prompt del sistema (identidad, comportamiento).
- Contexto actual del usuario (hechos esenciales).
- Conversación reciente.
Cuando sea pertinente:
- Documentos recuperados que coinciden con la consulta.
- Salidas de herramientas de pasos recientes.
Bajo demanda:
- Datos específicos que el agente solicita mediante llamadas a herramientas.
- Contexto histórico fuera de la ventana reciente.
El patrón «bajo demanda» es esencial para escalar: el agente recupera solo lo que necesita en el momento oportuno.
Patrón 11: Estrategias de expulsión
Cuando el contexto se acerca a los límites, ¿qué se expulsa?
- Basado en recencia: se expulsa primero el contenido más antiguo.
- Basado en relevancia: se expulsa primero el contenido menos relacionado con la tarea actual.
- Basado en importancia: se expulsa primero el contenido marcado como de baja importancia.
Un patrón práctico: etiqueta los elementos del contexto con niveles de prioridad. Cuando sea necesario expulsar, elimina en orden de prioridad.
context_items = [
{"content": "...", "priority": "critical"}, # Never evict
{"content": "...", "priority": "high"}, # Evict last
{"content": "...", "priority": "medium"}, # Evict if needed
{"content": "...", "priority": "low"}, # Evict first
]
def evict_to_fit(items, budget):
items_by_priority = sorted(items, key=lambda x: priority_value(x.priority))
while total_tokens(items) > budget:
items.remove(items_by_priority.pop(0)) # Remove lowest priority
return items
Patrón 12: Caché para contexto repetido
Muchas llamadas reutilizan el mismo contexto: prompt del sistema, descripciones de herramientas y perfil del usuario.
La mayoría de los proveedores ahora admiten caché de prompts:
- Anthropic: marcadores explícitos de
cache_controlen los mensajes. - OpenAI: automático para solicitudes con coincidencia de prefijo.
- Google: contenido caché explícito mediante API.
Cuando se reutiliza el mismo prefijo, la versión caché es más rápida y más barata (a menudo un 90% más barata).
Para agentes que hacen muchas llamadas en una sesión, asegúrate de que las partes estáticas (prompt del sistema, herramientas, contexto del usuario) sean cachéables. Coloca el contenido dinámico (paso actual, resultados recientes) después del prefijo cachéable.
Esta es una de las optimizaciones con mayor ROI. Un prefijo estático de 10K tokens utilizado en 50 llamadas paga el precio completo en la primera y obtiene un descuento del 90% en las siguientes. El ahorro es considerable.
Patrón 13: Prompts conscientes del contexto
Los prompts pueden animar al modelo a usar bien el contexto:
Reference the documents below to answer the user's question. Always cite the specific document and quote relevant passages.
If you cannot find the answer in the provided documents, say so explicitly. Do not invent information.
When information from multiple documents is relevant, synthesize them and note any disagreements.
Este tipo de prompting reduce la alucinación en tareas basadas en contexto y mejora la calidad de las citas.
Cuándo aceptar contextos más largos
A pesar de la degradación del contexto, contextos más largos son genuinamente mejores para algunas tareas:
Análisis de un solo documento. Si la tarea es “analizar este contrato”, incluir todo el contrato en el contexto suele ser mejor que recuperar fragmentos.
Comparación entre muchos elementos. Comparar 10 contratos lado a lado beneficia al tener todos los 10 en el contexto.
Edición de código en contexto. Modificar una función en un archivo de 5K líneas de código es más fácil con el archivo en contexto que con fragmentos recuperados.
Resumen de conversación completa. Producir un resumen de una conversación larga funciona mejor con contexto completo (hasta un punto).
El patrón: cuando la tarea fundamental requiere entender relaciones entre contenido, contextos más largos ayudan. Cuando la tarea puede hacerse con un fragmento pequeño, contextos más pequeños son mejores.
Heurística práctica: los contextos de hasta 50K tokens suelen ser aceptables. Entre 50-200K funcionan, pero la calidad disminuye. Con 200K+ suelen rendir peor que otros más cortos. Compruébalo de forma empírica.
Disciplina de evaluación
¿Cómo sabes si tu ingeniería del contexto está funcionando? Evalúa.
Evaluaciones específicas:
Pruebas de recuperación. Incluye hechos clave en posiciones variadas en contextos largos. Prueba si el modelo los usa. Mide la recuperación vs posición.
Pruebas de distractores. Compara el rendimiento en la misma consulta con y sin contexto irrelevante. Mide la degradación.
Comparación entre contexto largo y RAG. Las mismas consultas respondidas con contexto completo vs fragmentos recuperados. Compara la calidad.
Eficiencia en tokens. Calidad por dólar. A medida que crece el contexto, pagas más — ¿crece la calidad en proporción?
Estas evaluaciones revelan si tus decisiones sobre contexto realmente ayudan. Sin ellas, estás adivinando.
Ejemplo práctico: asistente de investigación
Un ejemplo real: un asistente de investigación de IA para un pequeño equipo.
Tarea: responder preguntas sobre un corpus de 200 documentos (artículos, documentos internos, notas de reunión).
Enfoque ingenuo: incluir todos los documentos en el contexto (300K tokens). La calidad es aceptable, pero el coste es alto y la latencia deficiente.
Enfoque ingenierizado:
Context budget: 25K tokens
- System prompt: 1500 tokens (cached)
- Tool descriptions (search, fetch_doc, etc.): 800 tokens (cached)
- Conversation memory: 1500 tokens (last 10 turns)
- Retrieved chunks for current query: 18000 tokens (top 12 chunks via RAG)
- User's current question: 200 tokens
- Output budget: ~3000 tokens
El agente recupera dinámicamente fragmentos según la pregunta. La memoria de conversación mantiene el contexto reciente. Los elementos estáticos se cachean.
Resultado:
- Latencia: 2-3 segundos (vs 10-15 con 300K de contexto).
- Costo: ~€0.01 por consulta (vs ~€0.10).
- Calidad: mejor, medida en el conjunto de evaluación, porque el contenido relevante se atiende adecuadamente.
Este es el aspecto de la ingeniería del contexto disciplinada. No una decisión única, sino ajustes continuos.
Errores comunes
Algunos patrones:
Error 1: «Más contexto = mejor». Utilizar ventanas más largas como solución a los problemas de calidad suele producir el efecto contrario.
Error 2: Sin presupuesto de contexto. Los componentes crecen sin límites. La sección del perfil del usuario se convierte en 5K de tokens; la sección de fragmentos recuperados se convierte en 50K. Sin disciplina.
Error 3: Ignorar posiciones. Instrucciones críticas enterradas en el medio, esperando que el modelo las encuentre. A veces lo hace; a menudo no.
Error 4: Prosa detallada para hechos. Frases largas donde los datos estructurados serían suficientes. Se desperdician tokens.
Error 5: Sin resumen de conversación. Las conversaciones crecen hasta exceder los límites. Luego se truncan o se rompen.
Error 6: Sin caché. Los prefijos estáticos repetidos pagan el precio completo en cada llamada y desperdician dinero.
Error 7: Sin evaluación de decisiones de contexto. Confianza en que “mejor ingeniería del contexto” funciona. A veces no lo hace.
Error 8: Resumen genérico. Resumir sin pensar en lo que necesitan las tareas posteriores. Se pierde información que importa.
El mensaje clave
Las ventanas de contexto largo son reales, pero no son una licencia para ignorar la ingeniería del contexto. La calidad se degrada mucho antes de los límites técnicos. El coste y la latencia son reales.
La disciplina de la ingeniería del contexto:
- Trata el contexto como un presupuesto.
- Organiza la memoria en capas: turnos recientes completos, antiguos resumidos y los más antiguos como hechos.
- Recupera justo a tiempo, no por anticipado.
- Comprime donde la compresión preserva información.
- Coloca contenido crítico en posiciones con alta atención.
- Capa el contexto por prioridad.
- Guarda los prefijos estáticos en caché.
- Evalúa continuamente.
Estos patrones producen sistemas mejores, más rápidos y baratos que el enfoque ingenuo de «incluirlo todo en el contexto».
Para sistemas de producción maduros, la ingeniería del contexto es una de las áreas con mayor impacto. Los primitivos técnicos son simples; la disciplina para aplicarlos rigurosamente es lo que separa “funciona en demostración” de “confiable en producción”.
Invierte en los patrones. Construye la disciplina. El resultado es sistemas de IA que escalan con gracia a medida que se enfrentan a más datos, más conversaciones y más complejidad.
