Din AI behöver en färdskrivare, och du bygger den dag ett
De få uppgifter som gör att du kan förklara vilket AI-svar som helst månader senare, och upptäcka kvalitetsförsämring innan en kund gör det.
När ett AI-system når produktion är den första svåra frågan aldrig hur det fungerar. Den är varför det sa så. En kund ifrågasätter en offert. En revisor frågar hur ett beslut fattades. Någon i ditt team märker att sammanfattningarna blivit sämre den här månaden och kan inte säga när det började.
I det ögonblicket har du antingen uppgifterna eller inte, och du kan inte rekonstruera dem i efterhand. Att köra samma fråga igen i dag ger dig dagens svar från dagens modell, dagens prompt och dagens data. Det är inte bevis för någonting.
Loggning är ett beslut du fattar dag ett. Läggs den till senare täcker den bara det som händer därefter.
De sex sakerna som producerar ett svar
Ett AI-svar är resultatet av en liten uppsättning indata. Fånga dem alla, vid varje anrop, från den första förfrågan:
- Förfrågan — ett unikt ID, en tidsstämpel, vilken person eller vilket system som frågade, och exakt vilken text eller vilka data som skickades in.
- Kontexten — varje dokument, post eller rad som systemet hämtade och lade fram för modellen, identifierade var för sig, med versionen av var och en.
- Instruktionerna — promptmallen plus allt som sätts ihop vid körning, och mallens version.
- Modellen — den exakta modellidentifieraren, inte familjenamnet, tillsammans med inställningarna som användes: temperatur, tokengränser, vilka verktyg den fick anropa.
- Utdata — det råa svaret före all efterbearbetning, och den bearbetade versionen om de två skiljer sig åt.
- Konsekvensen — vad som hände sedan: visades för en användare, mejlades till en kund, användes för att godkänna ett ärende, och om en person accepterade, redigerade eller förkastade det.
Utelämna kontexten och instruktionerna så sitter du med halva samtalet. Du kan se vad systemet svarade och aldrig fastställa varför det svaret var rimligt.
Versionerna är det alla hoppar över
Tre saker förändras under ett AI-system utan att någon lämnar in en ändringsbegäran. Någon redigerar en prompt en tisdagseftermiddag. Leverantören uppdaterar modellen bakom samma API-namn. Kunskapsbasen indexeras om och systemet börjar hämta andra dokument för samma fråga.
Var och en av dem kan påverka kvaliteten, och ingen av dem syns i en utdatalogg. Registrera en versionsidentifierare för prompten, modellen och dataindexet vid varje anrop, så tar frågan "vad förändrades mellan den bra veckan och den dåliga veckan" några minuter att besvara. Utan dem tar det en vecka av gissningar, vanligtvis medan någon högt uppsatt väntar.
Mänskliga rättelser är din bästa signal
När en person redigerar ett AI-utkast innan det skickas har hen berättat exakt vad som var fel, i de mest specifika ordalag som finns att tillgå. Spara originalet tillsammans med den redigerade versionen.
Gör du det följer två saker. Redigeringsfrekvensen blir ett kvalitetsmått du kan följa vecka för vecka, och det rör sig innan klagomålen gör det. Och rättelserna samlas till en uppsättning exempel du kan använda för att förbättra systemet, byggd av ditt eget arbete i stället för köpt eller påhittad.
Försämring är en jämförelse, inte ett larm
Ingenting kommer att meddela dig att svaren blivit sämre. Försämringen är gradvis och varje enskilt svar ser rimligt ut.
Den praktiska metoden är att hålla en fast uppsättning verkliga förfrågningar — hundra räcker, hämtade från faktisk trafik och med dina besvärliga fall representerade — och köra den igen varje månad. Jämför de nya svaren med de sparade. Där de skiljer sig läser en person båda och säger vilket som är bäst. Det här fungerar bara om du sparade indata, vilket är hela argumentet för att logga dem.
Kombinera det med siffrorna du redan har: redigeringsfrekvens, avslagsfrekvens, eskalering till en människa, andelen svar där systemet inte hittade några relevanta dokument. En ökning av den sista betyder oftast att dina data blivit inaktuella, inte att din modell blivit det.
Bestäm lagringstid och maskning först
De här loggarna innehåller vad dina kunder än har skrivit in, vilket betyder att de omfattas av samma skyldigheter som alla andra personuppgifter. Klassificera fält när de skrivs, maskera eller tokenisera det som inte behöver vara läsbart, och lagra loggarna separat från applikationen så att ett fel i den ena inte tar med sig uppgifterna om det.
Bestäm lagringstiden medvetet. För beslut med avtalsmässig eller regulatorisk tyngd, behåll uppgifterna så länge exponeringen varar, och gör den lagringen skrivskyddad efter tillägg så att ingen tyst kan skriva om historien. För rutintrafik är kortare bättre och billigare. Sätt en persons namn på policyn.
Lagringen är den billiga delen. Den dyra delen är att bygga in allt det här i efterhand i ett system som redan är i drift, medan du redan ombeds förklara ett svar du inte kan redogöra för. Vi bygger in de här uppgifterna från början, eftersom det är de som gör ett AI-system från något du litar på till något du kan visa.