Žmogaus dalyvavimo ribos: autonomijos ir priežiūros kalibravimas

Įvadas: Kai DI kodavimo asistentai tampa plačiai paplitę, jie atveria kodavimą visiems – net ir ne programuotojams – generuodami kodą per kelias sekundes. Tačiau greitesnis rezultatas sukelia naujų rizikų. Neišbandytas dirbtinio intelekto sukurtas pakeitimas gali sukelti klaidų ar saugumo problemų, kurias pastebėtų žmogus. Svarbiausia rasti tinkamą pusiausvyrą: leisti automatikai tvarkyti įprastas užduotis, tačiau užtikrinti, kad žmonės peržiūrėtų bet ką, kas yra didelės rizikos. Šiame straipsnyje paaiškinama, kaip nustatyti sprendimų taškus, kada reikalingas žmogaus patvirtinimas, o kada galima saugi autonomija, kaip sukurti vartotojo sąsajas, kurios paaiškina dirbtinio intelekto pakeitimus ir neapibrėžtumą, kaip įvertinti priežiūros darbo krūvį ir nustatyti eskalavimo kelius neaiškioms ar kritinėms užduotims. Tikslas yra padėti komandoms (nuo individualių kūrėjų iki įmonių) saugiai paspartinti kūrimą naudojant dirbtinį intelektą, kartu sumažinant peržiūros nuovargį ir klaidas (www.techradar.com) (www.clarityarc.com).

1. Sprendimas, kada įtraukti žmones ar dirbtinį intelektą

Kai kuriems sprendimams visada reikalingas žmogaus patikrinimas, o kiti gali būti saugiai vykdomi automatiškai. Kaip teigiama vienoje valdymo sistemoje, naudokite rizikos kalibruotą priežiūrą: paprasti, grįžtami veiksmai gali būti automatiniai; didelio poveikio ar negrįžtami pakeitimai reikalauja žmogaus patvirtinimo (www.clarityarc.com). Pavyzdžiui:

Įprasti arba gerai suprantami pakeitimai: kodo formatavimas, rašybos klaidų taisymas, nuoseklių pavadinimų suteikimas ar šablonų atnaujinimas – tai mažos rizikos užduotys. Dirbtinio intelekto įrankiai gali jas atlikti ir net išvalyti kodą prieš žmogaus peržiūrą. Daugelis komandų leidžia dirbtiniam intelektui „automatiškai taisyti“ linting ir stiliaus problemas, kol niekas kitas nemato kodo (graphite.com).
Sudėtingi arba kritiniai pakeitimai: architektūriniai pakeitimai, naujų funkcijų projektavimas, saugumui jautrus kodas ar tiesioginis diegimas į produkciją yra didelės rizikos. Tam reikalingas aiškus žmogaus patvirtinimas. „Graphite“ kodo peržiūros vadovas pataria apriboti dirbtinio intelekto naudojimą mechaninėms dalims ir leisti žmonėms sutelkti dėmesį į architektūrą, domenų logiką ir saugumą dideliems pakeitimams (graphite.com). Panašiai, vienas incidento tyrimas parodė, kad dirbtinio intelekto agentui suteikus plačią prieigą be žmogaus sprendimo sukėlė valandų prastovą, o paprastai sistemai reikėjo dvigubo žmogaus patvirtinimo dideliems pakeitimams (www.techradar.com).
Neaiškios arba kūrybinės užduotys: jei DI neaiškus arba jūsų reikalavimai nėra visiškai apibrėžti, įtraukite žmogų. Žmogaus intuicija reikalinga, kai instrukcijose paliekama vietos interpretacijai. Kaip perspėja Sistemų vientisumo institutas, nepakanka turėti žmogų sistemoje – jie turi turėti realią teisę įsikišti, kai DI klysta (www.systemsintegrity.org). Praktikoje tai reiškia, kad nereikia versti žmonių aklai tvirtinti kiekvieną pakeitimą, bet leisti jiems sustabdyti arba atšaukti DI veiksmus, kai reikia.

