La ingeniería de contexto sustituye a la ingeniería de prompts como la habilidad de IA que importa

La ingeniería de prompts nunca trató realmente de encontrar palabras mágicas. Se trataba de darle al modelo suficiente información relevante, en un formato que pudiera usar, para producir una buena respuesta. Esa distinción importaba menos cuando la tarea era un simple intercambio de pregunta y respuesta. Importa enormemente ahora que la mayoría de los sistemas de IA en producción son agentes: bucles que llaman herramientas, leen resultados, recuperan documentos y mantienen estado a lo largo de decenas de pasos.

La habilidad que determina si esos sistemas funcionan ya no es la redacción del prompt. Es la ingeniería de contexto: la disciplina de decidir qué entra en la ventana de contexto del modelo en cada paso, cómo se estructura y cuándo se descarta. Los equipos que tratan esto como algo secundario construyen agentes caros, lentos y que fallan de maneras difíciles de depurar.

Por qué la ingeniería de prompts dejó de ser suficiente

Un prompt bien elaborado asume que el modelo ya tiene lo que necesita para responder. Los flujos de trabajo agénticos no funcionan así. Un agente que depura un incidente en producción puede reunir fragmentos de logs, un manual operativo, tres hilos de Slack relacionados y el resultado de dos llamadas a herramientas, todo antes de escribir una sola palabra de su respuesta real. Nada de eso es “el prompt” en el sentido de 2023. Es un presupuesto de contexto, y cada token en él es una decisión.

Las ventanas de contexto más grandes empeoraron las cosas antes de mejorarlas. Cuando los modelos de la era GPT-4 topaban en torno a 32.000 tokens, los equipos se veían obligados a ser selectivos por necesidad. Las ventanas de contexto de un millón de tokens eliminaron esa restricción, y la respuesta ingenua —volcar todo lo relevante y dejar que el modelo lo ordene— resultó degradar el rendimiento. La investigación sobre recuperación en contextos largos muestra sistemáticamente que los modelos prestan atención de forma desigual en un contexto grande, favoreciendo a menudo la información cercana al principio o al final y perdiendo precisión en los datos enterrados en el medio. Más tokens no es más señal. A menudo es más ruido con una factura de API más alta.

Las cuatro tareas de la ingeniería de contexto

En la práctica, la ingeniería de contexto se descompone en cuatro problemas separables, y la mayoría de los fallos de los agentes se remontan a resolver mal uno de ellos.

Selección de recuperación

Decidir qué incorporar al contexto. Esta es la tarea para la que se construyeron los pipelines de RAG, pero la calidad de la selección importa más que la exhaustividad de la recuperación. Devolver los 20 fragmentos más similares semánticamente no es lo mismo que devolver los 5 que realmente responden a la pregunta. Los equipos que optimizan para exhaustividad en lugar de precisión terminan de vuelta en la trampa de volcarlo todo, solo que ahora es un modelo de embeddings quien lo hace en lugar de una persona.

Compresión

Las salidas brutas de herramientas, archivos de log y fragmentos de documentos rara vez merecen enviarse textualmente. Una traza de pila de 400 líneas normalmente se comprime a tres líneas relevantes y un resumen sin perder nada que el modelo necesite. La compresión es de donde proviene la mayor parte del ahorro de costes en tokens en sistemas de agentes en producción, y también es donde un resumen ingenuo puede eliminar silenciosamente el único detalle que importaba.

Estructura y orden

El lugar donde se sitúa la información en el contexto afecta a si el modelo la usa correctamente. Colocar restricciones e instrucciones justo antes del paso de generación, en lugar de enterrarlas al principio de un prompt de sistema largo, mejora de forma medible el seguimiento de instrucciones en contextos largos. El orden no es cosmético: es estructural.

Reescritura en memoria

Los agentes que operan en más de un turno necesitan una política sobre qué se escribe en memoria persistente frente a qué permanece efímero en el contexto actual. Escribirlo todo convierte la memoria en un segundo vertedero con el mismo problema de ruido. No escribir nada hace que el agente vuelva a derivar los mismos hechos en cada sesión, quemando tokens y latencia en redescubrimiento.

Dónde se equivocan los equipos

El fallo más común es tratar el contexto como gratuito. No lo es. Cada documento adicional en la ventana añade latencia, coste y, a partir de cierta densidad, una caída medible en la calidad de la respuesta, a veces llamada “degradación del contexto”. El segundo fallo más común es el ensamblaje estático del contexto: construir un único pipeline de construcción de contexto y usarlo para cada consulta, sin importar si la tarea necesita tres documentos o treinta. El tercero es omitir por completo la política de desalojo, de modo que una sesión de agente de larga duración acumula salidas de herramientas hasta que la mayor parte de la ventana de contexto es andamiaje de pasos que el agente ya no necesita.

Cómo se ve esto en un sistema que funciona

Los equipos que lo hacen bien suelen tener un presupuesto de contexto explícito por paso: un tope de tokens para documentos recuperados, un tope separado para salidas de herramientas, y una asignación reservada para instrucciones y los turnos de conversación recientes que nunca se desplaza. Registran qué había en el contexto cuando un agente produjo una mala respuesta, igual que registrarían una traza de pila, porque la composición del contexto es ahora una superficie de depuración principal, no un detalle de implementación.

Conclusiones prácticas

Deja de optimizar la redacción del prompt de forma aislada. Auditar qué entra realmente en la ventana de contexto en cada paso de la ejecución del agente, y medir cuánto de eso usa realmente el modelo.
Trata la precisión de recuperación como más importante que la exhaustividad. Devolver menos resultados más relevantes es mejor que devolver más resultados y esperar que el modelo los filtre.
Construye un paso de compresión para salidas de herramientas y logs antes de que lleguen a la ventana de contexto, no después de que una revisión de costes señale el gasto en tokens.
Coloca la instrucción de la tarea y las restricciones cerca del punto de generación, no enterradas al principio de un prompt de sistema largo, especialmente cuando el contexto supera unos pocos miles de tokens.
Define una política explícita de reescritura en memoria en lugar de recurrir por defecto a acumularlo todo o descartarlo todo entre turnos.