Michael JohnsonRecenzent AI może zostawić dziesiątki komentarzy, a mimo to przeoczyć błąd istotny przed wydaniem. 5 października 2026 roku GitHub zaprezentował ReviewBench — zapowiedź badawczą benchmarku, który porównuje agentów pod względem wykrytych problemów, pominięć i precyzji uwag.
Dla programistów istotna jest tu zmiana: zamiast liczyć komentarze, ocenia się ich treść. Benchmark porównuje wynik agenta z zestawem referencyjnym problemów dotyczących pull requesta, a także osobno uwzględnia wagę i kategorię wykrytych usterek.
Co dokładnie ocenia ReviewBench
Zestaw obejmuje 219 publicznych pull requestów ze 187 repozytoriów z otwartą licencją i kodem w 19 językach. GitHub informuje, że podczas tworzenia zbioru przeanalizował rozkład ponad 103,9 mln PR-ów. Rozmiary repozytoriów i udział języków dobrano z uwzględnieniem ogólnej próby GitHuba, natomiast rozmiar zmian celowo przesunięto w stronę bardziej znaczących PR-ów, które nadają się do przeglądu.
Dla każdego PR-a benchmark przechowuje uwagi referencyjne oznaczone poziomem istotności i kategorią — na przykład poprawnością, bezpieczeństwem, niezawodnością, łatwością utrzymania i testowaniem. ReviewBench oblicza precyzję: jaki odsetek komentarzy agenta odpowiada rzeczywistym problemom, oraz kompletność: jaki odsetek znanych problemów agent wykrył. Wskaźnik Fβ pozwala zmienić względną wagę tych dwóch kryteriów: większy nacisk na kompletność pomaga znaleźć więcej problemów, a większy nacisk na precyzję ogranicza zaszumione uwagi.
Jak interpretować dane GitHuba
W publikacji podano 96,6% zgodności między oznaczeniami ReviewBench a niezależną weryfikacją przeprowadzoną przez starszych inżynierów. Jest to miara zgodności eksperckich ocen problemów referencyjnych, a nie precyzji jakiegokolwiek agenta AI.
Osobno GitHub opisał wewnętrzny test A/B zespołu modeli dla Copilot code review. Według firmy, w porównaniu z grupą kontrolną odsetek komentarzy, po których wprowadzono odpowiednie zmiany w kodzie, wzrósł o 8,0%, kompletność — o 13,6%, liczba komentarzy — o 61%, a koszt przeglądu spadł o 8,0%. To wyniki jednego eksperymentu GitHuba; nie są oceną wszystkich agentów ani obietnicą takiego samego efektu w innych zespołach.
Rozdzielenie metryk jest szczególnie przydatne, gdy zespół dobiera ustawienia przeglądu. Większa liczba uwag może iść w parze z większą liczbą użytecznych wykryć, ale sama w sobie nie pokazuje, ile z nich zostało potwierdzonych. ReviewBench dzieli też wyniki według wagi i kategorii, aby zespół mógł osobno analizować na przykład krytyczne błędy lub kwestie bezpieczeństwa.
Jak wypróbować benchmark
Zgodnie z opisem GitHuba zapowiedź badawcza umożliwia zapoznanie się z pełnym zestawem danych, porównanie opublikowanych wyników i uruchomienie własnego agenta. Wstępny test obejmuje 25 PR-ów; pełne uruchomienie — 219 PR-ów w trzech rundach. Uczestnik dostarcza obraz kontenera, konfigurację i własny klucz modelu, a ocena odbywa się z użyciem wspólnego arbitra. Wyniki pozostają prywatne do czasu sprawdzenia i zatwierdzenia zgłoszenia.
Praktycznym celem takiego testu jest uzyskanie porównywalnego punktu wyjścia, a następnie sprawdzenie systemu według własnych zasad przeglądu i zmian typowych dla repozytorium. Warunki pracy konkretnego zespołu — języki, architektura, progi istotności i dopuszczalny poziom szumu — mogą różnić się od składu ogólnego zbioru.
GitHub twierdzi, że w jego eksperymentach zmiany wyników ocen offline w ReviewBench pokrywały się kierunkowo z rezultatami uzyskiwanymi w praktyce. Opublikowane pomiary dotyczą własnych testów firmy. Dlatego obecnie najbardziej wiarygodnym zastosowaniem benchmarku jest porównywanie agentów na wspólnym zbiorze i diagnozowanie ich mocnych stron; decyzję o wdrożeniu warto oprzeć również na testach w rzeczywistym procesie pracy danego zespołu.