Context Engineering: Introducción y técnicas Cuando pensamos en el diseño de un sistema de agentes de Inteligencia Artificial pasamos horas escudriñando las capacidades de los modelos, tratando de limitar sus puntos débiles a través de técnicas de ingeniería de prompting y buscando reducir en la medida de lo posible las alucinaciones y comportamientos erróneos. Sin embargo, a menudo pasamos por alto un aspecto crucial, que depende en gran medida de nuestro diseño y arquitectura: el contexto.

¿Qué es el contexto en el ámbito de los modelos de lenguaje?

El contexto es todo lo que el modelo ve como entrada en cada inferencia (mensajes, instrucciones y datos inyectados) y que condicionan su salida. Esta información se suele componer de diversas fuentes, como pueden ser:

  • System prompt: instrucciones de alto nivel, no visibles para el usuario, que definen comportamiento, políticas, estilo y procedimientos. Suelen tener prioridad sobre el resto de fuentes y los desarrolladores le pueden añadir capas intermedias de instrucciones además de las indicadas por la empresa propietaria. Suele ser muy específico y detallado.

  • Mensajes del usuario y adjuntos (texto, imágenes, audio, vídeo, documentos), limitados por las capacidades y la ventana de contexto del modelo.

  • La memoria: información existente en la propia conversación, conversaciones previas o preferencias del usuario. Solo forma parte del contexto cuando se reinyecta explícitamente en la llamada al modelo.

  • Enriquecimiento del prompt: información externa (pública o privada; estructurada, semiestructurada o no estructurada) añadida para guiar y mejorar la respuesta. Al igual que el system prompt, suele ser invisible para el usuario. Según cómo se recupere puede ser:
    • Información provista externamente: un sistema externo al modelo recupera, filtra y transforma contenido relevante y lo inyecta en el prompt. Las fuentes pueden ser internas (tickets, manuales, wikis, bases de conocimiento, código, etc.) o públicas (webs, papers, FAQs). Se recupera desde datos estructurados (SQL, tablas), semiestructurados (JSON, XML, HTML, CSV) o no estructurados (texto libre, PDFs). Se emplean técnicas léxicas (BM25, TF‑IDF) y semánticas (embeddings y BBDD vectoriales), a menudo de forma híbrida. Esta es la arquitectura típica de RAG (Retrieval Augmented Generation).
    • Información recuperada autónomamente por el modelo (tool calling): durante la inferencia, el modelo decide llamar herramientas externas y reinyectar sus resultados en el contexto. Puede usar APIs de negocio, bases de datos, buscadores web, file stores, y utilidades de transformación (parsers, conversores, extractores de tablas, etc.). En este ámbito, el Model Context Protocol (MCP) estandariza cómo el modelo descubre y usa herramientas y recursos externos.
  • Cadenas de pensamiento (chain‑of‑thought): aunque no forman parte del contexto por defecto, guían el razonamiento interno del modelo. Solo pasan a ser contexto si se exponen y se reinyectan explícitamente (por ejemplo, como scratchpad en pipelines multi‑paso).

Limitaciones de las ventanas de contexto

Si bien los modelos se entrenan con trillones de tokens, que se acaban traduciendo en billones de parámetros de la red neuronal, la ventana de contexto es bastante más limitada. Siempre debemos tener en cuenta que la ventana de contexto es finita y que conviene sintetizar y priorizar la información en mensajes breves, concisos y sin ambigüedades. Esto se debe a varios motivos:

  • Coste computacional o complejidad: el mecanismo de atención de los transformers tiene una complejidad algorítmica de O(n^2), lo que significa que el coste computacional crece de forma cuadrática con el tamaño del contexto.
  • Saturación de la ventana de atención: aunque modelos actuales pueden llegar a tener ventanas de contexto de hasta 2 millones de tokens, en la práctica no son capaces de recuperar información de manera consistente y precisa en ventanas de contexto tan grandes. Benchmarks como Needle-in-a-Haystack NIAH (inserta una “aguja” en un “pajar” largo y mide si el modelo la recupera según posición y longitud), RULER (arXiv) (estima el “contexto efectivo” con tareas de recuperación, multihop, agregación y QA, variando la longitud del contexto), y LongBench · ∞Bench (evaluación multitarea con contextos extensos y distractores) muestran que el “contexto efectivo” suele ser bastante menor y depende de la posición de la evidencia, el ruido y la propia tarea. En este sentido, ya ha sido demostrado el fenómeno “lost in the middle”: los LLM tienden a focalizar la atención al principio y al final del contexto, degradándose en la zona media.
  • Aumenta la probabilidad de introducir información contradictoria, ambigua o engañosa que dé pie a respuestas inconsistentes, erróneas o alucinaciones.

¿Qué es el context engineering y en qué se diferencia del prompt engineering?

