Michael JohnsonTekoälyarvioija voi jättää kymmeniä kommentteja ja silti ohittaa julkaisun kannalta tärkeän virheen. GitHub esitteli 5. lokakuuta 2026 ReviewBenchin, tutkimusvaiheessa olevan vertailutestin, joka vertaa agentteja löydettyjen ongelmien, ohitettujen virheiden ja huomautusten tarkkuuden perusteella.
Kehittäjien kannalta tässä on tärkeää siirtymä kommenttien laskemisesta niiden sisällön arviointiin. Vertailutestissä agentin tulosta verrataan pull requestin tunnettujen ongelmien vertailuaineistoon, ja löydösten vakavuus sekä luokka otetaan huomioon erikseen.
Mitä ReviewBench arvioi
Aineisto sisältää 219 julkista pull requestia 187 avoimen lisenssin repositoriosta, ja koodi on kirjoitettu 19 ohjelmointikielellä. GitHub kertoo analysoineensa aineiston muodostamista varten yli 103,9 miljoonan pull requestin jakaumaa. Repositorion koko ja ohjelmointikielet valittiin GitHubin kokonaisaineiston jakaumaa mukaillen, mutta muutosten koko painotettiin tarkoituksella laajempiin, arviointiin soveltuviin pull requesteihin.
Kullekin pull requestille vertailutesti tallentaa vertailuhuomautukset, joihin on merkitty vakavuus ja luokka, kuten oikeellisuus, tietoturva, luotettavuus, ylläpidettävyys ja testaus. ReviewBench laskee tarkkuuden eli sen, kuinka suuri osa agentin kommenteista koskee todellisia ongelmia, sekä kattavuuden eli sen, kuinka suuren osan tunnetuista ongelmista agentti havaitsi. Fβ-mittarilla näiden kahden kriteerin suhteellista painoa voi muuttaa: kattavuuden suurempi paino sopii useampien ongelmien etsimiseen, kun taas tarkkuuden suurempi paino auttaa vähentämään kohinaisia huomautuksia.
Miten GitHubin lukuja kannattaa tulkita
Julkaisussa ilmoitetaan, että ReviewBenchin merkinnät ja vanhempien insinöörien tekemä riippumaton uudelleentarkistus olivat 96,6-prosenttisesti yhteneviä. Kyse on vertailulöydöksiä koskevien asiantuntija-arvioiden yhtenevyydestä, ei minkään tekoälyagentin tarkkuudesta.
Erikseen GitHub kuvaili Copilotin koodikatselmointiin käytettyjen mallien yhdistelmän sisäistä A/B-testiä. Yhtiön mukaan kontrolliryhmään verrattuna niiden kommenttien osuus, joita seurasi niitä vastaava koodimuutos, kasvoi 8,0 prosenttia, kattavuus 13,6 prosenttia ja kommenttien määrä 61 prosenttia, samalla kun katselmoinnin kustannukset laskivat 8,0 prosenttia. Nämä ovat yhden GitHubin kokeen tuloksia, eivät kaikkien agenttien arvio tai lupaus vastaavasta vaikutuksesta muissa tiimeissä.
Mittareiden erottelu on erityisen hyödyllistä, kun tiimi valitsee katselmoinnin asetuksia. Huomautusten suuri määrä voi kulkea käsi kädessä hyödyllisten löydösten kasvun kanssa, mutta määrä yksin ei kerro, kuinka moni löydös vahvistettiin. ReviewBench jakaa tulokset myös vakavuuden ja luokkien mukaan, jotta tiimi voi tarkastella erikseen esimerkiksi kriittisiä virheitä tai tietoturvaan liittyviä kysymyksiä.
Näin vertailutestiä voi kokeilla
GitHubin kuvauksen mukaan tutkimusvaiheen esikatselussa voi tutustua koko aineistoon, vertailla julkaistuja tuloksia ja suorittaa oman agentin. Esikatselua varten on tarjolla 25 pull requestia; täysi suoritus kattaa 219 pull requestia kolmessa kierroksessa. Osallistuja toimittaa konttikuvan, asetukset ja oman mallin käyttöavaimen, ja arviointi tehdään yhteisellä arvioijalla. Tulokset pysyvät yksityisinä, kunnes osallistujan lähetys on tarkistettu ja hyväksytty.
Käytännössä tällainen suoritus tarjoaa vertailukelpoisen lähtötason, jonka jälkeen järjestelmää voi kokeilla omilla katselmointisäännöillä ja repositoriolle tyypillisillä muutoksilla. Yksittäisen tiimin olosuhteet — ohjelmointikielet, arkkitehtuuri, vakavuusrajat ja hyväksyttävä kohinan taso — voivat poiketa yleisen aineiston koostumuksesta.
GitHubin mukaan sen kokeissa ReviewBenchin offline-arviointien muutokset olivat samansuuntaisia kuin tuotantokäytössä havaitut tulokset. Julkaistut mittaustulokset koskevat yhtiön omia testejä. Siksi vertailutestin luotettavin käyttötapa tällä hetkellä on agenttien vertaaminen yhteisellä aineistolla ja niiden vahvuuksien kartoittaminen. Käyttöönottoa koskeva päätös kannattaa perustaa myös kokeiluun kyseisen tiimin omassa työnkulussa.