Ingeniería de peticiones efectiva
La ingeniería de peticiones, o prompt engineering, es la disciplina de diseñar instrucciones, contexto, ejemplos y restricciones para obtener respuestas más útiles, seguras y consistentes de un modelo fundacional. En AIF-C01 no se espera que memorices prompts complejos, pero sí que entiendas cuándo usar zero-shot, one-shot, few-shot, plantillas, prompts negativos, guardrails, versionado y controles frente a riesgos como prompt injection o jailbreaking.
1. Qué es realmente un prompt
Un prompt no es solo “una pregunta al modelo”. En una aplicación real suele ser una combinación de varias piezas: instrucciones del sistema, contexto del usuario, fragmentos recuperados desde una base de conocimiento, reglas de seguridad, ejemplos de respuesta y formato esperado. Cuanto más crítico sea el caso, más importante es separar estas piezas y controlarlas.
Define qué debe hacer el modelo: resumir, clasificar, explicar, comparar, extraer datos, generar una respuesta o transformar contenido.
Aporta información adicional para responder: política interna, documento, conversación, datos de entrada o fragmentos recuperados con RAG.
Indica cómo debe responder: tabla, JSON, lista breve, email, resumen ejecutivo, pasos numerados o respuesta en un tono concreto.
Delimitan lo que no debe hacer: no inventar, no responder fuera del contexto, no revelar datos sensibles, no ejecutar acciones sin confirmación.
2. Por qué prompt engineering aparece tanto en AIF-C01
El examen evalúa si sabes elegir la técnica adecuada antes de aplicar soluciones más complejas. Prompt engineering suele ser la primera capa de mejora porque no requiere reentrenar el modelo, no exige preparar un dataset nuevo y permite mejorar calidad, formato, seguridad y consistencia de forma rápida.
| Problema observado | Primera mejora razonable | Por qué |
|---|---|---|
| El contenido es correcto, pero el tono no encaja | Instrucciones de tono, ejemplos y formato. | El problema no es conocimiento, sino estilo y estructura. |
| El modelo devuelve respuestas demasiado largas | Límite de longitud, formato de salida y concisión explícita. | Reduce coste, tokens de salida y ruido para el usuario. |
| El modelo no sigue el formato esperado | Few-shot prompting o plantilla de respuesta. | Los ejemplos enseñan el patrón de salida sin ajustar el modelo. |
| El modelo inventa datos sobre documentos internos | RAG más instrucción de responder solo con el contexto. | Prompt engineering ayuda, pero necesita fuentes recuperadas y verificables. |
3. Estructura recomendada de un prompt
Una estructura clara reduce ambigüedad. No existe una única plantilla válida, pero para examen conviene pensar en estos bloques:
Objetivo: responder dudas sobre una política interna.
Instrucciones:
- Responde solo con el CONTEXTO proporcionado.
- Si el contexto no contiene la respuesta, indica: “No tengo información suficiente en la documentación disponible”.
- No inventes fechas, responsables ni excepciones.
- Usa un tono profesional y claro.
CONTEXTO:
{{fragmentos_recuperados}}
PREGUNTA DEL USUARIO:
{{pregunta}}
FORMATO:
1. Respuesta breve
2. Evidencia usada
3. Siguiente paso recomendado
4. Zero-shot, one-shot y few-shot
Estas técnicas indican cuántos ejemplos proporcionas al modelo dentro del prompt. Son importantes porque permiten guiar el comportamiento sin modificar pesos del modelo ni hacer fine-tuning.
| Técnica | Qué significa | Cuándo encaja | Riesgo o límite |
|---|---|---|---|
| Zero-shot | Das la instrucción sin ejemplos. | Tareas simples o modelos que ya entienden bien el formato. | Puede ser menos consistente si la tarea es ambigua. |
| One-shot / single-shot | Incluyes un único ejemplo de entrada y salida. | Cuando quieres mostrar el patrón esperado con poco contexto. | Un solo ejemplo puede no cubrir variaciones reales. |
| Few-shot | Incluyes varios ejemplos representativos. | Cuando necesitas consistencia en tono, formato o clasificación. | Aumenta tokens de entrada y puede subir coste/latencia. |
Escenario típico de examen
Una empresa quiere que el modelo responda siempre con un formato corporativo concreto. Ya ha probado instrucciones generales, pero la salida sigue variando. La mejor respuesta suele ser añadir ejemplos de entrada/salida correcta: few-shot prompting, antes de plantear fine-tuning.
5. Prompt templates y reutilización
Una plantilla de prompt permite reutilizar una estructura común con variables. Es muy útil cuando una aplicación usa el mismo patrón para muchos usuarios o documentos. En lugar de construir prompts manuales cada vez, defines una plantilla y sustituyes partes como la pregunta, el idioma, el contexto recuperado o el formato solicitado.
Plantilla:
Eres un asistente para {{departamento}}.
Responde en {{idioma}}.
Usa únicamente el siguiente contexto:
{{contexto}}
Pregunta:
{{pregunta_usuario}}
Devuelve la respuesta en este formato:
- Respuesta
- Fuente usada
- Nivel de confianza
Para AIF-C01 debes recordar que las plantillas ayudan a mantener consistencia, reducir errores, facilitar pruebas y gestionar cambios. AWS incluye en el dominio oficial la gestión y versionado de prompts mediante Amazon Bedrock Prompt Management.
6. Prompts negativos
Un prompt negativo indica explícitamente qué no debe hacer el modelo. No es una garantía absoluta, pero ayuda a reducir respuestas no deseadas, especialmente cuando se combina con guardrails y validaciones.
“No inventes datos. No respondas si la documentación no contiene la respuesta. No incluyas información personal en la salida”.
“No hagas nada malo”. Es demasiado genérico. El modelo necesita restricciones concretas y verificables.
7. Prompt engineering no sustituye a RAG
Una trampa habitual es intentar resolver con prompt engineering un problema que realmente es de conocimiento. Si el modelo no tiene acceso a documentación interna, actualizada o privada, un prompt mejor redactado no le dará mágicamente esa información. En ese caso, el patrón adecuado suele ser RAG.
| Situación | Mejor enfoque inicial | Motivo |
|---|---|---|
| El modelo no conoce políticas internas | RAG / Knowledge Base. | Necesita recuperar información desde fuentes autorizadas. |
| El modelo conoce la respuesta pero no respeta el tono | Prompt engineering. | El problema es de estilo, no de conocimiento. |
| Hay muchos ejemplos aprobados y una tarea estable | Fine-tuning si prompt/RAG no bastan. | Se busca adaptar comportamiento de forma más persistente. |
| El usuario puede pedir datos no autorizados | Control de acceso en retrieval + guardrails. | No basta con decirle al modelo “no reveles datos”. |
8. Guardrails y barreras de protección
Los guardrails son controles que ayudan a limitar el comportamiento de una aplicación generativa. Pueden restringir temas, filtrar contenido, bloquear categorías no permitidas, reducir exposición de datos sensibles o aplicar políticas de seguridad. En el examen, si el escenario habla de contenido inapropiado, fuga de datos o políticas corporativas, piensa en guardrails además de prompt engineering.
9. Riesgos: prompt injection, hijacking y jailbreaking
Las aplicaciones generativas aceptan texto de usuarios. Eso abre la puerta a intentos de manipular el comportamiento del modelo. AIF-C01 espera que reconozcas estos riesgos y sepas que no se mitigan únicamente con “prompts más educados”.
| Riesgo | Descripción | Mitigación razonable |
|---|---|---|
| Prompt injection | El usuario intenta insertar instrucciones para cambiar el comportamiento del sistema. | Separar instrucciones, contexto y entrada de usuario; aplicar guardrails; validar salida. |
| Prompt hijacking | El usuario intenta secuestrar la conversación y forzar otro objetivo. | Definir límites de tarea, rechazar peticiones fuera de alcance y monitorizar patrones. |
| Jailbreaking | El usuario intenta saltarse restricciones de seguridad o políticas. | Guardrails, filtros, pruebas adversariales y políticas de contenido. |
| Prompt poisoning | Datos maliciosos o contaminados influyen en el contexto usado por el modelo. | Validar fuentes, controlar ingesta documental y revisar contenidos indexados. |
10. Prompt versioning y gestión de cambios
En una aplicación real, los prompts cambian con el tiempo. Puedes ajustar tono, formato, instrucciones, fuentes, políticas o ejemplos. Si no versionas los prompts, será difícil saber por qué una respuesta cambió o qué versión estaba activa cuando ocurrió un incidente.
La guía oficial menciona estrategias de gestión de prompts con Amazon Bedrock Prompt Management, por lo que conviene asociar este servicio con versionado, reutilización y control de plantillas de prompt.
11. Buenas prácticas de prompt engineering
- Sé específico y conciso. Un prompt largo no siempre es mejor; debe aportar instrucciones útiles y evitar ruido.
- Define el formato de salida. Reduce variabilidad y facilita integración con aplicaciones.
- Incluye ejemplos cuando el formato sea importante. Few-shot ayuda a enseñar patrones concretos.
- Indica qué hacer si falta información. Esto reduce alucinaciones en escenarios con conocimiento limitado.
- Evita incluir datos sensibles innecesarios. Minimiza exposición en prompts y logs.
- Prueba con casos adversariales. No basta con validar preguntas fáciles.
- Combina con guardrails. Especialmente en aplicaciones públicas o con usuarios no confiables.
12. Relación entre prompt y parámetros de inferencia
El prompt define la tarea, pero los parámetros de inferencia influyen en el estilo de generación. No debes confundirlos: si el problema es que falta información, cambiar la temperatura no lo soluciona. Si el problema es variabilidad, una temperatura menor puede ayudar.
| Parámetro o decisión | Impacto | Cuándo importa |
|---|---|---|
| Temperatura | Controla variabilidad o creatividad. | Baja para cumplimiento y respuestas consistentes; más alta para ideación. |
| Longitud máxima | Limita tokens de salida. | Control de coste, latencia y respuestas excesivas. |
| Context window | Define cuánto contexto puede procesar el modelo. | Documentos largos, RAG y conversaciones extensas. |
| Prompt caching | Puede reducir coste/latencia en prompts repetidos. | Aplicaciones con instrucciones largas y contexto reutilizable. |
13. Cómo razonar preguntas tipo examen
14. Errores frecuentes
- Creer que prompt engineering resuelve cualquier falta de información. Si el modelo no tiene la fuente, necesitas RAG o datos en contexto.
- Usar solo instrucciones negativas genéricas. “No hagas nada malo” no es un control serio.
- Enviar datos sensibles al prompt sin necesidad. Incrementa exposición y riesgo de privacidad.
- No probar prompts con casos límite. Una demo buena no garantiza producción segura.
- No versionar prompts. Sin versionado no hay trazabilidad ni control de cambios.
- Usar few-shot sin medir coste. Los ejemplos ayudan, pero consumen tokens.
Resumen final
Prompt engineering es una de las herramientas más importantes para construir aplicaciones con modelos fundacionales. Permite mejorar calidad, formato, tono, consistencia y seguridad sin modificar el modelo. Para AIF-C01 debes dominar instrucciones, contexto, restricciones, zero-shot, one-shot, few-shot, plantillas, prompts negativos, guardrails, riesgos de prompt injection y gestión de versiones.
La idea clave es saber elegir la técnica adecuada según el problema: si falta conocimiento actualizado, usa RAG; si el formato o el tono no encajan, mejora el prompt; si necesitas consistencia mediante ejemplos, usa few-shot; si hay riesgo de abuso, añade guardrails y controles de seguridad; si el prompt cambia en producción, versiona y gestiona esos cambios.