ReviewBench: Ein offenes Benchmark für die Code-Überprüfung in KI

Die agentische Code-Review-Verfahren werden zu einem wichtigen Bestandteil des Entwicklungsprozesses. Sie ermöglicht es Ihnen, Pull Requests zu überprüfen, Probleme zu erkennen und zu entscheiden, welche Aspekte Beachtung verdienen, bevor das Code-Update veröffentlicht wird.

Aber die Qualität der bestehenden AI-Überprüfungen ist schwer zu messen. Man muss die Stärken einer Überprüferin oder eines Überprüfers kennen, bevor man weiß, ob sie hilfreich sein wird. Einige Überprüfer zeigen mehr Probleme auf, andere erzeugen weniger Störung, und wieder andere sind besser darin, kritische Probleme zu erkennen, während andere auch kleine Verbesserungen offenlegen. Man kann möglicherweise eine Code-Überprüfung benötigen, um verschiedene Aufgaben im Arbeitsablauf durchzuführen.

Das macht es wichtig, zu verstehen, wie die Revisoren tatsächlich vergleichen: Welche Systeme sie erkennen, was sie übersehen und welche Kompromisse sie eingehen. Ein guter Benchmark für Code-Review sollte die Vielfalt echter Pull-Requests widerspiegeln, eine breite Palette von Überprüfungsergebnissen festhalten und unterstützen, um nach Schweregrad, Kategorie und Präzision-Rücklauf-Einstellungen sinnvolle Analysen zu erstellen. Für Teams, die Code-Review-Agenten entwickeln, sollte das Benchmark auch ein Offline-Signal liefern, das zuverlässig überprüft, ob Änderungen die Nutzererfahrung in der Produktion verbessern könnten. Bestehende Benchmarks treffen oft Kompromisse zwischen Label-Qualität, Abdeckung und der Fähigkeit, den realen Code-Review-Prozessen gerecht zu werden, was eine Lücke für eine rigorose und reproduzierbare Bewertungsmethode hinterlässt, die diese Aspekte zusammenbringt.

Wir haben ReviewBench, ein neues Offline-Code-Review-Benchmark entwickelt, um dieses Problem zu lösen. Es ist heute für Sie verfügbar. Es folgt dem Sprachstand, der Größe der Repos und der Größenverteilung von Pull Requests, nachdem über 100 Millionen echte Pull Requests auf GitHub modelliert wurden. Es verwendet eine mehrquellenbasierte Gold-Set und eine konsistente Bewertungsmatrix und wurde von senioren Ingenieuren unabhängig validiert. Genauso wichtig ist, dass mit ReviewBench unsere Offline-Bewertung des Copilot-Code-Review (CCR) effektiver wurde, um die Richtung der Produktionsexperimente vorherzusagen, was uns mehr Vertrauen gibt, dass die gemessenen Verbesserungen echte Erfolge für die Benutzer sind.

In diesem Beitrag werden wir erklären, wie ReviewBench aufgebaut ist, wie es eine zuverlässige Ground Truth und Bewertung etabliert, sowie wie man sein eigenes Code-Review-System integriert und die Ergebnisse einreicht.

Was wir gebaut haben

Ein realistisches, umfassendes Benchmark für AI-Code-Review-Agenten

GitHub Pull Requests

Analysieren Sie die Verteilungen nach Sprache, Repository-Größe und Verformung.

Repräsentatives Benchmark-Corpus

219 öffentliche Pull Requests in 19 Sprachen, die an die weltweiten GitHub-Distributionen angepasst sind, während die inhaltlichen Überprüfungen erhalten bleiben.

Mehrquellen-Goldset

• Menschliche Überprüfer
• Frontier LLMs
• Statische Analyse

Geordnete Erkenntnisse

Jede Erkenntnis ist nach Schwere und Kategorie benannt, was es ermöglicht, personalisierte Slicks für den Benutzer zu erstellen.

Schwereheit

• Kritisch
• Medium
• Niedrig

Kategorie

• Richtigkeit
• Sicherheit
• Vertragsfähigkeit
• Verfügbarkeit
• Testen
• ......

Bewertungsmetriken

Vier Metriken messen sowohl bekannte als auch neu entdeckte Probleme.

• Gründliche Präzision
• Grundlegende Erinnerung
• Erweiterte Präzision
• Erweiterte Erinnerung

Objektive Bewertung

Messen die Verbesserung und vergleichen sie objektiv zwischen den Agenten. Unterstützen Sie die Benutzer dabei, den Revisor zu wählen, der am besten ihren Bedürfnissen entspricht.

Wie wir es vertrauenswürdig halten

Eine nachvollziehbare Kette von Richtlinien bis zur Validierung durch Experten und Produktprüfungen

Veröffentlichte Bewertungskriterien

Ein eindeutiger Standard für alle Ergebnisse.

