Modelos de lenguaje (LLM)

Context engineering (ingeniería del contexto)

Context engineering es la práctica de diseñar y gestionar todo el contexto que un modelo de IA recibe en cada interacción: prompt del sistema, ejemplos few-shot, fragmentos recuperados por RAG, herramientas disponibles, estado conversacional, instrucciones de formato. Es la evolución natural del prompt engineering hacia un campo más amplio que reconoce que el prompt es solo una pieza del contexto total.

Por Ana María González Actualizado: 9 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

El término context engineering se popularizó en 2024-2025 a medida que los modelos crecieron en ventanas de contexto (32K → 128K → 1M tokens) y los sistemas se hicieron más complejos (agentes con muchas herramientas, RAG con miles de fragmentos, cache de prompt persistente). Lo que importa ya no es solo el "prompt" en sentido clásico (la última pregunta) sino la totalidad del contexto que ve el modelo. Las decisiones de context engineering: qué información incluir y cuál no (más no es mejor; ver lost in the middle); cómo organizar el orden (lo más importante al inicio o al final, evitar el medio); qué cachear (prompt cache reduce coste y latencia); qué herramientas exponer y con qué descripción; qué historial conversacional preservar; qué formato pedir. Buenas prácticas emergentes: separar contexto estable (sistema, conocimiento corporativo) que se cachea, de contexto variable (consulta, historial reciente); usar structured output para forzar formato; mantener herramientas con descripciones cortas y precisas; reordenar fragmentos RAG para mitigar lost in the middle; logs de qué contexto exacto se envió en cada llamada para depurar. Es el estado del arte 2026 para sistemas IA empresariales.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa con sistemas IA en producción, dominar context engineering es la diferencia entre un sistema que funciona regular y uno que funciona muy bien. La regla práctica: cualquier sistema con más de unos cientos de consultas/mes merece una revisión específica de context engineering al menos cada trimestre; los modelos cambian, los flujos evolucionan, lo que era óptimo hace 3 meses puede no serlo ahora. La inversión es modesta (algunos días de trabajo de un ingeniero IA) y los resultados típicos son significativos: latencia reducida, coste reducido (cache + menos tokens innecesarios), calidad mejorada (mejor uso del contexto disponible). En 2026 muchas empresas españolas están descubriendo que su problema "el modelo no entiende bien" se resuelve no con un modelo mejor, sino con context engineering serio.

Ejemplo concreto

Caso real

Una empresa española de servicios automatizó la generación de informes técnicos con un asistente IA. Versión inicial: cada informe enviaba el modelo plantilla + datos + instrucciones (8.000 tokens promedio), respuestas tomaban 12-18 segundos, coste por informe ~0,12 €. Tras revisión de context engineering: separaron contexto estable (plantilla + 6 ejemplos few-shot + instrucciones) que se cachean (90% del prompt), del contexto variable (datos del informe específico, ~800 tokens). Resultado: latencia bajó a 4-6 segundos, coste por informe ~0,03 € (75% menos), calidad de output ligeramente superior por ejemplos few-shot consistentes. Inversión: 4 días de trabajo de un ingeniero. Ahorro anual estimado: ~14.000 € + mejor experiencia de usuario. Sin cambiar de modelo.