Trumpai tariant, apibrėžkite aiškias sprendimų ribas. Kai kurios organizacijos apibrėžia žmogaus sprendimo slenkstį: iki šio pakeitimo lygio DI gali tęsti veiksmus, tačiau viršijus jį, žmogaus peržiūra yra privaloma (www.clarityarc.com). Pavyzdžiui, galite pasakyti: „Visi pataisymų leidimai (nedideli pataisymai) gali būti automatiškai sujungti po testų, tačiau bet koks pakeitimas, susijęs su saugumo kontrolėmis ar klientų duomenimis, reikalauja vyresniojo peržiūros.“ Šių taisyklių užrašymas užtikrina, kad DI paspartins diegimą saugiai (www.clarityarc.com).

2. Vartotojo sąsajos šablonai skaidrumui ir rizikoms

Gerai suprojektuotos sąsajos padeda vartotojams suprasti, ką DI padarė, kiek jį galima pasitikėti ir kur nukreipti darbą. Štai trys pagrindiniai UX šablonai:

Skirtumų paaiškinimai

Kai DI keičia kodą (arba tekstą), sąsaja turėtų paaiškinti, kas pasikeitė ir kodėl, o ne tik rodyti neapdorotus skirtumus. Žmonėms reikia konteksto, kad pasitikėtų DI redagavimais. Pavyzdžiui, gyvenimo aprašymo įrankis naudojo vizualų skirtumų rodymą, išryškinantį kiekvieną DI pakeistą žodį, nes priešingu atveju vartotojai ištisas minutes žiūrėtų į DI parašytą tekstą (www.matcharesume.com). Panašiai, kodo peržiūrose galite naudoti anotacijas ar santraukas, kad paaiškintumėte didelius pakeitimus. Kai kurios komandos automatiškai generuoja trumpą pakeitimo santrauką ar diagramą kartu su skirtumais (www.codeant.ai). Įrankiai, tokie kaip „CodeAnt“, siūlo naudoti blokų schemas ar seka diagramas, be tekstinių skirtumų, kad būtų parodyta, kaip naujas kodas veikia vykdymo metu (www.codeant.ai).

Praktikoje: Kai DI siūlo redagavimus, pateikite juos lengvai suprantamu būdu. Tai gali reikšti DI paliestų kodo eilučių išryškinimą, automatiškai parašytą komentarą, pvz., „Pataisyta eilutės formatavimo problema“, ar net įterptas diagramas sudėtingai logikai. Tikslas yra skaidrumas: vartotojas turi iš karto matyti, kas buvo pakeista ir kokią problemą tai išsprendžia. Kaip pastebėjo viena komanda, pasitikėjimas smarkiai išaugo, kai jie padarė DI redagavimus matomus ir suprantamus, o ne paslaptingus „prieš/po“ skaidres (www.matcharesume.com).

Neapibrėžtumo komunikavimas

DI sistemos yra iš esmės probabilistinės, tačiau dauguma sąsajų tai slepia. Tai gali suklaidinti vartotojus per daug pasitikėti DI. Norint sukurti pasitikėjimą, aiškiai parodykite neapibrėžtumo ar pasitikėjimo lygius. Remiantis UX tyrimais, sąsajos neturėtų pateikti DI atsakymų su tokiu pat tikrumu, kaip deterministinius duomenis (www.uxatlas.io). Pavyzdžiui, jei kodo asistentas įterpia sudėtingą funkciją, bet nėra visiškai tikras, pažymėkite ją kaip „(Tikriausiai teisinga)“ arba naudokite spalvomis koduotą reklamjuostę.

