¿Quién califica al calificador? Validación de los conjuntos de evaluación de agentes antes de confiar en ellos.

En 2026, casi todos los equipos que lanzan un agente de IA también ejecutan un conjunto de pruebas de evaluación, completo con paneles de control, tasas de aprobación, puntos de control de integración continua y evaluadores de LLM que califican las trayectorias según criterios establecidos. Todo esto demuestra rigor, y parece marcar la diferencia entre un sistema en producción y una demostración que por casualidad funcionó dos veces.

Pero si se plantea la siguiente pregunta obvia, todo se vuelve silencioso. ¿Quién verificó que ese conjunto de pruebas mide lo correcto, lo mide adecuadamente y sigue dando resultados precisos medio año después de haber sido creado? Casi nadie. La industria pasó dos años desarrollando herramientas para evaluar a los agentes y apenas ha comenzado a crear herramientas para evaluar esas mismas herramientas. La brecha ya se está manifestando en la producción, de varias maneras predecibles.

La suposición que nadie expresa

Detrás de la mayoría de las configuraciones de evaluación de agentes existe una suposición tácita: un resultado positivo significa que el agente se comportó correctamente y uno negativo que no lo hizo. Al aceptar esto, el conjunto de herramientas se convierte en una caja negra en la que la gente confía automáticamente. El panel de control muestra un color verde, las fusiones de cambios se realizan y el equipo pasa a otra cosa.

Las investigaciones sobre los registros de los agentes han comenzado a cuestionar esa premisa. Un estudio analizó 58 registros que la evaluación de resultados había marcado como exitosos y descubrió que el 83 por ciento de esas ejecuciones ocultaban violaciones procedimentales o de seguridad que la evaluación de éxito/fallo nunca detectó. El agente dio la respuesta correcta y recibió una calificación perfecta, pero el método que utilizó estaba defectuoso. La distancia entre el resultado final y el proceso es precisamente lo que existe para detectar un sistema de evaluación, y también es precisamente lo que la mayoría de estos sistemas no pueden ver por diseño.

Hay cuatro patrones de fallo que merecen nombres separados. Cada uno requiere su propia solución, y los equipos suelen darse cuenta solo del que les ha causado problemas.

Deriva del juez. Todo lo semántico tiende a ser evaluado por un LLM, ya que una verificación basada en reglas no puede determinar si “el próximo viernes” se convirtió en la fecha correcta. Pero el “juez” también es un modelo, y los modelos cambian. Los equipos que utilizan suites a largo plazo a menudo observan cómo todo el panel de control de regresiones empeora de la noche a la mañana, pierden un día investigando y finalmente descubren que las calificaciones cambiaron porque se actualizó el modelo del juez y no porque el agente empeoró. Fijar una versión del modelo del juez y un hash de la rúbrica corregida reduce el problema sin eliminarlo, ya que los puntos de acceso del juez alojado siguen cambiando.

El error del resultado final. Evaluar únicamente el estado final ignora la parte interesante del proceso. Un agente podría utilizar la herramienta incorrecta, reenviar cuatro veces el mismo argumento defectuoso y, aun así, llegar a la respuesta correcta por suerte o perseverancia; sin embargo, un sistema que solo lee el mensaje final lo marcará como aprobado.

Modos de fallo privados. Los benchmarks públicos como BFCL o tau-bench ayudan a comparar modelos, pero no pueden detectar fallos que ocurren dentro del registro de herramientas de un equipo: un valor nulo en un campo opcional, un error de zona horaria en un argumento de fecha o una discrepancia monetaria en un campo de dinero. Dichos fallos pertenecen a las herramientas del equipo y nunca aparecen en una tabla de clasificación de uso general. Si la cobertura de pruebas se obtiene exclusivamente de benchmarks públicos, el validador quedará ciego justo en los puntos más importantes, es decir, en las partes del sistema que nadie más ha probado.

El punto ciego en los costos. El menos discutido, y quizás el de mayores consecuencias. Un sistema de evaluación puede calificar a un agente como preciso en todas las dimensiones que analiza, sin preguntarse nunca si el agente se autofinancia. Un caso bien conocido involucró a un agente que cumplía con cada una de las doce métricas de calidad, pero fue retirado del servicio, porque cada resolución exitosa costaba más que el proceso humano que debía reemplazar. Las puntuaciones de calidad eran precisas. No existía ninguna métrica para responder a la pregunta que decidió su destino.

Un agente de reservas con puntuación perfecta que fracasó

Imagínese a un agente de reservas al que le piden encontrar vuelos para “el próximo viernes”. De un registro con decenas de herramientas, elige la adecuada, por lo que la selección de herramienta obtiene un puntaje impecable de 1.0. Luego envía la fecha como una cadena literal sin resolver primero la expresión relativa. La API responde con un error de validación, y el agente vuelve a enviar la misma cadena defectuosa cuatro veces antes de disculparse y abandonar.

Ese seguimiento arroja dos cifras: un 1.0 perfecto para la selección de herramienta y un 0 para la finalización de la tarea. Ninguna de ellas indica cuál de las tres posibles causas del problema: una extracción defectuosa de los argumentos, una respuesta de error que el agente nunca leyó, o una lógica de reintentos que se repite con datos sin cambios. Un análisis detallado de la evaluación de las llamadas a herramientas demostró que verificar únicamente si se llamó la herramienta correcta evalúa la intención en lugar de la ejecución, y la intención no fue lo que falló.

Ese es el problema completo en miniatura. El conjunto de pruebas emitió dos números, ninguno completamente incorrecto, pero ambos inútiles para la única pregunta importante: ¿qué debe corregirse?

