Ingeniería de contexto: qué ve el modelo y por qué

La ingeniería de contexto (context engineering) es la práctica de decidir todo lo que ve un modelo de lenguaje cuando responde: no solo la pregunta que escribes, sino las instrucciones que la rodean, los documentos y resultados de herramientas que se le insertan, la memoria guardada sobre el usuario y la conversación hasta ese momento. Todo eso comparte una misma ventana de contexto, y el modelo responde a partir de ese texto y de nada más. El término se extendió en 2025, cuando cada vez más productos de IA se convirtieron en agentes que arman automáticamente la mayor parte de su contexto.

La ingeniería de prompts trata sobre todo de cómo redactar una petición. La ingeniería de contexto trata de qué debe tener el modelo delante en cada llamada, y en qué orden.

De un prompt a un contexto

En una app de chat escribes tú la mayor parte del contexto: la app añade un prompt de sistema y el historial, y tú pones el resto. En una aplicación, la balanza se invierte. Un usuario escribe una frase, y el código que rodea al modelo añade instrucciones, un perfil de usuario, tres artículos de ayuda encontrados con una búsqueda, la lista de herramientas disponibles y la salida de la última llamada a una herramienta. La frase del usuario puede ser una pequeña fracción de lo que lee el modelo.

Cuando un sistema así responde mal, la solución rara vez está en la redacción. La causa habitual es que el modelo tenía el material equivocado: un dato que faltaba, un resultado de herramienta desactualizado, un documento irrelevante que a la búsqueda le pareció relevante.

Qué entra en la ventana de contexto

Una llamada típica en una aplicación de IA contiene algunas de estas cosas, o todas, más o menos en este orden:

• Instrucciones de sistema: el rol, las reglas y el formato de salida, normalmente fijos para toda la app. Consulta prompts de sistema.
• Definiciones de herramientas: nombres, descripciones y parámetros de las herramientas que el modelo puede llamar.
• Ejemplos: algunas entradas y salidas de muestra que enseñan el comportamiento esperado.
• Memoria: datos guardados de sesiones anteriores, como el plan del usuario, su idioma o sus preferencias.
• Documentos recuperados: fragmentos encontrados al buscar en una base de conocimiento para esta pregunta (generación aumentada por recuperación, o RAG).
• Historial de la conversación: turnos anteriores, literales o resumidos.
• Resultados de herramientas: la salida de búsquedas, ejecuciones de código o llamadas a API hechas durante esta tarea, como en un ciclo ReAct.
• El mensaje actual: lo que acaba de preguntar el usuario.

El bloque de abajo es un contexto ya armado para un asistente de soporte. Desactiva las partes de una en una. Sin la parte de contexto, el modelo no puede saber el plan del cliente; sin la parte de entrada, no tiene datos del producto, y sus restricciones le dicen que lo diga en lugar de adivinar.

Contexto para un asistente de soporte

EditCopy

PartsRoleConstraintsContextInputFormatTask

Role

Eres el asistente de soporte de Acme Notes, una app para tomar notas.

Constraints

Responde solo a partir de los documentos de abajo. Si no cubren la pregunta, dilo y ofrece poner al cliente en contacto con una persona. Nunca adivines sobre funciones o precios.

Context

Memoria del cliente: se llama Dana, plan Free, usa la app de Android.

Input

<document source="help/offline-mode"> El modo sin conexión está disponible en el plan Pro. Las notas creadas sin conexión se sincronizan cuando el dispositivo vuelve a conectarse. Los adjuntos de más de 20 MB no están disponibles sin conexión. </document> <document source="help/plans"> Plan Free: hasta 3 dispositivos. Plan Pro: dispositivos ilimitados, modo sin conexión y 30 días de historial de versiones. </document>

Format

De dos a cuatro frases en lenguaje sencillo. Dirígete al cliente por su nombre.

Task

Pregunta del cliente: ¿Puedo usar la app en un avión sin internet?

Try it

Example replyReplies vary between models and runs.

Hola, Dana: el modo sin conexión forma parte del plan Pro, y tu cuenta está ahora en el plan Free, así que por el momento no lo tienes disponible. Con Pro, las notas que crees durante el vuelo se sincronizan solas cuando el teléfono vuelve a conectarse. Un límite que conviene saber: los adjuntos de más de 20 MB no están disponibles sin conexión.

Fíjate en que la respuesta correcta depende de unir dos fuentes: la memoria (plan Free) y un documento (el modo sin conexión es solo para Pro). Ninguna basta por sí sola, y eso es lo habitual. Gran parte de la ingeniería de contexto consiste en asegurarse de que las piezas que se necesitan entre sí lleguen juntas.

Cuatro formas en que un contexto falla

1. Falta información. El modelo rellena los huecos con suposiciones verosímiles, y de ahí salen muchas alucinaciones. Añade el dato o dile al modelo qué hacer cuando falte un dato.
2. Demasiado material. Cada párrafo irrelevante cuesta tokens y compite por la atención. Liu et al. 2023, "Lost in the Middle: How Language Models Use Long Contexts", vieron que los modelos que probaron usaban la información del principio o del final de una entrada larga de forma más fiable que la del medio. Los modelos más nuevos manejan mejor las entradas largas, pero enviar los pocos fragmentos que responden la pregunta sigue siendo más barato, y más fácil de usar para el modelo, que pegar el manual entero.
3. Información desactualizada. Un resultado de herramienta de hace diez pasos puede describir un archivo o un saldo que ya cambió. Si el modelo ve las dos versiones, puede usar la antigua.
4. Conflictos. Dos documentos no coinciden, o la memoria dice una cosa y el usuario otra. Dile al modelo qué fuente manda, por ejemplo "el último mensaje del usuario prevalece sobre la memoria guardada".

