ReviewBench : Un benchmark ouvert pour la revue du code d’IA

La revue de code agentique devient une composante essentielle du processus de développement. Elle vous permet d’inspecter les pull requests, de détecter les problèmes et de décider quelles actions nécessitent une attention avant que le code ne soit livré.

Mais la qualité des réviseurs d’IA existants est difficile à mesurer, et il faut connaître les points forts d’un réviseur avant de savoir s’il vous aidera. Certains réviseurs révèlent plus de problèmes, d’autres produisent moins de bruit, et certains sont plus efficaces pour repérer les problèmes critiques, tandis que d’autres présentent aussi de petites améliorations. Vous pourriez avoir besoin de la révision de code pour effectuer différentes tâches dans votre flux de travail.

Cela rend important de comprendre comment les réviseurs comparent réellement : quels systèmes différents ils repèrent, ce qu’ils manquent, et les compromis qu’ils font. Un bon critère de revue de code devrait refléter la diversité des demandes de pull requests réelles, capturer un large éventail de constatations de revue, et permettre des analyses significatives selon la gravité, la catégorie et les préférences de précision-rapide. Pour les équipes qui développent des agents de revue de code, le benchmark devrait également fournir un signal hors ligne permettant de déterminer avec précision si les modifications améliorent l’expérience en production. Les benchmarks existants font souvent des compromis entre la qualité des étiquettes, la couverture et la capacité à représenter correctement les revues de code dans le monde réel, ce qui laisse un vide pour une méthodologie d’évaluation rigoureuse et reproductible qui puisse intégrer ces éléments.

Nous avons développé ReviewBench, un nouveau benchmark de revue de code hors ligne, afin de combler cette lacune. Il est désormais disponible pour votre utilisation. Il suit le langage, la taille du repo et la distribution des tailles des pull requests, en s’inspirant de plus de 100 millions de pull requests réels sur GitHub. Il utilise un ensemble de données multi-source et une évaluation cohérente, et a été validé indépendamment par des ingénieurs senior. De manière tout aussi importante, avec l’aide de ReviewBench, notre évaluation hors ligne du code review de Copilot (CCR) est devenue plus efficace pour anticiper la direction des expériences de production, nous permettant ainsi de croire plus en ligne que les améliorations mesurées reflètent des gains significatifs pour les utilisateurs.

Dans cette publication, nous vous montrerons comment ReviewBench est construit, comment il établit une vérité de référence fiable et des scores, ainsi que comment intégrer votre propre système de revue de code et soumettre les résultats.

Ce que nous avons construit

Un benchmark réaliste et complet pour les agents de revue de code IA

Demandes de pull sur GitHub

Analyser les distributions par langue, taille du dépôt et forme de modification.

Corpus de référence représentatif

219 pull requests publiés dans 19 langues, alignés sur les distributions de GitHub tout en conservant les cas de revue substantielle.

Set doré à sources multiples

• Revues humaines
• Frontier LLMs
• Analyse statique

Résultats structurés

Chaque constat est étiqueté selon sa gravité et sa catégorie, permettant des sections personnalisées pour l’utilisateur.

Severité

• Critique
• Moyenne
• Basse

Catégorie

• Correctitude
• Sécurité
• Fiabilité
• Maintenabilité
• Test
• ......

Métriques d'évaluation

Quatre indicateurs mesurent à la fois les problèmes connus et ceux nouvellement découverts.

• Précision fondée
• Rappel fondé
• Précision augmentée
• Mémoire augmentée

Évaluation objective

Mesurez l’amélioration et comparez les résultats entre les agents de manière objective. Aidez les utilisateurs à choisir le réviseur qui correspond le mieux à leurs besoins.

Comment nous garantissons sa fiabilité

Une chaîne auditable allant de la rubrique à la validation par un expert et aux vérifications de production

Critère publié

Un standard explicite pour toutes les découvertes.

Set de développement marqué par l'humain

Les ingénieurs seniors établissent la vérité de base.