Menschlich markierter Entwicklungsdatensatz

Senior-Ingenieure etablieren die Grundwahrheit.

Kalibrierter Maßstab

In Übereinstimmung mit menschlichem Urteil.

Standardisierte Etikettierung

Dasselbe Standard in allen Quellen.

Veröffentlichtes Abkommen

Expertenprüfung der Qualität des Benchmarks.

Abrufbar von Anfang bis Ende

96,6 % Übereinstimmung

Die Senior-Ingenieure haben vor der Veröffentlichung unabhängig die goldene True-Positive-Markierung vorgenommen.

Offline-Signale, die die Produktion vorhersagen

Die Benchmarkbewegung wird an Online-Experimenten geprüft.

• Verbesserungen treten meist online auf
• Regressionen treten auch im Internet auf

Wie ReviewBench funktioniert

Unsere Benchmark basiert auf fünf Prinzipien:

1. Repräsentative Pull Requests, nicht eine Demo-Sammlung

Wir haben 103,9 Millionen GitHub-Pull Requests analysiert, um die tatsächliche Verteilung der Code-Review-Arbeitslasten im realen Umfeld zu beschreiben. ReviewBench enthält 219 Pull Requests von 187 öffentlichen Open-Source-Repositories in 19 Sprachen, wobei die Verteilung der Sprachen und der Repositionsgrößen stark mit der Gesamtzahl bei GitHub übereinstimmt. Das vollständige Benchmark-Datenset ist öffentlich verfügbar.

Wir machen eine bewusste Anpassung an diese Verteilung: Während die Sprache und die Größe des Repositoriums direkt auf GitHub entsprechen, wird der Umfang der Pull-Requests eher auf die zu überprüfenden mittleren und äußeren Bereiche ausgerichtet. Dadurch wird die Überrepräsentation kleiner, einzelner Änderungen verringert, während mehr bedeutende, mehrere Dateien umfassende Pull-Requests erhalten bleiben, bei denen die Qualität der Überprüfung am wichtigsten ist.

Schnelle Korpus-Snapshot:

2. Erkennung von breiten Wahrheiten, unabhängig bewertet

Kein einziger Revisor, sei es Mensch oder Modell, kann alles identifizieren, was im Pull-Request wertvoll ist. Um eine breitere und zuverlässigere Goldliste für die Grundtreueergebnisse zu erstellen, folgen wir einem dreistufigen Prozess:

• Sammeln der Ergebnisse der Kandidaten aus verschiedenen Quellen. Wir sammeln Ergebnisse von echten menschlichen Überprüfern, Probleme, die aus den Nachverfolgungskommata des Autors abgeleitet werden, deterministischen Analysewerkzeugen und mehreren fortschrittlichen LLMs verschiedener Modellfamilien.
• Semantisch deduzieren die überlappenden Erkenntnisse. Wir verschmelzen Erkenntnisse, die denselben grundlegenden Problemen zugerechnet werden, um den Umfang zu erweitern, ohne dass die Übereinkunft unter den Produzenten dazu führt, das „Goldene Set“ künstlich zu vergrößern oder es auf die blinden Stellen einer einzigen Quelle anzulegen.
• Valideren die Ergebnisse unter einem gemeinsamen Kriterienkatalog. Die Quelle eines Ergebnisses bestimmt nicht, ob es richtig ist: Ein Ergebnis gilt als echter Positivtest nur dann, wenn es wahr, relevant und nicht trivial ist. Wir verwenden Claude Sonnet 5 als LLM-Bewertungssystem und anwenden ein konsistentes Bewertungskriterienkatalog für alle Einreichungen. Für Transparenz und Reproduzierbarkeit veröffentlichen wir sowohl den Bewertungskriterienkatalog als auch das System, mit dem er angewandt wird.

3. Metriken, die sowohl bekannte als auch neu entdeckte Probleme messen

Die meisten Benchmarks berichten über Präzision und Recall gegenüber einem festen Gold-Set. ReviewBench berichtet über sechs Metriken in zwei Familien:

• Grundierte Präzision, Recall und F1-Score verwenden nur die bereits vorhandenen Gold-Label. Sie ermöglichen eine strenge, apples-to-apples-Bewertung: von den Problemen, die wir bereits kennen, wie viele fand das Agent, und welcher Anteil seiner Erkenntnisse entspricht einem bekannten Problem?
• Erhöhte Präzision, Recall und F1-Score bewerten auch Ergebnisse, die nichts im goldenen Set enthalten. Der Judge entscheidet unabhängig darüber, ob diese nicht übereinstimmenden Ergebnisse echte oder falsche Positives sind, sodass der Revisor für gültige Probleme belohnt werden kann, die kein Produzent im goldenen Set aufgedeckt hat.

