Cómo medir si las respuestas de tu agente son buenas

Se mide con un conjunto de casos de prueba que corre solo cada vez que algo cambia. Cada caso tiene una entrada, una salida esperada y una forma de calificarla sin intervención humana. Lo que decide si el conjunto sirve no es su elegancia: es que se ejecute siempre, incluso cuando nadie tiene tiempo.

Puntos clave

• Muchos casos con calificación automática rinden más que pocos calificados a mano. Lo dice la documentación del fabricante y va contra el instinto de todo el mundo.
• Las pruebas tienen que reflejar la distribución real de tu tarea, casos raros incluidos, no los ejemplos bonitos.
• Se corre en cada cambio de prompt, en cada cambio de modelo y una vez por semana aunque nadie toque nada.
• No hay un umbral de acierto de referencia. Se fija según lo que cuesta el error en tu caso.

¿Por qué no basta con probarlo a mano?

Porque probar a mano no se repite, y lo que no se repite no detecta regresiones.

El patrón es siempre igual. Alguien monta el agente, prueba quince conversaciones, queda contento y lo pone en producción. Tres semanas después cambia el prompt para arreglar una queja, y ese cambio rompe algo que funcionaba. Nadie se entera, porque las quince conversaciones de la primera vez no están escritas en ninguna parte y nadie las va a volver a probar una por una.

Un conjunto de pruebas es exactamente eso escrito y automatizado. La diferencia entre las quince conversaciones de la cabeza de alguien y las quince en un archivo que se ejecuta es la diferencia entre enterarte por una queja y enterarte antes de desplegar.

¿Cuántos casos hacen falta?

Más de los que te apetece escribir, y menos refinados de lo que te gustaría.

La recomendación de Anthropic para construir evaluaciones va justo contra el instinto: «Prioritize volume over quality: More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals.»

Traducido: más preguntas con calificación automática algo menos fina rinden mejor que pocas preguntas calificadas a mano con mucho cuidado. La razón es sencilla y tiene que ver con lo del apartado anterior. Veinte casos perfectos que necesitan una persona para calificarse se van a correr una vez y nunca más. Cien casos mediocres que se califican solos se van a correr en cada despliegue durante dos años.

Fuente: Anthropic, Create strong empirical evaluations, consultada el 31 de agosto de 2026.

Eso no significa escribir cien casos el primer día. Significa empezar por veinte que se califiquen solos y añadir uno cada vez que aparezca un fallo real en producción. A los seis meses tienes un conjunto que refleja tus problemas de verdad y no los que imaginaste al principio.

¿De dónde salen los casos?

De tu tráfico real, no de tu imaginación. La misma documentación lo pide así: «Be task-specific: Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!»

En la práctica hago tres montones.

El montón normal. Las preguntas o entradas que representan el 80% del volumen. Se sacan del historial: conversaciones reales, correos reales, documentos reales, con los datos sensibles quitados.

El montón raro. Los casos que aparecen poco y salen mal cuando aparecen. El cliente que escribe en dos idiomas a la vez, el documento escaneado torcido, la pregunta que mezcla dos temas. Estos son los que dan valor al conjunto, porque son los que nadie prueba a mano.

El montón peligroso. Entradas donde una respuesta incorrecta cuesta caro: preguntas sobre precios, sobre plazos legales, sobre lo que la empresa se compromete a hacer. Aquí el criterio no es que acierte, es que cuando no sepa lo diga.

¿Cómo se califica sin una persona delante?

Diseñando la pregunta para que se pueda calificar. La recomendación es explícita: «Automate when possible: Structure questions to allow for automated grading (for example, multiple-choice, string match, code-graded, LLM-graded).»

En orden de menos a más frágil:

Forma de calificar	Cuándo sirve
Coincidencia exacta	Clasificaciones, extracción de campos, cualquier salida con una respuesta correcta única
Coincidencia por reglas en código	Formatos, rangos, presencia de campos obligatorios, longitud
Otro modelo como juez	Respuestas abiertas donde importa el tono, la completitud o si citó la fuente
Persona	Solo la muestra que revisa al juez, y los casos nuevos antes de añadirlos

La tentación es saltar directo al modelo juez porque parece resolver todo. Es la opción más cara y la menos estable de las cuatro, y tiene una trampa: el juez también se equivoca. Antes de confiar en él hay que revisar a mano una muestra de sus veredictos, y volver a revisarla cada vez que el juez cambie de modelo.

Muchas tareas que parecen abiertas se pueden reformular para que admitan coincidencia exacta. En lugar de pedir un resumen y juzgarlo, pide el resumen más tres campos concretos y califica los tres campos. La calidad del resumen se juzga por muestreo; los campos se juzgan solos, siempre, gratis.

¿Cuándo se corre?

En tres momentos, y el tercero es el que nadie hace.

En cada cambio de prompt. Un ajuste que arregla un caso rompe otro con una frecuencia que sorprende, y sin pruebas no hay forma de saberlo hasta que alguien se queja.

En cada cambio de modelo. Es obvio y aun así se salta, normalmente porque la versión nueva promete ser mejor. Mejor en promedio no es mejor en tu caso.

Y una vez por semana aunque nadie haya tocado nada. Esta es la importante. Los modelos cambian por debajo, los datos de entrada cambian de forma, una integración empieza a mandar el campo vacío. La corrida semanal es lo que convierte «no sé desde cuándo pasa esto» en «empezó el martes».

El resto de lo que hace falta para sostener un agente en producción, desde el registro de llamadas hasta los límites de gasto, está en agentes con modelos de lenguaje.

¿Qué umbral es aceptable?

El que corresponda a lo que cuesta equivocarse, y eso lo decides tú porque no hay una cifra de referencia publicada que sirva.

Un clasificador que ordena una bandeja y cuyo error significa que alguien mueve un correo de carpeta puede vivir con un 85%. Uno que decide a qué vendedor se le asigna un lead necesita más, porque el error se nota en la comisión de alguien. Uno que contesta a un cliente sin revisión previa necesita otra conversación entera, y probablemente no debería existir todavía.

Lo que sí conviene siempre es fijar el umbral antes de correr las pruebas. Si se fija después, se fija en el número que salió, que es una forma elegante de no tener umbral.

Si quieres que revisemos cómo evaluar el agente que ya tienes o el que estás pensando montar, el diagnóstico inicial no tiene costo.

Preguntas frecuentes

¿Cuántos casos de prueba necesito? Más de los que te apetece escribir. Anthropic recomienda priorizar volumen sobre refinamiento: muchas preguntas con calificación automática algo menos fina rinden mejor que pocas calificadas a mano con mucho cuidado. Cien casos que corren solos valen más que veinte perfectos que nadie repite.

¿Puedo usar otro modelo para calificar las respuestas? Sí, y es la práctica normal cuando el resultado no admite coincidencia exacta. Pero el calificador también se equivoca, así que hay que revisar a mano una muestra de sus veredictos antes de confiar en él y repetir esa revisión cada vez que cambie de modelo.

¿Cada cuánto hay que correr las pruebas? En cada cambio de prompt, en cada cambio de modelo y una vez por semana aunque no se toque nada. Lo tercero es lo que casi nadie hace y lo que detecta que algo se movió por debajo sin que nadie lo avisara.

¿Qué nivel de acierto es aceptable? Depende del costo del error en tu caso, y no hay un número publicado que sirva de referencia. Un clasificador cuyo error solo significa que alguien reordena una lista tolera mucho más que uno que manda un correo a un cliente sin revisión.