¿Qué es la ingeniería de contexto? Dale a la IA la información justa, no más palabras
La ingeniería de contexto consiste en decidir qué ve un modelo de IA antes de responder. Qué significa, en qué se diferencia de la ingeniería de prompts, por qué más contexto no es mejor y cómo aplicarla en chats y agentes.
Durante un par de años el consejo fue sencillo: escribe un prompt mejor. Luego llegaron asistentes que leen archivos, buscan en la web y usan herramientas durante decenas de pasos, y apareció otro problema. El modelo no fallaba porque la instrucción estuviera mal redactada. Fallaba porque estaba mirando la información equivocada, o demasiada. Para resolverlo se ha impuesto un nombre: ingeniería de contexto (en inglés, "context engineering"). Esta guía explica qué es la ingeniería de contexto, en qué se diferencia de la ingeniería de prompts, qué entra realmente en el contexto de un modelo, por qué más no es mejor y cómo aplicarla tanto si chateas con ChatGPT como si construyes un agente.
Qué significa realmente ingeniería de contexto
Un modelo de lenguaje no tiene memoria entre peticiones ni puede ver tu pantalla, tus archivos ni tu empresa. Cada vez que responde, trabaja solo con el texto (y las imágenes) que recibe en esa petición: su ventana de contexto. La ingeniería de contexto consiste en decidir qué entra en esa ventana —qué incluir, qué dejar fuera, de qué forma y en qué orden— para que el modelo tenga lo que necesita para el siguiente paso y muy poco más.
El término despegó en junio de 2025, cuando el CEO de Shopify, Tobi Lütke, dijo que lo prefería a "prompt engineering" y Andrej Karpathy le dio la razón. Karpathy lo describió como "the delicate art and science of filling the context window with just the right information for the next step", es decir, "el delicado arte y ciencia de llenar la ventana de contexto con justo la información adecuada para el siguiente paso". Después, el equipo de ingeniería de Anthropic lo definió como el conjunto de estrategias para seleccionar y mantener el mejor conjunto posible de tokens mientras el modelo trabaja. Palabras distintas, misma idea: el prompt que escribes es solo una parte de lo que lee el modelo, y a menudo la más pequeña.
Imagina al modelo como un profesional muy capaz que llega cada mañana con amnesia total. Lo que haya sobre la mesa es todo lo que sabe del trabajo. La ingeniería de contexto es preparar esa mesa.
Ingeniería de contexto frente a ingeniería de prompts
No compiten. La ingeniería de prompts trata de cómo formulas una instrucción: el papel, la tarea, las restricciones y el formato. Nuestros fundamentos de la ingeniería de prompts explican ese oficio. La ingeniería de contexto está una capa por encima y se ocupa de todo lo que rodea a la instrucción.
- Alcance: la ingeniería de prompts da forma a un mensaje. La ingeniería de contexto da forma a todo el paquete que recibe el modelo: el prompt de sistema, el historial de la conversación, los documentos, los ejemplos y los resultados de las herramientas.
- Momento: un prompt suele escribirse una vez. El contexto suele ser dinámico: cambia en cada turno de una conversación y en cada paso de la ejecución de un agente.
- El fallo que corrige: la ingeniería de prompts corrige el "no ha entendido lo que le pedía". La ingeniería de contexto corrige el "lo ha entendido, pero no tenía los datos" y el "tenía tanto material que se ha despistado".
Un prompt impecable con el contexto equivocado da igualmente una respuesta segura y errónea. Un prompt sencillo con el contexto justo a menudo funciona a la primera. Por eso el término caló entre quienes crean productos de IA, pero sirve igual para cualquiera que use un chat para trabajar en serio.
Qué entra en el contexto de un modelo
Escribas en un chat o desarrolles una aplicación, el contexto se monta con los mismos ingredientes:
- Instrucciones: el prompt de sistema o las instrucciones personalizadas que fijan el papel, las reglas y el tono. Nuestra guía de prompts de sistema explica cómo escribirlas.
- La tarea: tu petición actual, idealmente con el objetivo y el público, no solo la acción.
- Ejemplos: unas cuantas muestras de un buen resultado. Dos o tres ejemplos bien elegidos suelen funcionar mejor que una página de reglas, y nuestro artículo sobre prompting few-shot explica por qué.
- Conocimiento: los documentos, datos o resultados de búsqueda de los que debe salir la respuesta, ya sea porque los pegas tú o porque se recuperan automáticamente (lo que se suele llamar RAG, generación aumentada por recuperación).
- Historial y memoria: los turnos anteriores de la conversación y todo lo que la herramienta haya guardado sobre ti o sobre el proyecto.
- Herramientas y sus resultados: la descripción de lo que el modelo puede hacer (buscar, ejecutar código, leer un archivo) y lo que devuelve cada vez que lo hace.
- Formato de salida: la estructura que esperas recibir, como una tabla, un JSON o un límite de palabras.
Cada elemento ocupa espacio, y todos compiten por la atención del modelo. Buena parte de la ingeniería de contexto consiste en equilibrarlos: lo suficiente de cada uno para hacer la tarea, y nada que tire en otra dirección.
Por qué más contexto no es mejor
Las ventanas de contexto ya llegan a cientos de miles de tokens, y algunos modelos aceptan un millón o más. Tienta pegarlo todo y que el modelo se apañe. En la práctica suele salir mal, por cuatro motivos:
- La atención se diluye: el conocido estudio "Lost in the Middle" comprobó que los modelos aprovechan mucho mejor la información del principio y del final de un texto largo que la que queda enterrada en medio. Anthropic describe un efecto relacionado como context rot (degradación del contexto): a medida que crece el contexto, al modelo le cuesta más recordar y usar cada dato concreto.
- Distracción: el material irrelevante no es neutro. Un documento a medio relacionar es una invitación a colar una frase que no pinta nada en la respuesta.
- Contradicciones: dos versiones de una política, una instrucción antigua y una nueva, una nota que contradice los datos. El modelo puede seguir cualquiera de las dos o mezclarlas, y no siempre te dirá que ha tenido que elegir.
- Coste y velocidad: cada token se procesa en cada llamada, así que un contexto inflado hace que las aplicaciones sean más lentas y más caras.
Cuando un modelo capaz da una mala respuesta, la causa suele ser uno de cuatro problemas de contexto: faltaba algo, algo estaba desfasado, dos cosas se contradecían o la parte útil estaba enterrada bajo el ruido. Pregúntate cuál es antes de reformular el prompt por quinta vez. La falta de contexto es además una de las grandes causas de las alucinaciones de la IA: cuando los datos no están, el modelo rellena el hueco con algo que suena verosímil.
Ingeniería de contexto en el chat de cada día
No hace falta construir nada para sacarle partido. Si usas ChatGPT, Claude o Gemini para trabajar, ya haces ingeniería de contexto cada vez que decides qué pegar, la hagas bien o mal. Algunos hábitos marcan la diferencia:
- Empieza con un briefing: antes de la petición, da el contexto que necesitaría un compañero recién llegado: para quién es, qué está ya decidido y cómo es un buen resultado.
- Pega la fuente, no tu resumen: si la respuesta tiene que ajustarse a un documento, incluye la parte relevante de ese documento.
- Recorta antes de pegar: los tres párrafos relevantes de un contrato valen más que el PDF entero de 40 páginas.
- Cuida lo que se carga solo: las instrucciones personalizadas, los proyectos con archivos subidos y las memorias guardadas son contexto que se carga automáticamente. Mantenlos breves y al día: una memoria desfasada sobre un trabajo que dejaste el año pasado sigue siendo contexto.
- Empieza de cero cuando un hilo se desvía: un chat largo acumula ideas abandonadas y errores ya corregidos. Si las respuestas mezclan material antiguo, abre un chat nuevo con un resumen limpio.
Un briefing reutilizable tiene este aspecto:
Cuando la respuesta tiene que salir de unos documentos concretos, una herramienta construida en torno a tus fuentes hace buena parte de este trabajo por ti. Nuestra guía sobre cómo usar NotebookLM muestra cómo funciona en la práctica.
Ingeniería de contexto para agentes y aplicaciones de IA
La ingeniería de contexto importa sobre todo cuando un modelo trabaja durante muchos pasos. Un agente de IA que busca, lee archivos y llama a herramientas genera contexto nuevo con cada acción. Si nadie lo gestiona, su ventana se llena de resultados caducados hasta que pierde el hilo. Las técnicas para evitarlo son sorprendentemente sencillas:
- Recupera justo a tiempo: en vez de cargarlo todo de entrada, guarda referencias ligeras (rutas de archivo, enlaces, consultas guardadas) y deja que el agente traiga lo que necesita en el momento en que lo necesita.
- Compacta: cuando una sesión larga se acerca al límite, resume lo importante (decisiones, problemas abiertos, datos clave) y continúa a partir del resumen. Borrar los resultados antiguos de las herramientas es la versión más simple.
- Toma notas fuera de la ventana: haz que el agente mantenga un archivo de progreso o una lista de tareas que pueda releer, para que lo importante sobreviva aunque se recorte la conversación.
- Divide el trabajo: los subagentes se encargan de una tarea concreta en un contexto limpio y devuelven un resumen breve, y el agente principal no carga con cada detalle de cada búsqueda.
- Pocas herramientas y bien descritas: si las herramientas se solapan y sus descripciones son vagas, el modelo tiene que adivinar cuál usar. Cada descripción de herramienta también es contexto.
- Sitúa el prompt de sistema a la altura adecuada: es la expresión de Anthropic para el término medio entre reglas rígidas del tipo "si pasa esto, haz aquello" y ánimos vagos: concreto en los objetivos y los límites, flexible en el método.
La compactación puedes probarla a mano en cualquier chat largo antes de pasar a uno nuevo:
Una lista de comprobación de contexto reutilizable
Antes de una petición importante, o cuando un asistente falla una y otra vez en lo mismo, repasa esta lista:
- Objetivo: ¿dice el contexto para qué es el resultado, y no solo qué hay que hacer?
- Fuentes: ¿tiene el modelo delante cada dato del que depende la respuesta?
- Actualidad: ¿hay algo desfasado, como un briefing antiguo, una versión ya sustituida o una memoria que ya no aplica?
- Contradicciones: ¿hay dos piezas que no coinciden? Quita una o indica cuál manda.
- Ruido: ¿qué podrías borrar sin perder nada que necesite la tarea?
- Etiquetas: ¿están los documentos y fragmentos claramente nombrados y separados, para que el modelo (y tú) los distingáis?
- Orden: ¿está la instrucción clave al principio o al final, y no enterrada en mitad de un texto largo?
- Formato: ¿has mostrado o descrito el resultado que quieres recibir?
También puedes pedirle al modelo que revise su contexto antes de responder nada:
Lo que la ingeniería de contexto no puede arreglar
La ingeniería de contexto es útil, pero no hace magia, y parte del revuelo promete más de lo que da. Límites que conviene conocer:
- No añade capacidades que el modelo no tiene: un contexto perfecto no hará que un modelo pequeño razone como uno grande, ni que cualquier modelo sea fiable en un tipo de tarea que hace mal.
- No garantiza la fidelidad: incluso con los documentos correctos delante, un modelo puede leer mal, exagerar o mezclar fuentes. Comprueba las afirmaciones que importan.
- Tus fuentes marcan el techo: si los documentos están equivocados, sesgados o desfasados, las respuestas también lo estarán, y con exactamente la misma seguridad.
- La recuperación puede traer lo que no es: la búsqueda automática en tus documentos a veces devuelve un fragmento que casi es el bueno, y el modelo razona con cuidado a partir del pasaje equivocado.
- El contenido no fiable es un riesgo: las páginas web, los correos y los archivos que le das a una IA pueden contener instrucciones ocultas, lo que se conoce como inyección de prompts (prompt injection). Trata todo lo que lee el modelo como datos, no como órdenes, y deja que una persona apruebe cualquier acción irreversible.
- Es un trabajo continuo: el contexto caduca. Las instrucciones, las memorias y los archivos de referencia necesitan mantenimiento como cualquier otra documentación.
La idea de fondo es sencilla: un modelo solo puede trabajar con lo que ve, así que decide a conciencia qué es eso. Dale el objetivo, los datos y un ejemplo de buen resultado, deja fuera lo que sobra y revisa lo que te devuelve. Ese hábito mejora las respuestas más que cualquier formulación ingeniosa.