Ordenar el contexto

El orden cambia tanto los resultados como el coste.

• Primero las partes estables. Las instrucciones de sistema, las definiciones de herramientas y el material de referencia fijo rara vez cambian entre llamadas. Varios proveedores de API ofrecen caché de prompts (prompt caching), que reutiliza el procesamiento de un comienzo idéntico de la entrada, así que un prefijo que no cambia hace más baratas y rápidas las llamadas repetidas.
• El material largo antes de la pregunta. Para un documento largo o un conjunto grande de fragmentos, pon el material primero y la pregunta y las instrucciones finales después. La guía de prompting de Anthropic, por ejemplo, recomienda este orden para entradas largas, con la pregunta justo antes de que el modelo empiece a escribir.
• Etiqueta cada pieza. Envuelve cada fuente en etiquetas como <document>, <memory> o <tool_result>, con el nombre de la fuente. Las etiquetas permiten al modelo distinguir los datos de las instrucciones y te permiten pedirle que cite de dónde salió una respuesta. Delimitadores y etiquetas XML repasa los formatos.

Recortar un contexto largo

Cada turno de un chat vuelve a enviar todo el historial, así que las sesiones largas crecen hasta que algo tiene que salir. Según la app, puede resumir o descartar los mensajes antiguos, o pedirte que empieces un chat nuevo. Obtienes mejores resultados si recortas a propósito.

• Conserva literales los últimos turnos y sustituye los más antiguos por un resumen.
• Cuando ya se usó un resultado de herramienta, sustitúyelo por una nota de una línea con lo que mostró.
• Conserva los identificadores exactos en cada resumen: nombres de archivos, de funciones, IDs, mensajes de error y números. Un resumen que dice "el archivo de configuración" donde el historial decía settings.prod.yaml pierde justo el detalle que importaba.
• En una app de chat, cuando la conversación se desvía, empieza un chat nuevo con una nota de traspaso. El prompt de abajo escribe una.

Comprimir un chat largo en un nuevo comienzo

EditCopy

Fill inproyectopalabras

Esta conversación se está alargando. Escribe una nota de traspaso que pueda pegar en un chat nuevo para que continúe el trabajo sin el historial. Incluye: 1. El objetivo de la refactorización del formulario de registro, en una frase. 2. Las decisiones que tomamos y el motivo de cada una. 3. El estado actual: qué funciona y qué está sin terminar. 4. Los nombres exactos que importan: archivos, funciones, mensajes de error, números. Cópialos tal cual. 5. Las preguntas abiertas y el siguiente paso. Deja fuera los callejones sin salida, salvo que expliquen una decisión. Máximo 200 palabras.

Try it

Example replyReplies vary between models and runs.

Objetivo: sustituir las validaciones escritas a mano del formulario de registro por un único esquema de validación compartido por el navegador y el servidor.

Decisiones

1. Un solo archivo de esquema, signupSchema.ts, importado por SignupForm.tsx y api/signup.ts, para que los dos conjuntos de reglas no puedan divergir.
2. Los mensajes de error se mantienen palabra por palabra, porque el centro de ayuda los cita.

Estado actual

1. La validación del navegador usa el esquema y SignupForm.test.tsx pasa.
2. El servidor todavía llama al antiguo validateSignup() en api/signup.ts.

Detalles exactos: las contraseñas necesitan al menos 8 caracteres y un número. Texto del error de correo: "Introduce una dirección de correo válida."

Siguiente paso: sustituir validateSignup() por el esquema y ejecutar las pruebas de la API.

Pregunta abierta: ¿un correo ya registrado debe devolver 409 o 400?

Memoria entre sesiones

La memoria es contexto que sobrevive a una conversación: datos que se escriben en un almacenamiento al final de una sesión y se cargan en la siguiente. Las apps de chat ofrecen versiones de esto, como memorias guardadas o instrucciones de proyecto que se añaden a todos los chats de un proyecto. En tu propia aplicación, la memoria es una tabla o un archivo de notas que tu código lee e inserta. Dos reglas la mantienen útil: guarda datos que sigan siendo ciertos (plan, idioma, stack preferido), no transcripciones; y carga solo lo relevante para la tarea actual, porque la memoria compite por el mismo espacio que todo lo demás.

Armar el contexto en código

En una aplicación, la ingeniería de contexto es código normal y corriente. Este esbozo con el SDK de Python de Anthropic pone las reglas fijas y la memoria en el prompt de sistema, conserva solo el historial reciente y coloca los documentos etiquetados antes de la pregunta.

import anthropic

client = anthropic.Anthropic()
MODEL = "your-model-id"  # e.g. from your provider's model list

def build_context(question, docs, history, memory, max_messages=6):
    documents = "\n".join(
        f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
    )
    system = (
        "You are the support assistant for Acme Notes. Answer only from the documents. "
        "If they do not cover the question, say so.\n"
        f"<memory>\n{memory}\n</memory>"
    )
    # history holds complete user/assistant pairs, so an even slice starts with a user turn
    recent = history[-max_messages:]
    user = f"<documents>\n{documents}\n</documents>\n\n{question}"
    return system, recent + [{"role": "user", "content": user}]

# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)

Cada decisión de esa función (qué documentos, cuántos mensajes, dónde va la memoria) es una decisión de ingeniería de contexto, y vale la pena probar cada una con preguntas reales, igual que probarías un cambio en la redacción.