VerifierBench: 19 LLM escribieron verificadores y el mejor apenas llegó a 62,1 puntos

Los agentes necesitan una forma de saber si han resuelto bien una tarea. Sin ella no pueden dar el trabajo por terminado ni filtrar datos sintéticos para entrenamiento. El equipo detrás de VerifierBench comprobó hasta qué punto los LLM lo logran por sí solos: a partir de una instrucción y un entorno disponible, el agente escribe un verificador ejecutable que debe aceptar cualquier solución correcta y rechazar cualquier solución incorrecta. El benchmark reúne 222 tareas de seis benchmarks agénticos y 4993 casos de prueba ocultos. En 19 modelos, la precisión balanceada normalizada se movió entre 10,6 y 62,1.

Qué evalúa exactamente VerifierBench

El planteamiento es exigente. El verificador recibe la misma información que el agente que resuelve la tarea: el texto del enunciado y el entorno. Con eso debe construir un programa que emita un veredicto sobre una solución ajena. Las tareas abarcan tres tipos de verificación: llamadas a herramientas (tool-call), comprobación del estado final del entorno (state-based) y comprobación de código.

Las pruebas ocultas están diseñadas para detectar algo más que fallos evidentes. Cada tarea tiene en promedio unos 22 casos. Entre ellos hay soluciones válidas alternativas, es decir, otras formas de llegar al resultado correcto, y ataques que intentan engañar a la verificación. Los autores someten los verificadores originales y los conjuntos de prueba a una auditoría de seis comprobaciones, Verifier4Verifier (V4V). Así evitan que la referencia se convierta en fuente de sus propios errores.

Parámetros clave del trabajo:

• 222 tareas de seis benchmarks agénticos
• 4993 casos de prueba ocultos, incluidas soluciones alternativas y ataques
• 19 modelos en un mismo harness agéntico
• normalized balanced accuracy: de 10,6 a 62,1
• la página del proyecto y el dataset son públicos

El verificador que no deja pasar a nadie

Lo más llamativo de los resultados es el sesgo. Los verificadores generados rechazan las soluciones incorrectas de forma sistemática mejor de lo que aceptan las correctas. A primera vista parece una virtud: una comprobación estricta se presume segura. Los autores muestran que detrás hay otra realidad. La mayoría de los falsos rechazos en los registros analizados corresponde a verificadores que no aceptan ninguna de las soluciones probadas para la tarea. Formalmente, ese verificador cumple bien la mitad del trabajo y la otra mitad no la cumple en absoluto.

Para los pipelines, esto es un problema serio. Si el verificador se usa para filtrar datos sintéticos, el exceso de rigor descarta en silencio trayectorias correctas. Si actúa como señal de éxito para el agente en tiempo de ejecución, el agente puede rehacer sin fin un resultado que ya era correcto.

El análisis de casos concretos revela de dónde viene esa severidad. Los verificadores incorporan supuestos sin comprobar sobre el formato de la solución, sobre qué herramientas hay que invocar y sobre el aspecto que debe tener el código tras los cambios. Cualquier solución que difiera de lo que imaginó el autor de la comprobación se descarta, aunque resuelva la tarea.

Por qué la autocomprobación no detecta el error

Se podría esperar que el agente notara el defecto al ejecutar su propio verificador sobre soluciones de prueba. En la práctica, los errores sobreviven a la autoevaluación, y los autores señalan dos causas. La primera: el agente prueba soluciones que comparten los mismos supuestos erróneos que el propio verificador. Escribe la comprobación para una plantilla de respuesta, genera después una respuesta con esa misma plantilla y todo cuadra. La segunda: parte de los agentes entrega el verificador sin asegurarse de que al menos una solución correcta lo supera.

Cómo probar a los propios verificadores

La conclusión de los autores es práctica: no basta con comprobar que el verificador acepta una solución correcta. También hay que comprobar si acepta las demás soluciones que la tarea permite. Para los equipos que construyen pipelines agénticos o ensamblan datasets sintéticos, de ahí se derivan varios pasos.

Primero, cada verificador generado necesita al menos un ejemplo correcto conocido que supere la comprobación; de lo contrario, puede acabar siendo un «muro impenetrable». Segundo, el conjunto de pruebas debe contener soluciones correctas alternativas, con otro formato, otro orden de llamadas y otra manera de modificar el código. Tercero, conviene vigilar por separado la proporción de falsos rechazos en lugar de fijarse solo en la precisión global: en una métrica agregada es fácil ocultar un sesgo hacia el exceso de rigor. Por último, la propia referencia debe auditarse, y el enfoque V4V ofrece un esquema ya preparado para ello.

La dispersión entre 10,6 y 62,1 indica además que la generación de verificadores está aún lejos de ser un problema resuelto. Incluso el mejor resultado deja un margen de error considerable. Por eso es pronto para fiarse de la evaluación agéntica sin un control independiente, y el dataset público ofrece a los equipos una forma cómoda de comparar modelos precisamente en esta habilidad.