Ingeniería de contexto: qué sustituyó a la ingeniería de prompts
Durante mucho tiempo, “trabajar con IA” significaba una sola cosa: formular bien un prompt. En 2025-2026 ya no basta. Los modelos llaman a tools, traen documentos con RAG, guardan memoria de sesión y operan en cadenas de agentes. Lo que decide la calidad no es la elegancia de la frase, sino la ingeniería de contexto - la disciplina que diseña exactamente qué ve el modelo en cada paso: instrucciones, hechos, historial, permisos y límites. Abajo - cómo sustituyó a la ingeniería clásica de prompts y cómo aplicarla en productos y procesos internos.
- Prompt - texto de instrucción; contexto - toda la entrada del modelo en un paso
- Cambio - de “busca la frase mágica” a “arma el paquete de datos correcto”
- Capas - system, retrieval, memoria, tools, estado de la tarea, políticas
- Objetivo - estabilidad, menos alucinaciones, control del coste de tokens
- Práctica - un contexto estrecho y relevante supera “meterlo todo en la ventana”
- Para el negocio - proceso y arquitectura vencen a un chat afortunado en ChatGPT
Qué es la ingeniería de prompts - y dónde se quedó corta
La ingeniería de prompts (prompt engineering) es el arte de formular peticiones a un LLM para obtener el estilo, formato y comportamiento deseados: roles (“eres un analista senior”), ejemplos few-shot, chain-of-thought, plantillas rígidas de respuesta.
Funciona bien para:
- tareas puntuales en el chat;
- generación de borradores;
- enseñar al equipo “cómo preguntar al modelo”;
- prototipos sin acceso a datos internos.
El límite aparece rápido:
| Situación | Por qué un prompt solo no alcanza |
|---|---|
| Hacen falta precios y normativas actuales | El modelo no conoce tu tarifa sin retrieval |
| Diálogo largo / agente con tools | La ventana se llena de ruido; se pierde el foco |
| Varios roles y sistemas | Un system prompt “universal” se diluye |
| Control de riesgo y compliance | Políticas y enmascarado de PII no son “una frase bonita” |
| Coste de API | Tokens de más en cada turno = pérdida directa |
El prompt sigue siendo parte del sistema. Dejó de ser la palanca principal de calidad.
Qué es la ingeniería de contexto
La ingeniería de contexto (context engineering) es diseñar el paquete de entrada completo para el modelo en cada llamada: qué poner en system, qué traer de la base, qué tomar de la memoria, qué resultados de tools mostrar, qué descartar y qué prohibir.
Si el prompt es “cómo pedir”, el contexto es “en qué entorno informativo responde el modelo”.
Capas típicas de contexto:
- Instrucciones y rol - system prompt, política de respuesta, formato JSON/Markdown.
- Tarea del usuario - petición actual e historial mínimo necesario.
- Conocimiento recuperado - fragmentos de wiki, CRM, código, FAQ vía búsqueda/RAG.
- Estado - etapa del funnel, id del trato, versión del documento, resultado del paso anterior.
- Observaciones de tools - respuestas de API, SQL, navegador, herramientas MCP.
- Restricciones - “no prometas descuento”, “no cites PII”, “escala a un humano”.
El ingeniero de contexto piensa como diseñador de pipeline, no como copywriter de frases afortunadas.
Cómo el contexto sustituyó la “magia del prompt”
| Antes (foco en el prompt) | Ahora (foco en el contexto) |
|---|---|
| System prompt largo “para todo” | Prompt estrecho + ensamblado dinámico de la entrada |
| Pegar el PDF entero en el chat | Retrieval: solo chunks relevantes |
| “Recuerda todo el diálogo” | Compresión, resumen, memoria selectiva |
| Un modelo - un chat | Agentes, orquestador + subagentes, ventanas distintas |
| Calidad = arte de formular | Calidad = relevancia, frescura, orden de capas |
| Depurar el texto del prompt | Depurar la fuente: miss de retrieval, fallo de tool, overflow |
El cambio de paradigma no significa que los prompts “murieran”. Se convirtieron en una capa junto a retrieval, memoria, tools y políticas - como una consulta SQL junto al esquema y los índices.
Por qué el cambio se aceleró en 2025-2026
Varios factores coincidieron:
- Agentes y tools - el modelo actúa, no solo responde; el contexto debe incluir resultados de herramientas.
- Ventanas largas - cabe más, pero “más” sin filtro = ruido y mayor coste.
- Datos empresariales - sin RAG y versionado de documentos, las respuestas no sirven al negocio.
- Multiagente - cada subagente necesita su propio brief estrecho, no el log completo.
- Coste y latencia - el ingeniero de contexto optimiza el presupuesto de tokens como el backend el payload.
Por eso la práctica se movió: del “prompt engineer” hacia platform/ML eng y producto que construyen pipelines de contexto.
Práctica: cómo armar el contexto en un paso
Checklist útil antes de llamar al LLM:
- Objetivo del paso - qué debe salir (JSON, decisión, borrador).
- Instrucciones mínimas - sin duplicar lo que ya dan tools y datos.
- Retrieval - top-k fragmentos con metadatos (fuente, fecha, versión).
- Historial - solo réplicas relevantes o un resumen corto, no todo el hilo.
- Salidas de tools - crudas pero recortadas; sin secretos ni campos de más.
- Presupuesto de tokens - límite duro; si hay overflow: instrucción → tarea → hechos → historial.
- Políticas - lo que el modelo no puede afirmar sin un humano.
Ejemplo para soporte:
[system] rol + prohibiciones + formato
[retrieved] 3 chunks de la base de conocimiento (con fecha)
[state] id del ticket, plan del cliente, idioma
[user] pregunta actual
No así:
[system] 4 páginas de “sé útil...”
[history] 80 mensajes completos
[files] todo el workspace de Notion
[user] pregunta
Contexto vs prompt: qué corregir si la respuesta falla
| Síntoma | A menudo se arregla con prompt | A menudo se arregla con contexto |
|---|---|---|
| Tono / formato incorrecto | Sí: afinar la instrucción | Rara vez |
| Hechos inventados | “No inventes” ayuda poco | Retrieval + no responder sin fuente |
| Contenido desactualizado | Poner una fecha en el prompt | Versiones de documentos + filtro de frescura |
| El modelo “olvidó” la tarea | Repetirla al final | Mantener goal/state en un bloque aparte |
| Caro y lento | Recortar cortesía | Recortar historial y ruido de retrieval |
| Acción peligrosa | “Ten cuidado” | Quitar el tool / exigir human-in-the-loop |
Regla de depuración: primero datos y selección, después redacción.
Qué significa para el negocio
Si implantas IA en CRM, soporte, búsqueda interna o agentes de código:
- El presupuesto deja de ir a “cursos de prompts para managers” y va a calidad del corpus, indexación, logs y políticas de acceso.
- KPI de calidad: hit-rate de retrieval, % de respuestas “con fuente”, coste por escenario, escalados a humano.
- Los playbooks de prompts siguen útiles para chats manuales - pero la IA de producto se construye como pipeline de contexto.
- Elegir contexto largo, RAG o fine-tuning es una decisión de arquitectura aparte; ver el desglose.
Test de madurez para el dueño: ¿puedes explicar de qué fuentes el modelo armó la respuesta del caso de ayer? Si no - aún tienes ingeniería de prompts en el chat, no ingeniería de contexto en el sistema.
Errores frecuentes
- Dar al modelo “todo lo que hay” porque la ventana es larga.
- Mantener un system prompt gigante en lugar de un ensamblado dinámico.
- No versionar documentos del RAG - respuestas seguras pero obsoletas.
- Pasar al subagente el log completo del orquestador en lugar de un brief corto.
- Meter secretos y PII en el contexto “porque al modelo le conviene”.
- Confundir mejorar la frase con tapar un agujero de datos.
Conclusión
La ingeniería de prompts nos enseñó a hablar con los modelos. La ingeniería de contexto enseña a construir sistemas donde el modelo recibe exactamente la información, las tools y los límites que necesita el paso - ni más ni menos. En 2026, la calidad de la IA empresarial no la marca una “frase mágica”, sino un pipeline: selección de hechos, memoria, tools, políticas y presupuesto de tokens. El prompt sigue siendo parte de ese pipeline - pero ya no es el protagonista.
Preguntas frecuentes
¿En qué se diferencia la ingeniería de contexto de la de prompts?
La de prompts se centra en el texto de la instrucción. La de contexto cubre toda la entrada del modelo: instrucciones + hechos recuperados + historial + estado + resultados de tools + prohibiciones. El prompt es una capa; el contexto es el sistema que ensambla esa capa y las demás.
¿Hace falta prompt engineering en 2026?
Sí, como habilidad y como capa. Instrucciones claras, formatos y few-shot siguen importando. Pero en productos y agentes, un “prompt perfecto” no estabiliza la calidad sin selección de datos, memoria y políticas.
¿Es lo mismo que RAG?
No: es más amplio. RAG es una forma de llenar el contexto con conocimiento del corpus. El contexto también incluye memoria del diálogo, estado del workflow, salidas de tools, roles y políticas de seguridad. RAG es un componente típico e importante, no toda la disciplina.
¿Por dónde empezar en la empresa?
Elige un escenario (soporte, búsqueda de normativas, asistente de ventas). Fija las fuentes de verdad, añade retrieval con fechas/versiones, comprime el historial a un resumen y registra “qué entró en el contexto”. Ajusta el prompt cuando los datos dejen de mentir.
¿Cómo saber si el problema es el contexto y no el modelo?
Si cambiar de modelo (GPT → Claude → Gemini) casi no cambia el error, pero cambiar documento / top-k / recorte de historial sí - el problema es el ensamblado de la entrada. Cambia de proveedor solo cuando el pipeline de contexto sea transparente y medible.