AI pilot projekti: kako osmisliti proof of value u 30 do 90 dana

AI proof of value vremenski je ograničen eksperiment, obično 30 do 90 dana, osmišljen da razriješi jednu određenu odluku: ide li sustav u produkciju. Od proof of concepta razlikuje se po tome što mora dokazati. Proof of concept pokazuje da tehnologija može raditi. Proof of value pokazuje da tehnologija pomiče broj koji tvrtka ionako prati, u uvjetima u kojima tvrtka doista posluje, uz trošak koji je netko spreman platiti. Prvo je demonstracija. Drugo je dokaz.

U procjepu između to dvoje tiho nestaje većina AI budžeta. Pilot završi, svi se slože da je bio zanimljiv, i ništa se ne promijeni. To rijetko kad je tehnički neuspjeh. Riječ je o pogrešci u osmišljavanju, a ona je gotovo uvijek vidljiva već prvog dana onome tko zna što tražiti. Ovaj je članak o tome kako postaviti pilot tako da proizvede odluku, a ne prezentaciju.

Što je prototype theater i kako ga prepoznati?

Prototype theater je pilot koji ne može propasti. Radi na ručno probranom isječku podataka, ocjenjuju ga oni koji su ga izradili, a mjeri se prema mjerilu koje nitko nije unaprijed zapisao. Na kraju se proglasi uspjehom jer nije postojala definicija uspjeha sposobna dati bilo koji drugi odgovor.

Prepoznaje se ne po kvaliteti demonstracije. Prototype theater obično izgleda sjajno, to mu je i svrha. Znakovi su strukturni i ima ih četiri:

• Nema unaprijed dogovorenog praga. Ako nitko nije zapisao broj koji bi pokrenuo odluku o produkciji, rezultat će naknadno tumačiti onaj tko ima najčvršće mišljenje.
• Nema polazne vrijednosti. Pilot javlja da je model točan 91%. Nitko nije izmjerio koliko postiže postojeći proces, pa taj broj visi bez uporišta. Može biti velik napredak ili osjetan nazadak.
• Podaci složeni ručno. Netko u IT-u izradio je jednokratni izvoz za pilot. Pilot dokazuje da se na tom izvozu može istrenirati model. Ne dokazuje ništa o tome mogu li se podaci dobiti u utorak, svaki utorak, u produkciji.
• Nema imenovanog vlasnika za poslije. Ako nitko ne odgovara za rad sustava u četvrtom mjesecu, pilot je siroče od začeća, kakvi god mu bili rezultati.

Sva četiri jeftino se rješavaju prije početka pilota i nikako nakon njega. Ta asimetrija cijeli je argument za promišljeno osmišljavanje pilota.

Što mora biti zapisano prije nego pilot krene?

Tri stvari, na jednoj stranici, koje potvrdi onaj tko upravlja produkcijskim budžetom. Ako tu stranicu ne možete sastaviti, niste spremni za početak, a vrijeme utrošeno na nju nije režija. To je najjeftiniji dio projekta.

Odluka kojoj pilot služi

Formulirajte je uvjetno: ako pilot pokaže X, učinit ćemo Y; ako ne pokaže, učinit ćemo Z. Zatim provjerite razlikuju li se Y i Z uistinu. Iznenađujuće često ne razlikuju se. Ako je odgovor "vjerojatno bismo to ionako izgradili" ili "svejedno bismo nastavili istraživati", pilot ne služi odluci i njegov budžet pripada negdje drugdje.

Time se rješava i opseg. Pilot mora smanjiti neizvjesnost samo toliko da se ta jedna odluka može sigurno donijeti. Ne mora pokriti svaki rubni slučaj, obuhvatiti svaku liniju proizvoda ni izgledati dovršeno. Širenje opsega u pilotima gotovo je uvijek nečije tiho podmetanje druge, veće odluke.

Mjera uspjeha i njezin prag

Mjera mora biti nešto što tvrtka već prati ili bi mogla pratiti bez novog projekta izvještavanja: stopa škarta, sati po predmetu, rješenost iz prvog pokušaja, dani naplate potraživanja, protok po smjeni. Mjere modela poput F1, preciznosti i odziva instrumenti su mjerenja. One vašim inženjerima govore radi li model. Vašem sponzoru ne govore treba li ga pustiti u rad.

Prag je teža polovica i postavlja se konkretnim pitanjem sponzoru: koji bi vas rezultat naveo da ovo pustite u rad bez daljnje rasprave? Zapišite taj broj prije nego vidite ijedan rezultat. Prag dogovoren naknadno nije prag, nego opravdanje. Kako te brojeve držati poštenima, uključujući polazne vrijednosti i pripisivanje učinka, razradili smo u tekstu o validaciji povrata na AI prije gradnje.