Praktiniu lygmeniu galite rodyti pasitikėjimo balus, mažas įspėjamąsias piktogramas arba natūralios kalbos apsidraudimus. Pavyzdžiui: „Aš esu maždaug 60% tikras, kad šis pakeitimas atitinka stiliaus taisykles, patikrinkite dar kartą.“ Tyrimai rodo, kad kai kūrėjai matė vidutinio pasitikėjimo žymę ant DI sugeneruoto kodo, jie jį peržiūrėjo atidžiau ir aptiko klaidų, kurių kitaip nebūtų pastebėję (www.uxatlas.io). (Priešingai, tobulai pasitikinčiai atrodantys DI pasiūlymai gali nuraminti peržiūrinčius asmenis priimti klaidas.) Trumpai tariant, neslėpkite DI abejonių – parodykite jas su UI nuorodomis, kad žmonės galėtų tinkamai reaguoti.

Rizikos reikalaujantis nukreipimas

Ne visi pakeitimai turėtų būti nukreipti tiems patiems peržiūrintiesiems. Sąsaja ir darbo eiga turėtų nukreipti didelės rizikos DI rezultatus didesniam patikrinimui. Pavyzdžiui, pažymėkite dirbtinio intelekto sugeneruotus „pull request“ (daugelis įrankių prideda roboto paskyrą ar metaduomenis) ir automatiškai padidinkite jų peržiūros lygį. Viena strategija yra nustatyti pasirinktines taisykles: jei „pull request“ autorius yra DI robotas, padidinkite blokuojančių problemų sunkumo slenkstį (www.tenki.cloud). Tokiu būdu, DI sukurtas „pull request“ gali reikalauti dviejų patvirtinimų arba numatytuoju būdu suaktyvinti papildomus CI patikrinimus.

Kitas būdas yra tiesiogiai vartotojo sąsajoje paryškinti rizikos tipą. Galite pažymėti, kad pakeitimas liečia saugius kodo kelius, arba kad DI turėjo mažą pasitikėjimą, ir tada pranešti vyresniajam inžinieriui arba saugumo komandai. Automatizuotoje peržiūros sistemoje žinomos silpnosios vietos (pvz., įvesties patvirtinimas ar kriptografija) gali būti iškeltos kaip didesnio prioriteto komentarai, kad žmonės skirtų papildomą dėmesį (www.tenki.cloud).

Praktikoje: Naudokite etiketes, žymas ar specialias juostas, kad nukreiptumėte DI darbą pagal riziką. Pavyzdžiui, visus agentų sugeneruotus redagavimus nukreipkite per griežtesnį darbo eigos kelią arba siųskite įspėjimą techniniam vadovui dėl bet kokio pakeitimo, turinčio įtakos kritiniams moduliams. „Propel Code“ rekomenduoja kurti „aiškius eskalavimo kelius“ – kitaip tariant, leisti UI automatiškai nukreipti ar blokuoti veiksmus, kurie viršija nustatytas rizikos ribas (www.propelcode.ai) (www.clarityarc.com). Tai užtikrina, kad tinkami žmonės greitai pamatys neaiškius ar svarbius pakeitimus.

3. Metrikos: priežiūros ir nuovargio kalibravimas

Kaip žinoti, ar jūsų automatizavimo ir peržiūros pusiausvyra yra teisinga? Naudokite metrikas, kad tinkamai suderintumėte priežiūrą. Stebėkite tiek saugumo, tiek efektyvumo rodiklius:

