← Tilbage til blog

Din AI har brug for en flyveskriver, og den bygger du fra dag ét

De få optegnelser, der gør dig i stand til at forklare et hvilket som helst AI-output måneder senere og opdage kvalitetsforringelse, før en kunde gør det.

Når et AI-system kommer i produktion, er det første svære spørgsmål aldrig, hvordan det virker. Det er, hvorfor det sagde det. En kunde bestrider et tilbud. En revisor spørger, hvordan en beslutning blev truffet. En på dit team bemærker, at resuméerne er blevet dårligere denne måned, og kan ikke fortælle dig, hvornår det begyndte.

I det øjeblik har du enten optegnelsen eller også har du den ikke, og du kan ikke rekonstruere den bagefter. At køre det samme spørgsmål igen i dag giver dig dagens svar fra dagens model, dagens prompt og dagens data. Det er ikke bevis for noget som helst.

Logning er en beslutning, der træffes på dag ét. Tilføjet senere dækker den kun det, der sker fremover.

De seks ting, der frembringer et svar

Et AI-svar er produktet af et lille sæt input. Registrer dem alle, ved hvert eneste kald, fra den allerførste forespørgsel:

  • Forespørgslen — et unikt ID, et tidsstempel, hvilken person eller hvilket system der spurgte, og den nøjagtige tekst eller de nøjagtige data, der blev indsendt.
  • Konteksten — hvert dokument, hver post og hver række, systemet hentede og lagde frem for modellen, identificeret enkeltvis og med versionen af hver enkelt.
  • Instruktionerne — promptskabelonen plus alt, hvad der blev sammensat undervejs, og skabelonens version.
  • Modellen — den nøjagtige modelidentifikator, ikke familienavnet, sammen med de anvendte indstillinger: temperatur, tokengrænser, hvilke værktøjer den kunne kalde.
  • Outputtet — det rå svar før enhver oprydning, og den bearbejdede version, hvis de to er forskellige.
  • Konsekvensen — hvad der skete derefter: vist til en bruger, sendt på mail til en kunde, brugt til at godkende et krav, og om et menneske accepterede, redigerede eller afviste det.

Drop konteksten og instruktionerne, og du står tilbage med en halv samtale. Du kan se, hvad systemet svarede, og aldrig fastslå, hvorfor det svar var rimeligt.

Versioner er den del, alle springer over

Tre ting ændrer sig under et AI-system, uden at nogen indsender en ændringsanmodning. En eller anden retter en prompt en tirsdag eftermiddag. Leverandøren opdaterer modellen bag det samme API-navn. Videnbasen bliver genindekseret, og systemet begynder at hente andre dokumenter til det samme spørgsmål.

Hver af disse kan flytte kvaliteten, og ingen af dem dukker op i en outputlog. Registrer en versionsidentifikator for prompten, modellen og dataindekset ved hvert kald, og spørgsmålet "hvad ændrede sig mellem den gode uge og den dårlige uge" tager minutter at besvare. Uden dem tager det en uges gætteri, som regel mens en seniorperson venter.

Menneskelige rettelser er dit bedste signal

Når et menneske retter et AI-udkast, før det bliver sendt, har det fortalt dig præcis, hvad der var galt, i de mest specifikke vendinger, der findes. Gem originalen sammen med den redigerede version.

Gør det, og to ting følger. Rettelsesraten bliver et kvalitetsmål, du kan følge uge for uge, og den bevæger sig, før klagerne gør. Og rettelserne hober sig op til et sæt eksempler, du kan bruge til at forbedre systemet, bygget på jeres eget arbejde frem for købt eller opdigtet.

Forringelse er en sammenligning, ikke en alarm

Ingen vil give dig besked om, at outputtene er blevet dårligere. Forringelsen er gradvis, og hvert enkelt svar ser plausibelt ud.

Den praktiske metode er at holde et fast sæt af rigtige forespørgsler — hundrede er nok, taget fra den faktiske trafik og dækkende jeres besværlige tilfælde — og køre det igen hver måned. Sammenlign de nye svar med de gemte. Hvor de afviger, læser et menneske begge og siger, hvilket der er bedst. Det virker kun, hvis du gemte inputtene, hvilket er hele argumentet for at logge dem.

Kombiner det med de tal, du allerede har: rettelsesrate, afvisningsrate, eskalering til et menneske, andelen af svar hvor systemet ikke fandt nogen relevante dokumenter. En stigning i den sidste betyder som regel, at jeres data er blevet forældede, ikke jeres model.

Beslut opbevaring og maskering først

Disse logge indeholder, hvad end jeres kunder har skrevet, hvilket betyder, at de er omfattet af de samme forpligtelser som alle andre personoplysninger. Klassificer felterne, mens de skrives, masker eller tokeniser det, der ikke behøver at være læsbart, og gem loggene adskilt fra applikationen, så en fejl i den ene ikke tager optegnelsen om den med sig.

Fastsæt opbevaringsperioden bevidst. For beslutninger med kontraktlig eller lovgivningsmæssig vægt skal optegnelsen bevares, så længe eksponeringen varer, og det lager skal kun kunne tilføjes til, så ingen stille og roligt kan omskrive historien. For rutinetrafik er kortere bedre og billigere. Sæt én persons navn på politikken.

Lagerplads er den billige del. Den dyre del er at eftermontere alt dette i et kørende system, mens I allerede bliver bedt om at forklare et output, I ikke kan redegøre for. Vi bygger disse optegnelser ind fra starten, fordi det er dem, der gør et AI-system fra noget, I stoler på, til noget, I kan dokumentere.

Artikler · Hercules A

Indsigt i at tilpasse din virksomhed til AI.

Contact