De la ingeniería de prompts a la ingeniería de contexto

¿Te acuerdas de los prompts «mágicos»? Aquellas fórmulas que circulaban por internet en 2023 y que prometían sacar lo mejor de ChatGPT: «actúa como un experto con veinte años de experiencia», «piensa paso a paso», «si lo haces bien te daré una propina». Algunas funcionaban. Muchas dejaban de funcionar con la versión siguiente del modelo. Y casi nadie sabía muy bien por qué.

En muy poco tiempo, la forma de trabajar con modelos de lenguaje ha cambiado de problema dos veces. Primero buscábamos la frase exacta. Después, cómo conectar el modelo con lo que no sabía. Ahora la pregunta es otra: qué le dejamos ver y qué le quitamos de encima.

La época de los trucos

Los primeros trucos nacieron por ensayo y error, y algunos tenían más fundamento del que parecía.

Asignar un papel al modelo («eres un profesor de secundaria») cambiaba el tono y el nivel de la respuesta. Pedirle que razonara paso a paso antes de responder mejoraba de forma medible los problemas de lógica y matemáticas; se describió en 2022, en trabajos como el de Wei y su equipo en Google, y a partir de 2024 acabó integrado en los propios modelos como «modo de razonamiento». Darle dos o tres ejemplos de lo que querías (few-shot) funcionaba mejor que explicárselo. Y dividir una tarea larga en varias llamadas encadenadas evitaba que se perdiera por el camino.

El problema era la fragilidad. Lo que funcionaba con un modelo fallaba con el siguiente, y era difícil distinguir la técnica de la superstición. Mucho de aquello era, en el fondo, compensar las limitaciones de una máquina concreta.

Cuando la frase dejó de ser el problema

Al llevar los modelos a productos reales aparecieron dos problemas que ninguna frase resolvía. El modelo no sabía lo que sabía la empresa: sus documentos, sus políticas, sus datos. Y no se comportaba de forma constante en un dominio muy específico. Es la distancia entre la demo y la producción.

Para lo primero llegó el RAG (generación aumentada por recuperación): antes de responder, el sistema busca los documentos relevantes y se los pone delante al modelo. Reduce mucho las respuestas inventadas por desconocimiento, aunque no las elimina. Si la búsqueda trae el documento equivocado, el modelo responde con la misma seguridad.

Para lo segundo, el ajuste fino: volver a entrenar parcialmente el modelo con ejemplos del dominio, para fijar un tono o un formato sin tener que repetirlo en cada llamada.

Y a medida que el modelo dejó de hablar solo con personas y empezó a alimentar a otros programas, hubo que controlar también la forma de la salida. Un JSON que no se puede leer rompe la cadena entera. Quien diseñaba los prompts tuvo que pensar en variables de entrada, validaciones y casos límite, y en lo que pasa cuando alguien cuela instrucciones donde no debe, la inyección de prompts. Ya no bastaba con redactar bien. Había que entender el contrato de datos que rodeaba cada llamada.

Ahí cambió el centro de gravedad. Importaba menos cómo se formulaba la pregunta y más qué información rodeaba al modelo.

La ingeniería de contexto

El término se popularizó a mediados de 2025. Anthropic lo describió como el conjunto de estrategias para seleccionar y mantener la información que el modelo ve en cada momento, más allá del prompt. Su recomendación de fondo me parece muy sensata: buscar el conjunto más pequeño de información que de verdad aporte señal.

La idea no es tanto una técnica nueva como un cambio de prioridad. Los modelos actuales planifican, descomponen tareas y se corrigen bastante bien por sí solos. El trabajo ya no es enseñarles a pensar, sino decidir qué tienen a mano: qué documentos, qué historial, qué herramientas. Y apartar lo que solo hace ruido. Es, a escala de sistema, lo mismo que pasa en un chat cualquiera: el modelo relee todo lo que tiene delante, y lo que sobra estorba (lo explicaba en «Ocho hábitos para que ChatGPT te responda mejor»).

