Michael Johnson5. marraskuuta alkaen GitHub Copilot Code Review’ta käyttävät tiimit ovat voineet nähdä API-raporteista, mihin huomautuksiin kehittäjät ovat reagoineet. Samana päivänä GitHub lisäsi kenttiä, joiden avulla ylläpitäjät voivat havaita puutteita telemetriatiedoissa ja vanhentuneita editoriversioita. Päivitykset antavat esihenkilöille ja organisaatioiden omistajille aiempaa konkreettisemman tavan tarkastella tekoälyarvioinnin toimintaa ja Copilotin käyttötietojen kattavuutta.
Miten tekoälyn huomautuksiin reagointia mitataan
Repositorion päivittäiseen raporttiriviin repos-1-day on lisätty objekti copilot_code_review. Sen kenttiin kuuluvat total_comments_evaluated, tarkastettujen huomautusten määrä, ja total_comments_addressed, niiden huomautusten määrä, joihin kehittäjä reagoi. Repositorion käsiteltyjen huomautusten osuuden voi laskea jakamalla jälkimmäisen arvon ensimmäisellä. Uudet kentät on kuvattu Copilot usage metrics API -päivityksessä.
GitHub laskee huomautukseen reagoimiseksi sen, että kehittäjä ottaa ehdotetun korjauksen käyttöön, pyytää Copilotia tekemään sen, muokkaa koodia itse tai vastaa, että korjaus sisällytetään seuraavaan pull requestiin. Raportissa kommentit eritellään myös vakavuuden, arviointitason, huomautuksen tyypin sekä lisäohjeiden tai työkalujen käytön mukaan. Näin tiimi voi selvittää esimerkiksi, reagoidaanko tietoturvaa koskeviin kommentteihin eri tavoin kuin muihin huomautuksiin tai mitkä kategoriat vaativat enemmän manuaalista työtä.
Mittari kertoo kirjatusta toiminnasta, ei korjauksen vahvistetusta laadusta. Siksi sitä kannattaa tarkastella yhdessä koodin tarkistuksen ja pull requestin tilan kanssa: suuri käsiteltyjen kommenttien osuus kertoo, että huomautuksiin on reagoitu, mutta ei yksinään sitä, että kaikki muutokset ovat oikein tai tarpeellisia. Huomionarvoista on myös, että kommentit lasketaan mukaan pull requestin yhdistämispäivänä, eivät päivänä, jona Copilot julkaisi ne.
Miksi reagointimittari eroaa ehdotusten hyväksymisestä
Aiemmat kentät seurasivat Copilot Code Review’n käynnistyskertoja ja tilanteita, joissa käyttäjä painoi valmiin ehdotuksen käyttöönottopainiketta. Uusi mittari kattaa useampia reagointitapoja: kehittäjä voi tehdä korjauksen itse, pyytää Copilotia tekemään sen tai siirtää muutoksen seuraavaan pull requestiin. Siksi total_comments_addressed vastaa kysymykseen huomautuksiin reagoimisesta, kun taas total_copilot_applied_suggestions kattaa vain yhdellä toiminnolla käyttöön otettavat ehdotukset.
Raportissa on myös kenttä total_merged_no_human_change_request_after_review, joka kertoo Copilotin tarkistamien yhdistettyjen pull requestien määrän silloin, kun kukaan ihminen ei pyytänyt muutoksia ensimmäisen arvioinnin jälkeen. Mittarit kuvaavat työn eri vaiheita ja niitä kannattaa tarkastella yhdessä: ensimmäinen kertoo kommentteihin reagoinnista, toinen arvioinnin etenemisestä ennen yhdistämistä.
Uudet kentät paljastavat, miksi raportit ovat puutteellisia
Toinen 5. marraskuuta julkaistu päivitys tuo tietoja asiakasohjelman telemetriasta ja työkalujen versioista. Kenttä client_telemetry_present kertoo, saapuiko käyttäjän editorista tapahtumia tiettynä päivänä; usage_metrics_requirements ilmaisee, täyttävätkö IDE ja laajennukset mittareiden vähimmäisversiovaatimukset. Ylläpitäjät näkevät myös päivittäiset lukumäärät käyttäjistä, joilta telemetriatiedot puuttuvat, sekä käyttäjistä, joilla on vähintään yksi vanhentunut komponentti. Tiedot on lueteltu Copilot-tietojen puutteita käsittelevässä huomautuksessa.
Tämä auttaa erottamaan käyttäjän aktiivisuuden raportoinnin kattavuudesta. GitHubin mukaan käyttäjä voidaan laskea aktiiviseksi, vaikka editorista ei saapuisi tapahtumia — tällöin raportista puuttuu tietoja esimerkiksi käytön jakautumisesta ominaisuuksien ja mallien mukaan. Syynä voi olla IDE:n tai laajennuksen vanha versio, editorin telemetrian poistaminen käytöstä tai tapahtumia estävä välityspalvelin tai palomuuri.
Puuteilmaisimien lukuja ei pidä laskea yhteen yksittäisten käyttäjien kokonaismääräksi, sillä sama henkilö voi kuulua molempiin ryhmiin. Lisäksi ajantasainen editoriversio ei takaa telemetrian saapumista — esimerkiksi verkkorajoitukset voivat edelleen estää sen. Jos arvo puuttuu tai on null, GitHub merkitsee tiedon saatavuuden puutteelliseksi; se ei tarkoita nollaa eikä sitä, ettei ongelmaa olisi.
Mitä tämä merkitsee tiimeille
Päivitysten ansiosta Copilotin yleisen aktiivisuusmittarin rinnalle saadaan kaksi käytännönläheisempää tarkastelua: mitä Code Review’n huomautuksille tapahtuu ja kuinka luotettavia sisäisen raportoinnin perustana olevat tiedot ovat. Tekniikkatiimien esihenkilöt voivat vertailla kommenttityyppejä ja repositorioita, ja ylläpitäjät voivat tunnistaa käyttäjät, joiden IDE tai laajennus on päivitettävä tai joiden verkkoasetukset on tarkistettava.
Raportit ovat saatavilla organisaatio- ja yritystasolla käyttäjille, joilla on tarvittavat oikeudet Copilot-mittareiden tarkasteluun. Copilot usage metrics -käytäntö on oltava käytössä. Code Review -tiedot löytyvät repos-1-day-riveiltä, ja telemetriaa sekä versioita koskevat kentät käyttäjäraporteista yhden ja 28 päivän ajalta. Päivitys on siksi erityisen hyödyllinen organisaatioille, jotka jo hallinnoivat Copilotia keskitetysti: ne voivat nyt tarkastella avustajan käytön lisäksi siihen liittyviin arviointeihin reagoimista ja puutteellisten mittaustietojen syitä.
