Ingeniería de contexto (context engineering)

La ingeniería de contexto es la práctica de decidir qué información entra en la ventana de contexto de un modelo, en qué orden y en qué formato, para maximizar la calidad de sus respuestas. Va más allá de redactar un buen prompt: abarca el system prompt, los datos recuperados, las definiciones de herramientas, el historial de la conversación y la memoria del agente. Dicho de forma breve, si la ingeniería de prompts trata de cómo pedir, la ingeniería de contexto trata de qué poner delante del modelo para que pueda responder bien.

Cómo funciona

Un modelo como Claude solo razona sobre lo que tiene dentro de su ventana de contexto en ese momento. No sabe nada de tu empresa, tu base de datos o la conversación de ayer salvo que se lo entregues. La ingeniería de contexto consiste en construir ese paquete de entrada de forma deliberada. Los componentes habituales son:

• Instrucciones del sistema: rol, reglas, formato de salida y guardrails en el system prompt.
• Conocimiento recuperado: fragmentos de documentos inyectados mediante RAG, filtrados por relevancia.
• Herramientas y su esquema: definiciones de funciones disponibles vía tool use o conectores MCP.
• Estado y memoria: resúmenes del historial, decisiones previas, variables del agente.
• Ejemplos: demostraciones few-shot cuando aclaran el formato esperado.

La parte difícil no es añadir, es seleccionar. Cada token que ocupas tiene un coste y compite por la atención del modelo. El arte está en entregar lo justo: suficiente contexto para acertar, sin saturar la ventana con ruido que diluye la señal.

Por qué importa

Cuando construyes agentes o aplicaciones sobre Claude, la mayoría de los fallos no vienen de un modelo malo, sino de un contexto mal gestionado: información obsoleta, instrucciones contradictorias, documentos irrelevantes recuperados por un RAG impreciso o un historial tan largo que el modelo pierde el hilo. La ingeniería de contexto es lo que separa un prototipo que funciona en una demo de un sistema fiable en producción.

En agentes de larga duración el problema se agudiza. A medida que el agente ejecuta pasos, el contexto crece con resultados de herramientas, errores y mensajes intermedios. Sin estrategias de compactación (resúmenes, poda de mensajes antiguos, recuperación bajo demanda) el agente degrada su rendimiento y dispara el coste por token. Técnicas como el prompt caching reducen el gasto de reenviar contexto estable en cada turno.

Ejemplo práctico

Imagina un asistente de soporte. Una ventana de 200K tokens parece enorme, pero volcar los 500 artículos del centro de ayuda en cada petición es un error: encarece la llamada y entierra la respuesta correcta entre textos irrelevantes. La ingeniería de contexto aquí sería:

1. Un system prompt breve con el tono y las reglas de escalado.
2. Recuperar solo los 3-5 fragmentos más relevantes a la consulta del usuario.
3. Incluir un resumen de los últimos turnos en lugar de la transcripción completa.
4. Exponer únicamente las herramientas que ese flujo necesita.

Qué NO es

No es lo mismo que la ingeniería de prompts, aunque la incluya: el prompt es una pieza del contexto, no el todo. Tampoco es simplemente ampliar la ventana de contexto; más espacio no equivale a mejor rendimiento, y a menudo introduce el problema del contexto perdido en medio. Y no se reduce a RAG: RAG es una técnica de recuperación concreta dentro de una estrategia de contexto más amplia que también gobierna herramientas, memoria y formato. Dominar esta disciplina es clave para dar el salto hacia agentes e integraciones con MCP y pasar de experimentos a sistemas de producción.