En la práctica, eso significa sustituir instrucciones fijas por acceso bajo demanda. La búsqueda en documentos deja de ser un bloque de texto que se mete siempre y pasa a ser una herramienta que el modelo usa cuando la necesita. Lo mismo con las consultas a otros sistemas (un CRM, un calendario, una base de datos), con la búsqueda en internet o con las skills, paquetes de instrucciones de un dominio que el modelo carga solo cuando la tarea lo pide. Y en los sistemas agénticos, como Claude Code o Codex, parte del trabajo se delega en subagentes, cada uno con su propio contexto acotado.

La ingeniería de prompts intentaba anticipar todo lo que el modelo podría necesitar y dárselo por adelantado. La ingeniería de contexto acepta que no se puede anticipar todo. Construye un entorno en el que el modelo puede ir a buscarlo.

Por qué menos reglas puede funcionar mejor

Lo comentan muchos equipos que construyen agentes: al pasar a un modelo más capaz, quitar buena parte de las instrucciones acumuladas para el anterior no empeora el resultado. A menudo lo mejora. No es un estudio, es experiencia de práctica, pero los propios fabricantes lo reconocen. La guía de Anthropic para sus modelos recientes avisa de que las instrucciones escritas en tono de alarma («IMPORTANTE: SIEMPRE debes…») para modelos que obedecían poco hacen que los nuevos, más atentos, se pasen de celo. Recomienda decirlo con normalidad.

Un caso típico: un asistente de atención al cliente arrastra una lista de veinte prohibiciones que se fueron añadiendo cada vez que el modelo anterior metía la pata. Con el modelo nuevo, la mitad de esas reglas corrigen errores que ya no comete, y la otra mitad lo vuelven rígido: se niega a cosas razonables por miedo a una regla que no venía al caso.

Tiene una explicación bastante razonable. Muchas de esas reglas existían para corregir lo que el modelo anterior no sabía hacer solo. Con un modelo mejor, dejan de corregir y empiezan a estorbar. Imponen una ruta de razonamiento peor que la que el modelo trazaría por su cuenta. Ocupan espacio en un contexto que no es gratis. Y, cuanto más detallan el cómo, menos margen dejan para resolver bien el qué.

De ahí una costumbre que recomiendo: cada cierto tiempo, retira tus instrucciones acumuladas y mira qué pasa. Lo que hace falta, vuelve a hacer falta enseguida. Lo demás estaba compensando una limitación que ya no existe.

Qué se hace ahora

Si hubiera que resumir cómo se trabaja hoy al diseñar un sistema con IA, serían cuatro costumbres.

Definir antes cómo se sabrá que el resultado es bueno. En código es fácil: los tests pasan o no pasan. En un texto, un guion o una respuesta a un cliente no hay un sí o un no, pero se puede medir igual: con criterios explícitos, con ejemplos de lo bueno y de lo malo, o con otro modelo que evalúe la salida contra esos criterios. Esta es, por cierto, la parte en la que más se nota tener formación lingüística.

Alimentar el sistema con datos reales, no con suposiciones sobre cómo funcionará.

Cambiar instrucciones fijas por fuentes vivas donde tiene sentido: documentos, sistemas de la empresa, búsqueda.

Y hacer la poda cada pocos meses, cada vez que cambia el modelo.

Saber pedir bien las cosas no ha dejado de importar. Pero ya no es el centro del problema. El centro es el mundo que rodea al modelo mientras trabaja: qué ve, a qué puede acceder y qué decide él. Y diseñar ese mundo se parece mucho más a organizar información para un lector que a escribir la frase perfecta.

Si quieres recibir los próximos artículos, suscríbete a la carta de Máquinas Hablantes.

Fuentes

• Wei, J. et al. (2022). «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models».
• Kojima, T. et al. (2022). «Large Language Models are Zero-Shot Reasoners».
• Lewis, P. et al. (2020). «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks».
• Anthropic (29 de septiembre de 2025). «Effective context engineering for AI agents».
• Anthropic. «Claude prompting best practices», sobre rebajar el lenguaje enfático con los modelos recientes.