Prvo izmjerite polaznu vrijednost, istom definicijom kojom ćete se koristiti na kraju. Ovo zvuči očito, a stalno se preskače. Ako postojeći proces nikada nije izmjeren, njegovo mjerenje prvi je tjedan pilota, a ne naknadna misao.

Kriteriji za prekid

Kriteriji za prekid zrcalna su slika praga uspjeha i dio su kojemu se timovi opiru. Trebaju navesti koji rezultat ili koje otkriće prijevremeno završava projekt. Korisni su kriteriji konkretni: podacima se u produkciji ne može pristupiti bez nove integracije koju nitko neće financirati; model ne doseže prag ni uz velikodušne pretpostavke; promjena procesa traži ljude kojih nema; proračun kašnjenja ne može se ispuniti na raspoloživoj infrastrukturi.

Imenujte tko ga smije proglasiti i stavite datum provjere. Kriterij za prekid koji nitko nije ovlašten pokrenuti puki je ukras. Nije riječ o pesimizmu, nego o tome da pilot zaustavljen u petom tjednu košta djelić onoga koji se dovuče do dvanaestog tjedna pa se tiho odloži. Rani prekid znači da pilot radi ispravno i tako ga treba unaprijed opisati timu, da ga nitko ne pročita kao neuspjeh.

Kako odrediti 30, 60 ili 90 dana?

Trajanje treba slijediti iz onoga što je neizvjesno, a ne iz sklonosti kalendaru. Tri oblika pokrivaju većinu slučajeva.

Oko 30 dana

Prikladno kada podaci već postoje u sustavu nad kojim se može postavljati upit, kada je zadatak blizu riješenog problema i kada jedan donositelj odluka odgovara za ishod. Tipičan oblik: izmjerite polaznu vrijednost, ocijenite gotov ili lagano prilagođen model na izdvojenom skupu stvarnih slučajeva i stavite izlaz pred ljude koji bi ga koristili. Rezultat je da ili ne na usko postavljeno pitanje. Trideset dana nije dovoljno za dokazivanje spremnosti za produkciju i pilot od 30 dana to ne bi smio ni tvrditi.

Oko 60 dana

Uobičajen slučaj. Dovoljno da se napravi navedeno i da se sustav spoji na jedan stvarni radni tok, sa stvarnim korisnicima, kroz nekoliko tjedana rada uživo. To je najkraći prozor koji daje dokaze o prihvaćanju, a ono je obično ograničenje koje veže. Model koji ljudi neće koristiti ima stvarnu točnost nula, a to se iz offline ocjene ne može saznati.

Oko 90 dana

Opravdano kada se podatkovni put mora izgraditi prije nego se išta može ocijeniti, kada je kontekst reguliran pa je i sam dizajn nadzora i dokumentacije dio onoga što se ispituje, ili kada se mora uskladiti više skupina dionika. Devedeset dana pravi je oblik i kada je iskren odgovor na pitanje "možemo li pouzdano doći do tih podataka?" glasi "mislimo da možemo". Otkriti u prvom mjesecu pilota od 90 dana da je odgovor ne dobar je ishod; otkriti to u sedmom mjesecu izgradnje nije.

Iznad 90 dana više ne pilotirate. Gradite, a da o tome niste odlučili, i to je problem upravljanja, a ne rasporeda.

Kakvu spremnost podataka pilot zapravo traži?

Manju nego što se strahuje za model, veću nego što se očekuje za cjevovod. Pilot rijetko treba cijelu povijesnu arhivu. Treba dovoljno reprezentativnih primjera za poštenu ocjenu i treba dokaz da se podaci mogu dobavljati ponovljivo.

To su dva različita pitanja, a piloti redovito odgovaraju samo na prvo. Praktičan test glasi: je li podatak za pilot stigao putem koji bi mogao preživjeti, dakle stvarnim upitom nad stvarnim sustavom, izvršenim više puta, od nekoga tko nije jedina osoba koja zna kako. Ako je odgovor tablica koju je kolega izvezao u ožujku, pilot spremnost podataka uopće nije ispitao. Neka ponovno izvršavanje izvoza bude izričit zadatak u prvom tjednu, a neuspjeh ondje tretirajte kao nalaz, a ne kao neugodnost. Naša procjena podatkovne infrastrukture dublje ulazi u to što izvor čini uistinu dohvatljivim.

