ReviewBench: otevřený benchmark pro AI kontrolu kódu je dostupný v research preview

GitHub představil ReviewBench, nový offline benchmark pro agenty pro kontrolu kódu. Vychází z reprezentativních pull requestů na GitHubu, referenčních nálezů z více zdrojů, kalibrovaného hodnocení a metrik provázaných s výsledky v produkci. Na jeho vzniku spolupracovaly týmy GitHubu a Microsoftu.

Kontrola kódu pomocí AI agentů se stává důležitou součástí vývoje. Pomáhá Vám procházet pull requesty, odhalovat problémy a rozhodovat, čemu věnovat pozornost před nasazením kódu.

Kvalita jednotlivých AI systémů se ale obtížně měří. Některé odhalí více problémů, jiné vytvářejí méně šumu. Některé lépe zachycují kritické chyby, další upozorňují i na drobná zlepšení. Přínos konkrétního nástroje proto závisí také na tom, co od kontroly kódu ve svém pracovním postupu očekáváte.

Smysluplné porovnání musí ukázat, co jednotlivé systémy najdou, co přehlédnou a jaké kompromisy volí. Dobrý benchmark má odrážet rozmanitost skutečných pull requestů, zahrnovat širokou škálu nálezů a umožňovat rozpad výsledků podle závažnosti, kategorie i preferovaného poměru přesnosti a úplnosti. Týmům, které tyto agenty vyvíjejí, by měl zároveň poskytovat spolehlivý offline signál, zda změny pravděpodobně zlepší fungování v produkci.

Dosavadní benchmarky často volí kompromis mezi kvalitou anotací, pokrytím a věrností reálné kontrole kódu. ReviewBench má tuto mezeru vyplnit důslednou a reprodukovatelnou metodikou. Jeho složení vychází z rozložení programovacích jazyků, velikostí repozitářů a velikostí více než 100 milionů skutečných pull requestů na GitHubu. Používá referenční sadu nálezů z více zdrojů a jednotná hodnoticí pravidla; výsledky navíc nezávisle ověřili seniorní vývojáři.

Podle GitHubu benchmark také zpřesnil odhad, jakým směrem se budou ubírat výsledky produkčních experimentů s Copilot code review (CCR). Naměřená offline zlepšení tak s větší jistotou odpovídají skutečnému přínosu pro uživatele.

Pět principů ReviewBench

1. Reprezentativní pull requesty místo demonstrační sady

GitHub analyzoval 103,9 milionu pull requestů, aby popsal skutečné rozložení úloh při kontrole kódu. ReviewBench obsahuje 219 pull requestů ze 187 veřejných repozitářů s open source licencí v 19 programovacích jazycích. Zastoupení jazyků a velikostí repozitářů přibližně odpovídá GitHubu jako celku. Kompletní datová sada benchmarku je veřejně dostupná.

U velikosti pull requestů provedli tvůrci záměrnou úpravu: zatímco jazyky a velikosti repozitářů přímo odrážejí rozložení na GitHubu, větší váhu dostaly středně velké a rozsáhlejší pull requesty vhodné pro kontrolu. Tím se omezuje nadměrné zastoupení drobných změn v jediném souboru a zůstává více podstatných změn napříč soubory, u nichž na kvalitě kontroly záleží nejvíce.

2. Referenční nálezy z více zdrojů s nezávislým posouzením

Žádný kontrolující – člověk ani model – nedokáže v pull requestu odhalit vše, co stojí za pozornost. Pro vytvoření širší a spolehlivější referenční sady, označované jako golden set, používá ReviewBench tři kroky:

• Sběr kandidátních nálezů z různých zdrojů. Zahrnuje připomínky skutečných lidských recenzentů, problémy odvozené z následných commitů autora, výstupy deterministických analytických nástrojů a několika špičkových velkých jazykových modelů z různých modelových rodin.
• Sémantické odstranění duplicit. Nálezy popisující stejný základní problém se slučují. Sada tak získává širší pokrytí, aniž by ji uměle nafukovala shoda více zdrojů nebo byla závislá na slabinách jediného zdroje.
• Ověření podle společných pravidel. Původ nálezu nerozhoduje o jeho správnosti. Za správně pozitivní nález se považuje pouze problém, který je skutečný, relevantní a netriviální. Jako hodnoticí LLM slouží Claude Sonnet 5, který na všechny odevzdané výsledky uplatňuje stejná pravidla. Kvůli transparentnosti a reprodukovatelnosti GitHub zveřejňuje pravidla i hodnoticí mechanismus, který je používá.

