Ingeniería de contexto
Prácticacontext engineering · gestión de contexto
La práctica de decidir qué información entra en la ventana de contexto de un modelo en cada paso: instrucciones de sistema, datos recuperados, definiciones de herramientas, historial y memoria. Si el prompt engineering trabaja la frase, la ingeniería de contexto trabaja todo el material que rodea a esa frase.
En agentes que corren muchos turnos, el contexto es un recurso escaso y caro: cada token compite con otro. La ingeniería de contexto es el trabajo de curar y mantener ese conjunto de tokens durante la inferencia — qué se inyecta, qué se resume, qué se poda, qué se guarda en memoria persistente entre sesiones y qué se deja fuera. Anthropic la describe como el conjunto de estrategias para mantener el conjunto óptimo de información durante la inferencia del modelo, más allá de los prompts. El término se popularizó en 2025 al calor de los agentes de larga duración. En AI Operations importa porque la mayoría de los fallos de un agente en producción no son fallos del modelo: son fallos de contexto. El agente no sabía algo que la empresa sí sabe, o lo sabía y se le había caído de la ventana.
En qué se diferencia de
- Prompt engineering
- El prompt engineering optimiza la instrucción concreta. La ingeniería de contexto diseña todo el pipeline que decide qué información acompaña a esa instrucción en cada paso.
- RAG
- RAG es una técnica concreta de recuperación. La ingeniería de contexto es la disciplina que decide si usar RAG, cuánto recuperar, cuándo resumirlo y cuándo tirarlo.
Ejemplos
- Podar el historial de un agente de soporte y sustituirlo por un resumen estructurado del caso antes de cada turno
- Cargar el catálogo de herramientas por fases en vez de inyectar las 60 definiciones en cada llamada
- Guardar decisiones del cliente en memoria persistente para que el agente no vuelva a preguntar lo mismo
Preguntas frecuentes
- ¿Por qué no basta con un modelo de contexto largo?
- Porque una ventana grande no es lo mismo que una ventana bien usada. Llenarla de ruido degrada la calidad de la respuesta y dispara el coste por tarea. El límite práctico no suele ser cuántos tokens caben, sino cuántos ayudan.
- ¿Quién se ocupa de esto en un equipo de AI Operations?
- Normalmente quien construye el agente, junto con quien conoce el proceso de negocio. Es un trabajo mixto: hace falta saber de arquitectura del agente y también saber qué información del proceso es la que de verdad decide.