Kada AI sistemai vis dar reikia žmogaus sprendimo

AI sistema dalį darbo padaro pati, o apibrėžtus atvejus sustabdo ir paduoda žmogaus sprendimui. Apibrėžtus atvejus, ne bendrą pažadą, kad kažkas viską prižiūrės. Tokių taškų procese yra keli, ir kiekvienas turi vieną paskirtą žmogų bei vieną sprendimo rūšį. Šiame straipsnyje aprašoma, kur tie taškai yra, ko tam žmogui reikia darbui padaryti ir kada įmonė gali jų neturėti.
Serijoje jau esame aprašę, kaip pasidarėme savo AI sąskaitų automatizaciją (opens in new tab). Ten einama per patį statymą: ką sistema perskaito, ką sulygina, ką užregistruoja. Po kiekvienu tų etapų lieka mažesnis klausimas, kuris atskiro straipsnio dar neturėjo: kurie atvejai grįžta žmogui ir ko iš jo tuo momentu tikimasi.
Kada AI sistema laukia žmogaus sprendimo
Sistema vykdo procesą. Apibrėžtose vietose ji sustoja ir laukia žmogaus, nes kitam žingsniui reikia sprendimo, kurio priimti ji nebuvo statoma. Toks veikimo būdas atėjo iš valdymo inžinerijos, angliškai jis vadinamas human in the loop, ir AI sistemose veikia lygiai taip pat.
Apibrėžtose vietose reiškia, kad taškai, kuriuose sistema kreipiasi į žmogų, yra nustatyti iš anksto. Jei jų nėra, žmogus tik stebi visą srautą ir gali pažiūrėti bet ką, bet nė vienas atvejis nėra konkrečiai jam paduotas. Toks žmogus stovi šalia proceso, o ne jame, ir realiai nieko nesprendžia.
Sustoja reiškia, kad ties tuo tašku procesas iš tikrųjų stabdomas. Jei sistema važiuoja toliau ir atvejį žmogui parodo tik vėliau, kartu su jau parengta ataskaita, žmogui belieka tikrinti tai, kas jau įvyko. Tai auditas, ne sprendimas: klaidą jis pamato, bet sustabdyti jos nebegali.
Laukia reiškia, kad atvejis lieka neužbaigtas, kol ateina žmogaus atsakymas. Sistema neužpildo jo spėjimu ir nekeliauja toliau. Ji palieka tą atvejį vietoje, kol žmogus nusprendžia.
Taisyklėmis paremtas įrankis tokios galimybės neturi. Jis arba atpažįsta šabloną, arba grąžina klaidą, o klaida nėra klausimas. AI sistema kartu su atsakymu pasako ir tai, kiek juo pasitiki, ir būtent tas pasitikėjimo įvertis leidžia jai sustoti. Kai sistema nepakankamai tikra, atvejis sustoja ir keliauja žmogui. Užtekus tikrumo, sistema atvejį uždaro pati, ir niekas jo nemato. Kiek tikrumo turi užtekti, sprendžiate jūs.
Trys vietos, kuriose procese atsiranda žmogus