Peržiūros darbo krūvis ir pralaidumas: Stebėkite, kiek „pull request“ ar pakeitimų laukia peržiūros ir kiek laiko užtrunka peržiūros. Jei DI smarkiai padidino apimtį, žmonės, atliekantys peržiūras, gali tapti kliūtimi. Pavyzdžiui, vienas tyrimas parodė, kad DI sugeneruoti „pull request“ turėjo 1,7 karto daugiau problemų nei žmonių parašyti, perkraunant komandas (www.tenki.cloud). Jei peržiūros eilės auga arba peržiūros laikas smarkiai išauga, tai signalizuoja apie peržiūros nuovargį.
Peržiūrinčiųjų atsiliepimų metrikos: Stebėkite, kaip dažnai DI pasiūlymai yra priimami, palyginti su atmetimu ar pataisymu žmonių (graphite.com). Didelis atmetimo rodiklis reiškia, kad DI reikia sureguliuoti arba labiau apriboti. Taip pat registruokite klaidingus teigiamus (kai DI pažymi neegzistuojančią problemą) ir klaidingus neigiamus (praleistus defektus). „Graphite“ rekomenduoja stebėti priėmimo rodiklį ir „praleistas kritines problemas“, kad kalibruotų DI jautrumą (graphite.com).
Kokybė ir defektai: Matuokite defektų pabėgimo rodiklį – klaidų, kurios patenka į produkciją, skaičių vienai kodo eilutei – idealiu atveju suskirstytą pagal DI ir žmogaus autorystę. „Propel Code“ siūlo šią metriką (ir „peržiūros naudingumą“) kaip apsauginio barjero rodiklį (www.propelcode.ai). Jei defektai didėja arba rimtų klaidų, kilusių iš DI kodo, skaičius didėja, sustiprinkite priežiūrą.
Peržiūros naudingumas: Įvertinkite, kiek naudingos yra peržiūros. Pavyzdžiui, registruokite, kiek problemų aptinka peržiūros, arba rinkite peržiūrinčiųjų pasitenkinimą atliekant trumpas apklausas. „Propel“ tai net vadina „peržiūros naudingumu“ – iš esmės klausiama, ar procesas aptinka problemas prieš diegimą (www.propelcode.ai).

Šios metrikos leidžia rasti pusiausvyrą: jei peržiūrintieji yra išsekę (ilgos eilės, lėtas sujungimas arba mažėjanti peržiūros kokybė (www.techradar.com)), gali prireikti sumažinti privalomų patikrinimų skaičių mažos rizikos užduotims. Ir atvirkščiai, jei defektų daugėja, sugriežtinkite žmogaus sprendimo ribą. Tikslas yra sumažinti nuovargį, išlaikant saugumą. Reguliariai peržiūrėkite šiuos skaičius ir koreguokite politiką: galbūt automatizuokite daugiau, kai padidėja pasitikėjimas, arba eskalate daugiau, jei atsiranda klaidų.

4. Eskalavimo protokolai neapibrėžtumui ir didelei rizikai

Ne kiekviena situacija atitinka taisyklę. Sukurkite aiškius eskalavimo protokolus kraštutiniams atvejams ar didelio poveikio sprendimams:

Apibrėžkite paleidiklius: Iš anksto nuspręskite, kokios situacijos reikalauja įsikišimo. Pavyzdžiai: DI praneša apie mažą pasitikėjimą, pakeitimas liečia kritinę infrastruktūrą, arba rezultatas pažeidžia atitikties taisyklę. Kaip teigiama viename vadove, jei agento sprendimas yra už jo „apibrėžtų parametrų“ ribų, jis turėtų būti perduotas žmogui, atliekančiam peržiūrą (www.clarityarc.com).
Kas sprendžia: Paskirstykite atsakomybę. Tai gali būti vyresnysis inžinierius, saugumo pareigūnas arba tarpfunkcinis komitetas. Dokumentuokite, kas atlieka eskalavimus. Pavyzdžiui, galite pasakyti: „Kritiniai saugumo pakeitimai patenka saugumo vadovui ir CTO peržiūrai.“ „ClarityArc“ sistema tai vadina „įvardytu peržiūrėtoju“ išimtims (www.clarityarc.com).
Daugiasluoksnis eskalavimas: Labai didelės rizikos problemoms eskalavimas atliekamas per kelis lygius. Mažas nukrypimas gali būti perduotas tik tiesioginiam bendraamžiui peržiūrėti, o duomenų pažeidimo rizika gali apimti inžinerijos vadovą ir teisinę komandą. Idėja yra turėti žingsnius: pirmiausia leisti vienam asmeniui tai išspręsti, tada, jei reikia, pasitelkti atsarginį variantą.
Nebausti už eskalavimą: Vartotojo patirties projektavime, perkėlimas yra toks, kad eskalavimas ar peržiūros prašymas nėra nesėkmė, o įprasta valdymo dalis. Padarykite komandos nariams be trikdžių iškelti problemą (mygtukai vartotojo sąsajoje, aiškios formos ir t.t.). Pavyzdžiui, vienas tinklaraštis siūlo traktuoti DI ir žmogaus perdavimus kaip darbo eigos funkciją, o ne sistemos gedimą (graph.digital).

