Sådan måler du, om et AI-projekt faktisk virkede
En praktisk ramme til at bedømme AI-projekter ud fra forretningsresultater — udgangspunkter, rigtige måltal, fulde omkostninger, og hvad man skal holde øje med efter lancering.
De fleste AI-projekter slutter med en demo og en klapsalve. Få slutter med et tal. Seks måneder senere kan ingen sige, om systemet sparede penge, vandt kunder eller blot tilføjede endnu et værktøj at vedligeholde. Problemet er sjældent teknologien. Det er, at ingen definerede, hvordan succes skulle se ud, før arbejdet gik i gang — så succes blev til det, projektet tilfældigvis leverede.
At måle et AI-projekt er ikke kompliceret. Det kræver, at man på forhånd beslutter, hvordan forretningen skal se ud, hvis projektet virker — og derefter tjekker.
Definér "virkede", før nogen skriver kode
Et AI-projekt virker, når det flytter et forretningstal, du allerede går op i. Ikke nøjagtighed, ikke svarkvalitet, ikke "udbredelse" i abstrakt forstand. Et tal: timer af manuelt arbejde fjernet, dage skåret af en proces, fejlrater i fakturaer, omkostning pr. håndteret sag, omsætning pr. sælger.
Skriv det tal ned, før projektet starter, sammen med målet. "Systemet skal skære tiden til at udarbejde tilbud fra tre dage til én" er en påstand, du kan efterprøve. "Systemet vil forbedre effektiviteten" er en påstand, du kun kan erklære dig enig i. Hvis teamet ikke kan nævne det tal, projektet skal flytte, er projektet ikke klart til at få penge.
Mål udgangspunktet først
Du kan ikke vise forbedring i forhold til et udgangspunkt, ingen har registreret. Brug en uge eller to, før systemet går i luften, på at kortlægge, hvordan processen præsterer i dag: hvor lang tid opgaverne tager, hvor ofte de går galt, hvad de koster, hvem der rører ved dem. Det er uglamourøst arbejde, og det er det mest oversprungne trin i hele AI-adoption.
Udgangspunktet behøver ikke være perfekt. Ti tidsmålte eksempler på den nuværende proces slår nul. Uden dem bliver enhver senere samtale om værdi til mening mod mening.
Bedøm resultater, ikke modellens præstation
Tekniske teams rapporterer tekniske måltal — nøjagtighed, svartid, benchmark-scorer. De betyder noget for dem og bør ikke betyde meget for dig. En model kan være 95 % nøjagtig og stadig fejle som projekt, fordi de 5 %, den tager fejl af, rammer dine vigtigste kunder, eller fordi medarbejderne stille og roligt holdt op med at bruge den i marts.
De måltal, der er værd at gennemgå på ledelsesniveau, falder i fire grupper:
- Output: er arbejdet målbart hurtigere, billigere eller bedre end udgangspunktet
- Udbredelse: hvor stor en andel af det relevante arbejde faktisk går gennem systemet, og om den andel vokser eller skrumper
- Undtagelser: hvor ofte et menneske skal gribe ind, rette eller tilsidesætte — og om de tilfælde bliver sjældnere
- Tillid: om de mennesker, der bruger det, ville protestere mod at miste det
Udbredelsestallet fortjener særlig opmærksomhed. Et system, der bruges til 8 % af de relevante sager, har ikke virket, uanset dets nøjagtighed. Faldende brug er det tidligste ærlige signal om, at noget er galt, og det viser sig længe før, nogen indgiver en klage.
Tæl hele omkostningen
Byggeomkostningen er den synlige del. Det reelle total omfatter de løbende dele: abonnements- og beregningsomkostninger, den tid medarbejderne bruger på at gennemgå output, vedligeholdelsen når en leverandør ændrer et API, eller den proces, systemet blev bygget omkring, forskyder sig. Et projekt, der sparer tyve timer om ugen, men bruger ti på gennemgang og vedligeholdelse, har et reelt afkast — halvdelen af det, overskriften lovede.
Sæt en gennemgang i kalenderen tre og seks måneder efter lancering, og sammenlign den fulde driftsomkostning med den målte gevinst. Mange projekter, der så marginale ud ved lanceringen, er klart positive ved måned seks; nogle, der demonstrerede strålende, er klart negative. Du vil gerne vide, hvilken af dem du har, mens der stadig er tid til at rette eller stoppe det.
Hold øje med forfald
Et AI-system er ikke en bro; det forbliver ikke bygget. Dataene ændrer sig, forretningen ændrer sig, modellen bag et API ændrer sig uden varsel. Et system, der virkede i januar, kan drive stille af kurs inden juli, og fordi outputtet stadig ser plausibelt ud, opdager ingen det, før en kunde gør.
Løsningen er enkel: hold en lille samling kendte sager med kendte korrekte svar, og kør dem gennem systemet hver måned. Hvis resultaterne forskyder sig, opdager du det gennem dine egne tjek i stedet for gennem markedet. Giv opgaven til en navngiven person. Forfald, som det ikke er nogens job at fange, bliver ikke fanget.
Én-sides-testen
Hvis et AI-projekt virkede, bør du kunne gøre rede for det på én side: udgangspunktet, målet, det målte resultat, den fulde omkostning og udviklingen siden lanceringen. Hvis den side ikke kan skrives, er den ærlige konklusion ikke, at projektet fejlede — det er, at ingen kan afgøre det, hvilket for forretningen kommer ud på ét.
Denne måledisciplin er tungere, end de fleste teams forventer, og det er præcis den vægt, der er værd at bære — det er den, der adskiller AI, der demonstrerer godt, fra AI, der betaler sig. Det er også den del af adoption, Hercules A bygger ind fra starten, så spørgsmålet "virkede det" altid har et tal som svar.