3. Metriky pro známé i nově objevené problémy

Většina benchmarků vykazuje přesnost a úplnost vůči pevné referenční sadě. ReviewBench nabízí šest metrik rozdělených do dvou skupin:

• Grounded precision, recall a F1 pracují pouze s existujícími anotacemi referenční sady. Poskytují přímé srovnání za stejných podmínek: kolik známých problémů agent našel a jaký podíl jeho nálezů odpovídal známému problému.
• Augmented precision, recall a F1 hodnotí také nálezy, které v referenční sadě nemají protějšek. Hodnoticí model nezávisle rozhodne, zda jde o správně, nebo falešně pozitivní nálezy. Systém tak může získat uznání i za skutečné problémy, které žádný ze zdrojů referenční sady neodhalil.

Toto rozlišení nabývá na významu s rostoucími schopnostmi agentů. Pevná referenční sada se nevyhnutelně stává neúplnou, když systémy nacházejí problémy, s nimiž její tvůrci nepočítali. Rozšířené metriky umožňují takové nálezy ocenit, místo aby za ně systém automaticky penalizovaly.

Protože se u augmented recall zvětšuje jmenovatel podle toho, co konkrétní agent objeví, používá ReviewBench jako hlavní metriku úplnosti pro srovnání mezi systémy grounded recall. Rozšířené metriky slouží jako doplňková diagnostika jednotlivých systémů.

4. Nastavitelné hodnocení podle priorit kontroly

Neexistuje jediná podoba kontroly kódu, která by vyhovovala všem. Někteří vývojáři chtějí řešit pouze kritické problémy, jiní oceňují i méně závažné nálezy, které nenarušují funkčnost. Někdo upřednostňuje širší pokrytí, jiný vysokou přesnost a minimum šumu. Další týmy potřebují specializovanou kontrolu zaměřenou například na zabezpečení nebo soukromí.

ReviewBench umožňuje členit výsledky podle závažnosti a kategorie. Přesnost a úplnost pak zachycují různé provozní preference. Ve skóre Fβ můžete upravit parametr β tak, aby větší váhu získala úplnost pro širší pokrytí, nebo přesnost pro menší množství šumu. Podle zvolených preferencí se přepočítává i pořadí v žebříčku, takže můžete snáze najít systém odpovídající Vašim prioritám.

5. Interní audit a reprodukovatelné hodnocení

Před vydáním benchmarku seniorní vývojáři, kteří se nepodíleli na sestavení datové sady, nezávisle a od začátku znovu označili každý referenční nález. Jejich rozhodnutí, zda jde o správně, nebo falešně pozitivní nález, se s hodnocením ReviewBench shodovala v 96,6 % případů.

GitHub verzováním sleduje datovou sadu, hodnoticí mechanismus i mechanismus párování nálezů použitý při každém vyhodnocení. Výsledky tak lze porovnávat při stejné konfiguraci benchmarku a po jeho změnách znovu ověřit. Zveřejněná je také metodika validace, měření shody a známá rizika pro platnost výsledků, aby bylo zřejmé, jak se kvalita benchmarku posuzuje a kde přetrvává nejistota.

Co je dostupné v research preview

Verze ReviewBench v režimu research preview je dostupná na webu ReviewBench. Můžete si prohlédnout celý benchmark, porovnat agenty pro kontrolu kódu nebo vyhodnotit a postupně vylepšovat vlastního agenta.

