Benchmarks d’agents IA : GAIA, WebArena, OSWorld et SWE-bench

GAIA évalue des réponses à des questions réalistes combinant raisonnement, multimodalité, navigation web et usage d’outils. WebArena évalue des tâches longues dans des sites web fonctionnels et reproductibles. OSWorld ajoute des applications desktop, du file I/O et des workflows multi-app dans un environnement informatique réel. SWE-bench part d’une issue GitHub et d’un snapshot du repository puis vérifie si un patch résout le problème de software engineering. Ce ne sont pas quatre classements interchangeables : chacun mesure une distribution de tâches, un espace observation/action et une définition du succès différents.

Commencez par nommer la décision de production : choisir un scaffold, autoriser un browser workflow, changer de coding agent ou étendre un niveau d’autonomie. Mappez ensuite le travail réel vers le contrat du benchmark. Un résultat externe fournit un prior sur la capacité, mais ne prouve pas la qualité sur vos données, permissions, locale, UI, repository ou coût d’erreur. Le release exige toujours un eval slice interne ayant la même forme de tâches et un oracle indépendant.

GAIA convient lorsque l’agent collecte des faits, travaille avec des fichiers et des entrées multimodales, utilise le web ou des tools et renvoie une réponse courte vérifiable. Sa force est de composer les capacités de base d’un assistant ; sa limite en production est l’absence de l’état réel de vos applications et de consequential side effects. Ajoutez vos propres tâches de knowledge work, règles de citation, freshness cutoff et cas d’abstention.

Choisissez WebArena pour un browser agent qui navigue dans des interfaces e-commerce, forum, collaborative development ou content management et doit atteindre un état fonctionnel. OSWorld correspond mieux à un computer-use agent passant entre navigateur, office, système d’exploitation et workflows de fichiers. Pour un coding agent, SWE-bench fournit un signal issue-to-patch sur de vrais repositories, mais votre replay interne doit reproduire toolchain, instructions, hidden checks et review policy.

• GAIA → questions d’assistant général, browsing, tools et preuves multimodales.
• WebArena → tâches web fonctionnelles et outcome basé sur l’exécution.
• OSWorld → desktop, fichiers et workflows entre applications.
• SWE-bench → issue de repository, modification de code et résolution fondée sur les tests.

Un nom de modèle accompagné d’un pourcentage n’est pas un résultat reproductible. Enregistrez la révision ou le split du benchmark, agent scaffold, prompt, tools, observation mode, action adapter, budget, retry policy, nombre d’échantillons, environment image, état des dépendances et version du grader. Pour le web et le desktop, ajoutez viewport, locale, account fixtures, reset status et part des infrastructure failures. Pour les coding evals, épinglez base commit, test command, application du patch, network policy et contamination controls.

Comparez uniquement des runs soumis à des règles compatibles. Pass@k avec plusieurs essais n’est pas la first-run reliability ; un succès avec browser n’est pas un succès sans accès web ; un scaffold différent peut mieux expliquer l’écart que la model capability. Ne transposez pas des baseline historiques au produit actuel : elles appartiennent à une version donnée du paper et du harness. Dans le decision record, conservez le lien vers le result artifact primaire plutôt qu’un chiffre de leaderboard recopié sans provenance.

La construct validity demande si la tâche et le grader mesurent réellement la capacité recherchée. Un exact answer est utile pour une question de type GAIA, mais ne dit rien sur la sûreté de la trajectoire. Un test réussi dans SWE-bench peut confirmer le comportement du patch sans garantir maintenabilité ni conformité à la policy interne. Un grader web ou desktop peut observer le bon final state tout en ratant un message inutile, une fuite de données ou un side effect répété. Ajoutez des verdicts séparés pour outcome, trajectory, policy et side effects.

Vérifiez si tasks, solutions, screenshots ou repositories ont pu apparaître dans l’entraînement, les exemples ou le prompt tuning. Un ensemble interne held-out ne doit pas être visible par l’équipe qui optimise l’agent. Étiquetez séparément les environment failures : un site qui ne démarre pas, une dépendance indisponible ou un oracle absent ne sont ni un échec du modèle ni un succès. Rejouez régulièrement une baseline known-good pour distinguer une régression de l’agent d’un drift du harness.

Un bridge set est un petit jeu de données versionné qui conserve la forme du benchmark externe mais remplace le domaine par le vôtre. Pour un research assistant, utilisez des questions multi-sources avec date de fraîcheur et citation oracle ; pour un browser agent, une copie réinitialisable d’un workflow clé ; pour un desktop agent, des fichiers synthétiques et outputs interceptés ; pour un coding agent, des issues historiques assainies sur des commits épinglés. Chaque tâche a besoin d’un owner, initial state, authority, terminal state, prohibited events et d’un grader indépendant.

Exécutez le public signal, le bridge set et la production regression comme trois couches distinctes. La première facilite la comparaison avec l’écosystème de recherche, la deuxième vérifie le transfert de capacité et la troisième protège les invariants locaux. La promotion exige des résultats acceptables par risk slice, aucune critical failure définie et un rollback testé pour le bundle model, prompt, tools et policy. Un score moyen ne compense ni paiement non autorisé, ni fuite de secret, ni patch destructif.

L’evidence pack contient la decision question, le mapping benchmark-to-workflow, le manifest de chaque run, les raw outcomes, la grader evidence, la failure taxonomy, les résultats segmentés, le reviewer sign-off et les known limitations. Notez séparément ce qui n’a pas été testé : nouvelle locale, tâche plus longue, autre permission tier, production latency ou side effect externe. Ce n’est pas de la bureaucratie ; c’est la frontière de ce que les preuves permettent réellement de conclure.

Après une mise à jour du model, scaffold, environment ou dataset, le verdict précédent devient une historical evidence. Rejouez d’abord le frozen slice, puis les tâches held-out, et seulement ensuite un canary étroit. Si le candidate est inférieur à la baseline locale ou crée une critical failure, le rollback restaure un bundle compatible et arrête les nouveaux runs ; les side effects incomplets doivent être reconciled séparément. Un leaderboard public n’annule jamais ce release gate.