Praktikoje: Kuriant procesą, aiškiai nubrėžkite šiuos protokolus. Įtraukite juos į dokumentaciją, kad visi žinotų: „Jei DI klausia „Ar turėčiau diegti?“, tik asmuo X gali pasakyti taip.“ Arba vartotojo sąsajos patarimai gali sakyti „Perduoti vyresniajam peržiūrėti“, kai kas nors spustelėja neaiškų pasiūlymą. Laikui bėgant, šios eskalavimo taisyklės turėtų būti išbandytos ir patobulintos (po incidentų analizės, auditų), kad neaiškios užduotys visada patektų į žmogaus akiratį.

Išvada

Apskritai, autonomijos ir priežiūros kalibravimas reiškia sąmoningą sprendimą, ką DI gali padaryti pats ir ką turi patikrinti žmonės (www.propelcode.ai) (www.clarityarc.com). Pateikite sąsajas, kurios paaiškina DI sprendimus ir pabrėžia neapibrėžtumą, kad vartotojai išliktų kontroliuojantys situaciją (www.uxatlas.io) (www.codeant.ai). Rinkite metrikas, tokias kaip priėmimo rodikliai ir defektų pabėgimas, kad užtikrintumėte, jog procesas neperkrauna peržiūrinčiųjų (graphite.com) (www.propelcode.ai). Ir visada turėkite aiškų eskalavimo kelią sudėtingiems ar didelės rizikos atvejams, kad niekas neliktų bejėgis sistemoje (www.systemsintegrity.org) (www.clarityarc.com).

Šis subalansuotas požiūris ypač naudingas komandoms, kurios dar tik pradeda naudoti DI įrankius. Pradėjus nuo mažų dalykų (pvz., leisti DI taisyti „lint“ problemas ir matuoti rezultatą), net ne programuotojai gali įgyti pasitikėjimo. Pirmas žingsnis yra nubrėžti savo darbo eigą: išvardinti tipiškas užduotis, pažymėti jų rizikos lygius ir nuspręsti, kurias iš jų DI gali atlikti autonomiškai. Tada įdiekite paprastus patikrinimus ir palaipsniui tobulinkite. Su aiškiomis ribomis ir komunikacija DI tampa turbokompresoriumi – paspartina kūrimą, neprarandant kokybės ar saugumo.

Tolesni žingsniai: Norėdami pradėti, pasirinkite nedidelį projektą ar modulį. Apibrėžkite du ar tris sprendimų taškus (pavyzdžiui, „stiliaus pataisymai“, „įprasti skaičiavimai“ ir „saugumo patikrinimai“) ir priskirkite juos DI arba žmogui, kaip aptarta. Naudokite korteles ar paprastas skaičiuokles rezultatams sekti (rastų problemų skaičius, sugaištas laikas). Šis praktinis bandymas atskleis, kaip tiksliai sureguliuoti autonomijos ir priežiūros derinį. Laikui bėgant, sukursite valdymą su tinkamu žmogaus dalyvavimu, leidžiančiu kūrybiškumui ir produktyvumui augti, neprarandant kontrolės.