Hur bra är bra nog? Bestäm ribban innan ni bygger vidare
”Den måste vara 100 procent rätt” stoppar fler AI-projekt än någon bugg. Så sätter ni en ribba som går att nå, mäta och försvara.
Kort sagt
- ”100 procent rätt” är en ribba som inget system når, och betyder i praktiken att ni aldrig släpper.
- Jämför med hur arbetet görs i dag, inte med perfektion.
- Dela upp felen i tre nivåer: får aldrig hända, ska vara ovanliga, spelar mindre roll, och sätt en siffra för varje.
- Bestäm ribban innan ni testar, tillsammans med verksamheten, och låt skyddsnätet avgöra hur hög den behöver vara.
I den här artikeln · 6 avsnitt
Mötet går bra ända tills någon från ledningen ställer frågan: ”Men hur säkra är vi på att den alltid svarar rätt?”
Projektledaren tvekar. ”Alltid… den svarar rätt nästan alltid.”
”Nästan alltid räcker inte för kunderna. Den måste vara hundra procent rätt.”
Alla nickar. Det låter ansvarsfullt. Och i det ögonblicket har projektet, utan att någon märkt det, fått en ribba som det aldrig kommer att nå.
Varför 100 procent är fel ribba
Det är lätt att förstå varför 100 procent känns rätt. Ingen vill skicka fel svar till en kund. Men tänk efter: vem svarar rätt på hundra procent av kundfrågorna i dag?
Inte kundtjänst. Människor missförstår, slarvar en sen fredag, missar en ändring i policyn, svarar olika på samma fråga. Fråga gärna kundtjänst om de minns en dag utan ett enda fel, och räkna med ett skratt. Det är inte ett problem med människorna; det är så verkligt arbete ser ut. Ingen kräver att kundtjänst ska vara perfekt innan den får öppna på måndag.
En ribba som inget system i världen kan nå betyder i praktiken ”släpp aldrig”. Det är ett beslut också, och oftast inte det man ville fatta.
Jämför med i dag, inte med perfekt
Den rätta frågan är inte ”är den perfekt?” utan ”är den bättre än alternativet, och klarar vi felen?”
Alternativet är oftast hur arbetet görs i dag. Ta reda på det innan ni bestämmer ribban:
- Hur lång tid tar det i dag att svara på en fråga av den här typen?
- Hur ofta blir det fel i dag, och hur upptäcks felen?
- Vad kostar det när det blir fel?
Ofta blir svaren överraskande. Det visar sig att en fjärdedel av svaren i dag tar mer än ett dygn, och att ingen riktigt vet hur ofta de innehåller fel, eftersom ingen har mätt. Plötsligt är frågan inte om AI:n är perfekt, utan om den kan svara snabbare med minst lika få fel.
Alla fel är inte lika farliga
”Rätt” och ”fel” är för grovt. Ett svar som är lite stelt formulerat är inte samma sak som ett svar som lovar en kund pengar tillbaka som hen inte har rätt till.
Dela upp felen i tre nivåer:
| Nivå | Exempel | Vad som gäller |
|---|---|---|
| Får aldrig hända | Lovar återbetalning som inte gäller, avslöjar en annan kunds uppgifter, ger farliga råd | Noll. Testas särskilt, och stoppar släppet. |
| Ska vara ovanliga | Fel leveranstid, missar en del av frågan, hänvisar till fel sida | En gräns, till exempel högst 1 av 20. |
| Spelar mindre roll | Lite stel ton, onödigt långt svar | Förbättras över tid, stoppar inte släppet. |
Det här är den viktigaste tabellen i hela projektet. Den gör om en känsla (”den måste vara säker”) till något ni kan testa.
Sätt ribban med siffror
När felen är uppdelade kan ribban skrivas på en rad per nivå. Ett exempel för en assistent som svarar på kundfrågor om beställningar:
- Får aldrig hända: 0 av de 20 frågor vi har skrivit särskilt för att lura den.
- Ska vara ovanliga: minst 46 rätt av 50 vanliga frågor, alltså högst 4 fel.
- Säger ”jag vet inte” när den inte vet: på alla 10 frågor som den inte ska kunna svara på.
Ribban ska bestämmas innan ni testar, inte efter. Annars är det lätt att flytta den till där resultatet råkade hamna.
Skyddsnätet sänker ribban
Ribban beror på vad som händer efter svaret. Det är den del som oftast glöms bort.
Om varje svar läses av en människa innan det skickas, är ett fel en sekund för medarbetaren att rätta, inte ett problem hos kunden. Då kan ribban för de vanliga felen vara lägre, och ni kan släppa tidigare.
Om svaren går direkt till kunden behöver ribban vara högre, och ni behöver ett sätt för kunden att säga till och få hjälp av en människa.
Många team börjar med människan i mitten, mäter hur ofta svaren behöver ändras, och låter svaren gå direkt först när den siffran är låg nog. Det är inte ett tecken på att AI:n är dålig. Det är så man bygger förtroende, både hos teamet och hos kunderna.
Vem bestämmer ribban?
Inte utvecklarna ensamma. Ribban är ett verksamhetsbeslut, eftersom det handlar om vilka risker ni är beredda att ta och vad ni vinner på det.
Ett bra sätt att göra det är ett kort möte med tre personer: den som ansvarar för verksamheten där AI:n ska användas, den som bygger den, och den som ska äga beslutet att släppa. Ta med tabellen med de tre felnivåerna och fyll i den tillsammans. Skriv ner resultatet och sätt det överst i projektets dokumentation.
Nästa gång någon frågar ”men hur säkra är vi?” har ni ett svar som går att visa.
När ribban finns är nästa steg att mäta mot den. Det går fortare än ni tror, och det visar Ert första test av AI-svaren. Har ni inte läst första delen, Demon fungerade. Varför släpper vi den inte?, börjar serien där.