ERB: agentes de IA diseñan sus propios tests para modelos y coinciden con la referencia en el 75% de los pares

La automejora recursiva de la IA choca con un problema poco glamuroso: para saber si un modelo ha mejorado hay que pasarlo por benchmarks pesados, lo que resulta caro y frena las iteraciones. Los equipos suelen salir del paso con un subconjunto de tareas o con un conjunto compacto armado a mano. Los investigadores se preguntaron si un agente puede hacerlo por sí solo y construyeron EvalResearchBench (ERB) para comprobarlo. Los mejores evaluadores que los agentes crearon dentro del presupuesto asignado ordenan los pares de modelos igual que los benchmarks objetivo en aproximadamente el 75% de los casos. El techo lo marca la coincidencia de los propios tests objetivo entre sí: 91%.

Cómo el agente se convierte en investigador de evaluación

En ERB, el agente, al que los autores llaman researcher, recibe materiales objetivo, referencias de desarrollo, una lista de API candidatas disponibles y límites fijos de tiempo y de gasto en API. A partir de ahí actúa como un ingeniero responsable de la calidad de los tests. Elige tareas ya hechas o sintetiza otras nuevas, escribe los graders y lanza ejecuciones piloto. Con sus resultados corrige las tareas y el código de verificación. Al final, el evaluador se congela como un programa ejecutable. Los dominios son tres: programación, co-work y razonamiento.

La verificación se basa en la comparación. Nueve agentes investigadores trabajaron con 13 modelos candidatos. Cada evaluador congelado se contrastó con 14 benchmarks objetivo según dos métricas: la consistencia de las puntuaciones finales y el acuerdo por pares, es decir, la coincidencia sobre cuál de los dos modelos es mejor.

Dónde se queda corta la automatización

Principales resultados del estudio:

• los mejores evaluadores logran cerca del 75% de coincidencias en los pares de modelos, frente a un techo del 91%;
• ningún agente investigador lidera en todas las métricas;
• el mejor evaluador sobre los benchmarks objetivo disponibles durante el desarrollo no es el mejor sobre los cerrados (sealed), que el agente no ha visto;
• la muestra humana de tareas públicas sigue siendo una base de comparación sólida;
• el evaluador con el menor coste de ejecución registrado obtuvo el mayor acuerdo por pares.

El segundo punto ilustra el clásico problema del sobreajuste a los referentes disponibles. El agente ve los objetivos de desarrollo (development) y ajusta el evaluador a ellos, pero en los benchmarks ocultos la ventaja desaparece. El último punto es poco intuitivo: dedicar más cómputo a la evaluación no implica un ranking más preciso de los modelos. Probablemente, el evaluador barato es más simple, encaja mejor en el presupuesto y falla con menos frecuencia por el camino.

Fallos típicos: respuestas truncadas, presupuesto agotado y preguntas dominantes

Los agentes saben corregir sus tareas y graders a partir del feedback de las ejecuciones piloto. Aun así, los evaluadores terminados sufren defectos concretos. Pueden truncar las respuestas del modelo, de modo que una solución correcta se contabiliza como error. Pueden agotar el presupuesto de evaluación antes de que termine la ejecución. Y pueden permitir que unas pocas preguntas determinen la puntuación final de todo un dominio, de modo que el ruido de un par de tareas acaba convertido en «calidad de razonamiento».

Estos errores no son nada exótico. Cualquier equipo que haya montado un conjunto de eval interno se ha topado con el límite de max_tokens que corta la respuesta o con un sesgo en los pesos de las tareas. Los agentes reproducen los tropiezos humanos, pero lo hacen en modo automático, donde nadie revisa.

Conclusión práctica para los equipos que construyen pipelines de eval

Por ahora, el agente investigador no sustituye a la persona, sino que funciona como un borrador de evaluador. Si automatiza la selección de tests, mantenga un conjunto cerrado de benchmarks que el agente no vea; de lo contrario, la elección del mejor evaluador será un autoengaño. La muestra humana de tareas públicas debe seguir siendo el punto de control: si el evaluador del agente no la supera en acuerdo por pares con los benchmarks objetivo, su automatización no aporta nada.

Antes de congelar el evaluador conviene añadir comprobaciones sencillas: que no se trunquen las respuestas, que la ejecución quepa en el presupuesto y que unas pocas preguntas no dominen un dominio. Por último, trate el coste como una métrica: según ERB, un evaluador barato puede ordenar los modelos igual de bien que uno caro, o incluso mejor. Para una industria donde los sistemas que se automejoran chocan con el precio del feedback, es una referencia concreta: 75% frente a 91% indica cuánto falta para llegar a ciclos autónomos en los que la IA construye su propia vara de medir.