Ambas son técnicas de refactorización, enriquecimiento y alteración de patrones para lograr un mejor resultado. Mientras que el prompt engineering se centra sobre todo en técnicas del system prompt y de los mensajes del usuario, el context engineering se focaliza en qué información mínima y de alto valor entra en la ventana de contexto en cada paso con el objetivo de maximizar la calidad de la respuesta y la robustez del agente.

Una evolución constante: del RAG a los MCPs

Enriquecer el prompt ha evolucionado en capas, y hoy conviven enfoques que se complementan más que se sustituyen. De los inicios al presente:

  • Prompt engineering: los inicios. En un primer momento, la técnica más común era jugar con el system prompt y los mensajes del usuario para lograr el comportamiento deseado. Sin embargo, limitaciones como el knowledge cutoff (fecha de corte del conocimiento del modelo) y la incapacidad de utilizar información específica y ajustada a casos propios de uso seguían siendo un problema. Aún hoy, un buen system prompt “hardcodeado” sigue siendo la base para fijar comportamiento, estilo y límites. Conviene incluir ejemplos de comportamiento (bien escogidos, representativos y no excesivos) para anclar el modelo sin introducir ruido ni fragilidad.

  • RAG: primera gran ola. El Retrieval-Augmented Generation consiste en introducir fragmentos relevantes (chunks) desde documentación (privada o pública) que previamente ha sido indexada en embeddings almacenados en bases de datos vectoriales, para acotar la respuesta al corpus proporcionado. Supuso una ganancia de control y conocimiento actualizado sin necesidad de reentrenar el modelo, y suele ser más rápido que leer documentos completos.

  • Rerankers y (omni)multimodalidad: refinamiento del RAG. Los rerankers mejoran la selección de fragmentos con un segundo filtro (a menudo modelos cross-encoder; en otros casos, un LLM) para priorizar la adherencia a la consulta y evitar incoherencias. La omnimodalidad/multimodalidad permite recuperar información desde texto, imagen, audio o vídeo, ampliando la capacidad de los sistemas existentes.

  • Ventanas de contexto más amplias y abaratamiento de tokens: un cambio de paradigma. Este avance permitió poder pasar documentos completos, sin tener que trocearlos en chunks, cuando preservar estructura y coherencia global es clave. Aun así, más contexto implica mayor coste computacional y riesgo de “lost in the middle”, por lo que conviene evaluar el coste/beneficio.

  • Agentes con herramientas: cuando los agentes empezaron a utilizar tools para buscar y filtrar de forma autónoma, pasamos a un enfoque aún más selectivo. Los metadatos (títulos, rutas, tipos, marcas temporales, etiquetas y permisos) son decisivos para encontrar lo relevante; el propio modelo decide, tras una lectura selectiva (p. ej., vistas parciales, búsquedas, resúmenes), si debe seguir leyendo, buscar nueva información o descartar partes, mitigando los sesgos de los chunks.

  • MCPs: siguiente nivel en la integración. Con Model Context Protocol (MCP), la definición de funciones/métodos y descripciones vive fuera del contexto (en el servidor) como un catálogo de herramientas; el LLM descubre y elige qué usar en tiempo de ejecución. Esto simplifica el mantenimiento, reduce tokens y favorece una orquestación más robusta entre agente y servicios.

Conclusión: no hay sustitución, sino complementariedad. Un system prompt claro es necesario; RAG aporta control y frescura; rerankers y multimodalidad refinan la relevancia; contextos largos preservan coherencia; tools/MCP habilitan agentes más autónomos. La clave del context engineering es combinar estas piezas según la tarea, el presupuesto de tokens y los requisitos de precisión y latencia.

Algunas técnicas de context engineering