Casseur calibré

Aligné avec le jugement humain.

Marquage uniforme

Même norme dans toutes les sources.

Accord publié

Audit expert de la qualité du benchmark.

Fin auditable du début à la fin

96,6 % d’accord

Les ingénieurs senior ont étiqueté indépendamment les véritables positifs dorés avant la sortie.

Signaux hors ligne qui préparent la production

Le mouvement de benchmark est vérifié via des expériences en ligne.

• Les améliorations apparaissent généralement en ligne
• Les régressions apparaissent aussi en ligne

Comment Work ReviewBench fonctionne-t-il

Notre critère de mesure repose sur cinq principes :

1. Des demandes de pull représentatives, pas un ensemble de démonstration

Nous avons analysé 103,9 millions de demandes de pull sur GitHub afin de caractériser la distribution des charges de revue de code dans le monde réel. ReviewBench contient 219 demandes de pull provenant de 187 répositories open source publics et licenciés, en 19 langues différentes ; ses distributions de langue et de taille de répository correspondent étroitement à celle de GitHub dans son ensemble. Le jeu de données d’évaluation complète est disponible publiquement.

Nous effectuons un ajustement délibéré dans cette distribution : tandis que le langage et la taille du répertoire reflètent directement GitHub, la taille des demandes de pull sont pondérées en faveur des demandes de revue à mi-hauteur et à la fin. Cela réduit l’exposition excessive de petites modifications en un seul fichier, tout en préservant les demandes de pull plus importantes impliquant plusieurs fichiers, où la qualité de la revue est la plus importante.

Aperçu rapide du corpus :

2. Découverte de la vérité large, jugée indépendamment

Aucun réviseur, qu’il soit humain ou modèle, ne peut identifier tout ce qui vaut la peine d’être trouvé dans une pull request. Pour établir un ensemble de référence plus large et plus fiable, nous suivons un processus en trois étapes :

• Rassemblez les résultats des candidats provenant de diverses sources. Nous collectons ces résultats auprès de réviseurs humains réels, d’informations déduites des commits de suivi de l’auteur, d’outils d’analyse déterministe et de multiples LLM de pointe appartenant à différentes familles de modèles.
• Dédupliquer les résultats qui se chevauchent sur le plan sémantique. Nous fusionnons les résultats qui identifient la même problématique sous-jacente, afin d’élargir la couverture sans permettre aux producteurs de s’accorder pour augmenter artificiellement le groupe de données valides ou en faisant dépendre ce groupe des points faibles d’une seule source.
• Vérifier les résultats selon un critère partagé. La source d’un résultat ne détermine pas sa justesse : un résultat est considéré comme un véritable positif uniquement s’il est vrai, pertinent et non trivial. Nous utilisons Claude Sonnet 5 comme outil de notation pour les LLM, en appliquant un critère de notation cohérent à tous les sujets. Pour garantir la transparence et la reproductibilité, nous publions à la fois le critère de notation et l’outil utilisé par le juge.

3. Indicateurs qui mesurent à la fois les problèmes connus et ceux nouvellement découverts

La plupart des benchmarks indiquent la précision et le taux de reconnaissance par rapport à un ensemble doré fixe. ReviewBench indique six métriques en deux familles :

• La précision fondée, le rappel et le score F1 utilisent uniquement les étiquettes dorées existantes. Elles permettent une comparaison stricte, sur un pied d’égalité : parmi les problèmes que nous connaissons déjà, combien a trouvé l’agent, et quelle part de ses résultats correspond à un problème connu ?
• La précision augmentée, le taux de reconnaissance et le score F1 évaluent également les résultats qui ne correspondent à rien dans l’ensemble doré. Le juge détermine indépendamment si ces résultats non correspondants sont des faux positifs ou des vrais positifs, permettant ainsi au réviseur de recevoir crédit pour les problèmes valides que aucun producteur de l’ensemble doré n’a mentionné.

