Evaluar y hacer pruebas de regresión de prompts de LLM en producción

La intuición es una mala forma de mejorar un sistema LLM en producción. Un equipo de soporte edita un prompt, lo prueba un par de veces y anuncia que la nueva versión se siente mejor. Eso no es una evaluación. Puede que el cambio haya mejorado la calidad de la clasificación. Pero también puede que solo haya ayudado a los pocos ejemplos que alguien probó por casualidad, mientras alargaba las respuestas, las ralentizaba, empeoraba los casos poco habituales o abría más la puerta a la inyección de prompts.

Cuando los prompts mueven una aplicación real, la evaluación es el bucle de retroalimentación que muestra si un cambio ayudó de verdad.

Empezar con casos de prueba concretos

Las pruebas de prompts empiezan con casos concretos. En una aplicación de soporte, un caso podría reunir el mensaje de un cliente que dice que su enlace para restablecer la contraseña ha caducado, junto con la documentación relevante para ese problema.

Input:
Customer says their password reset link expired.

Context:
Relevant support documentation.

Expected behavior:
Classify as password-reset issue.
Do not claim the account is locked.
Recommend the documented recovery path.
Return the required structured output.

Un runner pasa el caso por la aplicación y guarda el resultado. Sencillo en teoría, pero en producción pueden cambiar muchas cosas a la vez. Una edición del prompt puede llegar junto con un modelo nuevo, otra forma de elegir el contexto, datos de recuperación nuevos, definiciones de herramientas distintas, un nuevo esquema de salida o ajustes de generación cambiados. Lo que se prueba, por tanto, es toda la configuración del sistema, no solo el texto del prompt.

En parte por eso el trabajo con prompts empieza a parecerse a la ingeniería de software. Un prompt se convierte en un artefacto con entradas, comportamiento esperado, versiones, tests y regresiones.

Qué contiene un buen conjunto de pruebas

Un buen conjunto de evaluación no es un montón de peticiones corrientes que salen bien. Para el sistema de soporte debería incluir a propósito:

• casos sencillos de restablecimiento de contraseña
• peticiones ambiguas
• casos a los que les falta información
• documentos que se contradicen
• contexto irrelevante
• conversaciones inusualmente largas
• mensajes hostiles de clientes
• contenido recuperado hostil
• peticiones que el sistema no puede atender
• casos que requieren una herramienta
• casos en los que no se debe llamar a ninguna herramienta
• resultados de herramientas malformados o incompletos

El último grupo es el más importante. Un agente no solo debe demostrar que sabe acertar. Debe demostrar que falla de forma segura.

Medir más de una cosa

Una evaluación, o eval, es una forma repetible de medir el rendimiento frente a criterios definidos. En su forma más simple, cada respuesta se puntúa como correcta o incorrecta, uno o cero. Para clasificar puede bastar, pero las aplicaciones LLM reales suelen necesitar varias dimensiones. Una respuesta de soporte podría puntuarse en:

1. Clasificación: ¿identificó el sistema el problema real del cliente?
2. Fundamentación: ¿respaldan la respuesta las evidencias disponibles y la información recuperada?
3. Completitud: ¿cubre todo lo necesario para resolver el problema?
4. Seguridad: ¿evitó afirmaciones o acciones no autorizadas y se mantuvo dentro de sus permisos?
5. Formato: ¿sigue la salida la estructura o el esquema exigidos?
6. Utilidad: ¿ayudaría de verdad al cliente a conseguir su objetivo?
7. Eficiencia: ¿se ahorró contexto, recuperaciones y llamadas a herramientas innecesarias sin dejar de dar una buena respuesta?

Precisamente por eso una sola cifra de calidad puede engañar. Un sistema puede volverse más útil y menos seguro, más preciso y mucho más caro, o más elocuente mientras rompe su esquema más a menudo. Una evaluación seria sigue las dimensiones que importan para la aplicación. El proyecto HELM de Stanford refleja la misma idea: evalúa los modelos en muchos escenarios y dimensiones en lugar de comprimir su comportamiento en una única puntuación de capacidad, y abarca capacidad, seguimiento de instrucciones, seguridad, contexto largo, pruebas de dominio específico y más.

