Evalúa prompts como sistemas, no como trucos

Un prompt que funciona hoy puede fallar mañana por un cambio de modelo, de contexto o de datos. El problema no suele ser que el texto esté “mal escrito”. Es que lo tratamos como un truco aislado, cuando en realidad es una pieza de software con entradas, salidas y límites.

En proyectos de IA he encontrado más valor en diseñar un contrato pequeño y una evaluación repetible que en coleccionar prompts supuestamente mágicos. Esta es una arquitectura práctica para empezar sin montar una plataforma enorme.

El problema: un prompt no es una especificación

Un prompt describe una intención, pero deja preguntas abiertas:

• ¿Qué debe hacer el modelo si faltan datos?
• ¿Qué formato es obligatorio?
• ¿Qué errores son aceptables y cuáles bloquean el flujo?
• ¿Cómo sabemos que una nueva versión mejoró algo y no rompió otra cosa?

La respuesta no es añadir instrucciones indefinidamente. Cada frase extra puede reducir una ambigüedad y, al mismo tiempo, aumentar el acoplamiento al modelo. Conviene separar tres capas: contrato, ejemplos de evaluación y prompt de ejecución.

Define el contrato antes de medir

Un contrato útil cabe en una página. Para un clasificador, por ejemplo, puede exigir una etiqueta de un conjunto cerrado, una justificación breve y una señal explícita de incertidumbre. Para una herramienta, puede exigir argumentos válidos y ningún efecto secundario cuando la confianza es baja.

También hay que definir el comportamiento de abstención. Un modelo que responde siempre parece productivo, pero puede ser más costoso que uno que dice “no tengo suficiente contexto”. En un flujo de soporte, esa decisión debe poder ser revisada por una persona.

Una forma sencilla de documentarlo:

output:
  format: json
  required: [decision, reason]
  decision_values: [allow, review, reject]
  max_reason_chars: 240
failure_policy:
  missing_context: review
  invalid_output: retry_once_then_review

El YAML no hace cumplir el contrato por sí solo. La aplicación debe validar la salida y registrar el motivo del fallo.

Una arquitectura mínima de evaluación

Piensa en este flujo, de izquierda a derecha:

caso versionado → render del prompt → llamada al modelo → parser → checks → resultado comparable

Cada etapa debe dejar una evidencia pequeña. Guarda la entrada anonimizada, la versión del prompt, el modelo, la configuración relevante, la salida y los checks que pasaron. Los checkpoints para reanudar acciones son una idea útil aquí: una evaluación interrumpida no debería obligarte a empezar todo de nuevo.

No hace falta guardar cada token para comenzar. Sí hace falta que un resultado pueda responder: “¿qué cambió entre la versión 12 y la 13?”. Sin esa trazabilidad, comparar prompts es más opinión que ingeniería.

Diseña casos que fallen con intención

Un conjunto de evaluación no debe contener solamente ejemplos fáciles. Divide los casos en grupos:

1. Camino normal: entradas frecuentes y bien formadas.
2. Fronteras: textos ambiguos, largos, incompletos o con idiomas mezclados.
3. Adversariales: instrucciones dentro del contenido, intentos de prompt injection y datos contradictorios.
4. Regresión: incidentes reales ya corregidos.

Cada caso debería tener una expectativa verificable. Para JSON, valida el esquema. Para una respuesta narrativa, usa una rúbrica con criterios concretos y, si usas otro modelo como juez, revisa una muestra humana. El juez es un instrumento, no una autoridad neutral; puede preferir respuestas largas o imitar los sesgos del modelo evaluado.

Incluye también entradas de privacidad. Sustituye nombres, correos y tokens por valores sintéticos. Un tem email que aparece en un fixture puede parecer inocuo, pero los datos de prueba terminan viajando a más lugares de los previstos.

Métricas y tradeoffs

Empieza con pocas métricas, pero relacionadas con decisiones:

• Cumplimiento del contrato: ¿la salida se puede parsear y usar?
• Exactitud por grupo: ¿qué ocurre en fronteras y casos adversariales?
• Tasa de abstención: ¿el sistema pide revisión cuando debe?
• Coste y latencia: ¿el aumento de calidad compensa el consumo?

Una media única oculta los problemas. Un prompt puede subir la exactitud general y empeorar justo el grupo de riesgo. Por eso un gate de despliegue podría exigir: ningún descenso mayor a un umbral en casos adversariales, contrato válido en todas las salidas y latencia dentro del presupuesto.

Más casos dan confianza, pero cuestan dinero y mantenimiento. Evaluación continua detecta regresiones pronto, aunque añade tiempo al pipeline. Un conjunto pequeño, curado por incidentes y ejecutado en cada cambio suele ser el mejor primer paso.

Si el flujo necesita aprobaciones, estudia también estas aprobaciones por email con menos ruido: el resultado del modelo y la interfaz humana deben compartir estados claros.

Checklist de implementación

• Versiona prompt, modelo y conjunto de casos.
• Define una salida estructurada y valida en el borde.
• Añade casos normales, de frontera, adversariales y de regresión.
• Mide por grupos, no solo con un promedio.
• Configura un umbral de abstención y una ruta humana.
• Revisa manualmente los cambios importantes del juez automático.
• Publica resultados con coste, latencia y fallos visibles.

La meta no es encontrar el prompt perfecto. Es construir un sistema donde cambiarlo sea una decisión observable, reversible y razonable. Cuando el prompt tiene contrato y pruebas, la conversación deja de ser “¿te gusta esta redacción?” y pasa a ser “¿qué comportamiento compramos con este cambio?”.