Cette distinction devient encore plus importante à mesure que les agents de revue deviennent plus compétents. Un ensemble fixe et complet ne reste pas inéluctablement complet, car les systèmes découvrent des problèmes que leurs créateurs n’avaient pas anticipés. Les métriques augmentées permettent à ReviewBench de reconnaître ce comportement plutôt que de le punir automatiquement. Comme l’apprentissage augmenté élargit le dénominateur en fonction de ce que chaque agent découvre, nous utilisons le rappel fondé comme comparaison transsystémique principale et les métriques augmentées comme diagnostic supplémentaire par système.

4. Évaluation configurable pour différentes préférences de revue

Il n’existe pas d’expérience de revue universellement optimale. Certains développeurs souhaitent se concentrer uniquement sur les problèmes critiques, tandis que d’autres apprécient également les constatations de moindre gravité. Certains préfèrent une couverture plus large, tandis que d’autres privilégient la précision et le minimum de bruit. D’autres encore ont des besoins spécifiques, comme une revue axée sur la sécurité ou la confidentialité.

ReviewBench permet de diviser les résultats en fonction de la gravité et du catégorie, tandis que la précision et le rappel capturent différentes préférences d’exploitation. Les utilisateurs peuvent également ajuster β dans le score Fβ pour accorder plus de poids au rappel afin d’obtenir une couverture plus large, ou à la précision pour réduire le bruit. À mesure que ces préférences changent, le classement est réajusté en conséquence, aidant les utilisateurs à identifier les systèmes qui correspondent le mieux à leurs priorités de revue.

5. Audité interne et évalué de manière reproductible

Avant la publication, nous avons demandé aux ingénieurs senior qui n’avaient pas participé à la création du jeu de données de benchmark de redéposer indépendamment chaque résultat de vérité de zéro. Leurs jugements de vrai/faux positifs coïncèrent avec 96,6 % des fois avec ReviewBench. Nous versionnons le jeu de données de benchmark, les juges et les comparateurs utilisés dans toutes les évaluations, de manière à ce que les résultats puissent être comparés sous la même configuration de benchmark et révalidés lorsque le benchmark change. Nous publions également la méthodologie de validation, les mesures d’accord et les menaces connues pour la validité, afin que les lecteurs puissent voir comment la qualité du benchmark est évaluée et où subsiste l’incertitude.

Explorer ReviewBench

La version préliminaire de la recherche de ReviewBench est désormais disponible via le site web de ReviewBench, où vous pouvez explorer l’ensemble du benchmark, comparer les agents de revue de code, et intégrer votre propre agent pour évaluer et itérer.

Avec ReviewBench, vous pouvez :

• Explorez l’ensemble du jeu de données de benchmark. Le jeu de données ReviewBench complet est disponible publiquement, incluant les pull requests, les résultats, les étiquettes, les niveaux de sévérité et les annotations catégorielles. Cela vous permet d’examiner précisément sur quels systèmes sont évalués les tests et de reproduire les résultats du benchmark.
• Comparaisez les systèmes sur le leaderboard. Les résultats obtenus grâce aux agents de revue de code évalués, en utilisant toutes les données du benchmark, sont publiés sur un leaderboard commun, avec des visualisations concernant les performances globales, la gravité, la catégorie et différentes préférences de précision-rapport.
• Apportez votre propre agent et participez aux épreuves de montagne. Le ensemble complet de données du benchmark, la méthodologie d’évaluation, le prompt du juge LLM, la configuration du modèle de juge et le runner auto-service sont disponibles publiquement, afin que vous puissiez évaluer votre propre agent de revue de code, examiner ses points forts et ses lacunes, et itérer en fonction de la même configuration de benchmark.

Comment nous avons utilisé ReviewBench

