En el post anterior reunimos patrones que mejoran la calidad. Hoy veremos cómo comparar prompts con justicia para elegir el que maximiza valor: menos errores, menos costos y más consistencia.

¿Qué evaluar exactamente?

• Corrección / utilidad: ¿responde bien a la tarea definida?
• Groundedness (si hay RAG): ¿la respuesta se apoya en las citas?
• Formato: ¿cumple el contrato (p. ej., JSON válido)?
• Concisión: ¿va al punto, sin verborrea?
• Seguridad: ¿evita contenido prohibido o acciones riesgosas?
• Coste y latencia: tokens y p95. Ganar calidad perdiendo costos es el ideal.

Golden set y cobertura del dominio

Crea un golden set de entradas realistas con su salida esperada (o criterios de evaluación). Asegura cobertura de casos fáciles, difíciles y bordes (idiomas, formatos raros, tamaños). Versiona tu set (v1, v2…) para evitar sobreajuste.

Diseño de evaluación sin sesgo

• Etiquetado ciego: el evaluador no sabe qué prompt generó cada respuesta.
• Aleatorización: orden y pares aleatorios en cada corrida.
• Balance: mismas entradas para todos los prompts comparados.
• Semilla y temperatura controladas para reproducibilidad.

Métricas que sí ayudan

• Exactitud (tareas cerradas): exact match, F1 por campo.
• Win rate (generación abierta): victorias A vs. B por pares.
• Score por rúbrica: 1–5 para criterios (claridad, tono, formato).
• % JSON válido: cumplimiento de esquema.
• Abstención sana: % de “no sé” cuando falta evidencia.
• Coste por interacción y latencia p95.

LLM-as-judge (con cuidado)

Un modelo puede evaluar respuestas si le das una rúbrica clara, ejemplos y la salida en JSON. Usa un modelo distinto al que generó la respuesta para reducir auto-sesgo y pide justificación breve (no extensa) para auditoría. Valida una muestra con humanos para calibrar.

Rol: Juez con rúbrica.
Criterios: exactitud, groundedness, formato, concisión (1-5).
Salida:
{"score": {"exactitud":1-5,"groundedness":1-5,"formato":1-5,"concision":1-5},
 "is_preferred":"A|B|tie",
 "notes":"string breve"}

A/B tests: offline y online

• Offline: corre A vs. B sobre el golden set y compara métricas.
• Online: muestra A o B a usuarios reales; mide objetivos de negocio (CTR, resolución, CSAT).
• Significancia: usa prueba de diferencia de proporciones o bootstrap para win rate.
• Tamaño de muestra: define antes el mínimo; evita detener por “intuición”.

Observabilidad y toma de decisión

Centraliza resultados por versión de prompt, fecha, modelo y parámetros. Define un umbral de promoción (p. ej., +3% utilidad, -10% costo, sin degradar seguridad). Si no pasa, itera; si pasa, promociona y crea tag prompt.vN.prod.

Micro-workflow en n8n: “Comparador de prompts”

1. Webhook → recibe {promptA, promptB, dataset_id}.
2. HTTP → obtiene el golden set (entradas y criterios).
3. Split In Batches → itera entradas; llama LLM con A y B (semilla y temperatura fijas).
4. Function → envía ambas respuestas a un “juez” (LLM-as-judge) con rúbrica.
5. Aggregate → calcula win rate, media de scores, % JSON válido, coste y p95.
6. Database → guarda resultados por versión.
7. Notifier → si A gana por umbral y p-valor < 0.05, sugiere promoción.

Tip Laravel: expón un endpoint POST /eval/runs que dispare este flujo y persista métricas por versión de prompt.

Errores comunes (y cómo evitarlos)

• Cherry-picking: elegir ejemplos donde tu prompt luce mejor.
• Fuga de información: incluir respuestas ideales en el contexto.
• Sobreajuste al golden set: rota y versiona los datos de prueba.
• Sin control de variabilidad: temperatura/semilla cambiantes.
• Ignorar costo/latencia: elegir “mejor calidad” que quiebra tu presupuesto.

Conclusión

Evaluar sin sesgos es combinar buenos datos de prueba, diseño ciego y balanceado, métricas claras y una decisión estadística. Con este proceso, elegir el mejor prompt deja de ser subjetivo.

← Anterior: Patrones de prompt reutilizables que todo desarrollador debería conocer

Siguiente: In-context learning en serio: enseñando a tu modelo con pocos ejemplos →