El dataset importa más que un prompt de juez ingenioso

Imagina probar el sistema de soporte con solo diez casos fáciles, todos de restablecimiento de contraseña.

password reset
password reset
password reset
password reset
...

Un prompt nuevo podría sacar un 100 % y aun así funcionar mal en producción. Un dataset útil refleja la mezcla de casos que el sistema va a encontrarse, así que necesita variedad en la redacción, la dificultad, la calidad de los documentos, los idiomas o dialectos cuando proceda, la longitud del contexto, la ambigüedad, los casos límite, las entradas adversarias y las circunstancias del cliente. También necesita suficientes ejemplos difíciles para sacar a la luz los modos de fallo que importan.

Los benchmarks públicos ayudan a comparar la capacidad general de los modelos. MMLU abarca 57 áreas temáticas y HELM cubre muchos escenarios específicos de tareas y orientados al riesgo. Ninguno sustituye al conjunto propio de una aplicación, porque un producto de soporte define el éxito en sus propios términos. La pregunta no es qué modelo encabeza una clasificación general. Es qué configuración rinde mejor en el trabajo que esta aplicación hace de verdad.

Formas de juzgar una salida

Comparación exacta

Cuando la respuesta es fija, compara el valor generado con el esperado, por ejemplo una categoría igual a password_reset o una prioridad igual a high. Funciona mal con prosa abierta, donde muchas respuestas pueden ser aceptables.

Comprobaciones basadas en reglas

Algunas propiedades se pueden comprobar de forma determinista.

Does the JSON parse?
Does the required field exist?
Is urgency one of the permitted values?
Was a prohibited field returned?
Was an unauthorized tool called?

Estas comprobaciones no necesitan un segundo modelo para decidir, lo que las hace baratas y fiables.

Respuestas de referencia

Una respuesta escrita o verificada por una persona ofrece algo con lo que comparar. Un caso de soporte podría registrar el diagnóstico esperado y las evidencias que la respuesta debe citar.

Expected diagnosis:
Password-reset issue
Required evidence:
Recent reset request + unused reset link
Forbidden claim:
Account is locked

Después, la respuesta generada se califica frente a esos requisitos.

Rúbricas

Una rúbrica es una guía de puntuación explícita. En lugar de preguntar si una respuesta es buena, define niveles para cada criterio.

Grounding:
0 = contains unsupported claims
1 = mostly grounded
2 = fully grounded

Completeness:
0 = misses critical information
1 = partially complete
2 = complete

Safety:
0 = unsafe action or disclosure
1 = safe

La puntuación se vuelve más reproducible y el equipo se ve obligado a concretar qué significa realmente «bueno».

LLM como juez

Para texto abierto, a veces otro LLM puede hacer de evaluador.

Evaluate this support response.
Criteria:
1. Is the diagnosis supported by the supplied evidence?
2. Does the response answer the customer's question?
3. Does it avoid unsupported claims?
4. Does it follow the required tone?
Return a score from 1 to 5 and explain each score.

Es mucho más barato y rápido que hacer que una persona lea cada salida, y abarca cualidades que las reglas simples no captan, como la claridad o la utilidad. Pero el juez también es un modelo, y eso plantea un segundo problema: ¿quién evalúa al evaluador? Los estudios han encontrado una y otra vez sesgos e inestabilidad en el juicio basado en modelos, incluidos efectos de posición, estilo y autoridad. Un modelo juez no debe tratarse como verdad absoluta automática.

De ahí sale un orden de preferencia sensato. Usa comprobaciones deterministas siempre que se pueda, revisión humana cuando haga falta y evaluación con modelos donde aporte, con validación detrás. Comprueba la validez del JSON con un parser, no con otro LLM. Comprueba si un reembolso se emitió de verdad en el sistema de transacciones, no en el relato del propio modelo sobre lo que pasó. Para algo como la empatía en una respuesta al cliente, un juez LLM puede aportar una señal, respaldada por revisión humana.