Reprezentativnost je važnija od količine. Tisuću slučajeva koji obuhvaćaju vašu stvarnu varijabilnost, kroz lokacije, smjene, linije proizvoda, godišnja doba i nezgodne iznimke, reći će vam više od sto tisuća zapisa iz jednog čistog tromjesečja. Uzorkujte namjerno za uvjete u kojima očekujete pad i zadržite izdvojeni skup koji nitko ne gleda do kraja.

Oznake su uobičajeno usko grlo. Ako zadatak traži temeljnu istinu koja još ne postoji, označavanje je stvarna stavka sa stvarnim stručnim vremenom i mora se pojaviti u planu umjesto da ga tiho upije onaj tko je najuslužniji.

Koja se ograničenja primjene moraju ispitati tijekom pilota?

Ona koja bi mogla zaustaviti puštanje u rad. O tome vrijedi govoriti izravno: pilot koji radi u bilježnici na prijenosniku jednog inženjera dokazao je model, a ne sustav, i u razmaku između to dvoje projekti umiru. Ispitajte ovo unutar prozora pilota, makar i grubo:

• Gdje će raditi i tko ga podržava. Cloud, on-premise, na rubu mreže, unutar postojeće aplikacije. Svaka varijanta nosi drukčiju sigurnosnu provjeru, trošak i posljedice za podršku, a red za provjeru često je dulji od pilota.
• Proračun kašnjenja i protoka. Odgovor koji traje osam sekundi može biti u redu za skupnu obradu, a neupotrebljiv na radnom mjestu. Stvarni zahtjev izvedite iz radnog toka, a ne iz pretpostavke.
• Površina integracije. U koji sustav slijeće izlaz? Ako čovjek mora prepisivati rezultat s jednog zaslona na drugi, prihvaćanje će pasti na nulu bez obzira na kvalitetu.
• Sigurnost, privatnost i lokacija podataka. Kamo podaci smiju putovati, koji su dobavljači prihvatljivi, kakav je položaj prema GDPR-u. Započnite taj razgovor u prvom tjednu; to je često najdulja stavka i posve je predvidljiva.
• Put pri kvaru. Što se događa kada sustav nije dostupan ili nije siguran. Ako nema definiranog povratnog rješenja, pilot nije osmišljen za produkciju.

Ništa od toga ne mora se tijekom pilota izgraditi kako treba. Sve od toga mora se dotaknuti, da trošak urednog izvođenja bude poznat broj u završnoj preporuci, a ne iznenađenje u petom mjesecu. Više ponavljajućih pogrešaka u integraciji popisano je u tekstu pet pogrešaka koje tvrtke rade pri integraciji AI-ja.

Tko se mora uskladiti i oko čega?

Pet uloga, i pilot ne bi smio krenuti s ijednom praznom.

• Sponzor upravlja produkcijskim budžetom i odgovara za odluku. Prag mora osobno prihvatiti. Sponzor koji delegira prag delegirao je ishod.
• Vlasnik procesa vodi radni tok koji se mijenja. On zna iznimke koje će razoriti vaše pretpostavke i može tiho osigurati da pilot nikada ne dotakne stvarni posao ako ga se nije pitalo.
• Vlasnik podataka može odobriti pristup. Pronađite ga u prvom tjednu jer se nabava i odobrenja pristupa ne daju stisnuti.
• Krajnji korisnici moraju to koristiti. Uključite nekolicinu rano i dopustite im da budu skeptični; skepsa iznesena tijekom pilota informacija je, a skepsa iznesena nakon puštanja u rad otpor je.
• Budući vlasnik vodi sustav u šestom mjesecu, prati ga i odlučuje kada ga treba ponovno trenirati. Ako te osobe nema, to je nalaz i vrijedi više od bilo koje mjere modela.

Usklađenost koja je bitna nije oduševljenje, nego suglasnost oko praga i kriterija za prekid. Oduševljenja na početku ima napretek, a na pregledu je nepouzdano. Potpisan prag preživi onaj sastanak na kojem se rezultati pokažu dvojbenima, a upravo taj sastanak odlučuje je li pilot išta značio.

Što proof of value treba isporučiti?

Odluku i dokaze iza nje. Konkretno, pet stvari:

