KI-en din trenger en ferdsskriver, og du bygger den fra dag én
De få opptegnelsene som gjør at du kan forklare et hvilket som helst KI-svar flere måneder senere, og oppdage at kvaliteten glir før en kunde gjør det.
Når et KI-system kommer i produksjon, er det første vanskelige spørsmålet aldri hvordan det virker. Det er hvorfor det sa akkurat det. En kunde bestrider et pristilbud. En revisor spør hvordan en avgjørelse ble tatt. Noen på teamet ditt merker at sammendragene har blitt dårligere denne måneden, og kan ikke si når det begynte.
I det øyeblikket har du enten dokumentasjonen eller ikke, og du kan ikke rekonstruere den i ettertid. Å kjøre det samme spørsmålet på nytt i dag gir deg dagens svar fra dagens modell, dagens prompt og dagens data. Det er ikke bevis for noe som helst.
Logging er en beslutning du tar fra dag én. Legger du den til senere, dekker den bare det som skjer fra da av.
De seks tingene som skaper et svar
Et KI-svar er resultatet av et lite sett med inndata. Fang opp alle sammen, ved hvert eneste kall, fra den aller første forespørselen:
- Forespørselen — en unik ID, et tidsstempel, hvem eller hvilket system som spurte, og den nøyaktige teksten eller dataene som ble sendt inn.
- Konteksten — hvert dokument, hver post og hver rad systemet hentet fram og la foran modellen, identifisert enkeltvis, med versjonen av hver enkelt.
- Instruksjonene — promptmalen pluss alt som settes sammen under kjøring, og versjonen av malen.
- Modellen — den nøyaktige modellidentifikatoren, ikke familienavnet, sammen med innstillingene som ble brukt: temperatur, tokengrenser, hvilke verktøy den kunne kalle.
- Utdataene — det rå svaret før eventuell opprydding, og den bearbeidede versjonen hvis de to er ulike.
- Konsekvensen — hva som skjedde etterpå: vist til en bruker, sendt på e-post til en kunde, brukt til å godkjenne et krav, og om et menneske godtok, redigerte eller forkastet det.
Dropper du konteksten og instruksjonene, sitter du igjen med en halv samtale. Du kan se hva systemet svarte, men aldri fastslå hvorfor det svaret var fornuftig.
Versjoner er delen alle hopper over
Tre ting endrer seg under et KI-system uten at noen melder inn en endringsforespørsel. Noen redigerer en prompt en tirsdag ettermiddag. Leverandøren oppdaterer modellen bak det samme API-navnet. Kunnskapsbasen indekseres på nytt, og systemet begynner å hente fram andre dokumenter for det samme spørsmålet.
Hver av dem kan flytte på kvaliteten, og ingen av dem dukker opp i en logg over utdata. Registrer en versjonsidentifikator for prompten, modellen og dataindeksen ved hvert kall, så tar spørsmålet «hva endret seg mellom den gode uka og den dårlige uka» minutter å svare på. Uten dem tar det en uke med gjetting, som regel mens noen høyt oppe i systemet venter.
Menneskelige rettelser er ditt beste signal
Når et menneske redigerer et KI-utkast før det sendes, har vedkommende fortalt deg nøyaktig hva som var galt, så konkret som det går an. Lagre originalen sammen med den redigerte versjonen.
Gjør du det, følger to ting. Redigeringsandelen blir et kvalitetsmål du kan følge uke for uke, og den beveger seg før klagene gjør det. Og rettelsene hoper seg opp til et sett med eksempler du kan bruke til å forbedre systemet, bygget på ditt eget arbeid i stedet for kjøpt eller funnet på.
Drift er en sammenligning, ikke en alarm
Ingenting kommer til å varsle deg om at utdataene har blitt dårligere. Forringelsen er gradvis, og hvert enkelt svar ser plausibelt ut.
Den praktiske metoden er å holde på et fast sett med ekte forespørsler — hundre er nok, hentet fra virkelig trafikk og med de vanskelige tilfellene dine dekket — og kjøre det på nytt hver måned. Sammenlign de nye svarene med de lagrede. Der de er ulike, leser et menneske begge og sier hvilket som er best. Dette virker bare hvis du tok vare på inndataene, og det er hele poenget med å logge dem.
Kombiner det med tallene du allerede har: redigeringsandel, avvisningsandel, eskalering til et menneske, andelen svar der systemet ikke fant noen relevante dokumenter. En økning i det siste tallet betyr som regel at dataene dine har blitt utdaterte, ikke modellen.
Bestem lagringstid og sladding først
Disse loggene inneholder alt kundene dine skrev inn, og dermed gjelder de samme pliktene som for alle andre personopplysninger. Klassifiser felter i det de skrives, masker eller tokeniser det som ikke trenger å være lesbart, og lagre loggene atskilt fra applikasjonen, slik at en feil i den ene ikke tar dokumentasjonen av feilen med seg.
Sett lagringstiden bevisst. For avgjørelser med kontraktsmessig eller regulatorisk vekt beholder du dokumentasjonen så lenge eksponeringen varer, og lagringen skal bare kunne føyes til, slik at ingen kan skrive om historien i det stille. For rutinetrafikk er kortere både bedre og billigere. Sett navnet på én person ansvarlig for retningslinjen.
Lagring er den billige delen. Den dyre delen er å ettermontere alt dette i et system som allerede er i drift, mens du samtidig blir bedt om å forklare et svar du ikke kan gjøre rede for. Vi bygger denne dokumentasjonen inn fra starten, fordi det er den som gjør et KI-system om fra noe du stoler på til noe du kan vise fram.