💬 NLP

RealClawBench: Live OpenClaw Benchmarks from Real Developer-Agent Sessions

RealClawBench introduit un cadre de référence en direct dérivé de sessions réelles d'agents-développeurs OpenClaw qui utilise des environnements d'exécution reconstruits et des évaluateurs déterministes pour transformer 281 tâches réelles et complexes en évaluations reproductibles, révélant des écarts de performance significatifs dans les modèles actuels.

Auteurs originaux : Zongwei Lv, Zhewen Tan, Yaoming Li, Yilun Yao, Yuxuan Tian, Lin Sun, Xiangzheng Zhang, Weihong Lin, Tong Yang, Guangxiang Zhao

Publié 2026-06-03

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Zongwei Lv, Zhewen Tan, Yaoming Li, Yilun Yao, Yuxuan Tian, Lin Sun, Xiangzheng Zhang, Weihong Lin, Tong Yang, Guangxiang Zhao

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de tester les capacités d'un nouveau robot chef.

L'ancienne méthode (Benchmarks conventionnels) :
Traditionnellement, les chercheurs écrivaient une liste de recettes parfaites et théoriques comme « Faire un sandwich au fromage grillé » ou « Cuire un gâteau au chocolat ». Ils donnaient ces recettes au robot et observaient s'il suivait les étapes. Le problème ? La vie réelle n'est pas un manuel scolaire. Dans le monde réel, un client pourrait dire : « Mon pain est légèrement rassis, le fromage est au fond du frigo, et je n'ai qu'un four grille-pain, pas un gril. Pouvez-vous me préparer quelque chose d'édible ? » Les anciens tests ne vérifiaient pas si le robot pouvait gérer ces détails complexes et désordonnés de la vie réelle.

La nouvelle méthode (REALCLAWBENCH) :
Les auteurs de cet article ont réalisé que pour véritablement tester un « agent développeur » (un robot qui aide les programmeurs), ils devaient arrêter d'inventer des tests fictifs et commencer à observer de vraies personnes utiliser les robots sur le terrain.

Ils ont construit un système appelé REALCLAWBENCH. Voici comment il fonctionne, en utilisant des analogies simples :

1. Capturer des moments réels (La source)

Au lieu d'inventer des tâches, l'équipe a observé 76 155 sessions réelles où de véritables développeurs utilisaient un outil appelé « OpenClaw » pour obtenir de l'aide avec leur code. Ils ont vu de vraies personnes demander de l'aide avec des requêtes désordonnées, compliquées et parfois vagues.

Analogie : Imaginez une caméra de surveillance enregistrant des milliers de vrais clients commandant de la nourriture dans un restaurant très fréquenté, plutôt qu'un chef écrivant un menu dans une cuisine calme.

2. Le « Nettoyage Magique » (Le Pipeline)

On ne peut pas simplement prendre l'enregistrement brut d'un client réel et en faire un test. L'enregistrement peut contenir des mots de passe privés, des fichiers d'entreprise secrets ou des références à des ordinateurs qui n'existent plus.
L'article décrit un pipeline (une ligne de production étape par étape) qui nettoie ces moments réels :

Écran de confidentialité : Ils suppriment tous les secrets et informations privées, comme on flouterait des visages dans une vidéo.
Reconstruction de l'environnement : Si un développeur a demandé au robot de corriger un fichier sur son ordinateur spécifique, l'équipe construit une version fictive et sûre de cet environnement informatique afin que le test puisse être exécuté à nouveau plus tard.
Réécriture de la requête : Ils transforment une requête vague et conversationnelle (« Hé, peux-tu regarder ce truc dont j'ai parlé tout à l'heure ? ») en une instruction claire et autonome (« Veuillez corriger le bug dans le fichier de connexion »).
Le Juge Automatique : Au lieu qu'un humain évalue le travail, ils écrivent un programme informatique qui vérifie le résultat. Le fichier a-t-il été corrigé ? Oui/Non. Pas de place pour l'interprétation.

3. Le Résultat : Un test « Vivant »

Le produit final est un benchmark comprenant 281 tâches réelles.

Pourquoi c'est spécial : Il est « vivant » et « ancré ». Cela signifie que le test n'est pas une liste statique de questions qui devient obsolète. Parce qu'ils l'ont construit à partir d'un flux continu de données d'utilisateurs réels, ils peuvent mettre à jour le test plus tard avec de nouveaux exemples réels pour le garder actuel.
Le « Fossé de Réalisme » : L'article soutient que les tests précédents présentaient un « fossé » entre ce qu'ils testaient et ce qui se passe réellement. REALCLAWBENCH comble ce fossé. C'est comme passer du test d'un conducteur sur une piste parfaite et vide au test d'un conducteur en plein trafic aux heures de pointe, avec des nids-de-poule et des piétons confus.

