«Se veía bien cuando lo probé» es como llegan a producción la mayoría de las regresiones de prompts. Las pruebas y la evaluación de prompts lo sustituyen por evidencia: un conjunto fijo de entradas, una definición de salida correcta y una comprobación que se ejecuta cada vez que cambia el prompt.
Los dos términos se solapan. Evaluación es medir qué tan bueno es un prompt o su salida. Prueba es ejecutar esas mediciones automáticamente y fallar cuando no se alcanza un umbral.
Dos cosas que puedes evaluar
El propio prompt. ¿Es claro, completo, coherente y seguro tal como está escrito? Esto es análisis estático. No necesita ninguna llamada a un modelo, así que es instantáneo, gratuito y da el mismo resultado cada vez.
La salida del modelo. Dado este prompt y esta entrada, ¿es correcta la respuesta? Esto necesita llamadas al modelo y una forma de juzgar el resultado.
Detectan problemas distintos, y un buen proceso usa ambas. Las comprobaciones estáticas se ejecutan con cada pulsación de tecla y cada commit. La evaluación de la salida se ejecuta cuando un cambio podría afectar al comportamiento.
Capa 1: comprobaciones estáticas del prompt
Una comprobación estática lee el texto del prompt y busca defectos conocidos:
- Ningún objetivo declarado, o ningún formato de salida.
- Palabras vagas y tamaños sin números.
- Instrucciones que se contradicen o se repiten entre sí.
- Variables de plantilla sin delimitar.
- Formulaciones de inyección, credenciales o datos personales.
- Recuento de tokens por encima de un presupuesto.
Esto es lo que hace la evaluación de prompts de PromptFlowEngine. La puntuación es 100 menos una penalización fija por hallazgo (30 por crítico, 10 por advertencia, 3 por informativo), con un tope de 50 cuando hay algo crítico, con la misma aritmética para cada una de las ocho dimensiones. Como la fórmula es pública, un cambio de puntuación siempre se puede rastrear hasta un hallazgo concreto.
Una puntuación estática no te dice si la respuesta del modelo es correcta. Te dice si el prompt le da al modelo una oportunidad justa.
Capa 2: un conjunto de pruebas
Un conjunto de pruebas es una lista de entradas con expectativas. Empieza con pocas.
| Tipo de caso | Por qué |
|---|---|
| Entradas típicas | Confirma que funciona el camino principal |
| Casos límite | Vacío, muy largo, idioma equivocado, mal formado |
| Entradas adversarias | Intentos de anular las instrucciones |
| Fallos pasados | Cada error encontrado se convierte en una prueba permanente |
Veinte casos bien elegidos valen más que doscientos casi duplicados. Sácalos del tráfico real cuando puedas, sin datos personales.
Capa 3: decidir si una salida pasa
Usa el método más barato que pueda juzgar la propiedad.
Aserciones de código. Deterministas y gratuitas. Úsalas siempre que puedas.
- Se analiza como JSON y coincide con el esquema.
- Contiene, o no contiene, una cadena dada.
- Longitud dentro de los límites.
- La etiqueta es igual a la etiqueta esperada.
- Respuesta numérica dentro de la tolerancia.
Comparación con una referencia. Compara con una buena respuesta conocida mediante coincidencia exacta o una medida de similitud. Adecuada para extracción y clasificación, débil para la escritura abierta.
Evaluación mediante modelo. Un segundo modelo juzga la salida según una rúbrica. Úsala para cualidades que el código no puede comprobar: fidelidad a una fuente, tono, exhaustividad.
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
Los evaluadores basados en modelos son a su vez prompts, con sus propios modos de fallo. Limita cada rúbrica a una pregunta, pide la evidencia antes del veredicto y comprueba el evaluador con una muestra de juicios humanos antes de fiarte de él.
Revisión humana. El estándar de referencia y el más caro. Úsala para calibrar los métodos automáticos y para revisar una muestra de la salida de producción.
Métricas que merece la pena seguir
| Métrica | Qué te dice |
|---|---|
| Tasa de aprobación | Proporción de casos de prueba que cumplen las expectativas |
| Validez del formato | Proporción de salidas que se analizan correctamente |
| Fidelidad | Proporción de respuestas respaldadas por el contexto suministrado |
| Precisión de las negativas | Rechaza lo que debe y responde lo que debe |
| Coherencia | Acuerdo entre ejecuciones repetidas de una misma entrada |
| Tokens y latencia | Coste de la calidad que estás obteniendo |
Informa de la tasa de aprobación junto con el número de casos. Un «90 %» con 10 casos es un solo fallo.
Cómo tratar el no determinismo
El mismo prompt y la misma entrada pueden producir salidas distintas. Tenlo en cuenta:
- Fija la temperatura baja en las tareas que necesitan coherencia.
- Ejecuta cada caso varias veces e informa de la tasa de aprobación, no de un único resultado.
- Haz aserciones sobre propiedades («menciona el plazo de reembolso») en lugar de sobre el texto exacto.
- Fija la versión del modelo y vuelve a ejecutar el conjunto cuando cambie.
Pruebas de regresión en CI
Las pruebas solo te protegen si se ejecutan automáticamente.
En cada commit: comprobaciones estáticas. Son rápidas y no necesitan clave de API. La puerta de pruebas de prompts hace fallar una pull request cuando un archivo de prompt baja de una puntuación mínima, supera un límite de tokens o contiene un hallazgo crítico, como una clave filtrada.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
Ante cambios en un prompt o un modelo: el conjunto de pruebas de salida, con un umbral de tasa de aprobación.
Con una periodicidad programada: el conjunto completo contra el modelo en producción, para detectar cambios del lado del proveedor.
PromptFlowEngine cubre la primera de estas. No ejecuta prompts contra un modelo; la evaluación de la salida necesita tu propio ejecutor de pruebas y acceso al modelo.
Comparar dos versiones
Al elegir entre borradores, compáralos con las mismas entradas y mira qué cambió, no solo los totales: qué casos pasaron de aprobar a fallar, cómo se movieron los tokens y si se introdujeron problemas nuevos. La vista de comparación del espacio de trabajo informa de las diferencias de calidad, tokens y coste entre dos prompts y enumera los hallazgos que cada versión resuelve o introduce.
Un proceso mínimo para empezar
- Ejecuta la comprobación estática y corrige las advertencias.
- Escribe 20 casos de prueba con expectativas.
- Añade aserciones de código para el formato y el contenido obligatorio.
- Registra la tasa de aprobación de referencia.
- Condiciona las pull requests a la comprobación estática.
- Vuelve a ejecutar el conjunto de pruebas siempre que cambie el prompt o el modelo.
Para ver cómo usar estos resultados para mejorar un prompt, consulta la optimización de prompts. Para mantener ordenadas las versiones y los resultados, consulta la gestión de prompts.