Oppgraderingen du ikke ba om
Modelloppgraderinger kan stille og rolig ødelegge et AI-system som fungerer. Slik oppdager du regresjonen før kundene dine melder fra.
AI-systemet ditt fungerte på fredag. På mandag gir det fortsatt svar, svarer fortsatt på under to sekunder og består fortsatt alle helsesjekkene på dashbordet. Likevel er svarene subtilt annerledes — lengre, mer forbeholdne, formatert på en måte som ødelegger parseren nedstrøms, eller skråsikkert feil om en retningslinje det pleide å treffe riktig.
Ingenting feilet. Leverandøren din rullet ut en modelloppgradering.
Dette er feilmodusen som overrasker ledergrupper mest, fordi den ikke ligner på et driftsavbrudd i det hele tatt. Det er ingen røde lamper. Systemet melder om god helse mens kvaliteten på det det produserer har flyttet seg under føttene dine. Kundene dine oppdager det før overvåkingen gjør det.
Hvorfor oppgraderinger ødelegger noe som fungerte
En nyere modell er bedre i gjennomsnitt og annerledes i det enkelte tilfellet. Leverandørene optimaliserer mot aggregerte benchmarks; du satte i drift mot din egen smale bit av virkeligheten. Når modellen endrer seg, endrer også atferden du tilpasset deg til seg — formuleringene prompten din baserte seg på, JSON-strukturen integrasjonen din forventer, grensen for når modellen nekter å svare som compliance-teamet godkjente, lengden som passet i grensesnittet ditt.
Oppgraderinger kommer på tre måter. Leverandøren pensjonerer en modellversjon og migrerer deg over. Du har låst deg til et flytende alias som stille peker videre til den nyeste versjonen. Eller du oppgraderte bevisst for å kutte kostnad eller ventetid, og antok at kvaliteten bare kunne bli bedre. Alle tre gir samme resultat: atferden endret seg, og ingen målte hva som endret seg.
Bygg det som forteller deg det
Den ene kontrollen som betyr noe, er et fast sett med testtilfeller med kjente riktige svar — et gullsett. To hundre reelle eksempler hentet fra din faktiske trafikk, som dekker de vanlige tilfellene, ytterkantene og situasjonene der det er dyrt å ta feil. Hvert med svaret virksomheten din anser som korrekt.
Kjør settet mot den modellen du bruker i dag, og lagre resultatene. Den registreringen er grunnlinjen din. Når en ny modell dukker opp, kjører du samme sett på nytt og sammenligner. Sammenligningen er hele poenget: nå har du bevis i stedet for inntrykk.
Å bygge dette tar noen dager, og det er operatørene dine — ikke utviklerne — som må definere hva "riktig" betyr. De fleste organisasjoner dropper det fordi det føles som ekstraarbeid før lansering. Det er den billigste forsikringen i hele systemet.
Styr når endringen når deg
Lås eksplisitte modellversjoner i alle produksjonskonfigurasjoner. En låst versjon gjør et bakholdsangrep om til en beslutning du selv planlegger. Behandle deretter hver oppgradering som et lite prosjekt:
- Kjør gullsettet mot den nye versjonen og sammenlign, tilfelle for tilfelle, mot grunnlinjen
- La den forretningsansvarlige gjennomgå hvert tilfelle der svaret endret seg, ikke bare der det ble dårligere — forbedringer kan også ødelegge systemer nedstrøms
- Send en liten andel av den reelle trafikken til den nye versjonen og følg med på driftssignalene: eskaleringsrate, behandlingstid, endringer gjort av de ansatte, tommel ned-klikk
- Hold den gamle versjonen tilgjengelig i et tilbakerullingsvindu, og vit hvem som har myndighet til å trekke i spaken
- Dokumenter beslutningen, datoen og bevisene, slik at neste oppgradering starter fra en kjent tilstand
Legg merke til hva som ikke står på listen: en demo. Å se en ny modell svare imponerende på fem spørsmål forteller deg ingenting om den tjuende persentilen av trafikken din, og det er der klagene kommer fra.
Følg med på signalene virksomheten allerede produserer
Mellom oppgraderingene viser kvalitetsdrift seg i tall du sannsynligvis allerede samler inn. Eskaleringer til et menneske. Gjennomsnittlig behandlingstid. Hvor ofte ansatte skriver om systemets utkast før de sender det. Gjentatte henvendelser om samme sak innen en uke. Om noen av disse beveger seg tre-fire poeng i løpet av fjorten dager, er det verdt å se på hva som endret seg i modellaget.
Gi én person den stående oppgaven å gjennomgå disse tallene ukentlig, sett opp mot modellversjonen som kjører i produksjon. Ikke en komité, ikke en kvartalsgjennomgang. En navngitt ansvarlig og en sjekk på et kvarter.
Få det inn i kontrakten
Be leverandøren om skriftlig varsel før en versjon pensjoneres, om et dokumentert minimum av støtteperiode for låste versjoner, og om tilgang til forrige versjon under migreringen. Leverandører som betjener regulerte bransjer tilbyr vanligvis dette. De som ikke gjør det, vil si fra om det, og det svaret er nyttig å ha før du bygger på dem, ikke etterpå.
Den ærlige posisjonen
Du kan ikke hindre leverandøren din i å forbedre modellene sine, og du ville heller ikke ønsket det. Det du kan gjøre, er å sørge for at forbedringen lander på dine premisser: målt, trinnvis, reverserbar og med en eier.
Det er den lite glamorøse tyngden av å drive AI i produksjon i stedet for å pilotere det — og det er den delen vi bærer for kunder som heller vil bruke oppmerksomheten sin på forretningen. Uansett: bygg gullsettet. Alt annet avhenger av det.