Sjekken sjekkes
Verifikatorsteget fikk fem endringer på én ettermiddag, hentet fra det fagmiljøet diskuterte den uken. Testing og gjennomgang fant tre feil i det samme dag. To modeller, samme fangstrate, null falske positive.
Verifikatoren som tok verifikatoren beskriver et steg: før en dokumentasjons-commit prøver en annen agent, uten minne om arbeidet, å motbevise hver påstand i den. Samme dag som notatet ble publisert, leste vi diskusjonen om nettopp dette problemet; et dev.to-innlegg fra uken før hadde samlet det i én formulering: en agent kan gjøres verifiserbar, men ikke selvverifiserende. Å lese den diskusjonen opp mot vårt steg ga fem endringer. Å teste og gjennomgå det endrede steget ga tre funn om selve steget. Dette notatet er tallene.
Hva fagmiljøet sa
De skarpeste innvendingene, brukt på steget slik det var den formiddagen: den mistenkte skriver påstandslisten, så en påstand den første agenten utelater, blir aldri sjekket; en dom navngir ingen kilde, så en sjekk mot en mellomlagret kopi teller likt med en mot verten; den plantede testen kjørte én gang, og en verifikator som melder null avvik i en måned, ser ut som en som har sluttet å lete; en hoppet-over sjekk etterlater ingen spor; og en verifikator som får servert bekvemme bevis, kan lese dem i stedet for kilden; Goodhart Labs viste i september at frontmodeller fortsatt tar en snarvei når en evaluering byr på en.
Fem endringer
Verifikatoren trekker nå ut sin egen påstandsliste fra filene før den leser forfatterens; alt forfatteren utelot,
flagges [UNLISTED] og sjekkes likevel. Hver dom navngir hva den leste og hvor, og om det var kilden eller en kopi;
ingen navngitt kilde betyr uverifisert, aldri verifisert. Commit-meldingen bærer en Verify-Claims:-trailer med
tallene, eller sier at sjekken ble hoppet over. Et plantet notat og et rent notat holdes som kanarifugl og kjøres på
nytt hver gang steget eller modellen endres, med resultatet loggført. Og begrensningene er skrevet ned: en fersk
kontekst av samme modellfamilie fanger glipp, ikke felles vaner.
Sjekken sjekkes
Kanaritesten kjørte samme ettermiddag, på to modeller, uten at verifikatorene fikk vite at noe var plantet.
| Opus 5.5 | Fable 5.1 | |
|---|---|---|
| Plantet notat, 3 plantede feil | 3 av 3 fanget, 31 s, 4 verktøykall | 3 av 3 fanget, 51 s, 3 verktøykall |
| Rent notat | 0 falske positive, 24 s, 2 kall | 0 falske positive, 46 s, 2 kall |
Samme fangstrate, ingen falske positive. De plantede feilene var et linjenummer som bommet med én, et commit-tidspunkt som bommet med fem minutter, og linjetallet for én fil endret under en sum som ble stående riktig, så delene ikke lenger gikk opp; den andre modellen la merke til at regnestykket ikke stemte før den leste et eneste git-objekt.
Tre feil, funnet ved testing og gjennomgang
Den første kanarifuglen forfalt i løpet av timer. Påstandene dens handlet om levende servertilstand, og én av dem (hvilken commit en utsjekking sto på) var sann i sekstifire minutter den formiddagen. Om ettermiddagen meldte en korrekt verifikator den som avvik, og det var den: reell drift, ikke en plantet feil. En annen økt byttet ut fikstyrene med påstander om faste git-objekter alene, der det riktige svaret aldri endrer seg. På dem falt den tregere modellens tid fra åtte eller ni minutter per notat til under ett minutt.
Commit-traileren var ikke en trailer. Git leser trailere bare fra siste avsnitt i en commit-melding, og
Verify-Claims:-linjen sto i avsnittet over, så git log --format='%(trailers:…)' ga ingenting. Regelen hadde ikke
sagt hvor linjen må stå. Det kom fram i eierens gjennomgang sammen med den andre økten, og regelen navngir nå kommandoen
som sjekker det.
Og den nye merkelappen UNLISTED var skrevet som en fjerde dom, ved siden av verifisert, avvik og uverifisert. En
påstand forfatteren hadde utelatt, ble da meldt som ulistet og ingenting mer: funnet, men aldri vurdert som sann eller
usann. Samme gjennomgang gjorde den til et flagg oppå én av de tre dommene, talt med i begge summene.
En glipp til, ikke fanget av noen regel: en verifikator skrev ut en del av et øktstoken i sin egen verktøyutskrift mens den sjekket et API. Det nådde ingen rapport og ingen person, og reglene sier nå at man aldri skal skrive ut et autentiseringssvar, heller ikke der.
Hva dette gir
Et steg som sjekkes, er noe annet enn et steg som stoles på. Kanaritesten koster under ett minutt per notat og gir ett tall metodenotatene ikke kunne gi før: steget fanger fortsatt det det skal fange, på modellen som brukes i dag, og roper ikke ulv. Neste kjøring forfaller når steget eller modellen endres, og om en måned uansett.