Gestión de Contexto y Documentos Largos
Gestión de Contexto y Documentos Largos
Anterior: Batch Processing · Índice · Siguiente: Reliability y Escalación
Context window: capacidad y degradación
Claude tiene un context window de 200k tokens (~150,000 palabras). Sin embargo, la calidad de las respuestas degrada progresivamente a medida que se llena el contexto.
Regla del 40%
La degradación de calidad se vuelve notable al ~40% de uso del context window (~80k tokens). Después de ese punto:
- Aumentan las alucinaciones
- Claude “olvida” instrucciones del principio del contexto
- La precisión de extracción baja en documentos grandes
- Las instrucciones del system prompt pierden fuerza
Para el examen: La respuesta correcta a “qué pasa cuando el contexto se llena” NO es “Claude falla” sino “la calidad degrada gradualmente”. El modelo sigue funcionando pero con menor precisión.
Implicaciones prácticas
- No cargar todo el codebase en una sola conversación
- Preferir múltiples sesiones focalizadas sobre una sesión larga
- Monitorear el uso de tokens para anticipar degradación
- Priorizar la información más importante al inicio del contexto
Estrategias para documentos largos
Chunking
Dividir documentos grandes en segmentos procesables:
Por tamaño fijo: Dividir cada N tokens con overlap
- Simple de implementar
- Riesgo: cortar en medio de una sección lógica
- Overlap mitiga pérdida de contexto en boundaries
Por estructura semántica: Dividir por secciones, capítulos, o unidades lógicas
- Preserva contexto dentro de cada chunk
- Más complejo de implementar
- Mejor calidad de resultados
Estrategia de overlap: 10-20% de overlap entre chunks adyacentes para que información en el boundary no se pierda.
Cuándo chunking no es necesario
Si el documento cabe en <40% del context window (~80k tokens, ~60,000 palabras), procesarlo completo suele dar mejores resultados que chunking, porque Claude tiene el contexto completo.
Summarization
Para documentos o conversaciones que exceden el contexto útil:
Summarization progresiva
En conversaciones largas, resumir periódicamente el contexto acumulado:
- Cada N mensajes, generar un summary del progreso
- Reemplazar mensajes viejos con el summary
- Continuar con: summary + mensajes recientes
Summarization para handoffs
Cuando un agente pasa trabajo a otro (o entre sesiones):
Malo: Pasar toda la conversación raw
- Consume contexto del nuevo agente
- Incluye intentos fallidos, tangentes, ruido
Bueno: Pasar un structured summary
- Decisiones tomadas y su reasoning
- Estado actual del trabajo
- Próximos pasos pendientes
- Archivos modificados y por qué
Context loading selectivo
Solo cargar lo relevante
En lugar de cargar todo el proyecto, cargar solo los archivos relevantes a la tarea actual:
- Si se corrige un bug en
auth.ts, cargarauth.ts+ sus imports directos + el test file - NO cargar
README.md,package.json, archivos de configuración irrelevantes - Los archivos de contexto cargados deben estar directamente relacionados con la tarea
Priorización de contexto
Orden de prioridad en el contexto:
- System prompt — instrucciones permanentes (siempre al inicio)
- Tarea actual — lo que se necesita hacer ahora
- Archivos directamente relevantes — código que se va a modificar
- Contexto de soporte — tipos, interfaces, tests relacionados
- Background — documentación, specs (solo si cabe)
Context loading en Claude Code
Claude Code hace context loading selectivo automáticamente:
- Lee archivos bajo demanda (no carga todo el repo)
CLAUDE.mdse carga siempre (instrucciones persistentes)- Los archivos referenciados en la conversación se priorizan
Multi-turn conversation management
Cuándo comprimir
Señales de que la conversación necesita compresión:
- Más de 20-30 turns
- Claude empieza a contradecir decisiones anteriores
- Las instrucciones del inicio ya no se siguen consistentemente
- El token count supera el 40% del window
Cuándo empezar sesión nueva
- Cambio de tarea (de debugging a feature development)
- Después de completar un milestone
- Cuando la compresión perdería contexto crítico
- Al empezar trabajo en un módulo diferente del proyecto
Patrón de handoff entre sesiones
- Pedir a Claude que genere un summary del trabajo hecho
- Guardar el summary en un archivo (
session-notes.mdo similar) - En la nueva sesión, cargar solo el summary + archivos relevantes
- Continuar desde donde se dejó con contexto fresco
Pasar contexto entre agentes
Via archivos persistidos (recomendado)
Cuando un agente coordinator spawna subagentes:
- Los resultados se escriben a archivos en disco
- El coordinator lee los archivos con los resultados
- Cada subagente tiene su propio context window limpio
- No hay “contaminación” de contexto entre agentes
Via contexto compartido (NO recomendado)
- Pasar todo el historial de un agente a otro consume contexto
- El segundo agente hereda el “ruido” del primero
- Menos espacio para su propia tarea
- Más propenso a errores por contexto irrelevante
Para el examen: La forma correcta de pasar información entre agentes es via archivos persistidos, no via contexto compartido en memoria. Esto es un patrón fundamental del Agent SDK.
Estrategias de caching
Prompt caching
Para system prompts largos o few-shot examples que se repiten:
- El system prompt se cachea automáticamente
- Few-shot examples estáticos se benefician del cache
- Reduce latency y costo en invocaciones repetidas
Cuándo el caching ayuda más
- System prompts >1000 tokens
- Few-shot examples estáticos reutilizados en múltiples requests
- Prefijos de conversación comunes (context loading repetido)
Resumen
- Context window de 200k tokens, degradación notable al ~40% de uso
- Chunking semántico > chunking por tamaño fijo
- Documents <80k tokens: procesar completos sin chunking
- Summarization para handoffs entre sesiones (structured, no raw)
- Context loading selectivo: solo archivos relevantes a la tarea
- Empezar sesión nueva al cambiar de tarea o superar 40% del contexto
- Pasar info entre agentes via archivos persistidos, no contexto compartido
Anterior: Batch Processing · Índice · Siguiente: Reliability y Escalación