ReviewBench mierzy recenzentów AI — 219 pull requestów zamiast dema

Ogłoszenie GitHuba z 5 października 2026 r. przedstawia badawczą wersję ReviewBench: otwarty benchmark agentów recenzujących kod oparty na 219 publicznych pull requestach ze 187 repozytoriów i 19 języków programowania. Zamiast pojedynczego przykładu agenci dostają wspólny korpus zmian, a ich uwagi są zestawiane z ocenionymi ustaleniami.

Ranking pozwala porównać, ile znanych problemów recenzent wykrywa i ile jego komentarzy okazuje się trafnych. Przy wyborze agenta dla konkretnego zespołu znaczenie mają też podobieństwo testowanych zmian do własnego kodu, rodzaj przeoczonych usterek i koszt sprawdzania fałszywych alarmów. Oceniany jest cały sposób działania recenzenta, nie sam model.

Jak dobrano zmiany do testu

Korpus obejmuje publiczne repozytoria z otwartą licencją. Przy doborze zmian uwzględniono rozkład języków i wielkości repozytoriów na GitHubie, a większą wagę nadano pull requestom, które dają materiał do rozbudowanej recenzji. Drobne poprawki w jednym pliku nie dominują więc nad zmianami wymagającymi zrozumienia zależności między plikami.

Ta decyzja pozwala sprawdzić, czy agent wychodzi poza pobieżny komentarz do kilku zmienionych linii. Zmienia zarazem znaczenie słowa „reprezentatywny”: podobieństwo do szerokiego przekroju GitHuba dotyczy języków i wielkości repozytoriów, podczas gdy rozmiar zmian został celowo przesunięty w stronę obszerniejszych recenzji. Zespół utrzymujący głównie małe poprawki może otrzymać inny bilans trafień i szumu.

Same języki też niewiele mówią o trudności zadań. Recenzja poprawki testów, zmiany publicznego API i modyfikacji mechanizmu autoryzacji wymaga innego kontekstu, nawet gdy kod jest napisany w tym samym języku. Dlatego podział wyników według kategorii usterek jest dla wyboru narzędzia równie ważny jak wynik zbiorczy.

Skąd wiadomo, które uwagi są trafne

Punktem odniesienia jest zestaw ustaleń przypisanych do zmian. Kandydaci pochodzą z recenzji ludzi, późniejszych poprawek autorów, narzędzi analizy statycznej i modeli AI. Uwagi opisujące ten sam problem są łączone, aby kilka podobnych komentarzy nie zwiększało sztucznie liczby usterek.

Każdy kandydat przechodzi ocenę według wspólnej reguły: problem musi być rzeczywisty, związany ze zmianą i istotny dla recenzji. Do klasyfikowania ustaleń używany jest również sędzia oparty na modelu językowym. Różnorodne źródła pomagają znaleźć więcej potencjalnych problemów, lecz nie gwarantują kompletności listy; to istotne zwłaszcza wtedy, gdy oceniany agent wykryje błąd pominięty wcześniej przez wszystkich.

Według omówienia audytu przez LATENT niezależne oceny starszych inżynierów były zgodne z etykietami trafnych i fałszywych ustaleń w 96,6% przypadków, ale zgodność dokładnej oceny wagi wyniosła 62,9%. Pierwsza liczba opisuje jakość osądu o przydatności uwagi, a nie odsetek błędów wykrywanych przez agenta. Druga pokazuje, że ranking ograniczony do usterek o określonej wadze zależy także od mniej jednoznacznej klasyfikacji.

Dlaczego precyzję trzeba czytać razem z recall

Precyzja mówi, jaka część ocenianych uwag agenta jest trafna; recall wskazuje, jaką część znanych trafnych ustaleń agent odnalazł. Oszczędny recenzent może publikować niemal wyłącznie poprawne komentarze, ale przeoczyć wiele problemów. Bardziej dociekliwy może wykryć więcej usterek i zarazem obciążyć programistów większą liczbą alarmów do odrzucenia.

ReviewBench rozdziela metryki oparte na ustaleniach już zapisanych w zbiorze referencyjnym od metryk rozszerzonych o nowe uwagi agenta. W wersji opartej na znanych etykietach komentarz bez dopasowania nie wchodzi do mianownika precyzji. W wersji rozszerzonej taki komentarz jest oceniany osobno i może okazać się trafny albo fałszywy. Dlatego wysoka precyzja względem etykiet nie oznacza automatycznie, że podobny odsetek wszystkich komentarzy będzie użyteczny.

Rozszerzony recall ma jeszcze inną własność: odkryte przez agenta poprawne uwagi powiększają zarówno liczbę trafień, jak i pulę problemów, względem której wynik jest liczony. Ta pula może się różnić między agentami. Do bezpośredniego porównania pokrycia służy więc recall względem znanego zbioru, a wariant rozszerzony pomaga ocenić nowe odkrycia konkretnego systemu.

F1 łączy precyzję i recall, nadając im równą wagę. Ranking może też stosować Fβ i zmieniać znaczenie obu miar zgodnie z preferencją użytkownika. Wynik zbiorczy nie pokaże sam, czy stracone punkty oznaczają przeoczenie ważnej regresji, czy kilka nieprzydatnych komentarzy o drobnej sprawie.

Co ranking mówi o wyborze agenta

Wyniki można rozbić według wagi i kategorii ustaleń, więc zespół zainteresowany bezpieczeństwem może patrzeć na inny wycinek niż zespół szukający regresji funkcjonalnych. Taki podział ma sens tylko razem z liczbą zadań w danym wycinku: wąska kategoria daje mniej podstaw do mocnego wniosku niż cały korpus. Znaczenie ma również niepewność etykiet wagi.

Porównanie powinno obejmować zgodność języków i rozmiaru zmian, rodzaje problemów oraz koszt fałszywych alarmów. Istotna jest liczba powtórzeń, bo kolejne uruchomienia tego samego agenta mogą dać różne komentarze. Bezpośrednim sprawdzianem przy decyzji o wdrożeniu będzie równoległa recenzja tych samych własnych pull requestów przez kandydatów, z oceną uwag przez ludzi według jednakowych zasad.

Publiczny korpus daje wspólne warunki porównania, lecz kod prywatnego produktu ma lokalne konwencje, zależności i historię decyzji projektowych. Agent dobrze wypadający w szerokim teście może słabiej rozpoznawać reguły istniejące tylko w jednym repozytorium. Ta różnica wpływa zarówno na przeoczenia, jak i na komentarze, które brzmią rozsądnie bez znajomości kontekstu, ale dla zespołu są zbędne.

ReviewBench LangChain mierzy coś innego

Wcześniejszy ReviewBench zespołu LangChain, opisany 31 lipca 2026 r., obejmuje 59 zadań i 64 ustalenia bazowe wywiedzione z recenzji repozytorium LangSmith. Agent otrzymuje zamrożony kontekst zmiany, a ukryty weryfikator ocenia pokrycie ustaleń oraz precyzję przesłanych komentarzy. Trafna uwaga spoza listy bazowej poprawia tam precyzję, lecz nie zwiększa pokrycia.

Podobna nazwa i podobne słownictwo metryk nie oznaczają tej samej skali. Inne są pochodzenie zadań, sposób ustalania odniesienia i warunki oceny, więc wyniku jednego systemu z testu LangChain nie można zestawić liczbowo z miejscem w rankingu GitHuba. Dla zespołu rozstrzygające będzie to, czy wybrana konfiguracja utrzyma rozsądny bilans wykrytych problemów i zbędnych komentarzy na jego własnych zmianach.