Nuo AI pilotų iki atskaitingų operacijų
Pilotas, kuris vis laimėdavo
Pilotas buvo sėkmingas taip, kaip pilotai dažnai būna. Patalpa buvo maža, vartotojai draugiški, atvejai atrinkti, tiekėjo komanda dėmesinga, modelis elgėsi pakankamai gerai, o paskutinėje skaidrėje buvo procentas, dėl kurio visi pasilenkė į priekį. Asistentas sutrumpino dokumentų rengimo laiką. Klasifikatorius rado daugiau aktualių atvejų. Paieškos įrankis iškeldavo dokumentus, kurių egzistavimą žmonės buvo pamiršę. Išvada buvo akivaizdi: plėsti.
Tada pilotas susidūrė su pirmadieniu. Pirmadienį trūko duomenų, personalas buvo pavargęs, pasitaikė kraštinių atvejų, senų taisyklių, sutrikusių vartotojų, eilių spaudimas, lėtas tinklas, vadovas, prašantis ataskaitos iki vidurdienio, ir vienas atvejis, kuris netilpo į jokią kategoriją, kurią pilotas buvo naudojęs. Pirmadienį programinė įranga nustoja būti galimybe ir tampa atsakomybe. Tai taip pat metas, kai daugelis AI pilotų tyliai praranda žavesį, kurį turėjo toje patalpoje.
Atotrūkis tarp piloto ir veiklos daugiausia nėra modelio kokybės klausimas. Tai nuosavybė. Pilote išimtys yra įdomios. Veikloje prie išimčių pritvirtinti klientai, pacientai, piliečiai, kolegos, sąskaitos ir terminai. Pilote projekto komanda atidžiai stebi. Veikloje sistemą turi stebėti žmonės, turintys kitų darbų. Pilote sėkmė reiškia, kad idėja nusipelno dėmesio. Veikloje sėkmė reiškia, kad organizacija gali ja pasikliauti neapsimesdama, kad realybė tapo lengvesnė.
Atskaitinga veikla yra suaugusi AI piloto forma. Joje apibrėžiama, kam priklauso darbo eiga, kuriuos veiksmus sistema gali palaikyti, kokių įrodymų reikalaujama, kaip aptinkamos nesėkmės, kada sistema pristabdoma, kaip žmonės apskundžia sprendimus, kaip tvirtinami pakeitimai ir kaip matuojama vertė, kai naujumas jau išblėsęs. Mažiau įdomu nei pilotas, be abejo. Taip pat mažiau tikėtina, kad sukurs gražiai finansuojamą netvarką.
Pilotui leidžiama būti neišsamiam
Geras pilotas yra sąmoningai neišsamus. Jis tikrina klausimą. Ar šis modelis gali pakankamai gerai klasifikuoti šiuos dokumentus, kad būtų galima tęsti. Ar šis asistentas gali sutrumpinti dokumentų rengimo laiką. Ar šis paieškos būdas gali iškelti aktualių įrodymų. Ar šis planavimo metodas gali pagerinti grafiką. Pilotas turėtų būti ribotas, pakankamai greitas, kad iš jo būtų galima pasimokyti, ir sąžiningas dėl sąlygų, kuriomis jis vyko. Jis neturėtų apsimesti veikiančiu modeliu su mažiau susirinkimų.
The problem starts when pilot evidence is promoted beyond its jurisdiction. A selected case set becomes proof of production quality. Friendly users become evidence of adoption. Time saved in a controlled workflow becomes a business case for a messy department. A vendor-supported integration becomes proof that internal teams can operate. A dashboard watched daily by the project team becomes evidence that monitoring exists. The pilot did not lie. The organisation over-interpreted.
Pilots often avoid the hardest questions because that is how pilots move quickly. Who owns the model after launch. Who updates the prompt. Who handles an appeal. What happens when data is missing. What happens when the model refuses. Which cases must never be automated. How is drift detected. How is the system paused. What is the rollback path. Which budget pays for maintenance. These questions can wait during exploration. They cannot wait during operations.
There is no shame in a pilot being incomplete. There is shame in calling it ready because it was charming. A pilot earns the next phase when it produces learning, not when it produces enthusiasm. Enthusiasm is cheap to generate in a controlled room. Operations requires a different currency.
Allowed use is the first operational decision
Before scaling an AI system, define the allowed use. Not in vague language like improve productivity or support decision making. Name the action. Draft internal notes. Summarise evidence for review. Rank cases for attention. Recommend a route. Approve a low-risk transaction. Refuse a request. Send a message. Each verb carries a different consequence. Operations cannot govern a mist.
Allowed use should include boundaries. Which data sources may be used. Which cases are out of scope. Which confidence or evidence threshold is required. Which actions require human approval. Which actions are advisory only. Which outputs can leave the organisation. Which users may see them. Which decisions require a preserved record. The boundary is not a legal flourish. It is the map operators use when the system meets a case the pilot did not invite.
This is especially important because AI systems tend to expand by convenience. A tool that drafts internal summaries starts drafting customer replies. A classifier used for triage starts influencing eligibility. A search assistant used by experts starts answering novices. A model that was evaluated in English is used on translated material. Nobody necessarily announces a new use. It just becomes helpful in a new place. Helpful is not the same as authorised.
Accountable operations require a scope register that is actually used. It should connect use, consequence, evidence, owner, controls, monitoring, and review. When someone asks whether the system can support a new action, the answer should come through the register and a change process, not through a corridor conversation with a deadline.
Nuosavybė turi išlikti ir pasibaigus projekto komandos darbui
Pilotus dažnai palaiko ypatinga žmonių grupė, kuri supranta kontekstą, atsimena išimtis ir greitai atsako į klausimus, nes kalendorius dar kvepia projektu. Veikla negali tuo pasikliauti. Žmonės keičiasi. Tiekėjai išeina. Rėmėjai pasitraukia. Entuziastingas analitikas gauna paaukštinimą, kas yra puiku, kol visi nesupranta, kad užklausų biblioteka daugiausia buvo jo galvoje.
Veiklos nuosavybei reikia vaidmenų, o ne didvyrių. Verslo savininkas atsako už tikslą ir priimtiną riziką. Duomenų savininkas atsako už šaltinių kokybę, taisymą ir kilmę. Techninis savininkas atsako už diegimą, našumą, saugumą ir integraciją. Modelio savininkas atsako už vertinimą, stebėseną ir pakeitimus. Veiklos savininkas atsako už veiklos vadovus, palaikymą, incidentų valdymą ir naudotojų atsiliepimus. Valdysenos savininkas atsako už įrodymus, peržiūrą ir atitiktį leidžiamam naudojimui. Mažose organizacijose vienas asmuo gali eiti kelis vaidmenis. Vaidmenims vis tiek reikia pavadinimų.
Nuosavybei taip pat reikia įgaliojimų. Neužtenka kam nors priskirti atskaitomybę, kartu atimant galimybę sustabdyti darbo eigą, reikalauti įrodymų, atmesti pakeitimą, skirti priežiūros laiko ar didinti rizikos lygį. Tai ne nuosavybė. Tai dekoratyvus kaltės saugojimas. Veikla su atskaitomybe reikalauja įgaliojimų, lygių atsakomybei.
Biudžetas yra nuosavybės dalis. Pilotai dažnai turi specialų finansavimą. Veiklai reikia priežiūros finansavimo: stebėsenos, pakartotinio mokymo ar vertinimo, palaikymo, naudotojų mokymo, duomenų kokybės taisymų, saugumo peržiūros, incidentų pratybų ir periodinės valdysenos. Jei verslo atvejis finansuoja tik paleidimą, tai nėra verslo atvejis veiklai. Tai paleidimo vakarėlis su sąskaitomis, paslėptomis po staltiese.
Gamybiniai duomenys nėra pilotų duomenys su daugiau eilučių
Gamybiniai duomenys turi savo būdą. Jie vėluoja, būna neišsamūs, pasikartojantys, išversti, ranka taisyti, neteisingai klasifikuoti, komitetų pervadinti, formuojami paskatų ir kartais įvedami žmogaus, kuriam ta diena nesisekė. Pilotų duomenų rinkiniai dažnai būna švaresni, nes kažkas juos atrinko, išvalė ar bent kelias savaites jais rūpinosi. Šis skirtumas svarbesnis, nei komandos tikisi.
Duomenų nuosavybė operacijose turi apimti naujumą, kilmę, taisymo teises, trūkumus, nuokrypį, prieigą, saugojimo laiką ir išvestinius duomenis. Dirbtinio intelekto sistemos kuria išvestinę medžiagą: įterptis, santraukas, balus, etiketes, požymius, talpyklas ir atsiliepimus. Tai gali paveikti būsimus sprendimus. Jei niekam jie nepriklauso, operacija įgyja antrą duomenų nuosavybės sluoksnį, kuris yra mažiau matomas nei pirmasis, o kartais ir įtakingesnis. Labai efektyvu, jei tikslas yra netikėtumas.
Operacijų stebėsena todėl turėtų stebėti daugiau nei modelio tikslumą. Stebėkite šaltinių naujumą, trūkstamus laukus, neįprastus pasiskirstymus, paieškos aprėptį, dublikatus, kalbos pokyčius, vartotojų elgseną, pakeitimų priežastis, skundų nagrinėjimo rezultatus, delsą ir sąnaudas. Modelis gali būti techniškai tvarkingas, o duomenys aplink jį tuo metu jau nebereiškia to, ką reiškė bandomojo laikotarpio metu. Sistema nežino, kad bandomasis laikotarpis baigėsi. Ji tiesiog gauna įvestis.
Taisymo keliai taip pat svarbūs. Kai vartotojas pastebi, kad šaltinis klaidingas, ar šaltinį galima ištaisyti. Ar išvestiniai duomenys atnaujinami. Ar sprendimo įraše matoma sena būsena. Ar ištaisytas atvejis moko modelį ar darbo eigą. Jei taisymas keičia tik matomą įrašą, o paslėpti požymiai lieka pasenę, operacija tampa senų klaidų muziejumi su šviežiais dažais.
Stebėsena turi suprasti, ką reiškia veiksmas
Daugelis dirbtinio intelekto stebėsenos planų prasideda techninėmis priemonėmis: veikimo laikas, delsa, klaidų dažnis, žetonų naudojimas, modelio balas, nuokrypio metrika. Jos yra būtinos, bet nepakankamos. Atskaitingos operacijos stebi veiksmą, kurį sistema palaiko. Jei sistema nukreipia atvejus, stebėkite klaidingus nukreipimus, eilės padarinius, specialistų perkrovą, uždelstą eskalavimą ir vartotojų pakeitimus. Jei ji rengia atsakymų juodraščius, stebėkite taisymo pastangas, klientų sumišimą, politikos pažeidimus ir pakartotinius pakeitimus. Jei ji rekomenduoja sprendimus, stebėkite skundus, sprendimų pakeitimus, pogrupių rezultatus ir įrodymų spragas.
Stebėsenos klausimas yra ne tik ar modelis veikia. Tai ar darbo eiga vis dar verta pasitikėjimo. Modelis gali išlikti stabilus, kol keičiasi politika. Delsa gali būti puiki, o įrodymų kokybė kristi. Tikslumas gali būti aukštas vidutiniškai, o viena atvejų rūšis žlugti. Sąnaudos gali mažėti, o perdirbimas kitur augti. Stebėsena, kuri mato tik komponentą, praleis gedimus, gyvenančius operacijoje.
Operacijų stebėsenai taip pat reikia slenksčių ir atsakingų asmenų. Kas įspėjamas, kai šaltinio naujumas nepavyksta. Kas nutinka, jei pakeitimų dažnis išauga. Koks nuokrypio lygis sukelia peržiūrą. Koks skundų modelis sustabdo automatizavimą. Koks sąnaudų padidėjimas reikalauja architektūros peržiūros. Koks incidento sunkumas reikalauja informuoti paveiktus žmones. Skydelis be atsako taisyklių yra paveikslas su skaičiais.
Geriausios stebėsenos grandinės apima vartotojus. Vartotojai žino, kada sistema palengvina neteisingą dalyką, kada paaiškinimas yra nenaudingas, kada atsiranda nauja atvejų rūšis arba kada darbo eiga yra žaidžiama. Padarykite atsiliepimus artimus darbui. Traktuokite juos kaip operacinį signalą, o ne nuomonę. Žmonės, artimiausi darbui, dažnai yra pirmieji nuokrypio detektoriai, nors retai gauna tokį titulą.
Reagavimas į incidentus nėra pasirenkamas vien todėl, kad modelis protingas
Dirbtinio intelekto incidentai ne visada būna sprogimai. Jie gali būti tylūs: savaitę kartojamos klaidingos santraukos, paieškos indekse trūkstama dokumentų klasė, viename regione dreifuojantis klasifikatorius, pakeistas raginimas, pakeitęs toną reguliuojamuose atsakymuose, modelis, atsisakantis per mažai, modelis, atsisakantis per daug, eilė, pilna kraštinių atvejų, kurių niekas neprisiima. Tylūs incidentai vis tiek yra incidentai, jei jie paveikia žmones ar įsipareigojimus.
Veiklos pasirengimas apima incidentų veiksmų planus. Kas laikoma dirbtinio intelekto incidentu. Kas gali jį paskelbti. Kaip sistema sustabdoma. Kokie įrodymai išsaugomi. Kokie sprendimai turi būti peržiūrėti. Kokie naudotojai informuojami. Kokia tiekėjo prieiga reikalinga ir apribota. Kaip atliekamas atšaukimas. Kaip susisiekiama su paveiktais žmonėmis. Kaip incidentas uždaromas. Jei atsakymas yra surinksime komandą, komanda jau vėluoja.
Veiksmų planai turi būti repetuojami. Atkūrimo planas, kuris niekada neatkūrė, yra vilties dokumentas. Modelio atšaukimas, kurio niekas neišbandė, yra dekoratyvinis avarinis išėjimas. Skundų procesas, kuris negali atgauti atitinkamo sprendimo įrašo, yra teatras. Pratybos atskleidžia nuobodžias problemas, kol jos dar netapo viešomis: trūkstamus leidimus, neaiškius savininkus, pasenusią dokumentaciją, niekam nepasiekiamas informacijos suvestines ir vieną svarbų žmogų, atostogaujantį Fryzijoje su puikiomis ribomis.
Poincidentinė peržiūra turėtų sutelkti dėmesį į sistemos mokymąsi. Kokio pavojaus nepastebėjome. Koks signalas buvo ignoruotas. Kokia kontrolė žlugo. Koks žmogiškasis aplinkkelis neleido situacijai pablogėti. Kokia metrika paslėpė problemą. Koks sprendimo įrašas buvo neišsamus. Koks pakeitimas reikalingas. Kaltinti artimiausią operatorių yra emociškai efektyvu ir veiklos požiūriu silpna. Incidentai yra brangūs mokytojai. Bent jau perskaitykite pamoką.
Pakeitimų valdymas yra ten, kur bandomosios versijos tampa rimtos
Dirbtinio intelekto sistemos keičiasi dažnai. Modeliai atnaujinami. Raginimai keičiasi. Paieškos šaltiniai plečiasi. Politikos keičiasi. Naudotojai prisitaiko. Duomenų vamzdynai keičiasi. Tiekėjų komponentai evoliucionuoja. Bandomoji versija gali sugerti pakeitimus dėl didelio dėmesio. Veiklai reikia pakeitimų valdymo. Ne biurokratinės pelkės, o disciplinuoto kelio, kuris klausia, ką pakeitimas paveikia ir kaip organizacija sužinos, jei kas nors nutiks ne taip.
Kiekvienas esminis pakeitimas turėtų nurodyti paveiktą naudojimo atvejį, įrodymus, testus, atšaukimą, komunikaciją ir atsakingą asmenį. Pakeitus raginimą mažos rizikos juodraščiams, gali pakakti greitos peržiūros ir atrankos. Pakeitus modelį, skirtą tinkamumo rekomendacijoms, gali prireikti vertinimo segmentų, šešėlinio paleidimo, patvirtinimo, sprendimų registro suderinamumo ir atšaukimo kriterijų. Naujas duomenų šaltinis gali reikalauti kilmės peržiūros, privatumo vertinimo ir naujumo stebėsenos. Proporcingumas svarbus. Taip pat svarbu neapsimesti, kad visi pakeitimai yra maži vien todėl, kad teksto pakeitimas atrodė mažas.
Versijavimas yra itin svarbus. Sprendimai turėtų žinoti, koks modelis, raginimas, duomenų šaltinis, politika, ribinė reikšmė ir sąsajos versija juos suformavo. Be versijavimo organizacija negali paaiškinti, kodėl vienas atvejis elgėsi kitaip nei kitas. Ji negali švariai ištirti nuokrypių. Ji negali užtikrintai atšaukti pakeitimų. Versijavimas nėra prabangus darbas. Tai siūlas, leidžiantis operacijoms išnarplioti megztinį neapsimetant, kad megztinis yra šalikas.
Pakeitimų valdymas taip pat apsaugo nuo apimties išplėtimo. Jei komanda nori naudoti sistemą naujam veiksmui, pakeitimų kelias turėtų klausti, ar galioja esamas vertinimas, kontrolės priemonės, įrodymai ir atsakomybė. Dažnai nebegalioja. Tai nereiškia niekada. Tai reiškia neatsitiktinai.
Vertė turi būti matuojama po plojimų
Bandomieji projektai dažnai matuoja vertę ten, kur ją lengviausia pamatyti: sutaupytą laiką, pagerintą tikslumą, rastus dokumentus, parengtus juodraščius, patenkintus vartotojus. Operacijos turi matuoti vertę po plojimų. Ar sumažėjo perdirbimo darbų. Ar pagerėjo kokybė sudėtingais atvejais. Ar darbuotojų krūvis tapo tvarus. Ar vartotojai gavo aiškesnes paslaugas. Ar pasikeitė skundai. Ar sąnaudos pasikeitė ar tik persikėlė. Ar sistema sumažino riziką ar ją paslėpė. Ar sprendimus tapo lengviau paaiškinti.
Sutaupytas laikas ypač apgaulingas. Jei įrankis sutaupo dešimt minučių rengiant juodraštį, bet prideda aštuonias minutes tikrinimui, dvi minutes taisymui ir vėliau atnaujintą bylą, vertė nėra dešimt minučių. Jei įrankis taupo specialistų laiką perkeldamas darbą jaunesniems darbuotojams, vertė gali būti personalo iliuzija. Jei įrankis pagreitina lengvus atvejus, bet pablogina kraštinius atvejus, vidurkis gali pagerėti, o operacija gali tapti mažiau teisinga. Vertei reikia viso darbo srauto vaizdo.
Vertė taip pat apima išvengtą žalą. Atsisakymas, užkertantis kelią blogam sprendimui, turi vertę. Stebėsenos įspėjimas, pastebintis nuokrypį, turi vertę. Sprendimų įrašas, leidžiantis greitai išspręsti skundą, turi vertę. Atšaukimo kelias, apribojantis incidentą, turi vertę. Šias naudas sunkiau įtraukti į bandomojo projekto skaidrę, nes jos atrodo kaip dalykai, kurie neįvyko. Operacijos vis tiek turėtų jas įskaityti. Rimtos sistemos dažnai įrodo savo vertę padarydamos nuobodžias savaites labiau tikėtinas.
Finansinė atsakomybė turėtų atspindėti visą vaizdą. Jei automatizavimas sutaupo vienos komandos laiko ir sukuria peržiūros krūvį kitai, verslo atvejis turėtų parodyti abu. Jei priežiūra apsaugo nuo būsimų incidentų, biudžetas neturėtų vertinti priežiūros kaip pasirenkamos puošmenos. Atskaitingoms operacijoms reikia apskaitos, kuri seka darbą, o ne tik projekto kodą.
Veiklos peržiūra
Prieš bandomajam projektui tampant eksploatacija, atlikite veiklos peržiūrą. Darbotvarkė turėtų būti praktiška. Koks tikslus naudojimas patvirtintas. Kas atsako už kiekvieną lygmenį. Kurie duomenų šaltiniai įtraukti. Kuriems sprendimams reikia įrašų. Kurie rezultatai yra patariamieji. Kurie atvejai neįtraukti. Kurie valdikliai sustabdo nesaugų veiksmą. Kurie rodikliai svarbūs. Kurios ribos sukelia peržiūrą. Kurie žmonės apmokyti. Kurie veiksmų vadovai egzistuoja. Kuris atšaukimas išbandytas. Kuris biudžetas finansuoja priežiūrą.
Į šią peržiūrą turėtų būti įtraukti žmonės, artimi darbui. Operatoriai, pagalbos personalas, srities ekspertai, rizikos savininkai, duomenų savininkai, saugumo, teisės ir, kai tinka, paveiktų vartotojų atstovai. Tikslas nėra sukurti minią. Tikslas yra neleisti bandomojo projekto komandai supainioti savo paties dėmesio su veiklos modeliu. Žmonės, kurie gyvens su sistema, žino klausimus, kurių bandomasis projektas nežinojo, kaip užduoti.
Peržiūra turėtų turėti teisę pasakyti „nepasiruošta“. Ne kaip bausmę, o kaip naudingą būseną. Galbūt trūksta duomenų taisymo kelio. Galbūt įrodymų įrašai neišsamūs. Galbūt žmogaus peržiūra per lėta. Galbūt leidžiamas naudojimas neaiškus. Galbūt stebėsena mato ne tuos dalykus. Galbūt vertės atvejis ignoruoja papildomą darbą. „Nepasiruošta“ yra pigiau prieš paleidimą nei po institucinės priklausomybės susiformavimo.
Kai peržiūra sako „pasiruošta“, ji turėtų pasakyti kam. Pasiruošta patariamajam naudojimui vienoje darbo eigoje. Pasiruošta ribotai gamybai su atranka. Pasiruošta automatizuotam veiksmui žemiau pasekmių ribos. Pasiruošta platesniam diegimui po dviejų mėnesių stebėsenos. Pasirengimas nėra medalis. Tai sąlyga, pridedama prie naudojimo.
Pamoka
Perėjimas nuo dirbtinio intelekto bandomųjų projektų prie atskaitingos eksploatacijos nėra techninis diegimo žingsnis. Tai atsakomybės perdavimas. Klausimas keičiasi iš „ar tai gali veikti“ į „ar galime tai valdyti, kai veikia, kai žlunga, kai keičiasi, kai žmonės tuo pasikliauja ir kai kas nors prašo mums tai paaiškinti“. Tai daug geresnis klausimas ir mažiau patogus.
Bandomieji projektai išlieka vertingi. Jie leidžia organizacijoms mokytis greitai ir pigiai. Jie atskleidžia pažadus. Jie sumažina abstrakčias diskusijas. Jie padeda komandoms atrasti, ką modelis, darbo eiga ar sąsaja galėtų daryti. Tačiau bandomasis projektas nėra eksploatacinės atsakomybės įrodymas. Tai kvietimas ją sukurti.
Už atskaitingą veiklą reikia leistino naudojimo, nuosavybės, duomenų kontrolės, stebėsenos, reagavimo į incidentus, pokyčių valdymo, įrodymų įrašų, vartotojų atsiliepimų, biudžeto ir vertės matavimo, kuris apima visą darbo eigą. Reikia žmonių, kurie gali sustabdyti, taisyti, paaiškinti ir tobulinti. Reikia valdysenos, kuri veikia tada, kai niekas neploja.
Pirmadienis ateis. Jis visada ateina. Klausimas, ar pirmadienį AI sistema atvyks kaip sėkmingas bandomasis projektas su gerbėjų klubu, ar kaip atskaitinga operacija su darbu, kurį reikia atlikti.