Od AI pilotov k zodpovedným operáciám
Pilot, ktorý stále vyhrával
Pilot bol úspešný tak, ako piloty často bývajú. Miestnosť bola malá, používatelia priateľskí, prípady vybrané, dodávateľský tím pozorný, model sa správal dostatočne dobre a snímka na konci obsahovala percento, pri ktorom sa všetci naklonili dopredu. Asistent skrátil čas prípravy dokumentov. Klasifikátor našiel relevantnejšie prípady. Vyhľadávací nástroj vyniesol na povrch dokumenty, na ktoré ľudia zabudli. Záver bol jasný: škálovať.
Potom sa pilot stretol s pondelkom. Pondelok mal chýbajúce dáta, unavený personál, okrajové prípady, staré pravidlá, zmätených používateľov, tlak vo fronte, pomalú sieť, manažéra, ktorý chcel správu do poludnia, a jeden prípad, ktorý nezapadal do žiadnej z kategórií, ktoré pilot používal. Pondelok je miesto, kde softvér prestáva byť možnosťou a stáva sa zodpovednosťou. Je to tiež miesto, kde mnohé AI piloty potichu stratia šarm, ktorý mali v miestnosti.
Priekopa medzi pilotom a prevádzkou nie je hlavne o kvalite modelu. Je o vlastníctve. V pilote sú výnimky zaujímavé. V prevádzke majú výnimky zákazníkov, pacientov, občanov, kolegov, faktúry a termíny. V pilote projektový tím pozorne sleduje. V prevádzke musia systém sledovať ľudia, ktorí majú inú prácu. V pilote úspech znamená, že nápad si zaslúži pozornosť. V prevádzke úspech znamená, že sa naň organizácia môže spoľahnúť bez toho, aby predstierala, že realita sa stala jednoduchšou.
Zodpovedná prevádzka je dospelou formou AI pilotu. Definuje, kto vlastní pracovný postup, ktoré činnosti systém môže podporovať, aké dôkazy sa vyžadujú, ako sa zisťujú zlyhania, kedy sa systém pozastaví, ako sa ľudia odvolávajú, ako sa schvaľujú zmeny a ako sa meria hodnota po tom, čo novinka vyprchala. Menej vzrušujúce ako pilot, samozrejme. Tiež menej pravdepodobné, že vytvorí krásne financovaný chaos.
Pilot môže byť neúplný
Dobrý pilot je zámerne neúplný. Testuje otázku. Dokáže tento model klasifikovať tieto dokumenty dostatočne dobre na to, aby sa pokračovalo. Dokáže tento asistent skrátiť čas prípravy dokumentov. Dokáže tento spôsob vyhľadávania vyniesť na povrch relevantné dôkazy. Dokáže tento prístup k plánovaniu zlepšiť harmonogram. Pilot by mal byť ohraničený, dostatočne rýchly na učenie a úprimný o podmienkach, za akých prebiehal. Nemal by predstierať, že je prevádzkovým modelom s menším počtom stretnutí.
Problém začína, keď sa dôkazy z pilotného projektu povýšia nad svoj rozsah. Vybraný súbor prípadov sa stane dôkazom kvality produkcie. Priateľskí používatelia sa stanú dôkazom prijatia. Ušetrený čas v riadenom pracovnom postupe sa stane obchodným prípadom pre neprehľadné oddelenie. Integrácia podporovaná dodávateľom sa stane dôkazom, že interné tímy to zvládnu. Nástenka, ktorú projektový tím sleduje denne, sa stane dôkazom, že monitorovanie existuje. Pilotný projekt neklamal. Organizácia si ho vyložila príliš voľne.
Pilotné projekty sa často vyhýbajú najťažším otázkam, pretože takto sa pilotné projekty posúvajú rýchlo vpred. Kto vlastní model po spustení. Kto aktualizuje prompt. Kto rieši odvolanie. Čo sa stane, keď údaje chýbajú. Čo sa stane, keď model odmietne. Ktoré prípady sa nikdy nesmú automatizovať. Ako sa zisťuje odchýlka. Ako sa systém pozastaví. Aká je cesta späť. Ktorý rozpočet platí za údržbu. Tieto otázky môžu počkať počas prieskumu. Počas prevádzky čakať nemôžu.
Na neúplnom pilotnom projekte nie je nič hanebné. Hanebné je nazvať ho pripraveným, pretože bol očarujúci. Pilotný projekt si zaslúži ďalšiu fázu, keď prináša poznatky, nie keď prináša nadšenie. Nadšenie sa v riadenej miestnosti generuje lacno. Prevádzka si pýta inú menu.
Povolené použitie je prvé prevádzkové rozhodnutie
Pred rozšírením systému umelej inteligencie definujte povolené použitie. Nie vágne formuláciami ako zlepšiť produktivitu alebo podporiť rozhodovanie. Pomenujte činnosť. Navrhnúť interné poznámky. Zhrnúť dôkazy na posúdenie. Zoradiť prípady podľa pozornosti. Odporučiť postup. Schváliť transakciu s nízkym rizikom. Zamietnuť žiadosť. Poslať správu. Každé sloveso nesie iný dôsledok. Prevádzka nemôže riadiť hmlu.
Povolené použitie by malo zahŕňať hranice. Ktoré zdroje údajov sa môžu použiť. Ktoré prípady sú mimo rozsahu. Aká úroveň spoľahlivosti alebo dôkazov sa vyžaduje. Ktoré činnosti si vyžadujú schválenie človekom. Ktoré činnosti sú len odporúčacie. Ktoré výstupy môžu opustiť organizáciu. Ktorí používatelia ich môžu vidieť. Ktoré rozhodnutia si vyžadujú zachovaný záznam. Hranica nie je právnická ozdoba. Je to mapa, ktorú operátori používajú, keď systém narazí na prípad, ktorý pilotný projekt nepozval.
Toto je obzvlášť dôležité, pretože systémy umelej inteligencie majú tendenciu rozširovať sa podľa pohodlia. Nástroj, ktorý navrhuje interné zhrnutia, začne navrhovať odpovede zákazníkom. Klasifikátor používaný na triedenie začne ovplyvňovať oprávnenosť. Vyhľadávací asistent, ktorý používajú odborníci, začne odpovedať začiatočníkom. Model, ktorý bol vyhodnotený v angličtine, sa používa na preložený materiál. Nikto nemusí nové použitie ohlásiť. Jednoducho sa stane užitočným na novom mieste. Užitočné nie je to isté ako autorizované.
Zodpovedná prevádzka si vyžaduje register rozsahu, ktorý sa skutočne používa. Mal by spájať použitie, dôsledok, dôkazy, vlastníka, kontroly, monitorovanie a preskúmanie. Keď sa niekto opýta, či systém môže podporiť novú činnosť, odpoveď by mala prísť cez register a proces zmeny, nie cez rozhovor na chodbe s termínom.
Vlastníctvo musí prežiť projektový tím
Piloty často nesie osobitná skupina ľudí, ktorí rozumejú kontextu, pamätajú si výnimky a rýchlo odpovedajú na otázky, pretože kalendár ešte nesie vôňu projektu. Prevádzka sa na to nemôže spoliehať. Ľudia sa striedajú. Dodávatelia odchádzajú. Sponzori sa posúvajú ďalej. Nadšený analytik dostane povýšenie, čo je milé, až kým si všetci neuvedomia, že knižnica promptov bola väčšinou v jeho hlave.
Prevádzkové vlastníctvo potrebuje roly, nie hrdinov. Vlastník biznisu vlastní účel a prijateľné riziko. Vlastník dát vlastní kvalitu zdrojov, opravy a pôvod. Technický vlastník vlastní nasadenie, výkon, bezpečnosť a integráciu. Vlastník modelu vlastní vyhodnocovanie, monitorovanie a zmeny. Vlastník prevádzky vlastní runbooky, podporu, reakciu na incidenty a spätnú väzbu používateľov. Vlastník správy vlastní dôkazy, preskúmanie a súlad s povoleným použitím. V malých organizáciách môže jedna osoba zastávať niekoľko rolí. Roly stále potrebujú mená.
Vlastníctvo tiež potrebuje právomoc. Nestačí niekomu prideliť zodpovednosť, a zároveň mu odoprieť možnosť pozastaviť pracovný postup, vyžadovať dôkazy, odmietnuť zmenu, vyčleniť čas na údržbu alebo eskalovať riziko. To nie je vlastníctvo. To je dekoratívny zásobník viny. Zodpovedná prevádzka vyžaduje právomoc rovnajúcu sa zodpovednosti.
Rozpočet je súčasťou vlastníctva. Piloty majú často osobitné financovanie. Prevádzka potrebuje financovanie údržby: monitorovanie, preškoľovanie alebo opätovné vyhodnocovanie, podporu, školenie používateľov, opravy kvality dát, bezpečnostné preskúmanie, cvičenia na incidenty a pravidelnú správu. Ak obchodný prípad financuje len spustenie, nie je to obchodný prípad pre prevádzku. Je to oslava spustenia s faktúrami skrytými pod obrusom.
Produkčné dáta nie sú pilotné dáta s väčším počtom riadkov
Produkčné dáta majú svoju povahu. Prichádzajú neskoro, neúplné, duplicitné, preložené, ručne opravené, nesprávne klasifikované, premenované výbormi, formované stimulmi a občas ich zadá niekto, kto má zlý deň. Pilotné dátové sady sú často čistejšie, pretože ich niekto vybral, vyčistil alebo sa im aspoň pár týždňov venoval. Tento rozdiel je dôležitejší, než tímy očakávajú.
Vlastníctvo údajov v prevádzke musí zahŕňať aktuálnosť, pôvod, práva na opravu, chýbajúce hodnoty, odchýlky, prístup, uchovávanie a odvodené údaje. Systémy umelej inteligencie vytvárajú odvodený materiál: vloženia, súhrny, skóre, označenia, funkcie, vyrovnávacie pamäte a spätnú väzbu. Tieto môžu ovplyvniť budúce rozhodnutia. Ak ich nikto nevlastní, prevádzka získa druhý dátový majetok, ktorý je menej viditeľný ako prvý a niekedy vplyvnejší. Veľmi efektívne, ak je cieľom prekvapenie.
Prevádzkové monitorovanie by preto malo sledovať viac než len presnosť modelu. Sledujte aktuálnosť zdrojov, chýbajúce polia, nezvyčajné rozdelenia, pokrytie vyhľadávania, duplicity, jazykové posuny, správanie používateľov, dôvody prepísania, výsledky odvolaní, latenciu a náklady. Model môže byť technicky v poriadku, zatiaľ čo údaje okolo neho prestali znamenať to, čo znamenali počas pilotnej prevádzky. Systém nevie, že pilotná prevádzka sa skončila. Len prijíma vstupy.
Dôležité sú aj cesty opravy. Keď používateľ zistí, že zdroj je nesprávny, možno zdroj opraviť. Aktualizujú sa odvodené údaje. Záznam rozhodnutia zobrazuje starý stav. Opravený prípad učí model alebo pracovný postup. Ak oprava zmení iba viditeľný záznam, zatiaľ čo skryté funkcie zostanú zastarané, prevádzka sa stane múzeom starých chýb s čerstvým náterom.
Monitorovanie by malo vedieť, čo znamená činnosť
Mnohé plány monitorovania umelej inteligencie začínajú technickými opatreniami: dostupnosť, latencia, miera chýb, využitie tokenov, skóre modelu, metrika odchýlok. Tieto sú nevyhnutné, ale nedostatočné. Zodpovedné prevádzky monitorujú činnosť, ktorú systém podporuje. Ak systém smeruje prípady, monitorujte nesprávne smerovanie, vplyvy na fronty, preťaženie špecialistov, oneskorenú eskaláciu a zásahy používateľov. Ak navrhuje odpovede, monitorujte úsilie pri opravách, zmätok zákazníkov, porušenia pravidiel a opakované úpravy. Ak odporúča rozhodnutia, monitorujte odvolania, zvrátenia, výsledky podskupín a medzery v dôkazoch.
Otázka monitorovania nie je len to, či model funguje. Je to, či si pracovný postup stále zaslúži dôveru. Model môže zostať stabilný, zatiaľ čo sa zmení politika. Latencia môže byť vynikajúca, zatiaľ čo kvalita dôkazov klesá. Presnosť môže byť v priemere vysoká, zatiaľ čo jeden typ prípadov zlyháva. Náklady môžu klesať, zatiaľ čo prepracovanie inde rastie. Monitorovanie, ktoré vidí iba komponent, prehliadne zlyhania, ktoré žijú v prevádzke.
Prevádzkové monitorovanie tiež potrebuje prahy a vlastníkov. Kto je upozornený, keď zlyhá aktuálnosť zdrojov. Čo sa stane, ak miera prepísaní stúpne. Ktorá úroveň odchýlok spustí preskúmanie. Ktorý vzor odvolaní pozastaví automatizáciu. Ktoré zvýšenie nákladov si vyžaduje preskúmanie architektúry. Ktorá závažnosť incidentu si vyžaduje komunikáciu s dotknutými ľuďmi. Dashboard bez pravidiel reakcie je obraz s číslami.
Najlepšie monitorovacie slučky zahŕňajú používateľov. Používatelia vedia, kedy systém uľahčuje nesprávnu vec, kedy je vysvetlenie zbytočné, kedy sa objaví nový typ prípadu alebo kedy sa pracovný postup obchádza. Zabezpečte spätnú väzbu blízko k práci. Považujte ju za prevádzkový signál, nie za náladu. Ľudia najbližšie k práci sú často prví, ktorí zistia odchýlky, hoci málokedy majú príslušný titul.
Reakcia na incidenty nie je voliteľná len preto, že je model šikovný
Incidenty s AI nie sú vždy výbuchy. Môžu byť tiché: nesprávne zhrnutia opakované týždeň, index vyhľadávania, ktorému chýba trieda dokumentov, klasifikátor driftujúci pre jeden región, zmena promptu meniaca tón v regulovaných odpovediach, model odmietajúci príliš málo, model odmietajúci príliš veľa, fronta plná okrajových prípadov, za ktoré nikto nezodpovedá. Tiché incidenty sú stále incidentmi, ak ovplyvňujú ľudí alebo povinnosti.
Prevádzková pripravenosť zahŕňa playbooky pre incidenty. Čo sa považuje za incident s AI. Kto ho môže vyhlásiť. Ako sa systém pozastaví. Ktoré dôkazy sa uchovajú. Ktoré rozhodnutia si vyžadujú preskúmanie. Ktorí používatelia sú informovaní. Ktorý prístup dodávateľa je potrebný a ohraničený. Ako sa vykoná rollback. Ako sa kontaktujú dotknutí ľudia. Ako sa incident uzavrie. Ak je odpoveď, že zhromaždíme tím, tím už mešká.
Runbooky by sa mali nacvičovať. Plán obnovy, ktorý nikdy nič neobnovil, je dokument nádeje. Rollback modelu, ktorý nikto nevyskúšal, je dekoratívny núdzový východ. Proces odvolania, ktorý nedokáže získať príslušný záznam o rozhodnutí, je divadlo. Cvičenia odhalia nudné problémy skôr, než sa stanú verejnými: chýbajúce oprávnenia, nejasných vlastníkov, zastaranú dokumentáciu, dashboardy, ktoré nikto nemôže otvoriť, a jednu kľúčovú osobu na dovolenke vo Frízsku s výbornými hranicami.
Preskúmanie po incidente by sa malo zamerať na učenie systému. Ktoré nebezpečenstvo sme prehliadli. Ktorý signál bol ignorovaný. Ktorá kontrola zlyhala. Ktorý ľudský obchádzkový postup zabránil zhoršeniu situácie. Ktorá metrika skryla problém. Ktorý záznam o rozhodnutí bol neúplný. Ktorá zmena je potrebná. Obviňovať najbližšieho operátora je emocionálne efektívne a prevádzkovo slabé. Incidenty sú drahí učitelia. Aspoň si prečítajte lekciu.
Riadenie zmien je miesto, kde sa piloty stávajú vážnymi
Systémy AI sa menia často. Modely sa aktualizujú. Prompty sa posúvajú. Zdroje vyhľadávania sa rozširujú. Politiky sa presúvajú. Používatelia sa prispôsobujú. Dátové pipelines sa menia. Komponenty dodávateľov sa vyvíjajú. Pilot dokáže absorbovať zmeny pozornou pozornosťou. Prevádzka potrebuje riadenie zmien. Nie byrokratické močiare, ale disciplinovanú cestu, ktorá sa pýta, čo zmena ovplyvňuje a ako organizácia zistí, že sa niečo pokazilo.
Každá podstatná zmena by mala uviesť dotknuté použitie, dôkazy, testy, vrátenie zmien, komunikáciu a vlastníka. Zmena promptu pri nenáročnom písaní návrhov môže vyžadovať rýchlu kontrolu a vzorkovanie. Zmena modelu pri odporúčaniach oprávnenosti môže vyžadovať vyhodnocovacie segmenty, tieňový beh, schválenie, kompatibilitu rozhodovacieho záznamu a kritériá vrátenia. Nový zdroj údajov môže vyžadovať kontrolu pôvodu, posúdenie ochrany súkromia a monitorovanie aktuálnosti. Dôležitá je primeranosť. Rovnako dôležité je nepredstierať, že všetky zmeny sú malé len preto, že úprava textu vyzerala malá.
Verzovanie je kľúčové. Rozhodnutia by mali vedieť, ktorá verzia modelu, promptu, zdroja údajov, politiky, prahu a rozhrania ich ovplyvnila. Bez verzovania organizácia nedokáže vysvetliť, prečo sa jeden prípad správal inak ako druhý. Nedokáže čisto vyšetriť odchýlky. Nedokáže s istotou vrátiť zmeny. Verzovanie nie je okrasná práca. Je to niť, ktorá umožňuje operačným tímom rozpliesť sveter bez toho, aby tvrdili, že sveter je šál.
Riadenie zmien tiež bráni rozširovaniu rozsahu. Ak chce tím použiť systém na novú činnosť, postup zmeny by sa mal opýtať, či existujúce vyhodnotenie, kontroly, dôkazy a vlastníctvo stále platia. Často neplatia. To neznamená nikdy. Znamená to nie náhodou.
Hodnotu treba merať po potlesku
Pilotné projekty často merajú hodnotu tam, kde je najľahšie ju vidieť: ušetrený čas, zlepšená presnosť, nájdené dokumenty, vytvorené návrhy, spokojní používatelia. Prevádzka musí merať hodnotu po potlesku. Klesla miera prepracovania. Zlepšila sa kvalita pri náročných prípadoch. Stalo sa pracovné zaťaženie zamestnancov udržateľným. Dostávali používatelia jasnejšie služby. Zmenili sa odvolania. Posunuli sa náklady alebo sa len presunuli. Znížil systém riziko alebo ho skryl. Stali sa rozhodnutia ľahšie vysvetliteľnými.
Ušetrený čas je obzvlášť zradný. Ak nástroj ušetrí desať minút pri písaní návrhu, ale pridá osem minút kontroly, dve minúty opravy a neskôr znovuotvorený prípad, hodnota nie je desať minút. Ak šetrí čas špecialistom tým, že presúva prácu na juniorov, hodnota môže byť ilúziou personálneho obsadenia. Ak zrýchľuje jednoduché prípady, ale zhoršuje okrajové, priemer sa môže zlepšiť a prevádzka sa môže stať menej spravodlivou. Hodnota si vyžaduje pohľad na celý pracovný postup.
Hodnota zahŕňa aj vyhnutú škodu. Odmietnutie, ktoré zabráni zlému rozhodnutiu, má hodnotu. Monitorovací alert, ktorý zachytí odchýlku, má hodnotu. Rozhodovací záznam, ktorý rýchlo vyrieši odvolanie, má hodnotu. Cesta vrátenia, ktorá obmedzí incident, má hodnotu. Tieto prínosy sa na pilotný slajd umiestňujú ťažšie, pretože vyzerajú ako veci, ktoré sa nestali. Prevádzka by ich napriek tomu mala započítať. Seriózne systémy často dokazujú svoju hodnotu tým, že zvyšujú pravdepodobnosť nudných týždňov.
Finančné vlastníctvo by malo odrážať celý obraz. Ak automatizácia šetrí čas jednému tímu a vytvára záťaž na kontrolu pre iný, obchodný prípad by mal ukázať oboje. Ak údržba predchádza budúcim incidentom, rozpočet by nemal zaobchádzať s údržbou ako s voliteľnou ozdobou. Zodpovedná prevádzka si vyžaduje účtovníctvo, ktoré sleduje prácu, nielen kód projektu.
Prevádzková kontrola
Skôr ako sa pilot stane prevádzkou, uskutočnite prevádzkovú kontrolu. Program by mal byť praktický. Aké presné použitie je schválené. Kto vlastní každú vrstvu. Ktoré zdroje údajov sú v rozsahu. Ktoré rozhodnutia potrebujú záznamy. Ktoré výstupy sú odporúčacie. Ktoré prípady sú vylúčené. Ktoré kontroly zastavia nebezpečnú činnosť. Ktoré metriky sú dôležité. Ktoré prahové hodnoty spúšťajú kontrolu. Ktorí ľudia sú vyškolení. Ktoré runbooky existujú. Ktorý návrat bol otestovaný. Ktorý rozpočet financuje údržbu.
Táto kontrola by mala zahŕňať ľudí blízkych práci. Operátorov, pracovníkov podpory, doménových expertov, vlastníkov rizík, vlastníkov údajov, bezpečnosť, právne oddelenie a dotknutých zástupcov používateľov, kde je to vhodné. Cieľom nie je vytvoriť dav. Cieľom je zabrániť pilotnému tímu, aby si pomýlil vlastnú pozornosť s prevádzkovým modelom. Ľudia, ktorí budú so systémom žiť, poznajú otázky, ktoré pilotný tím nenapadlo položiť.
Kontrola by mala mať možnosť povedať nie je pripravené. Nie ako trest, ale ako užitočný stav. Možno chýba cesta na opravu údajov. Možno sú záznamy dôkazov neúplné. Možno je ľudská kontrola príliš pomalá. Možno je povolené použitie vágne. Možno monitorovanie vidí nesprávne veci. Možno hodnotový prípad ignoruje prepracovanie. Nie je pripravené je lacnejšie pred spustením ako po vytvorení inštitucionálnej závislosti.
Keď kontrola povie pripravené, mala by povedať pripravené na čo. Pripravené na odporúčacie použitie v jednom pracovnom toku. Pripravené na obmedzenú produkciu so vzorkovaním. Pripravené na automatizovanú činnosť pod prahom následkov. Pripravené na širšie nasadenie po dvoch mesiacoch monitorovania. Pripravenosť nie je medaila. Je to podmienka spojená s použitím.
Ponaučenie
Prechod od AI pilotov k zodpovednej prevádzke nie je technický krok nasadenia. Je to prenos zodpovednosti. Otázka sa mení z funguje to na môžeme to vlastniť, keď to funguje, keď to zlyhá, keď sa to mení, keď sa na to ľudia spoliehajú a keď nás niekto požiada, aby sme to vysvetlili. To je oveľa lepšia otázka a menej pohodlná.
Piloty zostávajú hodnotné. Umožňujú organizáciám učiť sa rýchlo a lacno. Odhaľujú prísľub. Znižujú abstraktnú debatu. Pomáhajú tímom objaviť, čo by model, pracovný tok alebo rozhranie mohli robiť. Ale pilot nie je dôkaz prevádzkovej zodpovednosti. Je to pozvanie navrhnúť ju.
Zodpovedná prevádzka potrebuje povolené používanie, vlastníctvo, kontrolu nad dátami, monitorovanie, reakciu na incidenty, riadenie zmien, záznamy o dôkazoch, spätnú väzbu od používateľov, rozpočet a meranie hodnoty, ktoré sleduje celý pracovný postup. Potrebuje ľudí, ktorí vedia pozastaviť, opraviť, vysvetliť a zlepšiť. Potrebuje riadenie, ktoré funguje, aj keď nikto netlieska.
Pondelok príde. Vždy príde. Otázka je, či systém umelej inteligencie príde v pondelok ako úspešný pilot s fanúšikovským klubom, alebo ako zodpovedná prevádzka s prácou, ktorú treba urobiť.