ERB : des agents IA conçoivent eux-mêmes des tests pour les modèles et s'alignent sur la référence dans 75% des paires

L'auto-amélioration récursive de l'IA se heurte à un problème prosaïque : pour savoir si un modèle a progressé, il faut le passer sur des benchmarks lourds, ce qui coûte cher et ralentit les itérations. Les humains se débrouillent généralement en prenant un sous-ensemble de tâches ou en assemblant un jeu compact. Des chercheurs se sont demandé si un agent pouvait le faire seul, et ont construit EvalResearchBench (ERB) pour le vérifier. Les meilleurs évaluateurs créés par les agents dans le budget imparti ordonnent les paires de modèles comme les benchmarks cibles dans environ 75% des cas. Le plafond est fixé par l'accord des tests cibles entre eux : 91%.

Comment l'agent devient chercheur en évaluation

Dans ERB, l'agent, que les auteurs appellent researcher, reçoit les matériaux cibles, des références de développement, une liste d'API candidates et des limites fixes de temps et de dépenses d'API. Il agit ensuite comme un ingénieur responsable de la qualité des tests. Il choisit des tâches existantes ou en synthétise de nouvelles, écrit les graders et lance des essais pilotes. À partir de leurs résultats, il corrige les tâches et le code de vérification. À la fin, l'évaluateur est gelé sous forme de programme exécutable. Trois domaines sont couverts : le code, le co-work et le raisonnement.

La validation repose sur la comparaison. Neuf agents-chercheurs ont travaillé avec 13 modèles candidats. Chaque évaluateur gelé a été confronté à 14 benchmarks cibles selon deux métriques : la cohérence des scores finaux et l'accord par paires, c'est-à-dire la concordance sur lequel de deux modèles est le meilleur.

Là où l'automatisation reste en deçà

Principaux résultats de l'étude :

• les meilleurs évaluateurs obtiennent environ 75% de concordance sur les paires de modèles, contre un plafond de 91% ;
• aucun agent-chercheur ne domine sur toutes les métriques ;
• le meilleur évaluateur sur les benchmarks cibles accessibles pendant le développement n'est pas le meilleur sur les benchmarks fermés (sealed), que l'agent n'a pas vus ;
• l'échantillon humain de tâches publiques reste une solide base de référence ;
• l'évaluateur au coût d'exécution enregistré le plus bas a obtenu l'accord par paires le plus élevé.

Le deuxième point illustre le problème classique du surapprentissage sur les repères accessibles. L'agent voit les cibles de développement et ajuste l'évaluateur en conséquence, mais l'avantage disparaît sur les benchmarks cachés. Le dernier point est moins intuitif : davantage de calcul pour l'évaluation ne garantit pas un classement plus précis des modèles. Un évaluateur bon marché est probablement plus simple, tient mieux dans le budget et plante moins souvent en cours de route.

Pannes typiques : réponses tronquées, budget épuisé et questions dominantes

Les agents savent corriger leurs tâches et leurs graders grâce au retour des essais pilotes. Mais les évaluateurs finis souffrent quand même de défauts précis. Ils peuvent tronquer les réponses du modèle, et une solution correcte est alors comptée comme une erreur. Ils peuvent épuiser le budget d'évaluation avant la fin de l'exécution. Enfin, ils peuvent laisser quelques questions déterminer le score final de tout un domaine, si bien que le bruit sur deux ou trois tâches se transforme en « qualité de raisonnement ».

Ces erreurs n'ont rien d'exotique. Toute équipe qui a monté un jeu d'évaluation interne s'est heurtée à une limite max_tokens qui coupe la réponse, ou à un déséquilibre des poids entre tâches. Les agents reproduisent les écueils humains, mais en mode automatique, là où personne ne vérifie.

Ce que les équipes qui construisent des pipelines d'évaluation doivent

en retenir

Pour l'instant, l'agent-chercheur ne remplace pas l'humain : il produit un brouillon d'évaluateur. Si vous automatisez la sélection des tests, conservez un jeu de benchmarks fermé que l'agent ne voit pas, faute de quoi le choix du meilleur évaluateur relèvera de l'illusion. L'échantillon humain de tâches publiques doit rester le point de contrôle : si l'évaluateur de l'agent ne le dépasse pas en accord par paires avec les benchmarks cibles, son automatisation n'apporte rien.

Avant de geler un évaluateur, il convient d'ajouter des vérifications simples : les réponses sont-elles tronquées, l'exécution tient-elle dans le budget, quelques questions dominent-elles le domaine. Enfin, traitez le coût comme une métrique : d'après ERB, un évaluateur bon marché peut classer les modèles aussi bien qu'un évaluateur coûteux, voire mieux. Pour une industrie où les systèmes auto-améliorants butent sur le prix du retour d'information, c'est un repère concret : 75% contre 91% montre la distance qui reste avant des boucles autonomes où l'IA se fabrique elle-même sa règle de mesure.