• Prozkoumání celé datové sady. Veřejně dostupné jsou pull requesty, nálezy, anotace i označení závažnosti a kategorií. Můžete tedy přesně zjistit, na čem se systémy hodnotí, a reprodukovat výsledky benchmarku.
• Porovnání systémů v žebříčku. Výsledky agentů vyhodnocených na celé datové sadě se zveřejňují ve společném žebříčku. K dispozici jsou pohledy na celkový výkon, závažnost, kategorie i různé preference poměru přesnosti a úplnosti.
• Vyhodnocení a postupné ladění vlastního agenta. Veřejně dostupné jsou kompletní data, metodika hodnocení, prompt pro hodnoticí LLM, konfigurace hodnoticího modelu i samoobslužný nástroj pro spouštění testů. Vlastního agenta tak můžete hodnotit, zkoumat jeho silné stránky a mezery a opakovaně jej zlepšovat při stejné konfiguraci benchmarku.

Jak ReviewBench pomáhá zlepšovat Copilot code review

GitHub používá ReviewBench k vyhodnocování jednotlivých iterací Copilot code review (CCR). Získává tím jednotný způsob měření pokroku, zachycování regresí a výběru slibných změn.

Jedním z největších přínosů je včasný offline signál, jak si změna produktu pravděpodobně povede v produkci. U experimentů vyhodnocených pomocí ReviewBench před A/B testováním podle GitHubu offline výsledky soustavně ukazovaly stejný směr jako pozdější produkční měření.

Konkrétním příkladem je nedávný experiment ve variantě lite-tier. GitHub zavedl kontrolu založenou na kombinaci více modelů: několik nezávislých běhů modelů se spojuje do jedné kontroly namísto spoléhání na jediný běh. ReviewBench předpověděl vyšší přesnost, úplnost i počet komentářů a současně nižší náklady na jednu kontrolu.

Pro porovnání offline a produkčních výsledků GitHub používá odpovídající online ukazatele:

• Addressed rate jako online protějšek přesnosti: podíl komentářů CCR, které podle posouzení LLM vedly vývojáře k odpovídající změně kódu. Model vychází z rozdílu verzí kódu, diskusního vlákna, reakcí, stavu vyřešení a kódu po kontrole.
• Ukazatel úplnosti: kolik dodatečné lidské kontroly je ještě potřeba.

Online A/B test potvrdil směr předpovědi ReviewBench. V porovnání s produkční kontrolní variantou:

• addressed rate, tedy ukazatel přesnosti, vzrostl o 8,0 %;
• úplnost vzrostla o 13,6 %;
• počet komentářů vzrostl o 61 %;
• náklady na jednu kontrolu klesly o 8,0 %.

Samotný počet komentářů ale nevypovídá o jejich kvalitě. Více kritických nálezů má zcela jiný význam než více drobných připomínek nízké závažnosti. Hodnocení podle závažnosti v ReviewBench zachytilo i tento rozdíl: předpovědělo nárůst počtu kritických komentářů o 227 %, zatímco v produkci činil nárůst 262 %. Současně správně ukázalo celkový posun k většímu počtu komentářů střední závažnosti a menšímu počtu drobných připomínek.

ReviewBench tak poskytuje rychlý a opakovatelný signál ještě před spuštěním produkčních experimentů. Rozhodujícím měřítkem dopadu na uživatele zůstávají online experimenty, benchmark však pomáhá s větší jistotou určit, které změny má smysl v produkci testovat.

Jak vyhodnotit vlastního agenta

1. Přihlaste se pomocí GitHubu na webu ReviewBench.
2. Zaregistrujte svého agenta. Dodejte kontejnerový obraz, konfiguraci a vlastní klíč k modelu. Hodnoticí mechanismus poskytuje GitHub.
3. Vyzkoušejte testovací sadu. Spusťte hodnocení nad sadou 25 pull requestů. K dispozici jsou podrobnosti pro každý pull request a test můžete při ladění konfigurace opakovat.
4. Spusťte závěrečné hodnocení. Až budete připraveni, spusťte celou sadu 219 pull requestů ve třech kolech. Výsledky posoudí stejný hodnoticí mechanismus jako u ostatních záznamů.
5. Zveřejněte výsledky v žebříčku. Skóre zůstane neveřejné, dokud odevzdané výsledky nezkontroluje a neschválí správce. V žebříčku se zveřejní pouze tehdy, pokud překoná dosavadní skóre daného agenta, nebo pokud jde o jeho první záznam.