Paslėpta tikimybinių darbo eigų kaina
Sąskaita, kurios bandomajame etape niekas nepastebėjo
Bandomasis etapas atrodė pigus. Tai buvo pirmoji problema. Komanda prie įprasto darbo srauto prijungė dirbtinio intelekto žingsnį: gaunami dokumentai buvo klasifikuojami, sukuriama trumpa santrauka, parenkamas rekomenduojamas maršrutas, o žmogus peržiūrėtojas jį patvirtindavo arba pakeisdavo. Demonstracija buvo tvarkinga. Modelis atrodė kompetentingas. Sąskaita už žetonus buvo mažesnė nei biudžetas pietums, todėl visi jautėsi finansiškai subrendę. Kažkas ištarė žodį „keičiamo dydžio“, ir kambaryje trumpam pasidarė pavojinga.
Po trijų mėnesių pokalbis apie išlaidas pasikeitė. Sąskaita už žetonus vis dar nebuvo įspūdinga. Paslėptos išlaidos buvo kitur. Peržiūrėtojai skirdavo papildomų minučių ribinių rezultatų tikrinimui. Atsirado pakartotinių paleidimų, nes tas pats įvestis kartais pateikdavo pakankamai kitokį atsakymą. Išimčių eilės augo. Duomenų komandos tyrė, kodėl vienas dokumentų tipas klaidino klasifikatorių. Operacijų skyrius pridėjo atranką. Teisės skyrius paprašė įrodymų dėl ginčijamų atvejų. Vadovai klausė, kodėl ciklo laikas tapo mažiau nuspėjamas. Inžinieriai pridėjo raginimų, paskui apsaugų, paskui atsarginių variantų, paskui stebėseną, o paskui skaičiuoklę, kurios niekas nemėgo, bet visi atidarydavo. Darbo srautas nesprogo. Jis įgijo kintamumą.
Tai yra paslėpta tikimybinių darbo srautų kaina. Modelio iškvietimas yra matomas vartojimo vienetas, tačiau veiklos sąnaudas lemia neapibrėžtumas aplink tą iškvietimą. Tikimybinis komponentas gali būti naudingas, galingas ir ekonomiškai pagrįstas. Jis taip pat gali perkelti išlaidas į peržiūrą, derinimą, įrodymus, palaikymą, eilių projektavimą, incidentų analizę, kokybės matavimą ir žmogaus dėmesį. Jei šios išlaidos nėra įtrauktos į darbo srauto projektą, jos vis tiek atsiranda, paprastai su mažiau kantrybės.
Tradicinės darbo srautų sistemos nėra tobulos. Jos žlunga, nukrypsta ir nustebina žmones savo nuobodžiais būdais. Tačiau jos dažnai turi naudingą savybę: tas pats įvestis, būsena ir taisyklė paprastai duoda tą patį rezultatą. Tikimybinės sistemos silpnina šią prielaidą. Kartais tai ir yra esmė. Jos tvarko dviprasmybę, kalbą, vaizdus, netvarkingus dokumentus ir neaiškius ketinimus. Gerai. Kaina ta, kad operacijos turi nustoti apsimesti, jog neapibrėžtumas yra demonstracijos detalė. Tai yra pirmos eilės įvestis į išlaidų modelį.
Kintamumas nėra įgyvendinimo detalė
Probabilistiniai komponentai įneša kintamumą keliose vietose. Modelis gali pateikti šiek tiek kitokią formuluotę. Klasifikatorius ribinį atvejį gali priskirti vienai ar kitai slenksčio pusei. Atgavimo sistema po indekso atnaujinimo gali grąžinti kitą šaltinių rinkinį. Apibendrintuvas gali praleisti detalę, kuri vėliau buvo svarbi vertintojui. Įrankius naudojantis agentas gali pasirinkti kitokią iškvietimų seką. Nė vienas iš šių atvejų savaime nėra klaida. Tai tiesiog kitokia medžiaga nei deterministinis kodas. Traktuoti tai kaip įprastą kodą vien todėl, kad jis turi API, yra kategorijos klaida su sąskaitomis.
Kintamumas turi veiklos pasekmių. Jis didina atrankos ir peržiūros poreikį. Jis apsunkina incidentų atkūrimą. Jis apsunkina našumo matavimą, nes vidutinė kokybė gali paslėpti kraštinių atvejų nestabilumą. Jis sukelia nesutarimus tarp naudotojų, mačiusių skirtingus rezultatus. Jis gali padaryti vėlesnes sistemas trapias, kai jos tikisi stabilios struktūros. Jis gali paversti paprastą paslaugų lygio susitarimą pokalbiu apie tikimybių skirstinius, o tai puikus būdas sužinoti, kam salėje matematika tikrai patinka.
Pirmoji sąnauda yra sprendimų trintis. Kai rezultatai kinta, žmonės skiria laiko nuspręsti, ar tas kintamumas svarbus. Juodraštinis el. laiškas, kuriame tas pats pasakyta kitais žodžiais, gali būti priimtinas. Medicinos suvestinė, kurioje praleistas vaistas, ne. Palaikymo klasifikatorius, kuris vieną užklausą nukreipia kitaip, gali būti tinkamas. Išmokų tinkamumo paaiškinimas, kuris keičia savo motyvavimą, ne. Darbo eiga turi turėti tolerancijos modelį: koks kintamumas yra nekenksmingas, koks reikalauja peržiūros, o koks yra draudžiamas.
Antroji sąnauda yra atkuriamumas. Jei klientas, pilietis, auditorius ar inžinierius klausia, kodėl priimtas toks sprendimas, organizacija turi atkurti reikiamą kontekstą: modelio versiją, užklausą, atgavimo rinkinį, įvestį, politiką, parametrus, įrankių rezultatus ir žmogaus veiksmą. Be tokio įrašo tyrimas tampa reginiu. Kažkas paleidžia užklausą iš naujo, gauna kitą atsakymą, ir visi salėje skaudžiai išmoksta, kad bandymas dar kartą nėra įrodymas.
Pakartotiniai bandymai nėra nemokami vien todėl, kad jie automatizuoti
Pakartotiniai bandymai iš kodo vidaus atrodo pigūs. Jei modelis pateikia silpną atsakymą, kvieskite jį dar kartą. Jei klasifikatorius neaiškus, paprašykite kito pavyzdžio. Jei JSON atsakymas netinkamas, pataisykite jį. Jei įrankio iškvietimas nepavyksta, bandykite kitą kelią. Darbą atlieka mašina, todėl instinktas yra traktuoti pakartotinius bandymus kaip inžinerinius klijus. Probabilistinėje darbo eigoje pakartotiniai bandymai yra politika. Jie nusprendžia, kiek kintamumo sistema gali paslėpti, kol jį pamato žmogus.
Yra gerų priežasčių bandyti dar kartą. Laikinas gedimas neturėtų sustabdyti proceso. Netinkamą atsakymą dažnai galima ištaisyti. Antrojo ėjimo paprašymas gali pagerinti kokybę. Tačiau pakartotiniai bandymai taip pat sukuria sąnaudas ir dviprasmybę. Kuris rezultatas laikomas įrašu. Ar laikome visus bandymus. Ar vėlesni bandymai perrašo ankstesnius. Ar rodome vertintojui nestabilumą. Ar pakartotiniai bandymai šališkai linksta prie įtikinamiau skambančių atsakymų. Ar bandome dar kartą tik pigius atvejus, netyčia sulėtindami svarbius. Ar skaičiuojame pakartotinius bandymus sąnaudų ir delsos biudžetuose. Kuklus pakartotinis bandymas turi daug nuomonių, kai tik pakviečiate jį į gamybą.
Pakartotiniai bandymai taip pat keičia paskatas. Jei komandos žino, kad sistema bandys tol, kol rezultatas atitiks numatomą formą, jos gali nepakankamai investuoti į įvesties kokybę, schemos dizainą, užklausos apribojimus ar deterministinį išankstinį apdorojimą. Pakartotinis bandymas tampa šluota. Šluotos yra naudingos. Pastato strategija, pagrįsta šlavimu, yra mažiau įspūdinga.
A better pattern is to classify retry reasons. Transient infrastructure failure is one category. Formatting repair is another. Low confidence is another. Policy conflict is another. Source conflict is another. Each category needs limits, records, and escalation rules. A retry that hides uncertainty from the user should be treated differently from a retry that merely recovers from a network hiccup. The cost is not only compute. It is the cost of deciding which uncertainty the organisation is comfortable hiding.
The exception queue is the real architecture diagram
Every probabilistic workflow eventually reveals its real design through the exception queue. Not the happy path. The happy path is where diagrams go to look employable. The exception queue shows which cases the system does not understand, which inputs are dirty, which policies conflict, which users need support, which thresholds are wrong, and which promises were made too early.
If the exception queue is designed well, it becomes a learning surface. Cases are categorised, sampled, reviewed by the right roles, connected to source data fixes, tied to policy changes, and fed back into evaluation. If it is designed poorly, it becomes a swamp. Hard cases sit in a backlog. Reviewers invent local habits. Managers see only volume. Engineers see only aggregate failure. Users see delay. The model remains mysterious because the organisation hid its best evidence in operational sludge.
The cost of exceptions is not just the number of cases. It is their shape. A ten percent exception rate can be manageable if cases are quick, low risk, and easy to route. A two percent exception rate can be expensive if each case needs legal interpretation, domain review, customer contact, and evidence reconstruction. Average automation rate is therefore a suspicious metric. It tells you how much passed through the machine, not how much cost the machine displaced.
Exception design should be explicit. Define confidence bands. Define abstention. Define which conflicts pause the workflow. Define which roles can resolve which classes. Define maximum queue age. Define sample review for accepted cases, not only failed ones. Define what gets fixed when an exception repeats. Otherwise the organisation has not automated work. It has automated the creation of a second, less visible job.
Probabilistic output makes downstream systems negotiate
Programinės įrangos sistemos mėgsta sutartis. Laukas yra data. Būsena turi leidžiamas reikšmes. Suma turi tikslumą. Taisyklė turi šaką. Tikimybiniai rezultatai dažnai ateina kaip kalba, reitingas, pasitikėjimas ar iš dalies struktūruoti spėjimai. Tada žemyn srautinės sistemos derasi. Jos analizuoja. Jos tikrina. Jos taiso. Jos klausia dar kartą. Jos susieja neaiškias etiketes su tiksliomis būsenomis. Jos kuria atsarginius variantus. Kiekvienos derybos yra maža kaina. Pakankamai mažų kainų tampa architektūra.
Struktūruota išvestis padeda, bet nepašalina neapibrėžtumo. Modelis gali pateikti tinkamą JSON ir vis tiek pasirinkti neteisingą kategoriją. Jis gali užpildyti kiekvieną lauką ir vis tiek praleisti sąlygą. Jis gali nurodyti šaltinį ir vis tiek jį klaidingai suprasti. Schema pagauna formos klaidas. Ji neįrodo reikšmės. Tai dažni spąstai, nes formos klaidas mato mašinos, o reikšmės klaidas mato žmonės. Spėkite, kas taisoma pirmiausia.
Žemyn srautinės derybos taip pat keičia atsakomybę. Jei atvejis nukreipiamas neteisingai, nes modelio išvestis buvo neaiški, o integracijos sluoksnis spėjo, kam priklauso klaida. Modelio komandai. Platformos komandai. Proceso savininkui. Recenzentui. Duomenų komandai. Kiekvienas gali pateikti pagrįstą argumentą, ir būtent taip suprantate, kad veiklos modelio trūksta. Tikimybiniams darbo srautams reikia atsakomybės ties riba, kur neapibrėžtumas tampa sistemos būsena.
Vienas praktinis metodas yra atskirti pasitikėjimą, išsamumą ir pasekmes. Pasitikėjimas nurodo, kiek tikėtina išvestis. Išsamumas nurodo, ar yra reikiamų įrodymų. Pasekmės nurodo, kiek žalos gali sukelti neteisingas veiksmas. Didelio pasitikėjimo išvestis su trūkstamais įrodymais vis tiek gali reikalauti peržiūros. Mažo pasitikėjimo išvestis su mažomis pasekmėmis gali būti greitai nukreipta. Vidutinio pasitikėjimo išvestis su didelėmis pasekmėmis gali reikalauti eskalavimo. Darbo srautas neturėtų vertinti viso neapibrėžtumo kaip tos pačios geltonos spalvos.
Vertinimas yra pasikartojanti veiklos sąnauda
Daugelis komandų vertinimą laiko projekto etapu. Prieš paleidimą jos surenka testų rinkinį, paleidžia užklausas, palygina rezultatus, galbūt įvertina kokybę ir paskelbia pasirengimą. Tada ateina realybė su naujais dokumentais, naujais vartotojais, naujais kraštiniais atvejais, nauja kalba, nauja politika ir naujomis modelio versijomis. Vertinimo rinkinys pradeda senti. Kaip sūris, tik mažiau skanus ir labiau tikėtina, kad sukels susitikimą.
Tikimybiniams darbo srautams reikia pasikartojančio vertinimo. Tai reiškia kruopščiai atrinktus atvejus, priešiškus atvejus, naujausius gamybos pavyzdžius, regresijos rinkinius, srities peržiūrą, teisingumo patikras ten, kur tai aktualu, sąnaudų ir delsos stebėjimą bei testus, kurie paleidžiami, kai keičiasi užklausos, modeliai, paieškos indeksai, politikos ar šaltinio duomenys. Vertinimas nėra vienkartinis vartai. Tai veiklos biudžetas, skirtas žinoti, ar darbo srautas vis dar nusipelno srauto.
Šios sąnaudos stebina žmones, nes bandomasis projektas jas paslepia. Bandomojo projekto metu ekspertai yra arti sistemos. Jie neoficialiai pastebi problemas. Įvesties mišinys yra ribotas. Stakės yra kontroliuojamos. Gamyboje sistema tampa pakankamai nuobodi, kad ekspertai nustoja stebėti kiekvieną išvestį, ir būtent tada formalus vertinimas turi perimti. Tikimybinė sistema be pasikartojančio vertinimo yra mašina, kuri lėtai eikvoja pasitikėjimą, kol praneša apie veikimo laiką.
Vertinimas taip pat turi būti susietas su sprendimais. Jei kokybė krenta, kas gali sustabdyti. Jei delsa didėja, kas nusprendžia, ar sumažinti modelio dydį, sumažinti pakartotinius bandymus ar padidinti peržiūros pajėgumus. Jei naujas modelis pagerina vidutinį balą, bet pablogina kritinį pogrupį, kas atsisako atnaujinimo. Jei sąnaudos didėja, nes daugėja išimčių, kam priklauso sprendimas. Skydelis, rodantis nuosmukį be įgaliojimų veikti, yra tik brangi orų prognozė.
Žmogiškoji peržiūra turi eilių teorijos sąskaitą
Žmogiškoji peržiūra dažnai pridedama kaip raminanti frazė. Žmogus liks cikle. Puiku. Kuris žmogus, su kokia eile, kokiu kontekstu, kokia įgaliojimų apimtimi, kokiu tikslo laiku, kokiu eskalavimo keliu, kokiu nuovargio modeliu ir kokia atsarga, kai sistema penktadienį 16:45 atsiunčia per daug ribinių atvejų. Ciklas turi logistiką. Logistika turi sąnaudų. Sąnaudos turi žavų įprotį atsirasti po architektūros skaidrės.
Peržiūros pajėgumas nėra tiesinis. Nedidelis neaiškių atvejų padidėjimas gali sukelti didelį laukimo laiko padidėjimą, kai peržiūros komanda yra arti pajėgumo ribos. Eilių teorija žiauri, bet teisinga. Jei atvykimai tampa įvairesni, o aptarnavimo laikas įvairesnis, vėlavimai gali sparčiai augti. Tikimybiniai darbo srautai dažnai padidina abu: netolygesnį atvejų sudėtingumą ir įvairesnį peržiūros laiką. Organizacija gali tikėti, kad automatizavo aštuoniasdešimt procentų darbo, o likę dvidešimt procentų tyliai valdo paslaugų lygio susitarimą.
Peržiūros kokybė taip pat priklauso nuo konteksto. Jei peržiūrintieji mato tik galutinį atsakymą, jie turi rekonstruoti, kodėl jis atsirado. Jei jie mato šaltinius, pasitikėjimą, politiką, ankstesnius bandymus ir žinomus neaiškumus, jie gali veikti greičiau ir geriau. Jei jie matuojami tik pagal pralaidumą, jie išmoks per daug pasitikėti mašina arba per mažai jai priešintis. Žmogiškoji peržiūra nėra stebuklingas tirpiklis, užpilamas ant neaiškumo. Tai kvalifikuotas darbas, kuriam reikia dizaino.
Paslėpta sąnauda yra dėmesys. Žmonės negali be galo peržiūrėti neriboto neaiškumo. Nuovargis keičia standartus. Atsiranda vietiniai įpročiai. Vieni peržiūrintieji tampa griežti, kiti pragmatiški, treti rezignuoti. Darbo srautas pradeda duoti skirtingus rezultatus priklausomai nuo to, kas gavo atvejį. Tada tikimybinė sistema kaltinama dėl nenuoseklumo, kurį organizacija sustiprino peržiūros dizaine. Mašina tiekė dispersiją. Žmonės tiekė eilių dinamiką. Puikus duetas, jei tikslas yra audito skausmas.
Sąnaudų apskaitoje turi būti neaiškumas
Naudingas sąnaudų modelis tikimybiniams darbo srautams apima daugiau nei modelio iškvietimus. Jis apima įvesties paruošimą, gavimą, pakartotinius bandymus, validaciją, peržiūros laiką, išimčių tvarkymą, vertinimą, įrodymų saugojimą, incidentų analizę, stebėjimą, vartotojų palaikymą, raginimų ir politikos priežiūrą, duomenų taisymą ir vėlesnį taisymą. Jis taip pat apima pasirinkimo galimybę: sąnaudas keisti modelį, tiekėją, raginimą, indeksą ar darbo srautą, kai dabartinė sąranka nebetinka.
Tai nereiškia, kad tikimybiniai darbo srautai yra blogi. Tai reiškia, kad jie yra realūs. Daugelis jų verti savo kainos. Sistema, kuri sumažina pasikartojantį skaitymą ir kartu išryškina rizikingus atvejus, gali būti puiki. Klasifikatorius, kuris geriau nei taisyklės tvarko netvarkingą kalbą, gali sutaupyti laiko. Santraukų generatorius, kuris ekspertams suteikia gerą pirmąjį įvertinimą, gali pagerinti paslaugą. Esmė ne vengti tikimybių. Esmė nustoti slėpti jų veiklos biudžetą kitų žmonių kalendoriuose.
Vienas naudingas apskaitos metodas yra kainodara pagal atvejų klases. Tiesiogiai apdorojami atvejai turi modelio, patikros ir atrankos sąnaudas. Padedami atvejai prideda vertintojo laiko. Išimtiniai atvejai prideda rūšiavimo, specialistų peržiūros ir įrodymų sąnaudas. Ginčytini atvejai prideda atkūrimo, komunikacijos ir galimo taisymo sąnaudas. Tobulinimo atvejai prideda duomenų arba užklausų priežiūros sąnaudas. Tai paverčia automatizavimo rodiklį turtingesniu vaizdu: ne tik kiek atvejų palietė dirbtinis intelektas, bet ir kaip neapibrėžtumas pakeitė darbą ir riziką.
Kitas metodas yra variacijos biudžeto stebėjimas. Kiek išvesties variacijos yra priimtina šiai užduočiai. Kaip dažnai pakartotiniai vykdymai gali skirtis. Kiek išimčių per dieną eilė gali sugerti. Kiek peržiūros laiko vienam atvejui yra numatyta. Kiek įrodymų turi būti saugoma. Kaip greitai ginčytini rezultatai turi būti atkurti. Šie skaičiai nepašalina neapibrėžtumo. Jie daro jį valdomą.
Determinizmas vis dar turi savo vaidmenį
Tikimybinių sistemų plitimas nepadaro deterministinės inžinerijos pasenusia. Jis daro deterministines ribas vertingesnes. Naudokite deterministinį analizavimą ten, kur yra struktūra. Naudokite aiškias taisykles ten, kur politika yra nedviprasmiška. Naudokite stabilią paiešką ten, kur šaltiniai turi būti atkuriami. Naudokite schemas, tikrintuvus, baigtines būsenas, versijuotas užklausas, fiksuotus vertinimo rinkinius ir įrašytus parametrus. Naudokite tikimybes tai užduoties daliai, kuriai tikrai reikia sprendimo dėl dviprasmybės, o ne tai daliai, kuriai tereikėjo, kad kas nors parašytų nuobodų kodą.
Tai ne grynumas. Tai sąnaudų kontrolė. Kiekviena deterministinė riba pašalina vieną vietą, kur variacija gali nutekėti. Darbo srautas, kuris naudoja modelį netvarkingam tekstui skaityti, tada deterministinį tikrinimą reikiamiems laukams patikrinti, tada taisykles žinomai politikai taikyti, tada žmogaus peržiūrą didelės pasekmės neapibrėžtumui, paprastai bus lengviau valdomas nei darbo srautas, kuris prašo modelio padaryti viską ir tada apsimeta nustebęs, kai viskas apima kelias nuomones.
Determinizmas taip pat gerina įrodymus. Jei taisyklė suveikė, įrašykite taisyklę. Jei analizatorius ištraukė lauką, įrašykite šaltinio vietą. Jei paieška reitingavo dokumentus, įrašykite indekso versiją ir balus. Jei modelis sukūrė santrauką, įrašykite užklausą, šaltinių rinkinį, modelio versiją ir vertintojo sprendimą. Tikslas nėra paversti kiekvieną darbo srautą teismo sale. Tikslas yra padaryti vėlesnius klausimus atsakomus be visos inžinerijos komandos kvietimo į susitikimą, vadinamą greita sinchronizacija.
Riba tarp deterministinio ir tikimybinio darbo turėtų būti aiški diagramose ir biudžetuose. Kuris žingsnis gali keistis. Kuris žingsnis negali. Kurį žingsnį galima bandyti iš naujo. Kuris žingsnis turi būti atkartotas tiksliai. Kurį žingsnį galima paaiškinti statistiškai. Kuriam žingsniui reikia įrašo. Jei komanda negali nubrėžti tos ribos, ji negali sąžiningai įvertinti sąnaudų.
Pamoka
Paslėpta tikimybinių darbo eigų kaina nėra priežastis jų vengti. Tai priežastis į jas žiūrėti sąžiningai. Kaina pasireiškia pakartotiniais bandymais, peržiūromis, išimtimis, įrodymais, vertinimu, eilėmis, pagalba ir lėtesniu sprendimu, koks nuokrypis yra priimtinas. Jei darbo eiga sutaupo laiko įprastu keliu, bet jį išleidžia ginčytinais atvejais ir veiklos migloje, verslo atvejis buvo parašytas tik pusiau.
Gera tikimybinė veikla prasideda nuo neapibrėžtumo traktavimo kaip medžiagos. Įvardykite, kur jis patenka. Apribokite, kur jis gali kisti. Užfiksuokite pakankamai konteksto, kad sprendimus būtų galima atkartoti. Sukurkite išimčių eiles kaip mokymosi paviršius. Suteikite peržiūrintiems asmenims įgaliojimus ir laiko. Vertinkite nuolat. Išlaikykite deterministines ribas ten, kur jos mažina sąnaudas. Įkainokite išėjimą ir pokyčius. Didžioji dalis to nėra įspūdinga. Tai ženklas, kad tai gali išlikti gamyboje.
Modelio iškvietimas yra lengva eilutė. Tikrasis klausimas yra tai, ką organizacija turi padaryti prieš tą iškvietimą ir po jo, kad rezultatas būtų patikimas, ginčijamas, taisomas ir tobulinamas. Tikimybė gali padaryti darbo eigas pajėgesnes. Ji taip pat gali padaryti jas mažiau nuspėjamas. Skirtumas nėra magija. Tai veikla, kuri lieka vieta, kur įspūdingos demonstracijos tampa arba naudingos, arba brangios.