• Izmjeren rezultat u odnosu na polaznu vrijednost, na izdvojenim stvarnim slučajevima, uz ponovno naveden prag i utvrđenje je li dosegnut. Bez pridjeva.
• Pošten prikaz onoga što je puklo, uključujući praznine u podacima, trenje pri integraciji i slučajeve koje je sustav loše obradio. Korisnost ovog odjeljka razmjerna je njegovoj neugodnosti.
• Procjenu troška do produkcije koja pokriva izgradnju, integraciju te trajni trošak rada i održavanja sustava, dakle broj koji poslovni slučajevi najčešće izostavljaju. Pogled na cijeli vijek obrađuje izračun povrata za projekte strojnog učenja.
• Preporuku sa stvarnom opcijom prekida. Nastaviti, nastaviti sa suženim opsegom, vratiti se nakon određenog preduvjeta, ili stati. Proces pilotiranja koji nikada nije preporučio prekid nije proces pilotiranja.
• Ponovno upotrebljive dijelove, dakle okruženje za evaluaciju, označeni skup i dokumentiran put podataka. Oni nadživljavaju odluku i čine idući pilot jeftinijim čak i ako ovaj stane.

Kada je pilot pogrešan alat?

U četiri slučaja, a njihovo prepoznavanje štedi više novca od svega ostaloga ovdje.

Kada je odgovor već poznat. Ako je pristup dobro utvrđen za vaš točan zadatak, a stvarno je pitanje trošak integracije, treba vam plan provedbe, a ne eksperiment.

Kada je ograničenje organizacijsko. Ako proces nije definiran, vlasništvo je sporno ili su podaci nedostupni iz političkih, a ne tehničkih razloga, pilot će to skupo iznijeti na vidjelo. AI Readiness Audit to iznosi u djeliću vremena, zbog čega audit u nizu stoji prije pilota, a ne poslije njega. Širi obrazac neuspjeha i kontrolne točke koje ga hvataju izloženi su u tekstu kako izbjeći neuspjeh AI projekta.

Kada nema polazne vrijednosti ni volje da se izmjeri. Bez prije nema poslije, i pilot će završiti u prepirci oko tumačenja.

Kada nitko neće preuzeti rezultat. To sponzoru treba jasno reći prije početka jer je to jedini uvjet koji jamči rasipanje, koliko god pilot bio dobro izveden.

Pošten sažetak

Dobar pilot mala je, dobro instrumentirana argumentacija. Imenuje odluku kojoj služi, mjeri prema polaznoj vrijednosti koja je postojala prije njega, drži se praga koji je netko potpisao, ispituje ograničenja koja bi doista mogla blokirati puštanje u rad, i smije završiti ranije. Ništa na tom popisu nije tehnički zahtjevno. Sve je organizacijski neugodno, zbog čega se preskače i zbog čega je to preskakanje najpouzdaniji predznak pilota koji proizvede divljenje i nikakvu promjenu.

Ako odlučujete odakle krenuti, redoslijed koji funkcionira obično je isti: najprije validirajte poslovni slučaj, zatim provedite jedan usko postavljen proof of value prema pragu, a kada je nešto u produkciji i traži trajnu brigu, stavite na to iskusne ruke. Takav je oblik naših servisnih paketa, od procjene spremnosti do omeđenog proof of concepta, i zato je Fractional AI Lead korak nakon uspješnog pilota, a ne zamjena za njega. Audit vam kaže što graditi, pilot vam kaže radi li, a vlasništvo odlučuje hoće li potrajati.

Česta pitanja

Koliko podataka treba za AI pilot?

Manje nego što većina timova pretpostavlja. Pilot treba dovoljno reprezentativnih slučajeva za poštenu ocjenu, obično stotine, a ne milijune, uz dokaz da se isti podaci mogu ponovno dohvatiti. Tisuću slučajeva koji pokrivaju vašu stvarnu varijabilnost vrijedi više od sto tisuća iz jednog čistog tromjesečja.

Može li pilot raditi bez diranja produkcijskog sustava?

Može, i kod prvog pilota obično tako i treba. Pustite model usporedo s postojećim procesom i uspoređujte izlaze umjesto da išta zamjenjujete. I dalje učite o točnosti i prihvaćanju, a izbjegavate upravljanje promjenom koje neuspio pilot čini skupim.

Tko treba voditi pilot, interni tim ili vanjski partner?

Onaj tko ga može dovršiti unutar zadanog prozora. Interni timovi poznaju podatke i iznimke, vanjski donose disciplinu ocjenjivanja i nisu opterećeni svakodnevnim poslom. Presudno je tko će sustav voditi poslije, jer ta osoba treba biti uključena u svakom slučaju.

Što ako pilot uspije, a nitko ga ne želi pustiti u rad?

To je pogreška u opsegu koja se pokazala kasno. Znači da odluka koju je pilot trebao razriješiti nikada nije bila stvarno otvorena, ili sponzor koji upravlja budžetom nije prihvatio prag. Oboje se rješava prije idućeg pilota: zapišite uvjetnu odluku i neka je sponzor potpiše.