Nous avons utilisé ReviewBench pour évaluer la revue de code Copilot (CCR) au cours de plusieurs itérations, ce qui nous permet d’évaluer de manière cohérente les progrès, de détecter les regressions et de prioriser les modifications prometteuses. Avec le temps, cela nous a aidés à améliorer le produit. L’un des avantages les plus importants de ReviewBench est qu’il fournit un signal précoce hors ligne indiquant comment une modification du produit sera performée en production. Dans les expériences évaluées avec ReviewBench avant les tests A/B, les modifications hors ligne ont systématiquement suivi la même direction que celle observée plus tard en production.

Une expérience récente de niveau lite fournit un exemple concret de ce modèle plus large. Nous avons introduit une revue à ensemble de plusieurs modèles, qui combine plusieurs exécutions indépendantes en une seule revue, plutôt que de compter sur une seule exécution. ReviewBench a prévu une précision, un taux de rappel et un volume de commentaires plus élevés, ainsi qu’un coût plus faible par revue.

Pour comparer les résultats hors ligne et en production, nous utilisons les signaux en ligne correspondants. Le taux de traitement, notre équivalent en ligne par rapport à la précision, est le pourcentage de commentaires CCR que un LLM détermine comme ayant poussé un développeur à effectuer une modification de code correspondante, basée sur le diff, le thread, les réactions, l’état de résolution et le code après revue. Pour la recall, nous mesurons combien de revue humaine supplémentaire est encore nécessaire.

Le test A/B en ligne s’est déroulé dans la même direction que celle prédite par ReviewBench : le taux de traitement (précision) a augmenté de 8,0 %, le taux de rappel a augmenté de 13,6 %, et le volume des commentaires a augmenté de 61 %. Par ailleurs, le coût par revue a diminué de 8,0 %, tous en comparaison avec le contrôle de production.

Cependant, le volume seul ne reflète pas la qualité des commentaires. Les constatations plus critiques signifient quelque chose de très différent de les remarques peu importantes. L’évaluation du niveau de gravité par ReviewBench a également montré cela : elle a prédit une augmentation de 227 % des commentaires critiques, contre 262 % en ligne, ainsi qu’une tendance plus générale vers des commentaires plus modérés et moins de remarques.

Cela nous fournit un signal rapide et reproductible avant de réaliser des expériences en production. Les expériences en ligne restent la mesure ultime de l’impact sur les utilisateurs, mais ReviewBench nous donne plus de confiance quant aux changements qui valent la peine d’être mis en œuvre.

Comment soumettre votre propre run

1. Connectez-vous avec GitHub sur le site ReviewBench.
2. Enregistrez votre agent. Fournissez une image de conteneur, votre configuration et votre clé de modèle personnelle. Nous fournissons le juge.
3. Essaie-le sur l’ensemble de données d’essai. Exécutez-le contre un ensemble de données 25-PR, avec des détails par PR, et répètez en ajustant votre configuration.
4. Faites une dernière exécution. Lorsque vous êtes prêt, exécutez l’ensemble de 219 pull requests (trois tours), évalués par le même juge que tous les autres candidats.
5. Publier sur le classement. Vos scores restent privés jusqu’à ce qu’un maintaineur les examine et les approuve. Les scores ne sont publiés sur le classement que si ils dépassent le score actuel du agent sur le classement, ou si c’est la première entrée de l’agent dans le classement.

Nous vous invitons à explorer ReviewBench, évaluer votre propre système, remettre en question nos hypothèses et nous aider à améliorer le benchmark. Nous sommes enthousiastes de collaborer avec des chercheurs et des professionnels afin que l’évaluation des revues de code devienne plus ouverte, fiable et utile — et finalement contribuer au progrès des revues de code d’IA.

Remerciements

ReviewBench était un travail d’équipe entre GitHub et Microsoft. Nous sommes reconnaissants envers les chercheurs et les ingénieurs qui l’ont créé : ceux qui ont conçu la méthodologie, sélectionné les pull requests, construit le ensemble de benchmarks et le pipeline d’évaluation, et ont fait en sorte que le benchmark puisse être exécuté par n’importe qui.

La publication ReviewBench : un benchmark ouvert pour la révision du code en IA a été publiée en premier sur Le Blog GitHub.