Pruebas de regresión

Supón que la versión 7 del prompt de soporte funciona bien. Un mes después, un ingeniero cambia la plantilla de contexto. Las respuestas basadas en documentos mejoran, pero el modelo empieza a ignorar el historial de la conversación. Puede que el propio diff del prompt no dé ninguna pista del problema.

Una prueba de regresión detecta el momento en que un comportamiento que antes era aceptable empeora tras un cambio. El flujo es así.

La idea viene de las pruebas de software clásicas. Lo que pasa es que las aplicaciones LLM tienen muchos más componentes que pueden moverse, lo que amplía la zona donde se esconden las regresiones. Un cambio en cualquiera de estos elementos puede alterar el comportamiento.

Prompt
Model
Model version
Context selection
Retrieved documents
Memory
Tool definitions
Tool implementation
Output schema
Generation settings
Safety policies

Por tanto, la suite de regresión debe ejecutar el sistema en condiciones representativas y no limitarse a comprobar el texto del prompt.

Los compromisos se esconden en un veredicto único

Supón que el prompt antiguo obtuvo estas puntuaciones.

Classification accuracy: 94%
Grounding:               96%
Schema validity:         99%
Unsafe tool calls:       1%
Average latency:         1.8 s

Y el nuevo, estas.

Classification accuracy: 96%
Grounding:               95%
Schema validity:         99%
Unsafe tool calls:       4%
Average latency:         2.4 s

Decir que la nueva versión es mejor ocultaría un compromiso. La clasificación ganó dos puntos, pero las llamadas a herramientas inseguras se cuadruplicaron y la latencia también subió. La evaluación deja estos compromisos a la vista.

Las medias también pueden ocultar fallos graves. Si el 99 % de las peticiones son seguras pero el 1 % restante implica acciones financieras no autorizadas, una puntuación de seguridad del 99 % puede ser inaceptable. Para comportamientos de alto riesgo, los equipos suelen mirar por separado la categoría de fallo correspondiente para que no desaparezca en un agregado.

Trampas de cobertura en el dataset

Hay una trampa sutil. Un dataset de 1.000 casos en el que 900 son peticiones de restablecimiento de contraseña casi idénticas puede dar una puntuación impresionante y decir muy poco sobre situaciones raras pero importantes. La cobertura hay que planificarla. Un conjunto práctico tiene capas.

Core cases
    Common production scenarios

Edge cases
    Ambiguous, unusual, incomplete inputs

Adversarial cases
    Injection, manipulation, malicious content

Safety cases
    Requests involving restricted actions or information

Regression cases
    Previously observed failures

Golden cases
    Carefully reviewed examples representing important behavior

Un caso dorado es un ejemplo especialmente fiable cuyo comportamiento esperado se ha revisado con cuidado, y sirve de ancla al comparar versiones.

El dataset también debe seguir evolucionando. Cuando la monitorización revela un fallo nuevo en producción, ese fallo suele merecer convertirse en una nueva prueba de regresión. El resultado es un bucle.

Con el tiempo, la suite se convierte en un registro de errores que el sistema ha aprendido a no repetir nunca.

Hacia dónde lleva esto

La ingeniería de prompts tiene ahora otra capa por encima.

Esa capa pesa más que cualquier truco de prompting individual. Los sistemas de producción más sólidos no salen de encontrar un prompt mágico. Salen de un proceso iterativo en el que cada cambio se mide frente a casos representativos.

Medir también abre la puerta a la siguiente etapa. Cuando el rendimiento se puede cuantificar, surgen preguntas razonables. ¿Ayudarían más ejemplos o un prompt más corto? ¿Debería el sistema recuperar más contexto o menos? ¿Merece la pena probar otro modelo u otra forma de dividir la tarea? ¿Se podría automatizar la búsqueda de prompts? ¿Compensa ganar precisión a costa de más tokens? Las respuestas dependen de compromisos medibles, y ahí es donde empieza la optimización de prompts.