Prompt engineering como disciplina de sistemas

Un prompt define el rol del modelo, la tarea, las restricciones, los datos disponibles y el formato de salida esperado. No garantiza la veracidad ni sustituye la validación. La fiabilidad aparece cuando las instrucciones funcionan junto con retrieval, esquemas, pruebas y herramientas controladas.

Un prompt frágil intenta anticipar todos los posibles fallos añadiendo más texto. Un enfoque sistemático elimina primero la ambigüedad del contrato, separa las instrucciones de los datos y después añade solo reglas justificadas por pruebas.

Las reglas críticas deben ser breves, explícitas y situarse en el nivel de instrucciones más alto disponible. Los datos del usuario, los documentos RAG y los resultados de herramientas se tratan como entradas no confiables, no como una extensión de la política del sistema.

Una estructura práctica contiene objetivo, contexto, restricciones, formato de salida, criterios de éxito y comportamiento cuando los datos son insuficientes. Cada bloque debe tener una sola función; los requisitos mezclados son más difíciles de probar y versionar.

• objetivo y límites de la tarea;
• hechos disponibles y su procedencia;
• acciones prohibidas;
• formato de salida;
• criterios de rechazo o escalado.

Los ejemplos few-shot son útiles cuando el formato o el estilo son difíciles de describir solo mediante reglas. Deben cubrir no solo el caso correcto, sino también rechazo, estados desconocidos, conflictos entre fuentes y valores límite.

Conviene dividir una tarea compleja en etapas como extracción de hechos, verificación, clasificación y construcción de la respuesta. Esto reduce las decisiones ocultas en una sola llamada y facilita el diagnóstico.

Un prompt debe probarse con un conjunto de evaluación estable que incluya ejemplos reales, negativos y adversariales. Se miden criterios cumplidos, errores de formato, afirmaciones sin respaldo y coste, no la impresión producida por unas pocas respuestas.

La versión del prompt se guarda junto con la versión del modelo, el esquema de salida y las métricas. Cambiar una sola frase puede afectar a todo el pipeline, por lo que una regresión del prompt debe tratarse igual que una regresión de código.

Si al modelo le faltan hechos necesarios, hay que mejorar retrieval. Si el resultado rompe un parser, hay que usar structured outputs. Si un agente ejecuta acciones innecesarias, hay que limitar sus herramientas y su policy layer. Otro párrafo en el system prompt rara vez corrige un defecto arquitectónico.

El mejor prompt suele hacerse más corto cuando el sistema separa correctamente datos, instrucciones, herramientas y validaciones.

Prompt engineering en producción significa gestionar las instrucciones como código. Un prompt tiene responsable, versión, conjunto de pruebas, formato esperado y criterios de rollback. Editar texto sin evaluación crea regresiones ocultas: mejorar un escenario puede empeorar otro, y cambiar de modelo puede alterar por completo el comportamiento de una instrucción antigua.

Un system prompt debe contener solo reglas estables. El contexto dinámico, los datos del usuario y los resultados de retrieval se pasan por separado y se marcan como no confiables. Para tareas complejas es más robusto descomponer el workflow en varios pasos verificables que acumular decenas de requisitos contradictorios en un mega-prompt.

• Guardar las plantillas de prompts en control de versiones.
• Ejecutar regression evals antes de cambiar un prompt de producción.
• Separar las instrucciones de los datos no confiables.

Un prompt de producción necesita un contrato explícito: propósito, entradas permitidas, esquema de salida esperado, capacidades de herramientas, restricciones de seguridad y comportamiento de fallback. Las system instructions, la plantilla de tarea, los ejemplos y el contexto recuperado deben versionarse por separado para que un cambio en una capa no oculte otro. El prompt se construye de forma determinista a partir de variables tipadas; el input del usuario y los documentos recuperados se marcan como datos no confiables en lugar de concatenarse sin límites. Para respuestas estructuradas, la validación del esquema y la estrategia de retry forman parte del contrato igual que el texto de las instrucciones.

Cada cambio debe pasar por regresión offline, shadow evaluation y rollout limitado. El diff del archivo de prompt no basta: hay que conservar los resultados en un dataset de control, el impacto sobre token usage y latencia, la tasa de rechazo y los fallos críticos. Los ejemplos few-shot se eligen por cobertura, no por estética; no deben contener secretos, datos personales ni revelar accidentalmente el answer key. La propiedad, revisión y deprecación de prompts deben formalizarse o decenas de plantillas casi idénticas acabarán divergiendo entre servicios.

• Guardar el ID y la versión del prompt en cada trace.
• Validar las variables runtime antes de componer los mensajes.
• Probar conflictos de instrucciones e indirect prompt injection.
• Mantener un rollback rápido hacia una versión estable.