Prácticas que ayudan

Una vez que el conjunto de evaluación se trata como un sistema que merece sus propias pruebas de calidad, una configuración madura se ve de manera diferente. Un puñado de hábitos distingue a los equipos que detectan los problemas temprano de aquellos que lo descubren tarde y con dificultad:

• Una capa de metaevaluación propia. En implementaciones serias, el trabajo ahora se divide en evaluación de resultados, evaluación de cada paso del proceso y una capa que compara a los evaluadores entre sí para que la puntuación de ningún único juez se tome al pie de la letra.
• Verificación basada en la ejecución en lugar de la comparación de texto. Los benchmarks más fiables examinan qué es lo que realmente ha cambiado en el mundo. tau-bench lee el estado de la base de datos, SWE-Bench ejecuta las pruebas reales, y tau2-bench’s pass-at-k verifica si un agente logra tener éxito de manera consistente en intentos repetidos. Los conjuntos de pruebas desarrollados localmente deberían seguir este mismo enfoque y confirmar los cambios reales, independientemente de lo que informe el agente.
• Costo junto con la calidad. El argumento en el ámbito financiero aboga por seguir el costo por resultado exitoso como métrica fundamental junto con la precisión, calculándolo desde el principio en lugar de hacerlo más tarde, cuando quien gestiona el presupuesto comienza a hacer preguntas.
• CI por niveles. Las evaluaciones completas de extremo a extremo son muy costosas porque cada tarea requiere dos llamadas al modelo, la del agente y la del juez, y un conjunto de cien tareas con cinco pruebas cada una duplica aproximadamente el costo del CI. Los equipos que mantienen esto bajo control separan las verificaciones rápidas, gratuitas y deterministas que se ejecutan en cada commit de las evaluaciones lentas, costosas y basadas en juezes que solo se realizan cuando un cambio afecta la lógica del agente.
• Un conjunto que sigue funcionando. En una encuesta reciente del sector, la mayoría de los encuestados indicó que sus evaluaciones no cumplen con las expectativas porque el tráfico real se aleja del conjunto de pruebas original y resulta imposible mantenerlo al día. Un conjunto que no se modifica desde su lanzamiento no es inofensivo; mide un sistema que ya dejó de existir.

Cuatro pasos para mejorar un conjunto que ya tienes

Para un equipo que cuenta con un conjunto de herramientas de evaluación y desea validarlas en lugar de confiar únicamente en ellas, cuatro pasos cubren la mayor parte de las necesidades:

1. Seleccionar de diez a veinte registros de producción que la herramienta haya marcado como exitosos y leer manualmente cada trayectoria completa, no solo la respuesta. La cantidad de casos exitosos que ocultan defectos procedimentales constituye una medida real de hasta qué punto se puede confiar en el panel de control.
2. Identificar claramente la versión del modelo de evaluación y el texto de las pautas, y registrar ambos junto con cada calificación, de modo que una actualización silenciosa del modelo se considere un evento identificado en lugar de una regresión misteriosa.
3. Registrar el costo por resultado exitoso desde el primer día, incluso antes de que alguien lo solicite.
4. Crear un pequeño conjunto de casos de regresión a partir de fallos reales en producción y no solo de casos sintéticos. Los puntos de referencia públicos establecen un mínimo, mientras que el historial de incidentes propio del equipo es lo que permite predecir el próximo fallo embarazoso.

Nada de esto sustituye al conjunto de pruebas. Simplemente deja de tratar al conjunto como el único componente demasiado importante como para ser revisado.

Respuestas rápidas

¿Qué significa la validación del conjunto de pruebas con eval para los agentes? Se aplica el mismo escrutinio al sistema de evaluación que el sistema aplica al agente, preguntándose si el juez, la rúbrica y el proceso de puntuación siguen midiendo lo que afirman.

¿Por qué varían las puntuaciones cuando el juez es un modelo LLM? El juez es un modelo. Cuando su proveedor lo actualiza o se reemplaza por una versión más reciente, las puntuaciones pueden cambiar aunque el agente evaluado no haya cambiado.

¿Pueden los benchmarks públicos reemplazar a un conjunto de pruebas personalizado? No. Ayudan a comparar modelos en tareas comunes, pero no detectan fallos originados en las herramientas, datos o casos especiales propios del equipo.

¿Es suficiente una alta tasa de aprobación para mantener a un agente en producción? No por sí sola. Un agente puede tener buenos resultados en precisión y calidad de la trayectoria y aún así ser retirado si el costo por resultado exitoso no justifica el valor que brinda.

¿Con qué frecuencia se debe revisar o reconstruir el conjunto de herramientas? Continuamente, a medida que cambia el tráfico de producción. El uso se aleja del conjunto de pruebas original, por lo que los casos extraídos de fallos reales deben llegar de forma regular y no solo en el momento del lanzamiento.

La afirmación detrás del panel de control

Un conjunto de pruebas de evaluación no es prueba de que un agente funcione. Es una afirmación sobre qué significa “funcionar”, escrita por quien lo desarrolló, calificada por un evaluador cuyos criterios pueden cambiar, y aplicada a un conjunto de pruebas que comienza a envejecer en el momento en que se crea. Considerar esa afirmación como obviamente verdadera es la razón por la cual algunos agentes se lanzan al mercado y pasan todas las métricas mostradas en los paneles de control, pero fallan en la pregunta realmente importante. Una revisión manual de diez registros, como se describió anteriormente, muestra rápidamente cuánto ha estado ocultando el panel de control.