Ingeniería de Contexto
La ingeniería de prompts trata sobre las palabras que eliges. La ingeniería de contexto trata sobre el espacio de trabajo que le entregas al modelo: qué hay en él, en qué orden está y qué dejaste fuera deliberadamente.
La distinción importa porque una ventana de contexto no es un bloc de notas. Es un recurso atencional limitado y caro. Cómo la llenas cambia en qué se centra el modelo, cuánto te cuesta y si sigue siendo útil a medida que las sesiones crecen.
El presupuesto de contexto
Cada modelo tiene un tamaño máximo de contexto: un techo estricto medido en tokens. Piénsalo como un presupuesto. Lo gastas en:
- Tu prompt de sistema y tus instrucciones permanentes
- Documentos recuperados, fragmentos de la base de código, definiciones de herramientas
- El historial de conversación
- La salida del modelo (que también cuenta contra la ventana en sesiones de varios turnos)
Cuando te quedas sin presupuesto, algo tiene que ceder. O se descarta contenido antiguo, o la sesión choca contra un muro.
La mayoría de las guías para principiantes tratan la ventana de contexto como "cuanto más, mejor". La ingeniería de contexto la trata como un recurso que hay que asignar con cuidado: gástalo en lo que el modelo realmente necesita para este turno, no en todo lo que pudiera ser relevante.
La degradación de contexto y el "lost in the middle"
Hay un fenómeno bien documentado en los LLM de contexto largo: los modelos prestan una atención desproporcionada al contenido cercano al principio y al final de su contexto, y su recuerdo del contenido enterrado en el medio se degrada. Los investigadores que estudiaron este efecto lo llamaron "lost in the middle" (perdido en el medio).
La consecuencia práctica: si rellenas un contexto de 100.000 tokens con documentos y entierras la instrucción más crítica en la posición 60.000, el modelo puede ignorarla en la práctica — no porque sea incapaz de leer tan lejos, sino porque la atención no se distribuye de forma uniforme por la ventana.
La "degradación de contexto" (context rot) es el patrón más amplio: a medida que una sesión crece, la calidad de las respuestas tiende a desviarse. Las instrucciones tempranas se diluyen. El ir y venir repetido desplaza la tarea original. El modelo empieza a poner reservas, a repetirse o a perder el hilo de lo que realmente pediste.
Estos no son fallos que puedas corregir del todo con un mejor prompt. Son propiedades estructurales de cómo funciona la atención a escala. La respuesta de ingeniería es mantener el contexto más pequeño y más afilado, no llenarlo y confiar.
El orden importa
Dónde colocas el contenido es tan importante como qué incluyes. Buena práctica establecida:
| Posición | Qué poner ahí |
|---|---|
| Muy arriba (prompt de sistema) | Instrucciones estables y duraderas. Persona, reglas, requisitos de formato. |
| Tras el prompt de sistema | La tarea actual, en términos llanos. |
| Justo antes del último turno del usuario | El contexto más crítico y específico para esta petición exacta. |
| En el medio | Documentos de apoyo, fragmentos recuperados — ordenados por relevancia, no por cronología. |
| Historial de conversación | Solo lo necesario para la continuidad. Pódalo de forma agresiva. |
La regla general: cuanto más cerca del turno actual, más atención recibe. Las instrucciones críticas que viven solo en el medio de un historial largo están en riesgo.
Recuperación en lugar de embutir
La tentación es meterlo todo: todos los documentos, la base de código completa, la conversación entera. Resístela.
El enfoque mejor es la recuperación selectiva: identificar qué necesita el modelo de verdad para esta petición concreta e inyectar solo eso. Un fragmento de 2.000 tokens bien recuperado del documento correcto supera a un volcado de 40.000 tokens donde la respuesta está en algún punto del medio.
Por esto existe la generación aumentada por recuperación (RAG): no solo para superar los límites de contexto, sino para mejorar la calidad manteniendo el contexto curado.
Para las sesiones interactivas aplica la misma lógica: en vez de acumularlo todo, compacta o limpia el historial periódicamente para eliminar contenido que ya no es relevante para la tarea actual. Los comandos /compact y /clear de Claude Code son herramientas de ingeniería de contexto, no solo de gestión de sesiones.
El ángulo del coste
Los tokens que envías son tokens que pagas, tanto en dinero como en latencia. Embutir el contexto con material vagamente relevante infla ambos. La ingeniería de contexto y la eficiencia de costes son el mismo problema.
Más concretamente:
- Un prompt de sistema hinchado que copias y pegas de una plantilla se paga en cada llamada.
- El historial de conversación antiguo que arrastras porque "podría ser útil" se paga en cada llamada.
- Los documentos que inyectas "por si acaso" se pagan en cada llamada.
Recortar lo que no necesita estar ahí es simultáneamente mejor para la calidad y más barato de ejecutar.
Tácticas prácticas para usuarios de Claude
En Claude.ai:
- Usa conversaciones distintas para tareas distintas. No dejes que una tarde de tangentes contamine el contexto de un proyecto enfocado.
- Resume los hilos largos antes de hacer una pregunta compleja que dependa de ellos. Un resumen explícito suele ser más útil que el historial en bruto.
- Pon lo concreto que quieres al final de un mensaje largo, no enterrado en el medio.
En Claude Code:
- Mantén tu archivo
CLAUDE.mdesbelto. Cada línea que contiene se inyecta en cada sesión. Consulta CLAUDE.md y Gestión de Contexto. - Usa
/clearal cambiar a una tarea genuinamente distinta. Usa/compactcuando quieras continuar pero la sesión está creciendo. - Referencia los archivos por ruta en lugar de pegar su contenido cuando el archivo completo no es necesario para el paso actual.
A nivel de API:
- Diseña los prompts de sistema para que contengan solo lo que toda petición realmente necesita. Mueve las instrucciones específicas de la tarea al turno del usuario.
- Para casos de uso con muchos documentos, recupera e inyecta los fragmentos relevantes en lugar de subir un corpus entero.
- Estructura el prompt de modo que el prefijo estable y reutilizable vaya primero — esto también habilita el almacenamiento en caché de prompts, un compañero natural de la ingeniería de contexto.
El cambio de mentalidad
La ingeniería de prompts pregunta: "¿Qué debería decir?" La ingeniería de contexto pregunta: "¿Qué debería ver el modelo, en qué orden, y qué debería dejar fuera deliberadamente?"
La segunda pregunta es más difícil, pero es la que de verdad determina la calidad a escala.