GitHubov ReviewBench meri tudi hrup pregledovalcev kode

GitHub je 5. oktobra 2026 v predstavitvi merila ReviewBench objavil javno dostopen raziskovalni predogled za ocenjevanje agentov za pregled kode. Preizkus zajema 219 javnih zahtev za združitev iz 187 odprtokodnih repozitorijev v 19 programskih jezikih. Ločeno meri, koliko veljavnih težav agent odkrije in koliko neveljavnih opozoril doda pregledu.

Pri izbiri primerov je GitHub upošteval porazdelitev 103,9 milijona zahtev za združitev, kot pojasnjuje analiza LATENT; agente ocenjuje le na izbranem naboru. Za ekipo je ta razlika pomembna: rezultat opisuje obnašanje pregledovalca na določenih spremembah kode, ne kakovosti njegovega dela v vsaki zbirki kode.

Kako so izbrane spremembe in ugotovitve

Preizkus temelji na resničnih spremembah v javnih repozitorijih. Porazdelitev programskih jezikov in velikosti repozitorijev sledi širši dejavnosti na GitHubu, velikost samih sprememb pa je prilagojena: več teže imajo spremembe, pri katerih je vsebinski pregled smiseln. Zato drobni popravki ene datoteke ne prevladajo, nabor pa ni naključni prerez vseh zahtev za združitev.

Za vsako spremembo ReviewBench pripravi referenčni nabor ugotovitev. Kandidate zbere iz človeških pregledov, poznejših popravkov avtorjev, orodij za statično analizo in različnih jezikovnih modelov. Ugotovitve, ki opisujejo isto osnovno težavo, združi, da več podobnih komentarjev ne poveča umetno števila zaznanih napak.

Oznaka veljavnosti je ločen korak. Ugotovitev mora biti resnična, povezana s pregledovano spremembo in dovolj pomembna, da je uporabna. Pri pripravi referenčnega nabora sodeluje modelni ocenjevalnik, njegove oznake pa so pregledali tudi izkušeni inženirji. Tak postopek daje agentom skupno osnovo za primerjavo, čeprav je presoja posamezne pripombe lahko odvisna tudi od konteksta ekipe.

Kaj pomenita natančnost in priklic

Natančnost odgovarja na vprašanje, kolikšen delež ocenjenih opozoril je veljaven. Nižja vrednost pomeni več pripomb, ki jih mora razvijalec prebrati in zavrniti. Priklic pokaže, kolikšen delež znanih veljavnih težav je agent našel. Pregledovalec lahko odkrije veliko napak, a hkrati napiše toliko neutemeljenih pripomb, da pregled človeku vzame več časa.

ReviewBench zato loči osnovne metrike, vezane na referenčni nabor, od razširjenih. Osnovna natančnost upošteva ugotovitve, ki jih je mogoče povezati z že označenimi primeri; opozorila brez para v tem izračunu izpusti. Sama po sebi torej ne pove, kolikšen delež prav vseh komentarjev agenta je koristen. Osnovni priklic meri, koliko istih znanih veljavnih težav najde vsak kandidat.

Razširjena natančnost zajame tudi opozorila brez para v referenčnem naboru. Ocenjevalnik jih razvrsti med veljavna in neveljavna, zato lahko agent dobi priznanje za resnično težavo, ki je pripravljavci nabora niso zabeležili. Prav tu se pokaže hrup: nova pripomba lahko pomeni dragoceno odkritje ali dodatno delo brez koristi.

Pri razširjenem priklicu se z novimi veljavnimi ugotovitvami poveča tudi imenovalec. Ker lahko vsak agent odkrije drugačne dodatne težave, ta metrika kandidatov ne primerja vedno glede na povsem enak seznam. Osnovni priklic je zato jasnejša skupna mera dosega, razširjeni priklic pa predvsem pokaže, koliko je posamezni agent odkril zunaj že znanih primerov.

Zakaj se lahko vrstni red spremeni

ReviewBench omogoča razčlenitev ugotovitev po resnosti in vrsti, denimo po pravilnosti, varnosti, zanesljivosti, vzdrževanju in testiranju. Ekipa, ki želi predvsem zaznati resne napake, lahko zato drugače presodi isti rezultat kot ekipa, ki želi čim manj nepomembnih pripomb. Skupna ocena zakrije, kakšne ugotovitve sestavljajo rezultat.

Razmerje med natančnostjo in priklicem spremeni tudi utež v oceni Fβ. Večja teža priklica daje prednost širšemu odkrivanju težav, večja teža natančnosti pa pregledovalcu z manj hrupa. Ob spremembi teh nastavitev se lahko spremeni tudi vrstni red na lestvici. Primerjava je zato smiselna le, če imajo kandidati enaka merila za pomembnost ugotovitev.

Meje javnega preizkusa

Raznolikost javnih repozitorijev še ne pomeni, da nabor predstavlja interno kodo določene ekipe. Če njeno delo večinoma obsega selitve podatkovnih zbirk, ustvarjeno kodo ali zelo velike spremembe v enem repozitoriju, se lahko sestava njenih pregledov precej razlikuje. Podobno lahko rezultat spremeni kontekst, ki je agentu na voljo med dejanskim delom, na primer dostop do testov ali zgodovine projekta.

Javni primeri omogočajo pregled metodike, obenem pa so znani razvijalcem agentov. Izboljšanje na istem naboru zato še ne zagotavlja izboljšanja pri novih spremembah. Tudi presoja opozoril je odvisna od objavljenih pravil in ocenjevalnika: pripomba, ki je po teh pravilih veljavna, ni nujno enako koristna v postopku združevanja vsake ekipe.

Kaj pove primerjava z lastno kodo

Javni repozitorij ReviewBench loči preizkusni nabor 25 zahtev za združitev od celotnega nabora 219 zahtev, na katerem temelji uradna lestvica. Lokalni preizkus na manjšem naboru pokaže posamezne odzive agenta, njegova ocena pa ni enakovredna objavljenemu rezultatu na lestvici. Pri primerjanju objavljenih ocen je pomembna tudi različica nabora in ocenjevalnika.

Interna primerjava lahko to omejitev dopolni s spremembami, ki so značilne za delo ekipe in jih kandidati niso poznali vnaprej. Vsi kandidati potrebujejo enak dostop do kode, testov in drugih podatkov ter enaka pravila za presojo ugotovitev. Koristno je ločeno zabeležiti spregledane pomembne težave, dodatne veljavne ugotovitve in neveljavne pripombe, ki jih morajo razvijalci zavrniti.

Takšni podatki lahko pokažejo drugačno razmerje med koristjo in bremenom pregleda kot javna lestvica. Agent z boljšim skupnim rezultatom je lahko za določeno ekipo manj uporaben, če večino njegove prednosti tvorijo manj pomembne pripombe, njegove napake pa zahtevajo veliko človeške presoje.

Preberite tudi:

• Cursor ali GitHub Copilot: vrsta naloge spremeni zmagovalca
• GitHub Actions ali GitLab CI: brezplačne minute skrivajo drugačen strošek
• DeepL ali Google Prevajalnik: slovenščina še vedno potrebuje pregled