Ingeniería de contexto: el trabajo antes del aviso
· 7 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
La palabra del momento, en el pequeño mundo de los agentes de IA, es ingeniería de contexto.
Parece una etiqueta más inventada para vender algo que ya hicimos. En parte lo es. Sin embargo, como suele suceder, la etiqueta prevalece porque da nombre a un dolor real.
El problema es éste: los modelos no fracasan sólo porque "no piensan". A menudo fallan porque los enviamos a trabajar en la habitación equivocada.
Les damos viejas instrucciones. Le ocultamos archivos importantes. Les pasamos documentos demasiado largos y no decimos lo que importa. Les mostramos registros sin prioridad. Les damos diez herramientas sin explicarles cuándo usarlas. Entonces nos sorprende que el agente se mueva como una persona despierta en un apartamento desconocido.
El mensaje es la frase que le dices. El contexto es el mundo que preparas a su alrededor.
De la ingeniería rápida a la ingeniería de contexto
A menudo se pensaba que la ingeniería rápida era escritura. Elija las palabras correctas, pregunte de la manera correcta, agregue ejemplos, especifique el formato.
La ingeniería de contexto está más cerca de la arquitectura.
No se pregunta simplemente "¿cómo formulo la solicitud?". Pregunta:
- ¿Qué información se necesita realmente?
- ¿Qué son los ruidos?
- ¿Qué hay que recuperar sobre la marcha?
- ¿Qué hay que recordar?
- ¿Qué herramientas deberían exponerse?
- ¿Qué instrucciones son estables y cuáles dependen de la tarea?
- ¿Cómo hago para que el agente comprenda qué es la autoridad?
Es un cambio sutil pero enorme. Porque cuando trabajas con agentes, el contexto no es un bloque estático. Cambia a cada paso.
El agente abre un archivo, aprende algo, ejecuta una prueba, recibe un error, actualiza el plan, llama a una herramienta, descubre una dependencia. En cada vuelta tiene que decidir qué llevar consigo y qué dejar fuera.
Esto es ingeniería.
El contexto no es un vertedero
Las plantillas con grandes ventanas contextuales nos dieron la tentación: incluyamos todo.
Es comprensible. Si tengo un millón de tokens, ¿por qué debería elegir?
Porque incluso cuando puedes poner todo, eso no significa que todo ayude. De hecho, el ruido tiene un coste. Cuesta tokens, cuesta atención, cuesta latencia, cuesta calidad. Un modelo puede perderse en detalles irrelevantes como nosotros cuando abrimos veinte pestañas y ya no recordamos por qué.
El buen contexto tiene una jerarquía:
- instrucciones y políticas del sistema;
- objetivo específico;
- situación actual;
- datos relevantes;
- limitaciones;
- herramientas disponibles;
- realizar un seguimiento de las decisiones ya tomadas.
No es necesario tratar todo al mismo nivel. Un comando de usuario vale más que una nota antigua. Una prueba fallida vale ahora más que una preferencia estética de hace tres meses. Una política de seguridad vale más que un atajo en la producción.
La ingeniería de contexto también significa dar ponderaciones, no sólo datos.
Memoria: recuerda menos, recuerda mejor
La memoria en los agentes es uno de los temas más resbaladizos.
Como usuario, quieres que el agente te conozca. Quieres que recuerde el tono, el plan, las convenciones, las cosas ya decididas. Como ingeniero, usted sabe que cada recuerdo persistente también es un riesgo: puede ser incorrecto, antiguo, demasiado personal, demasiado genérico o no verificable.
Una memoria útil debe tener al menos tres cualidades:
- procedencia: ¿de dónde viene esta información?
- fecha: ¿cuándo fue cierto?
- finalidad: ¿para qué tipo de tarea debería utilizarse?
Sin estas tres cosas, la memoria se convierte en superstición.
Me gusta pensar en la memoria agente como un libro de trabajo, no como una mente mágica. Hay notas temporales, decisiones confirmadas, preferencias de estilo, limitaciones técnicas, enlaces a fuentes. Algunas cosas caducan. Algunos necesitan ser reescritos. Algunos deben ser eliminados porque el agente los malinterpretó.
Un buen sistema debe hacer que este mantenimiento sea normal. No heroico.
Recuperación y herramientas no son lo mismo
Cuando hablamos de contexto, a menudo terminamos inmediatamente en RAG. Incrustación, base de datos vectorial, fragmentación, reclasificación.
Todo útil. Pero la recuperación es sólo una manera de llevar información al modelo. Él no es el único.
Un agente puede obtener contexto leyendo archivos, consultando una API, llamando a un servidor MCP, abriendo un navegador, ejecutando pruebas, buscando en Slack, mirando un panel, preguntando al ser humano.
Lo interesante es decidir qué ruta utilizar y cuándo.
Si el agente necesita responder a una pregunta histórica, quizás basta con recuperarla. Si tiene que corregir un error, tiene que leer código real. Si necesita comprender por qué falla una implementación, debe consultar registros nuevos. Si necesita escribirle a un cliente, debe recuperar el tono, el historial y el estado del ticket. Si debe actuar sobre la producción, debe pedir permiso.
El contexto no es una base de datos. Es un flujo de trabajo.
El buen agente también sabe ignorar
Una señal de madurez en los agentes será la capacidad de decir: no necesito esta información.
Parece trivial, pero es muy difícil. Se acumulan muchos sistemas agentes. Cada llamada de herramienta agrega texto. Cada error permanece en el búfer. Cada archivo leído se suma a la pila. Al final el modelo tiene una historia muy larga y ningún mapa.
Se necesita compresión. Se necesita una síntesis intermedia. Necesita estar estructurado.
No "eso es todo lo que pasó", sino:
- el objetivo sigue siendo válido;
- hipótesis actual;
- archivos ya comprobados;
- decisiones tomadas;
- riesgos abiertos;
- próxima acción.
Esto hace que el agente sea menos teatral y más útil. No porque parezca más inteligente, sino porque trabaja con un escritorio ordenado.
Ingeniería de contexto para equipos, no para artistas rápidos
La razón por la que este tema me interesa es que transfiere la responsabilidad del individuo al sistema.
En la ingeniería rápida, a menudo gana el que mejor puede hablar con el modelo. En ingeniería de contexto, gana el equipo que mejor organiza su trabajo: documentación, convenciones, problemas, registros, pruebas, propiedad, nombres, fuentes.
Un repositorio limpio se convierte en un mejor contexto. Un número bien escrito se convierte en un mejor combustible. Un runbook actualizado ahorra tokens y ansiedad. Un registro de cambios claro reduce las alucinaciones.
Esta es una noticia buena y algo incómoda. Bello porque premia las buenas prácticas. Es un inconveniente porque no se puede resolver todo con un mensaje inteligente.
Los agentes amplifican la seguridad del sistema que encuentran.
##Cómo lo aplicaría mañana
Si tuviera que introducir la ingeniería de contexto en un proyecto real, empezaría por cosas pequeñas:
- un archivo de instrucciones del proyecto breve y mantenido;
- buenos ejemplos de resultados esperados;
- una lista de herramientas disponibles y casos en los que utilizarlas;
- decisiones arquitectónicas escritas de manera citable;
- problema con contexto mínimo obligatorio;
- fácil de recuperar registros y pruebas;
- memoria persistente modificable por los humanos.
Entonces mediría una cosa sencilla: ¿cuántas veces el agente tiene que pedir aclaraciones o va en la dirección equivocada?
Si sucede con frecuencia, no agregaría un modelo más grande de inmediato. Yo miraría el contexto.
Mi lectura
Ingeniería de contexto es una palabra un poco exagerada, sí. Pero el concepto es sólido.
Nos recuerda que la inteligencia de un agente no está sólo en el modelo. Está en el entorno que le preparamos: lo que ve, lo que recuerda, lo que puede hacer, lo que tiene prohibido hacer, qué fuentes reconoce como verdaderas.
La parte humana es ésta: preparar bien el contexto es una forma de cuidar. Le dice al agente, pero también al equipo: "No quiero que adivines, quiero que tengas lo que necesitas".
Menos magia. Cuarto más limpio. Los agentes lo necesitan tanto como nosotros.
Fuentes
- Blog de LangChain: El auge de la ingeniería contextual
- Simon Willison: ingeniería de contexto
- [Protocolo de contexto modelo: introducción] (https://modelcontextprotocol.io/introduction)
- [Antrópico: Construyendo agentes efectivos](https://www.anthropic.com/engineering/building- Effective-agents)
- OpenAI: Nuevas herramientas para agentes de construcción