En modell är ett verktyg som gissar bra. Det är dess styrka och det är hela problemet. Gissningen är ovärderlig när uppgiften saknar regler, och den är ett driftbekymmer när uppgiften har dem.
Väldigt många av de sysslor som mindre bolag vill bli av med har regler. Därför är svaret på dem inte AI.
Två sorters uppgifter
Det går att sortera nästan varje flöde i två högar med en enda fråga: kan ni skriva ned regeln?
Om en faktura från en viss leverantör alltid ska på ett visst konto, om en order över ett visst belopp alltid ska godkännas av en viss person, om ett mejl med ordet reklamation alltid ska till en viss låda, då har ni en regel. Regler ska kodas, inte gissas.
En kodad regel gör samma sak varje gång, kostar nästan ingenting att köra, går att testa innan den släpps och går att förklara efteråt. Fyra egenskaper en modell inte har.
Vad modellen faktiskt kostar
Priset per anrop är sällan problemet. Det som kostar är tre andra saker.
Osäkerheten
Ett regelstyrt flöde som fungerar idag fungerar likadant om ett halvår. Ett flöde som bygger på en modell kan börja svara annorlunda för att leverantören uppdaterat något ni inte styr över. Det betyder att någon måste titta till det, och den tiden är en löpande kostnad.
Kontrollen
Ett regelstyrt flöde går att testa uttömmande. Ni matar in tjugo fall och ser tjugo rätta utfall. Ett modellstyrt flöde går att testa i stickprov, aldrig i sin helhet, och det innebär att ni måste bygga en väg för det som blir fel. Den vägen är ofta större arbete än själva flödet.
Förklaringen
Den dag någon frågar varför flödet gjorde som det gjorde vill ni kunna peka på en rad. Med en regel finns raden. Med en modell finns ett resonemang som lät rimligt vid tillfället.
De fyra lägen där en modell är rätt svar
Det finns arbete som inte går att koda som en regel, och där är en modell inte bara acceptabel utan överlägsen.
- Ostrukturerad text in. Fakturor och följesedlar som ser olika ut från varje leverantör, mejl skrivna av människor, inskannade dokument. Att plocka ut fälten ur röran är precis vad en modell är bra på, och det är svårt att skriva regler för.
- Sortering med luddiga gränser. Avgöra om ett inkommande ärende är en reklamation, en beställning eller en fråga. Ingen exakt regel finns, men gränsen är tydlig för en människa som läser.
- Sammanfattning för en människa. Dra ihop femton mejl i en tråd till ett stycke som någon ska läsa och sedan besluta på. Att en människa läser efteråt gör felrisken hanterbar.
- Text ut som ändå ska granskas. Ett utkast till svar, en produktbeskrivning, en första version av ett protokoll. Modellen tar er från blankt papper till något att rätta i.
Mönstret är värt att lägga märke till. I samtliga fyra fall handlar det om att tolka eller formulera språk, och i tre av dem tittar en människa på resultatet innan något händer.
Det vanligaste rätta svaret är en blandning
I praktiken ser ett bra flöde ofta ut så här: en modell läser den röriga inkommande texten och plockar ut fälten. Sedan tar vanlig kod över och gör allt det andra, alltså kontrollen mot regeln, uppslaget mot registret, bokningen i systemet och loggen.
Modellen får det den är bra på, som är tolkning, och gör det på ett ställe där ett fel går att fånga. Koden får det den är bra på, som är att göra exakt samma sak varje gång.
Lägg modellen där texten är rörig. Lägg koden där konsekvensen är dyr.
Varför vi säger det här högt
Det ligger inte i vårt kortsiktiga intresse. Ett uppdrag med AI i går att ta mer betalt för, och det låter bättre när det ska beskrivas.
Men vi säljer flöden som ska fortsätta gå efter att vi lämnat rummet, utan drift och utan supportavtal. Ett flöde vi byggt onödigt komplicerat kommer tillbaka som ett problem, och då har vi tjänat pengar en gång och tappat en referens.
Så frågan vi ställer på varje kartläggning är den enklaste som finns: går det att skriva ned regeln? Går det, skriver vi ned den.