Prompt engineering y context engineering
Antes de construir un RAG, que es caro y complejo, hay que saber exprimir un prompt y decidir qué información vale la pena enviar al modelo.
Tiempo de lectura: 2 min
Prompt engineering
El prompt engineering es el oficio de redactar las instrucciones para que el modelo haga la tarea de forma fiable: definir el rol, el objetivo, las restricciones, el formato de salida y, si hace falta, añadir ejemplos. Un buen prompt se parece más a un encargo bien escrito para un colaborador nuevo que a una fórmula mágica.
Las prácticas que más rinden son poco sofisticadas: ser específico, explicar el porqué de cada regla, separar claramente las instrucciones de los datos (por ejemplo, con etiquetas o delimitadores) y pedir una salida estructurada que el código pueda validar. Y, sobre todo, tratar los prompts como código: versionados y probados con casos reales antes de cambiarlos.
Context engineering
El context engineering es decidir qué entra en la ventana de contexto en cada llamada, y en qué orden: qué instrucciones, qué documentos, qué parte del historial y qué datos de la aplicación. Si el prompt engineering es cómo pides la tarea, el context engineering es con qué información la resuelve el modelo.
El contexto es un recurso escaso: cada token cuesta dinero y tiempo, y la información irrelevante distrae al modelo. Las técnicas habituales son seleccionar solo lo relevante, resumir el historial largo, recortar el ruido (pies de correo, avisos legales) y construir el contexto dinámicamente según el caso. Por ejemplo, para un cliente nuevo, la política general; para un cliente habitual con una incidencia abierta, su historial reciente.
Fine-tuning, prompt engineering o RAG
Son tres formas de adaptar un modelo a tu caso. El prompt engineering cambia las instrucciones. El RAG le da información externa en el momento de la consulta. El fine-tuning lo reentrena con ejemplos propios para que cambie su comportamiento de base.
El orden razonable es este: primero prompt engineering, que es barato e inmediato; después RAG, cuando el problema es que el modelo no tiene la información; y fine-tuning solo cuando necesitas un estilo o un formato muy específico de forma consistente y ya has agotado las otras vías. El fine-tuning no es una buena forma de enseñarle datos que cambian: para eso está el RAG.
Examínate de este módulo
Copia este prompt y pégalo en tu IA (ChatGPT, Claude, Gemini…). Te hará un test de 20 preguntas sobre los conceptos del módulo y después te propondrá un ejercicio práctico.
Actúa como examinador de la «Guía de Ingeniería IA» de Dani Pérez. Examíname del módulo «Prompt engineering y context engineering» (https://daniperez.pro/resources/ai-engineering-guide/prompt-and-context-engineering). Conceptos que entran en el examen: - Prompt engineering - Context engineering - Fine-tuning, prompt engineering o RAG Examen: 1. 20 preguntas tipo test, cada una con 4 opciones (a, b, c, d) y una sola respuesta correcta. 2. Pregunta sobre comprensión y criterio (para qué sirve cada cosa y cuándo NO usarla), no sobre memorizar definiciones. 3. Reparte la posición de la respuesta correcta de forma equilibrada entre a, b, c y d. 4. Hazme las preguntas en 4 tandas de 5. No pongas ningún ejemplo de respuesta (como "1a 2b 3c 4d 5a"): yo ya sé que debo responder con las letras. No me digas si he acertado hasta que haya respondido las 20. 5. Al final, corrígelas todas: para cada pregunta, mi respuesta, la correcta y una explicación breve. Dame la nota sobre 20 y dime qué conceptos debo repasar. Ejercicio práctico (después de la corrección): 6. Pregúntame qué aplicación tengo o quiero construir, y con qué lenguaje y framework trabajo. Si no tengo ninguna, usa esta: la aplicación de atención al cliente de una tienda online, con tickets, clientes, pedidos y una base de conocimiento (FAQ y políticas de devolución). En ese caso, centra el ejercicio en: redactar un borrador de respuesta a un ticket construyendo el contexto según el tipo de cliente (nuevo, habitual o enfadado). 7. Propónme un ejercicio que aplique los conceptos de este módulo a esa aplicación: objetivo, requisitos, criterios para darlo por bueno y errores habituales a evitar. 8. No me lo resuelvas. Cuando te traiga mi solución, revísala con esos criterios.