Definición en una frase
Diseño sistemático de instrucciones, datos, herramientas, memoria y estado que se entregan al modelo en cada paso.
Definición: diseñar la información disponible para una tarea
La ingeniería de contexto es el diseño y la gestión de la información que se presenta a un modelo de IA durante una ejecución para ayudarle a realizar una tarea concreta. Puede incluir instrucciones, el mensaje del usuario, partes del historial, ejemplos, resultados de herramientas, documentos recuperados y datos sobre el estado actual del trabajo. La decisión central no es solo qué decirle al modelo, sino qué información incluir, en qué forma, en qué momento y con qué límites.
El término se usa en un campo que evoluciona y no tiene una definición formal universal aceptada por todas las disciplinas y proveedores. Es más preciso tratarlo como una denominación práctica para un conjunto de decisiones técnicas observables: reunir información, elegir qué parte es pertinente, organizarla para la tarea y actualizarla cuando cambian los resultados o el estado del sistema. El nombre no garantiza que un sistema aplique un método específico ni que mejore su rendimiento.
En una conversación sencilla, el contexto puede consistir principalmente en instrucciones y mensajes. En una aplicación con recuperación de documentos o herramientas, también puede incorporar resultados externos. En un agente que trabaja en varias etapas, parte de la información puede guardarse fuera de la conversación y volver a incorporarse cuando se necesite. En todos los casos, lo importante es el contenido efectivamente disponible para el modelo en esa ejecución.
Qué puede formar parte del contexto
Las instrucciones establecen el papel, los límites o el formato esperado. El mensaje del usuario expresa la necesidad inmediata. El historial puede aportar referencias a decisiones previas, siempre que esas intervenciones sigan siendo pertinentes. Los ejemplos muestran patrones de respuesta o de resolución, aunque su utilidad depende de que sean representativos de la tarea.
Los documentos recuperados y los resultados de herramientas aportan información externa al mensaje inicial. Una herramienta puede, por ejemplo, devolver el contenido de un archivo o una respuesta de una búsqueda. El estado de trabajo puede recoger qué se ha hecho, qué falta y qué resultado debe conservarse para el siguiente paso. Estos elementos no tienen que estar siempre presentes: incluirlos sin necesidad también consume espacio y puede añadir ruido.
El contexto no es necesariamente un único texto redactado por una persona. Puede ser una composición que prepara una aplicación antes de cada llamada al modelo. Una parte puede proceder de una solicitud; otra, de una fuente de datos, una búsqueda, el historial o una operación previa. Por eso, analizar solo el prompt visible para el usuario no siempre permite saber qué información recibió el modelo.
Elementos habituales y preguntas de control
| Elemento | Para qué puede servir | Pregunta de control |
|---|---|---|
| Instrucciones | Delimitar la tarea, las restricciones y el formato. | ¿Son claras y compatibles entre sí? |
| Historial y estado | Mantener continuidad entre pasos o turnos. | ¿Qué parte sigue siendo necesaria y está vigente? |
| Documentos y resultados de herramientas | Aportar datos para responder o actuar. | ¿Son pertinentes, fiables y suficientes para esta tarea? |
| Ejemplos | Ilustrar un patrón de respuesta o trabajo. | ¿Representan el caso actual sin inducir una imitación inadecuada? |
Cómo funciona el ciclo de ingeniería de contexto
Una estrategia de contexto puede entenderse como un ciclo. Primero se identifica qué necesita la tarea: por ejemplo, responder una pregunta, modificar un archivo o comparar fuentes. Después se obtiene la información disponible mediante el mensaje, el historial, documentos, herramientas o una memoria externa. Obtener datos no significa que todos deban incluirse: hay que seleccionar lo pertinente, revisar su vigencia y descartar lo que no ayude.
A continuación se ordena y transforma el material. Puede ser necesario extraer fragmentos, resumir resultados, separar hechos de preguntas abiertas o estructurar el estado del trabajo. Luego se incorpora lo elegido al contexto que verá el modelo. Tras su respuesta o acción, el sistema puede comprobar el resultado y actualizar el estado: conservar un hallazgo útil, reemplazar información caducada o buscar lo que aún falta.
El proceso se repite cuando la tarea continúa. La estrategia adecuada depende de la tarea, las fuentes y las capacidades del sistema; no existe una receta que asegure un resultado correcto. Una selección pobre puede omitir un dato decisivo. Una selección excesiva puede dificultar que el modelo encuentre lo importante. Por ello, conviene diseñar el ciclo alrededor de necesidades concretas y observar qué información usa el sistema.
Ciclo básico
- 01Definir qué necesita la tarea y qué resultado se espera.
- 02Obtener posibles datos del mensaje, el historial, documentos o herramientas.
- 03Seleccionar, ordenar y transformar la información pertinente.
- 04Incluirla en el contexto disponible para el modelo.
- 05Revisar la respuesta o acción y actualizar el estado para el siguiente paso.
Ejemplo aplicado: agente de programación
Imaginemos que una persona pide corregir un error en una aplicación. Cargar de una vez todos los archivos del proyecto puede ser innecesario. Una estrategia más selectiva empieza por identificar el mensaje de error y localizar los componentes probablemente relacionados. El sistema puede consultar archivos, pruebas y documentación mediante herramientas y aportar al modelo los fragmentos pertinentes, junto con las restricciones del cambio solicitado.
Después de una modificación, los resultados de pruebas o las salidas de herramientas pueden pasar a ser parte del contexto del siguiente paso. Si el trabajo debe continuar en otra etapa, una nota de estado puede resumir el objetivo, las decisiones, los archivos modificados y las tareas pendientes. Esa nota es una representación parcial del trabajo, no una transcripción completa ni una garantía de que no se haya perdido un detalle.
Este patrón ilustra por qué gestionar el contexto puede incluir tanto consultas a demanda como el mantenimiento de información entre etapas. Los sistemas descritos para agentes de larga duración emplean mecanismos de traspaso y estado externo para continuar el trabajo cuando una sola ventana de contexto no basta. La forma concreta de implementarlos depende del agente.
Ejemplo aplicado: atención al cliente
En un asistente de atención al cliente, la pregunta de una persona podría combinarse con la política vigente aplicable al caso y con una parte pertinente del historial autorizado. Por ejemplo, para consultar el estado de una devolución, el sistema podría necesitar la consulta actual, la regla correspondiente y el dato del pedido necesario para identificar la operación. Este ejemplo es ilustrativo: las fuentes disponibles no documentan un sistema concreto de atención al cliente con esta configuración.
La selección también debe limitar el acceso a lo necesario. Si un dato personal no ayuda a resolver la solicitud, no hay motivo para incorporarlo por defecto al contexto. La aplicación debe definir qué información puede recuperar, quién puede acceder a ella y cuánto tiempo conservarla. Estas decisiones de privacidad y autorización pertenecen al diseño del sistema; no se resuelven simplemente añadiendo instrucciones al modelo.
El asistente también debe distinguir entre política vigente y mensajes anteriores que puedan estar desactualizados. Si la respuesta depende de una norma actual, la información recuperada debe poder contrastarse con una fuente autorizada. El hecho de que un documento aparezca en el contexto no prueba por sí solo que sea correcto, vigente o aplicable al caso.
Ejemplo aplicado: agente de investigación
Un agente de investigación puede distribuir una pregunta compleja en varias líneas de trabajo y mantener separados los materiales reunidos en cada una. En vez de presentar todos los documentos a un único modelo en cada paso, puede conservar fuentes y hallazgos por tema, y entregar al coordinador una síntesis con referencias al material pertinente y preguntas aún sin resolver.
Una síntesis facilita el traspaso entre etapas, pero puede omitir matices o reservas. Por eso, el estado de trabajo debería diferenciar qué se observó en las fuentes, qué es una inferencia y qué queda pendiente de comprobar. Si la conclusión depende de un detalle, puede ser necesario volver al documento original en lugar de confiar únicamente en un resumen.
Un sistema de investigación multiagente descrito por Anthropic constituye un ejemplo de organización del trabajo entre agentes con contextos separados y síntesis de hallazgos para un agente coordinador. Es un caso concreto de diseño y no demuestra que la misma arquitectura sea superior para todas las investigaciones.
Conceptos cercanos: prompt, RAG, fragmentación, memoria y ventana de contexto
La ingeniería de prompts se centra principalmente en redactar y organizar instrucciones para orientar la respuesta del modelo. La ingeniería de contexto tiene un alcance más amplio: también considera cómo reunir, seleccionar, ordenar y actualizar el resto de la información disponible. Ambas prácticas pueden solaparse; una buena instrucción forma parte del contexto, pero no resuelve por sí sola qué documentos recuperar o qué estado conservar.
La generación aumentada por recuperación, o RAG, es un enfoque que combina recuperación de información con generación. Puede ser una forma de adquirir documentos para el contexto, pero no es sinónimo de ingeniería de contexto. Un sistema puede usar RAG y aun tener que decidir qué recuperar, qué fragmentos incluir y cómo tratar el resultado. También es posible gestionar contexto sin emplear un sistema RAG.
La fragmentación, o chunking, consiste en dividir documentos u otros materiales en unidades para almacenarlos, recuperarlos o procesarlos. Afecta qué porciones pueden llegar al modelo, pero no determina por sí sola si son relevantes ni cómo se combinarán con instrucciones e historial. La memoria, por su parte, designa mecanismos para conservar y recuperar información entre momentos o tareas. Al recuperar algo de esa memoria, el sistema debe decidir si sigue siendo pertinente antes de incluirlo.
La ventana de contexto es el límite de información que un modelo puede procesar en una ejecución, según las características del sistema. No equivale a una estrategia para elegir contenido: una ventana amplia no establece qué incluir ni garantiza que cada parte reciba la misma atención. La caché puede reutilizar contenido o resultados de procesamiento para reducir trabajo repetido, pero tampoco es lo mismo que decidir qué información es necesaria para una tarea.
Cómo distinguir los conceptos
| Concepto | Pregunta principal | Relación con la ingeniería de contexto |
|---|---|---|
| Ingeniería de prompts | ¿Cómo expresar las instrucciones? | Es una parte del diseño del contexto, no todo el proceso. |
| RAG | ¿Cómo recuperar información para generar una respuesta? | Puede aportar documentos, cuya selección e inclusión aún deben gestionarse. |
| Chunking | ¿Cómo dividir materiales en unidades? | Influye en lo recuperable; no decide por sí solo qué conviene incluir. |
| Memoria | ¿Qué información conservar y recuperar entre momentos? | Puede aportar estado que se evalúa antes de incorporarlo al contexto actual. |
| Ventana de contexto | ¿Cuánta información puede procesar una ejecución? | Impone un límite, no una política de selección. |
Errores frecuentes y límites
Un error frecuente es asumir que más contexto siempre ayuda. Los experimentos sobre modelos con contextos largos han observado que la capacidad de usar información puede variar según dónde aparezca la evidencia pertinente. Por tanto, aumentar la cantidad de texto o el tamaño de la ventana no garantiza que el modelo identifique o utilice mejor el dato necesario.
Otro error es confundir información disponible con información usada. Que un documento se haya incluido no demuestra que haya influido correctamente en la respuesta. Del mismo modo, un resumen no conserva necesariamente todos los matices del original. Al comprimir, pueden perderse condiciones, excepciones o desacuerdos; los detalles decisivos deberían poder contrastarse con la fuente.
El material recuperado también puede estar incompleto, ser irrelevante o haber caducado. Además, documentos y páginas web pueden contener instrucciones maliciosas dirigidas al agente. Si el sistema trata ese contenido como instrucciones confiables, puede ser inducido a desviarse de la tarea. La inyección de instrucciones es un riesgo asociado a incorporar contenido no confiable; las medidas de defensa deben probarse y no se deben dar por efectivas por el mero hecho de existir.
La selección de contexto implica además decisiones de coste, latencia y privacidad. Recuperar o procesar más información puede añadir trabajo, y trasladar datos que no hacen falta amplía innecesariamente su exposición. No hay una cantidad universal de contexto que sea correcta: depende de la tarea, de la calidad de las fuentes, de las restricciones del sistema y de qué errores se quieren evitar.
Cómo evaluar una estrategia
Para saber si una estrategia ayuda, conviene definir tareas de prueba representativas y fijar de antemano qué cuenta como un resultado aceptable. Después se pueden comparar variantes: por ejemplo, qué pasa al recuperar menos documentos, ordenar de otra forma la evidencia o conservar un resumen de estado más explícito. Cuando sea posible, las comparaciones deberían cambiar una decisión cada vez para facilitar la interpretación.
La evaluación puede observar la calidad de las respuestas o acciones, las omisiones de información relevante, los errores de selección, la latencia, el coste y la cantidad o sensibilidad de los datos incluidos. En sistemas con documentos, también interesa comprobar si las respuestas se apoyan en fuentes aplicables y vigentes. El resultado debe interpretarse en relación con las tareas y los datos de prueba utilizados: no demuestra automáticamente que la estrategia funcionará en otros casos.
Para atribuir una mejora a la gestión del contexto, hay que comparar resultados de forma sistemática y mantener constantes, en la medida de lo posible, el modelo y las demás condiciones relevantes. Una impresión anecdótica o el hecho de que una respuesta parezca convincente no basta para demostrar causalidad. Si aparecen errores, analizar qué se recuperó, qué se omitió y qué información llegó realmente al modelo puede ayudar a localizar el problema.
Lista breve para revisar un diseño
- 01¿La información incluida responde a una necesidad identificada de la tarea?
- 02¿Se ha comprobado la pertinencia y vigencia de las fuentes?
- 03¿El sistema conserva detalles críticos que un resumen podría omitir?
- 04¿Se excluyen los datos personales que no hacen falta?
- 05¿Se han medido calidad, omisiones, latencia y coste en tareas representativas?
- 06¿Se han probado entradas no confiables y situaciones en las que la recuperación falla?
Criterios prácticos y conceptos relacionados
Al diseñar un sistema, empieza por precisar la tarea y el dato que podría cambiar la respuesta o la acción. Obtén solo información de fuentes permitidas, selecciona lo pertinente y conserva una vía para revisar el material original si una síntesis no basta. Actualiza el estado cuando haya evidencia nueva, en vez de acumular indefinidamente historial que quizá ya no sea útil.
Después prueba el diseño con casos normales y casos límite: fuentes contradictorias, información obsoleta, solicitudes ambiguas y documentos que incluyan instrucciones ajenas a la tarea. Revisa qué llega al modelo, qué queda fuera y qué resultado se obtiene. Si el sistema falla, no des por hecho que necesita más contexto; comprueba si el problema está en la recuperación, la selección, la organización, la vigencia de los datos o la interpretación del modelo.
Para seguir explorando el vocabulario relacionado, consulta las fichas del glosario sobre ingeniería de prompts, RAG, fragmentación o chunking y memoria, además de la entrada general del glosario. La distinción práctica es sencilla: el prompt trata sobre todo de instrucciones; RAG, de recuperar información para generar; chunking, de dividir materiales; memoria, de conservar y recuperar estado. La ingeniería de contexto considera cómo combinar esas piezas para una ejecución concreta.