AI darbo sraute žmogus gali stovėti prieš sistemos veiksmą, ties pažymėtu atveju arba po veiksmo, prie atrankos iš to, ką sistema uždarė pati. Šias tris pozicijas surinkome iš sistemų, kurias esame paleidę gyvai, o paskutiniame lentelės stulpelyje surašyta, ką matėme, kai vienos iš jų nebuvo.
Kur stovi žmogus | Ką jis daro | Ko tam reikia | Kas nutinka, kai jo nėra |
|---|---|---|---|
Prieš sistemos veiksmą | Vieną kartą patvirtina taisyklę, užuot tvirtinęs kiekvieną atvejį | Taisyklė surašyta ir turi savininką | Procesas toliau laikosi pernykštės prielaidos |
Ties pažymėtu atveju | Išsprendžia atvejus, kuriuos sistema pažymėjo kaip neaiškius | Pažymėjimo priežastis matoma ekrane kartu su šaltiniu | Eilė išvaloma jos neperskaičius |
Po sistemos veiksmo | Peržiūri nedidelę atranką iš to, ką sistema uždarė pati | Tikrinantysis turi teisę pakeisti, kada sistema klausia žmogaus | Pirmą klaidingą dėsnį pastebi klientas |
Atranka po veiksmo yra nedidelė dalis atvejų, kuriuos sistema uždarė pati ir kuriuos žmogus vėliau peržiūri. Ji iškrenta pirmiausia, nes niekas jos nelaukia ir niekas nepasigenda, kai ji sustoja. Bet būtent ji vienintelė parodo, ar riba, ties kuria sistema klausia žmogaus, nustatyta bent apytiksliai teisingai.
Žmogui lieka tie atvejai, kurių automatizuoti neįmanoma
Lisanne Bainbridge šį reiškinį aprašė 1983 m. žurnale „Automatica“, nagrinėdama pramoninių procesų valdymą. Automatizavimas, jos teigimu, problemas su žmogumi operatoriumi veikiau išplečia nei panaikina (opens in new tab), nes įprastas sprendimas palieka operatoriui atsakomybę už nestandartines situacijas.
Perskaitykite tai galvodami apie savo procesą. Įprastas darbas keliauja sistemai. Žmogų pasiekia tiekėjas, kurio niekas neatpažįsta, skaičius, kuris nesusiveda, ir užklausa, parašyta taip, kaip niekas nesitikėjo. Atvejų kiekis krenta, o vidutinis jų sunkumas kyla. Perduodant tokį darbą kitam, jis dažniausiai pristatomas skirtingai.
Iš to seka du dalykai, ir abu yra projektavimo sprendimai. Tikrinti turi žmogus, kuris išmano verslą, o ne tas, kuris tą savaitę turi mažiausiai susitikimų. Ir pažymėtų atvejų turi būti tiek, kad kiekvieną spėtų perskaityti. Trumpą eilę žmogus perskaito. Ilga eilė, atimanti visą rytą, būna išvaloma.
Ko žmogui reikia, kad galėtų pasakyti ne
Paskirti tikrinantįjį yra lengvoji dalis. ES dirbtinio intelekto aktas apie kitą dalį kalba konkrečiai. Rašydamas apie didelės rizikos sistemas, jis reikalauja, kad diegėjai žmogaus atliekamą priežiūrą pavestų asmenims, turintiems reikiamą kompetenciją, mokymą ir įgaliojimus bei reikiamą paramą (opens in new tab).
Sąskaitas ar ataskaitas automatizuojanti įmonė didelės rizikos AI sistemos šia teisine prasme dažniausiai neturi, tad ir prievolė jos gali nepasiekti. Bet tas sąrašas skaitosi kaip dažniausiai daromos klaidos. Kompetencija, nes tikrinantysis, kuris neatskiria teisingo atsakymo nuo sklandaus, prideda vėlavimą ir nieko nepataiso. Mokymas, nes sistema bus atnaujinta, o senas klaidas pakeis naujos. Parama, nes kažkas turi būti pasiekiamas tada, kai problema yra pati sistema.
Praleidžiami dažniausiai būna įgaliojimai. Tikrinti neretai paskiriamas jaunesnis darbuotojas, o jį pasiekia būtent tie atvejai, prie kurių prikabinti pinigai arba klientas. Kai pasakyti ne reiškia prieštarauti tam, kas nustatė tikslą, toks tikrinimas lieka schemoje, bet įmonėje jo nėra.
Kaip tai atrodo mūsų pačių sąskaitų sistemoje
Mūsų sąskaitų sistema remiasi paties dokumento struktūra, o ne tuo, ką jūsų įmonė yra gavusi anksčiau. Todėl net pirmą kartą gauta naujo tiekėjo sąskaita apdorojama iškart, be iš anksto paruošto šablono.
Būtent dėl šios savybės kai kur ir prireikia žmogaus sprendimo. Skaitydama niekada nematytą dokumentą, sistema kartu įvertina, kiek pati tikra dėl kiekvieno lauko. Mažiau patikimus atvejus ji grąžina žmogui kartu su priežastimi: šio laukelio nepavyko perskaityti, šiam tiekėjui tinka du įrašai, šios eilutės nesusideda į bendrą sumą. Į tokį klausimą žmogus atsako per kelias sekundes, užuot suvedinėjęs visą dokumentą iš naujo.
Tokia pati sandara veikia ir ataskaitose. Tas pats įmonės pavadinimas trijose sistemose dažnai užrašytas trimis skirtingais būdais, ir sistema jį arba sulygina pati, arba palieka žmogui. Apie tai plačiau rašėme straipsnyje, kodėl mėnesio ataskaita vis dar užtrunka savaitę (opens in new tab).
Kada žmogaus sprendimo nereikia
Atvejų, kada sistema gali spręsti viena, yra trys, ir trečiasis prieštarauja viskam, kas parašyta aukščiau.
Žingsnį lengva atšaukti, o jį perdaryti pigu. Pavyzdžiui: juodraštis, kurio niekas nesiunčia; vertimas, kurį perskaito vienas žmogus; santrauka prieš susitikimą. Kai klaidingas rezultatas kainuoja minutę, kiekvieno rezultato tikrinimas atsieina brangiau nei pati klaida. Tokiu atveju visa reikalinga patikra yra ta pati atranka po veiksmo.
Darbą ir patikrą daro tas pats žmogus. Mažoje įmonėje tikrinantysis yra buhalteris, o buhalteris yra visa apskaita. Atskiras priežiūros žingsnis, kai viską daro tas pats žmogus, tik prideda dar vieną dokumentą, o kontrolės neduoda.
Sprendimas visą laiką buvo verslo sprendimas. Ar toliau dirbti su tiekėju, kokią nuolaidą duoti, kas prisiima ginčijamas valandas. Kai toks klausimas perduodamas AI sistemai, taisyti reikia ne rezultatą, o patį sumanymą. Rekomendacija, kurios apskritai neturėjo būti, nuo tikrinančio žmogaus saugesnė netampa.
Nuo ko pradėti
Paimkite vieną žingsnį, kurį jau automatizavote arba ruošiatės automatizuoti, ir atsakykite į tris klausimus apie jį. Ką sistema daro, kai nėra tikra? Kas tą atvejį pamato? Ką tas žmogus po to gali pakeisti?
Jei į pirmą klausimą atsakymo nėra, vadinasi, niekada nebuvo nuspręsta, kiek sistema turi būti tikra. Tokiu atveju ji viską uždaro pati, ir žmogui nepatenka nė vienas atvejis. Jei atsakymo nėra į trečią, turite žmogų, kuris atvejus peržiūri, bet nieko pakeisti negali.
Susisiekite (opens in new tab), ir kartu pereisime vieną jūsų procesą bei nurodysime, kurioje jo vietoje turi stovėti žmogus.

Justas Česnauskas
CEO | Founder
Builder of things that (almost) think for themselves
Prisijunkite LinkedIn
