GitHub a lancé le benchmark ouvert ReviewBench pour évaluer les agents de revue de code, afin de s’attaquer à un problème fondamental des outils de revue assistés par l’intelligence artificielle : la difficulté de comparer les erreurs qu’ils détectent, celles qu’ils manquent et le volume de bruit qu’ils produisent. Le benchmark est disponible pour les chercheurs et les équipes qui développent des systèmes de revue de code ; il permet également d’intégrer un système personnalisé et de le comparer à d’autres systèmes.
Un benchmark fondé sur des demandes de fusion réelles
GitHub a conçu l’ensemble ReviewBench en s’appuyant sur l’analyse de la répartition de plus de 103,9 millions de demandes de fusion sur la plateforme. L’ensemble comprend 219 demandes de fusion provenant de 187 dépôts publics sous licence open source, couvrant 19 langages de programmation, avec une répartition des langages et des tailles de dépôts alignée sur le profil général de GitHub. Toutefois, la taille des changements a été pondérée en faveur des demandes de taille moyenne et importante pouvant être examinées, plutôt que de privilégier excessivement les petits changements dans un seul fichier.
Ce que GitHub appelle l’« ensemble de vérité » ne repose pas sur une seule source. Les résultats possibles ont été recueillis auprès de réviseurs humains, de changements ultérieurs effectués par les auteurs des demandes, d’outils d’analyse statique et de plusieurs modèles de langage avancés. Après suppression des résultats sémantiquement redondants, ceux-ci ont été évalués selon un critère unifié définissant qu’un résultat correct doit être exact, pertinent et non marginal. GitHub utilise le modèle Claude Sonnet 5 comme évaluateur linguistique et publie le rubric ainsi que les paramètres d’évaluation afin de favoriser l’auditabilité et la reproductibilité.
Des métriques qui ne pénalisent pas la découverte de nouveaux problèmes
ReviewBench distingue deux familles de métriques. Les métriques grounded precision, grounded recall et grounded F1 mesurent la capacité du système à détecter les problèmes déjà présents dans l’ensemble de vérité, offrant ainsi une comparaison directe entre les systèmes. Les métriques augmented precision, augmented recall et augmented F1 examinent également les résultats qui ne correspondent à aucun problème connu et accordent un crédit au système si l’évaluateur prouve qu’il s’agit d’un problème valide.
Cette distinction est importante, car un ensemble fixe d’erreurs ne peut pas nécessairement être exhaustif ; un nouvel agent peut découvrir un problème que les concepteurs du benchmark n’avaient pas détecté. GitHub utilise le grounded recall comme indicateur principal pour comparer les systèmes, tandis que les métriques augmentées fournissent un diagnostic supplémentaire pour chaque système.
Une évaluation réglable et auditable
Les résultats peuvent être ventilés selon la gravité et la catégorie du problème, comme la correction, la sécurité, la fiabilité, la maintenabilité et les tests. Le critère Fβ permet également de modifier le poids entre le rappel et la précision, afin que l’utilisateur privilégie une couverture plus large ou un nombre réduit de commentaires plus précis. Avant le lancement, des ingénieurs seniors qui n’avaient pas participé à la constitution des données ont réétiqueté tous les résultats, et le taux d’accord avec les jugements de ReviewBench a atteint 96,6 %. GitHub affirme qu’elle fige les versions des données, de l’évaluateur et de l’outil de mise en correspondance utilisés lors de chaque évaluation.
Que prouve-t-il en pratique ?
GitHub a utilisé ReviewBench pour évaluer les versions successives de Copilot Code Review et a déclaré que la tendance à l’amélioration ou à la détérioration observée dans les tests hors ligne correspondait aux expériences de production. Dans une expérience portant sur un système de revue combinant plusieurs exécutions de modèles différents, le benchmark a prédit une hausse de la précision, du rappel et du nombre de commentaires, ainsi qu’une baisse du coût de la revue. Le test A/B en production est allé dans le même sens : le taux de commentaires ayant entraîné une modification du code a augmenté de 8,0 %, le rappel de 13,6 % et le volume de commentaires de 61 %, tandis que le coût par revue a diminué de 8,0 % par rapport au groupe de contrôle. Le benchmark avait également prédit une hausse de 227 % des commentaires critiques, contre 262 % en production.
Lecture éditoriale de certi.news : la valeur la plus importante de ReviewBench ne réside pas dans le lancement d’un nouvel outil, mais dans la tentative de transformer l’évaluation des agents de revue de code en un processus comparable et auditable, tout en reconnaissant que « davantage de commentaires » ne signifie pas nécessairement une meilleure revue. La même source admet toutefois que les expériences de production restent la mesure finale de l’impact pour l’utilisateur, et que le fait qu’une partie de l’évaluation repose sur un évaluateur linguistique laisse ouverte la question des limites de la cohérence du jugement automatisé.
GitHub propose une version de recherche initiale du benchmark, avec les données, la méthodologie, les paramètres de l’évaluateur et un outil d’exécution autonome. Les agents peuvent être testés sur un ensemble de 25 demandes de fusion, puis l’évaluation complète peut être exécutée sur 219 demandes en trois tours avant de demander la publication du résultat dans le classement.