Diese Unterscheidung wird wichtiger, wenn die Überprüfungsagenten bessere Fähigkeiten entwickeln. Ein festes, goldenes Set wird unweigerlich unvollständig, da Systeme Probleme entdecken, die ihre Schöpfer nicht vorhergesehen hatten. Erweiterte Metriken ermöglichen es ReviewBench, dieses Verhalten zu erkennen, anstatt es automatisch zu bestrafen. Da die erweiterte Erinnerung den Nenner auf der Grundlage dessen erweitert, was jeder Agent entdeckt, verwenden wir die „grounded recall“ als Hauptvergleich zwischen den Systemen und die erweiterten Metriken als zusätzliche systembezogene Diagnose.

4. Konfigurierbare Bewertung für unterschiedliche Überprüfungsvorlieben

Es gibt keine einzige universell optimale Bewertungserfahrung. Einige Entwickler möchten sich nur auf kritische Probleme konzentrieren, während andere auch weniger schwere, nicht wirksame Erkenntnisse schätzen. Einige bevorzugen eine umfassendere Abdeckung, während andere Präzision und minimalen Lärm priorisieren. Andere haben spezielle Anforderungen, wie Bewertungen, die auf Sicherheit oder Privatsphäre ausgerichtet sind.

ReviewBench ermöglicht es, die Ergebnisse nach Schwere und Kategorie zu filtern, während Präzision und Recall unterschiedliche Betriebsvorlieben abbilden. Die Benutzer können auch den Wert β im Fβ-Score anpassen, um mehr Gewicht auf Recall für eine breitere Abdeckung oder auf Präzision für weniger Störung zu legen. Da sich diese Vorlieben ändern, wird die Rangliste entsprechend neu bewertet, wodurch die Benutzer die Systeme identifizieren können, die am besten ihren Bewertungsprioritäten entsprechen.

5. Intern ausgewertet und reproduzierbar bewertet

Vor der Veröffentlichung baten wir die leitenden Ingenieure, die nicht an der Erstellung des Benchmark-Datasets beteiligt waren,, alle Grundtruth-Erkenntnisse selbstständig neu zu labeln. Ihre richtig/fehlerhaft-positive Beurteilungen stimmten 96,6% der Zeit mit ReviewBench überein. Wir versionieren das Benchmark-Datasets, die Bewertung und der Matcher, die in jeder Evaluierung verwendet werden, sodass die Ergebnisse unter derselben Benchmark-Konfiguration verglichen werden können und bei Änderungen des Benchmarks erneut validiert werden. Wir veröffentlichen auch die Validierungsmethode, die Übereinstimmungsmessungen sowie bekannte Bedrohungen für die Gültigkeit, damit Leser sehen können, wie die Qualität der Benchmark erfasst wird und wo Unsicherheit besteht.

Erkunden ReviewBench

Die Forschungsvorlageversion von ReviewBench ist jetzt über die Website von ReviewBench verfügbar, wo Sie den vollständigen Benchmark erkunden, Code-Review-Agenten vergleichen und Ihren eigenen Agent einsetzen können, um zu bewerten und weiterzuentwickeln.

Mit ReviewBench können Sie:

• Erkunden Sie das vollständige Benchmark-Datenset. Das komplette ReviewBench-Datenset ist öffentlich verfügbar, einschließlich der Pull-Requests, Erkenntnisse, Labels, Schweregrad und Kategorie-Anmerkungen. Dadurch können Sie genau sehen, auf welche Systeme es getestet wird, und die Benchmark-Ergebnisse nachbilden.
• Vergleichen Sie Systeme auf der Rangliste. Die Ergebnisse der bewerteten Code-Review-Agenten unter Verwendung des vollständigen Benchmark-Datens werden auf einer gemeinsamen Rangliste veröffentlicht, mit Einblicken in die Gesamtleistung, Schweregrad, Kategorie und unterschiedliche Präzision-Recall-Einstellungen.
• Bringen Sie Ihren eigenen Agent mit und gehen Sie auf die Bergstrecke. Das volle Benchmark-Datenset, die Bewertungsmethode, der LLM-Judge-Prompt, die Konfiguration des Judge-Modells und der selbstverwaltende Runner sind öffentlich verfügbar, sodass Sie Ihren eigenen Code-Review-Agent testen, seine Stärken und Schwächen untersuchen und gegen dieselbe Benchmark-Konfiguration iterieren können.

Wie wir ReviewBench verwendet haben

Wir haben ReviewBench verwendet, um Copilot Code Review (CCR) in verschiedenen Iterationen zu bewerten. Dadurch haben wir eine konsistente Methode erhalten, um Fortschritte zu messen, Rückfälle zu erkennen und vielversprechende Änderungen zu priorisieren. Im Laufe der Zeit hat dies dazu beigetragen, das Produkt zu verbessern. Einer der wertvollsten Vorteile von ReviewBench ist, dass es eine frühe Offline-Signale liefert, wie sich eine Änderung im Produkt in der Produktion verhalten wird. In den mit ReviewBench evaluierten Experimenten vor dem A/B-Testing zeigten die Offline-Änderungen immer dieselbe Richtung wie das, was später in der Produktion erwartet wird.