Qu'ont-ils découvert ?

Ils ont testé 14 des modèles d'IA les plus intelligents actuellement disponibles sur ce nouveau test complexe et réel.

Le Score : Même le meilleur modèle d'IA (Claude Opus 4.7) n'a résolu qu'environ 66 % des tâches.
La Conclusion : Cela signifie qu'il reste encore beaucoup de place pour l'amélioration. Les robots actuels, même « super-intelligents », luttent encore avec les problèmes désordonnés de la vie réelle auxquels les développeurs sont confrontés chaque jour.

Résumé

En bref, l'article dit : « Arrêtez de tester les robots avec des scénarios parfaits et fictifs. Testons-les avec les problèmes désordonnés de la vie réelle auxquels ils sont réellement confrontés, mais nettoyons-les juste assez pour pouvoir les évaluer équitablement. »

Ils ont construit un système pour faire exactement cela, et ils ont découvert que même les meilleurs robots d'aujourd'hui ne sont encore qu'aux deux tiers du chemin pour être véritablement fiables dans le monde réel.

Résumé Technique : REALCLAWBENCH

Énoncé du Problème

Les benchmarks d'agents actuels ne parviennent souvent pas à refléter la réalité des sessions développeurs-agents déployées. Bien que les benchmarks existants (par exemple, SWE-bench, WebArena, AgentBench) aient amélioré l'exécutabilité et la conscience des outils, ils reposent principalement sur des tâches rédigées, des artefacts publics ou des environnements organisés. Cela crée un « écart de réalisme » où les benchmarks peuvent être exécutables et difficiles, mais manquent de l'état local, de l'intention implicite de l'utilisateur et des critères de succès naturellement survenant dans les flux de travail réels de production.