Para finalizar este artículo, me gustaría compartir con vosotros técnicas de context engineering. Algunas están inspiradas en este artículo de Anthropic, cuya lectura recomiendo encarecidamente, y otras son personales basadas en la experiencia o en otras lecturas.

  1. Recomendaciones para sistemas RAG:
    • Reformulación de consultas: Sobre la consulta que ha formulado el usuario, suele ser recomendable lanzar varias consultas paralelas con diferentes reformulaciones o alternativas para mejorar la búsqueda vectorial en la recuperación de los fragmentos. La utilización de uno o varios LLM que hagan esta labor de forma independiente suele mejorar los resultados sobre la consulta directa del usuario. Además, normalmente, tecnificar la pregunta del usuario con jerga del ámbito suele ser más efectivo. Aquí pueden ser interesante la combinación con técnicas léxicas (BM25, TF-IDF) en enfoques híbridos en los que el primer filtro sea léxico y el segundo semántico.
    • Ponderación y condensación de la información recuperada: introducir un sistema de reranker que seleccione los fragmentos más apropiados es una buena técnica cuando introducimos reformulaciones de la consulta inicial del usuario. Así, nos aseguramos de elegir los fragmentos que estén más relacionados con la pregunta original, ya sea por un sistema de votación o por un score. Otra buena práctica puede ser colocar un agente que entre los fragmentos elegidos haga un resumen o consolide la información para facilitárselo en el contexto al agente encargado de responder, evitando incoherencias e información difusa. Es especialmente útil cuando hay varias fuentes y no queremos cargar de información el contexto del agente principal.
  2. “Garbage collector” o compactación: se refiere a la acción de limpiar el contexto en cada interacción, o conjunto de interacciones, para suprimir información irrelevante, focalizar sobre cuestiones particulares y mantener con más consistencia conversaciones o procesos largos. Esto consiste en pedir al LLM un resumen de toda la información incorporada al contexto e ir consolidando ese resumen con la información adicional proporcionada con cada nueva iteración, utilizando este resumen como nuevo contexto para el siguiente paso en lugar de toda la información provista. Al ser más conciso, se optimiza el uso de tokens, es más rápido y coherente.
  3. Memoria externa estructurada: En lugar de incluir muchísima información detallada en un system prompt sobredimensionado, consiste en recurrir a archivos externos de almacenamiento (en formato markdown preferiblemente) para compilar resúmenes, notas, procesos o resultados que se hayan ido desarrollando en la interacción, con la finalidad de cargarlos ad hoc dinámicamente en el contexto. De esta forma, al tener la información compartimentada, logramos evitar incoherencias, ahorramos contexto e introducimos comportamientos más específicos para cada escenario. Además, puede servir como sistema de almacenamiento del agente para ir anotando avances o resultados sin necesidad de cargar el contexto y recuperarlos de manera más selectiva. Es importante que el sistema tenga y actualice un archivo raíz actualizado con la estructura, los archivos existentes y una descripción de qué contiene cada uno para saber cuál cargar en cada momento. Para los experimentados en la materia es un sistema similar a las rules de Cursor o el archivo CLAUDE.md en Claude Code.
  4. Jerarquización y orquestación de subagentes con contextos más acotados y especializados. En lugar de condensar toda la información en un solo agente, utilizar un sistema de agentes para distribuir y fragmentar el contexto entre éstos, de tal manera que cada uno tendrá en su ventana información sobre un mismo aspecto y con un tamaño más reducido.
  5. Consejo de sabios: en algunos escenarios puede ser beneficioso introducir varios agentes que se fuercen a buscar información u obtener resultados bajo diferentes técnicas y enfoques, volcando sus puntos de vista en un lugar común y contrastando información e iniciando bucles de depuración que lleve a respuestas consensuadas que luego se facilitan al agente encargado de responder o continuar el proceso. La decisión puede ser conjunta (aunque puede llevar a bucles infinitos y un consumo excesivo) o delegarla en un revisor sin que tengan conexión entre los agentes.
  6. Dotar de herramientas para la autonomía en la búsqueda de información. No depender de un sistema determinista programado, sino que el propio LLM decida cuándo buscar, dónde y cómo, conforme a unas instrucciones previas. Aquí son importantes los MCPs para lograr el acceso a servicios externos en los que buscar información relevante sin tener que pensar en flujos muy cerrados. El hecho de que el propio sistema pueda llevar a cabo consultas SQL, de redes de grafos o incluso vectoriales, o llamadas a APIs, alivia el exceso de información y permite seguir un hilo continuado y coherente de acciones. Otras herramientas, como la ejecución de código o el acceso al terminal, facilitan el tener información contrastada y testada con la que garantizar una respuesta más precisa. Sin embargo, muchas veces es recomendable omitir el acceso a internet del sistema agéntico para evitar información contradictoria, contaminada o en escenarios donde debe prevalecer la información interna. Como consejo, una alternativa podría ser controlar o restringir el acceso, dándole listados de fuentes autorizadas de información que sepamos que es segura y no entra en conflicto con la propia (listas blancas).
  7. Uso el tipo de modelo adecuado para cada tarea: los modelos razonadores pueden ser útiles para toma de decisiones porque al tener varias líneas de pensamiento pueden contrastar y depurar información. Pero no siempre son recomendables. Para simples resúmenes o extracciones, los modelos no razonadores son mucho más rápidos, baratos y no incurren en el riesgo de sobreajuste. También es importante valorar las capacidades de los modelos y crear una estructura que haga un mix adecuado entre los puntos fuertes y débiles de cada uno. Ajusta los parámetros para lograr mayor determinismo o creatividad (temperature, top_p) y para respuestas más detalladas o concisas (max_tokens, verbosity). En otras ocasiones, soluciones de Machine Learning tradicionales pueden ser más efectivas, introducir menos latencia y ser más baratas que un LLM. No hay que matar moscas a cañonazos.

Espero que este contenido divulgativo te haya resultado de interés y utilidad. Si es así, te animo a compartirlo y a comentarlo. Siempre estoy deseoso de poder entablar conversaciones con otros aficionados sobre estos temas. ¡Gracias por leerme!