Ein kürzlich durchgeführtes Lite-Tier-Experiment gibt ein konkretes Beispiel für dieses breitere Muster. Wir haben eine multi-model-basierte Überprüfung eingeführt, die mehrere unabhängige Modellläufe in eine einzige Überprüfung zusammenfasst, anstatt auf einen einzigen Lauf zu setzen. ReviewBench erzielte höhere Präzision, Recall und mehr Kommentare sowie einen niedrigeren Kostenaufwand pro Überprüfung.

Um die Offline- und Produktionsergebnisse zu vergleichen, verwenden wir die entsprechenden Online-Signale. Die adressierte Rate, unsere Online-Abbildung der Präzision, ist das Prozentumfang der CCR-Kommentare, bei denen ein LLM dazu führt, dass ein Entwickler einen entsprechenden Code-Update vornehmen muss, basierend auf dem Diff, dem Thread, den Reaktionen, dem Lösungszustand und dem nach Überprüfung veröffentlichten Code. Für die Rückkehr messen wir, wie viel zusätzliche menschliche Überprüfung noch erforderlich ist.

Der Online A/B-Test verlief in derselben Richtung wie von ReviewBench vorhergesagt: Die Adressrate (Präzision) stieg um 8,0 %, die Erinnerungsrate stieg um 13,6 %, und das Volumen der Kommentare stieg um 61 %. Gleichzeitig sank der Kosten pro Bewertung um 8,0 %, alles im Vergleich zum Produktionsmanagement.

Der Anzahl der Kommentare allein beschreibt jedoch nicht die Qualität der Kommentare. Wichtigere Erkenntnisse bedeuten etwas ganz anderes als geringfügige Probleme. Die Bewertung des Schweregrads durch ReviewBench hat dies ebenfalls erfasst: Es wurde eine Steigerung von 227% bei kritischen Kommentaren prognostiziert, im Vergleich zu 262% online, sowie eine allgemeine Verlagerung hin zu moderateren Kommentaren und weniger Problemen.

Das gibt uns ein schnelles und wiederholbares Signal vor dem Durchführen von Produktionsexperimenten. Online-Experimente bleiben die ultimative Messgröße für den Einfluss auf den Benutzer, aber ReviewBench gibt uns mehr Vertrauen darin, welche Änderungen es wert sind, dort durchgeführt zu werden.

Wie man seinen eigenen Lauf einreicht

1. Angemeldet sich mit GitHub auf der ReviewBench-Website.
2. Registrieren Sie Ihren Agent. Geben Sie eine Container-Image, Ihre Konfiguration und Ihr eigenes Modell-Schlüssel an. Wir stellen den Judge bereit.
3. Probieren Sie es im Testdatensatz aus. Führen Sie die Ausführung gegen einen 25-PR-Testdatensatz mit detaillierten Informationen pro PR durch und wiederholen Sie das, während Sie Ihre Konfiguration anpassen.
4. Führen Sie eine letzte Prüfung durch. Wenn Sie bereit sind, führen Sie die gesamte Gruppe von 219 Pull Requests (drei Runden) durch – die von derselben Jury bewertet werden wie alle anderen Einsendungen.
5. Veröffentlichen Sie auf der Rangliste. Ihre Punktzahlen bleiben privat, bis ein Betreuer die Einreichung überprüft und genehmigt. Die Punktzahlen werden nur auf die Rangliste gesetzt, wenn sie den aktuellen Rang des Agents übertreffen oder wenn es sich um die erste Eintragung des Agents in der Rangliste handelt.

Wir laden Sie ein, ReviewBench zu erkunden, Ihr eigenes System zu bewerten, unsere Annahmen herauszufordern und uns dabei zu helfen, das Benchmark zu verbessern. Wir freuen uns darauf, mit Forschern und Praktikern zusammenzuarbeiten, um die Bewertung von Code-Reviews offener, zuverlässiger und nützlicher zu machen – und letztendlich dazu beizutragen, die AI-Code-Review-Kultur voranzubringen.

Danksagungen

ReviewBench war eine Teamleistung von GitHub und Microsoft. Wir sind den Forschern und Ingenieuren dankbar, die es entwickelt haben: jenen, die die Methodik entworfen, die Pull Requests geprüft, das Goldset sowie den Bewertungsprozess erstellt haben, und dafür gesorgt haben, dass das Benchmark für jeden nutzbar ist.

Die Artikelseite ReviewBench: Ein offenes Benchmark für AI-Code-Review erschien zunächst in The GitHub Blog.