Les sessions réelles développeur-agent (spécifiquement au sein de l'écosystème OpenClaw) présentent des défis uniques pour l'évaluation :

Dépendance au Contexte : Les tâches dépendent souvent d'environnements d'exécution locaux et d'états de projet spécifiques.
Intention Implicite : Les requêtes des utilisateurs contiennent fréquemment des objectifs sous-spécifiés ou des ellipses conversationnelles.
Difficulté de Vérification : Les critères de succès sont souvent non déterministes ou nécessitent un jugement subjectif, ce qui rend la notation automatisée difficile.

Par conséquent, les évaluations existantes ne mesurent peut-être pas avec précision la capacité d'un agent à résoudre des tâches issues de la distribution réelle d'utilisation déployée.

Méthodologie

Le document présente REALCLAWBENCH, un framework de benchmark en direct construit directement à partir de réelles sessions utilisateurs d'OpenClaw. La méthodologie centrale repose sur un pipeline qui transforme les journaux de déploiement bruts et sensibles en tâches reproductibles, protégées pour la confidentialité et scorées automatiquement.

1. Ancrage de la Distribution Source

Le framework utilise 76 155 sessions d'utilisation d'outils déployées de OpenClaw comme distribution source. Contrairement aux approches précédentes qui échantillonnent à partir de pools finaux organisés, REALCLAWBENCH ancre son échantillonnage sur le flux d'utilisation d'outils nettoyé avant le filtrage de qualité final. Cela garantit que le benchmark préserve la distribution empirique des demandes réelles des utilisateurs, y compris les catégories rares et les mélanges de tâches spécifiques.

2. Pipeline Session-vers-Tâche

Chaque instance publiée est construite via un processus de transformation en quatre étapes (illustré par la Figure 2) :

Reconstruction de l'Environnement ( $E_0$ ) : L'espace de travail initial est matérialisé à partir des preuves de la session, incluant les fichiers, les dépendances, les contextes de commande et les schémas. Les tâches reposant sur des services privés sont soit soutenues par des fixtures, soit rejetées.
Réécriture de la Requête ( $x$ ) : Les messages originaux des utilisateurs sont convertis en instructions autonomes. Ce processus résout les références locales et les ellipses conversationnelles tout en supprimant les identifiants privés. Crucialement, les réécritures préservent la catégorie de tâche originale sans ajouter d'indices de solution.
Construction du Vérificateur ( $V$ ) : Un programme déterministe est construit pour vérifier l'espace de travail final, le stdout et les sous-processus bornés. Les vérificateurs contrôlent les résultats structurels (ex: existence de fichiers, validité du schéma). Les tâches nécessitant un jugement subjectif ou esthétique sont exclues afin de garantir une notation automatique et déterministe.
Revue de Fidélité : Les instances de brouillon subissent un sondage pour détecter les bugs, les formulations ambiguës ou les instructions « fuyantes ». Seules les instances passant les tests de reconstructibilité et de validité du vérificateur sont publiées.

3. Mécanisme de Publication en Direct

REALCLAWBENCH supporte des publications en direct versionnées. La même carte de construction ( $T$ ) peut être appliquée à des fenêtres temporelles non chevauchantes de futurs journaux. Cela permet au benchmark de suivre les décalages temporels dans la demande des utilisateurs tout en maintenant un protocole d'évaluation contrôlé.

Contributions Clés

Identification de l'Écart de Réalisme : Le document définit formellement la divergence entre les benchmarks d'agents exécutables et la distribution réelle de l'utilisation déployée des développeurs-agents, soulignant le manque d'état local et d'intention implicite dans les jeux de données actuels.
Pipeline Session-vers-Tâche : Un nouveau pipeline qui convertit les journaux de déploiement bruts et sensibles à la vie privée en tâches de benchmark reproductibles via la reconstruction d'environnement, la réécriture préservant l'intention et des vérificateurs déterministes.
Publication de Benchmark en Direct : La publication de REALCLAWBENCH, un benchmark ancré dans la distribution contenant 281 tâches exécutables échantillonnées à partir de sessions réelles. Il démontre que le processus de construction peut être réexécuté sur de futurs journaux pour produire des mises à jour versionnées sans redéfinir les filtres.

Résultats

Fidélité de la Distribution

Le pipeline de construction préserve avec succès la forme de la distribution réelle des utilisateurs.

Divergence de Jensen-Shannon (JSD) : La publication finale de 281 tâches maintient une JSD maximale de 0,0448 par rapport à la distribution source (76 155 sessions) sur quatre axes : type de tâche, tours d'utilisateur, outils définis et appels d'outils.
Impact du Filtrage : Un filtrage agressif (des appels bruts au set final) n'a pas introduit de dérive de distribution significative, tous les décalages entre étapes adjacentes restant inférieurs à 0,05 bit.

Performance des Modèles (Leaderboard)

Le benchmark a été utilisé pour évaluer 14 modèles contemporains (incluant Claude Opus/Sonnet, GPT-5.5, DeepSeek, Gemini, et d'autres) sous un harnais OpenClaw partagé avec un timeout de 600 secondes.

Performance de Pointe : Le meilleur modèle, Claude Opus 4.7, a atteint un taux de succès moyen par échantillon de 65,8 %.
Marge de Progression : Le fait que le meilleur modèle ne résolve que ~66 % des tâches révèle une marge de progression substantielle pour les agents actuels sur des charges de travail de développement réalistes.
Efficacité des Coûts : La performance et le coût ne sont pas étroitement alignés. Par exemple, MiMo V2.5 Pro offrait un compromis favorable à un coût nettement inférieur (11,87 $) comparé à des modèles plus coûteux comme GPT-5.5 (61,87 $) qui se classait plus bas.
Comportement de Longue Traîne : Les scores macro-moyennés (tenant compte de la distribution déséquilibrée des types de tâches) ont révélé des classements différents par rapport aux simples moyennes par échantillon, soulignant l'importance d'évaluer la performance à travers diverses catégories de tâches réelles.

Validation du Benchmarking en Direct

Le pipeline a été testé sur une fenêtre temporelle ultérieure ( $W_{live}$ ) sans modifier les filtres ou les règles.

Rendement : Le pipeline a produit avec succès 34 cas finaux à partir de la fenêtre en direct, avec des ratios de rétention comparables à la fenêtre de base.
Dérive : La fenêtre en direct est restée distributionnellement proche de la fenêtre de base (JSD max de 0,0411), confirmant que le protocole peut suivre les changements de demande tout en maintenant la comparabilité.

Signification et Revendications

Le document affirme que REALCLAWBENCH offre une voie pratique vers des benchmarks qui mesurent mieux la capacité des agents dans l'usage réel. En transformant de réelles sessions déployées en instances d'évaluation contrôlées, le framework répond aux limites des benchmarks rédigés.

Les revendications clés incluent :

Réalisme : Le benchmark capture la distribution, la diversité et la difficulté réelle de l'utilisation des agents déployés, ce qui est souvent manqué par les jeux de données organisés.
Reproductibilité : Il démontre que les sessions réelles peuvent être converties en tâches reproductibles et scorées automatiquement sans perdre la « forme mesurée » de la distribution source.
Évaluation Dynamique : Le framework supporte des publications en direct et versionnées qui réduisent l'obsolescence et la contamination des données, permettant au benchmark d'évoluer parallèlement à l'usage déployé des agents.

Les auteurs soulignent que le benchmark est spécifique à l'écosystème OpenClaw et à la population d'utilisateurs orientée développeur, et que les scoreurs programmatiques privilégient les résultats vérifiables dans un espace de travail final, pouvant potentiellement manquer des qualités comme la maintenabilité du code ou le progrès partiel. Cependant, le framework établit un nouveau standard pour ancrer l'évaluation des agents dans les données de déploiement du monde réel.