Cilvēka iesaistes robežas: Autonomijas un uzraudzības kalibrēšana

Ievads: Mākslīgā intelekta (MI) kodēšanas asistenti kļūstot plaši izplatīti, tie padara kodēšanu pieejamu ikvienam – pat tiem, kas nav izstrādātāji – ģenerējot kodu dažu sekunžu laikā. Tomēr ātrāka izvade rada jaunus riskus. Nepārbaudīta MI ģenerēta izmaiņa var ieviest kļūdas vai drošības problēmas, kuras cilvēks pamanītu. Galvenais ir atrast pareizo līdzsvaru: ļaut automatizācijai veikt rutīnas uzdevumus, taču nodrošināt, ka cilvēki pārskata visu, kam ir liela nozīme. Šajā rakstā ir paskaidrots, kā noteikt lēmumu punktus cilvēka apstiprināšanai pret drošu autonomiju, izstrādāt lietotāju saskarnes, kas precizē MI izmaiņas un nenoteiktību, novērtēt uzraudzības darba slodzi un noteikt eskalācijas ceļus neskaidriem vai kritiskiem uzdevumiem. Mērķis ir palīdzēt komandām (no individuāliem veidotājiem līdz uzņēmumiem) droši paātrināt attīstību, izmantojot MI, vienlaikus samazinot pārskatīšanas nogurumu un kļūdas (www.techradar.com) (www.clarityarc.com).

1. Lemjot, kad iesaistīt cilvēkus vai MI

Dažiem lēmumiem vienmēr ir jābūt pakļautiem cilvēka pārbaudei, savukārt citi var droši darboties autonomi. Kā norādīts vienā pārvaldības ietvarā, izmantojiet uz risku kalibrētu uzraudzību: vienkāršas, atgriezeniskas darbības var būt automātiskas; liela ietekme vai neatgriezeniskas izmaiņas prasa cilvēka apstiprinājumu (www.clarityarc.com). Piemēram:

Rutīnas vai labi saprotamas izmaiņas: Koda formatēšana, drukas kļūdu labošana, konsekventu nosaukumu pieņemšana vai šablonu atjaunināšana – šie ir zema riska uzdevumi. MI rīki var tos apstrādāt un pat iepriekš attīrīt kodu pirms cilvēka pārskatīšanas. Daudzas komandas ļauj MI “automātiski labot” lintinga un stila problēmas, pirms kāds cits redz kodu (graphite.com).
Kompleksas vai kritiskas izmaiņas: Arhitektūras izmaiņas, jaunu funkciju izstrāde, drošībai jutīgs kods vai tieša izvietošana ražošanā ir augsta riska uzdevumi. Tiems ir nepieciešams skaidrs cilvēka apstiprinājums. Graphite koda pārskatīšanas ceļvedis iesaka ierobežot MI līdz mehāniskajām daļām un ļaut cilvēkiem koncentrēties uz arhitektūru, domēna loģiku un drošību lielu labojumu gadījumā (graphite.com). Tāpat vienā incidenta pārskatā tika atzīmēts, ka MI aģentam piešķirta plaša piekļuve bez cilvēka sprieduma izraisīja stundām ilgu dīkstāvi, savukārt parasti sistēma lielām izmaiņām prasīja dubultu cilvēka apstiprinājumu (www.techradar.com).
Neskaidri vai radoši uzdevumi: Ja MI ir neskaidrs vai jūsu prasības nav pilnībā definētas, iesaistiet cilvēku. Cilvēka intuīcija ir nepieciešama, ja instrukcijas pieļauj interpretāciju. Kā brīdina Sistēmu integritātes institūts, nepietiek ar to, ka cilpā ir cilvēks – viņam ir jābūt reālām pilnvarām iejaukties, kad MI kļūdās (www.systemsintegrity.org). Praksē tas nozīmē nevis piespiest cilvēkus automātiski apstiprināt katru izmaiņu, bet gan ļaut viņiem apturēt vai atcelt MI, ja nepieciešams.

Īsāk sakot, definējiet skaidras lēmumu pieņemšanas robežas. Dažas organizācijas definē cilvēka sprieduma slieksni: līdz šim izmaiņu līmenim MI var turpināt darbu, taču pēc tā cilvēka pārskatīšana ir obligāta (www.clarityarc.com). Piemēram, varat teikt: “Visas labojumu versijas (nelieli labojumi) var tikt automātiski apvienotas pēc testu nokārtošanas, taču jebkuras izmaiņas, kas skar drošības kontroli vai klientu datus, prasa augstāka līmeņa pārskatīšanu.” Šādu politiku dokumentēšana nodrošina, ka MI paātrina piegādi droši (www.clarityarc.com).

2. UX modeļi caurskatāmībai un riskiem

Labi izstrādātas saskarnes palīdz lietotājiem saprast, ko MI darīja, cik lielu uzticību tam piešķirt un kur novirzīt darbu. Šeit ir trīs galvenie UX modeļi:

Izmaiņu (Diff) paskaidrojumi

Kad MI maina kodu (vai tekstu), saskarnei vajadzētu paskaidrot, kas un kāpēc mainīts, nevis vienkārši parādīt neapstrādātas atšķirības (diffs). Cilvēkiem ir nepieciešams konteksts, lai uzticētos MI labojumiem. Piemēram, CV rīks izmantoja vizuālu atšķirību (visual diff), izceļot katru vārdu, ko MI mainīja, jo pretējā gadījumā lietotāji minūtēm ilgi skatītos uz MI rakstītu tekstu (www.matcharesume.com). Līdzīgi koda pārskatīšanā varat izmantot anotācijas vai kopsavilkumus, lai precizētu lielas izmaiņas. Dažas komandas automātiski ģenerē īsu kopsavilkumu vai diagrammu par izmaiņām kopā ar atšķirībām (www.codeant.ai). Rīki, piemēram, CodeAnt, iesaka izmantot plūsmas shēmas vai secības diagrammas papildus teksta atšķirībām, lai parādītu, kā jaunais kods darbojas izpildes laikā (www.codeant.ai).

Praksē: Ikreiz, kad MI piedāvā labojumus, prezentējiet tos viegli saprotamā veidā. Tas varētu nozīmēt koda rindu izcelšanu, kuras MI skāris, automātiski uzrakstīta komentāra, piemēram, “Šeit labota virknes formatēšanas problēma”, nodrošināšanu vai pat diagrammu iegultni sarežģītai loģikai. Mērķis ir caurskatāmība: lietotājam nekavējoties ir jāredz, kas tika mainīts un kādu problēmu tas atrisina. Kā atklāja viena komanda, uzticība strauji pieauga, kad viņi padarīja MI labojumus redzamus un saprotamus, nevis noslēpumainas “pirms/pēc” slaidu veidā (www.matcharesume.com).

Nenoteiktības paziņošana

MI sistēmas pēc būtības ir probabilistiskas, bet vairums saskarņu to slēpj. Tas var maldināt lietotājus pārāk uzticēties MI. Lai veidotu uzticību, skaidri norādiet nenoteiktību vai pārliecības līmeņus. Saskaņā ar UX pētījumiem, saskarnēm nevajadzētu MI atbildes prezentēt ar tādu pašu pārliecību kā deterministiskus datus (www.uxatlas.io). Piemēram, ja koda asistents ievieto sarežģītu funkciju, bet nav pilnībā pārliecināts, apzīmējiet to kā “(Visticamāk pareizs)” vai izmantojiet krāsu kodētu joslu.

Praktiskā līmenī varat attēlot pārliecības rādītājus, mazas brīdinājuma ikonas vai dabiskās valodas apzīmējumus. Piemēram: “Esmu aptuveni 60% pārliecināts, ka šīs izmaiņas atbilst stila noteikumiem, lūdzu, pārbaudiet vēlreiz.” Pētījumi liecina, ka, redzot mērenas pārliecības marķējumu uz MI ģenerēta koda, izstrādātāji to pārbaudīja rūpīgāk un atklāja kļūdas, kuras citādi būtu palaiduši garām (www.uxatlas.io). (Pretēji, perfekti pārliecinoši izskatīgi MI ieteikumi var likt pārskatītājiem pieņemt kļūdas.) Īsāk sakot, neslēpiet MI šaubas – parādiet tās ar UI norādēm, lai cilvēki varētu atbilstoši reaģēt.

Uz risku orientēta maršrutēšana

Ne visas izmaiņas jāsūta vieniem un tiem pašiem pārskatītājiem. Saskarnei un darba plūsmai augsta riska MI izvades jānovirza rūpīgākai pārbaudei. Piemēram, atzīmējiet MI ģenerētos “pull request” (daudzi rīki pievieno robotu kontu vai metadatus) un automātiski palieliniet to pārskatīšanas līmeni. Viena stratēģija ir noteikt pielāgotus noteikumus: ja PR autors ir MI robots, paaugstiniet bloķējošo problēmu smaguma slieksni (www.tenki.cloud). Tādā veidā, MI veidots PR var prasīt divus apstiprinājumus vai pēc noklusējuma aktivizēt papildu CI pārbaudes.

Cits modelis ir riska veida izcelšana tieši UI. Jūs varat atzīmēt, ka izmaiņas skar drošus koda ceļus, vai ka MI bija zema pārliecība, un pēc tam paziņot vecākajam inženierim vai drošības komandai. Automatizētā pārskatīšanas sistēmā zināmas vājās vietas (piemēram, ievades validācija vai kriptogrāfija) var parādīties kā augstākas prioritātes komentāri, lai cilvēki pievērstu papildu uzmanību (www.tenki.cloud).

Praksē: Izmantojiet etiķetes, atzīmes vai īpašas plūsmas, lai novirzītu MI darbu, pamatojoties uz risku. Piemēram, visus aģenta ģenerētos labojumus veiciet, izmantojot stingrāku darba plūsmas ceļu, vai nosūtiet brīdinājumu tehniskajam vadītājam par jebkurām izmaiņām, kas ietekmē kritiskus moduļus. Propel Code norādījumi ir veidot “skaidrus eskalācijas ceļus” — citiem vārdiem sakot, ļaut UI automātiski novirzīt vai bloķēt darbības, kas pārsniedz definētās riska robežas (www.propelcode.ai) (www.clarityarc.com). Tas nodrošina, ka pareizās personas laicīgi redz neskaidras vai svarīgas izmaiņas.

3. Metrika: Uzraudzības un noguruma kalibrēšana

Kā zināt, vai jūsu automatizācijas un pārskatīšanas līdzsvars ir pareizs? Izmantojiet metriku, lai optimizētu uzraudzību. Izsekojiet gan drošības, gan efektivitātes rādītājus:

Pārskatīšanas darba slodze un caurlaidība: Uzraugiet, cik daudz PR vai izmaiņu gaida pārskatīšanu un cik ilgs laiks paiet pārskatīšanai. Ja MI dramatiski palielināja apjomu, cilvēku pārskatītāji var kļūt par vājo punktu. Piemēram, viens pētījums atklāja, ka MI ģenerētajiem “pull request” bija 1,7 reizes vairāk problēmu nekā cilvēka rakstītajiem, pārslogojot komandas (www.tenki.cloud). Ja pārskatīšanas rindas pieaug vai izpildes laiks palielinās, tas liecina par pārskatīšanas nogurumu.
Pārskatītāju atsauksmju metrika: Sekojiet, cik bieži MI ieteikumi tiek pieņemti pretī noraidītiem vai cilvēku labotiem (graphite.com). Augsts noraidīšanas līmenis nozīmē, ka MI ir jāpielāgo vai vairāk jāierobežo. Reģistrējiet arī viltus pozitīvos (kad MI atzīmē problēmu, kas nav problēma) un viltus negatīvos (nepamanītus defektus). Graphite iesaka izsekot pieņemšanas rādītājam un “nepamanītiem kritiskiem jautājumiem”, lai kalibrētu MI jutīgumu (graphite.com).
Kvalitāte un defekti: Mēriet defektu izvairīšanās ātrumu – kļūdu skaitu, kas iekļūst ražošanā uz koda rindu skaitu – ideālā gadījumā sadalot pēc MI pret cilvēka autorību. Propel Code iesaka šo metriku (un “pārskatīšanas lietderīgumu”) kā drošības indikatoru (www.propelcode.ai). Ja defekti pieaug vai nopietnu kļūdu skaits no MI koda palielinās, pastipriniet uzraudzību.
Pārskatīšanas lietderīgums: Novērtējiet, cik noderīgi ir pārskati. Piemēram, reģistrējiet, cik daudz problēmu pārskati atklāj, vai vāciet pārskatītāju apmierinātību, veicot īsas aptaujas. Propel to pat sauc par “pārskatīšanas lietderīgumu” – būtībā jautājot, vai process atklāj problēmas pirms ieviešanas (www.propelcode.ai).

Šī metrika ļauj jums atrast līdzsvaru: ja pārskatītāji ir izsmelti (garas rindas, lēnas sapludināšanas vai samazināta pārskatīšanas kvalitāte (www.techradar.com)), iespējams, jums vajadzēs samazināt obligātās pārbaudes zema riska uzdevumiem. Savukārt, ja defekti pieaug, pastipriniet cilvēka sprieduma robežu. Mērķis ir mazināt nogurumu, vienlaikus saglabājot drošību. Regulāri pārskatiet šos skaitļus un pielāgojiet politikas: varbūt vairāk automatizējiet, kad uzticība pieaug, vai vairāk eskalējiet, ja parādās kļūdas.

4. Eskalācijas protokoli neskaidrībām un augstam riskam

Ne katra situācija atbilst noteikumam. Izveidojiet skaidrus eskalācijas protokolus nestandarta gadījumiem vai lēmumiem ar lielu ietekmi:

Definēt aktivizētājus: Iepriekš izlemiet, kuras situācijas prasa iejaukšanos. Piemēri: MI ziņo par zemu pārliecību, izmaiņas skar kritisko infrastruktūru vai izvade pārkāpj atbilstības noteikumus. Kā norādīts vienā vadlīnijā, ja aģenta lēmums ir ārpus tā “definētajiem parametriem”, tas jānodod cilvēka pārskatīšanai (www.clarityarc.com).
Kas lemj: Piešķiriet atbildību. Tas var būt vecākais inženieris, drošības speciālists vai starpfunkcionāla komiteja. Dokumentējiet, kurš uzņemas eskalētos uzdevumus. Piemēram, varat teikt: “Kritiskas drošības izmaiņas tiek nodotas drošības vadītājam un CTO pārskatīšanai.” ClarityArc ietvars to sauc par “norādītu pārskatītāju” izņēmumiem (www.clarityarc.com).
Slāņveida eskalācija: Ļoti svarīgu jautājumu gadījumā eskalējiet caur vairākiem līmeņiem. Neliels anomālija var nonākt tikai pie tiešā kolēģa pārskatītāja, savukārt datu pārkāpuma risks var iesaistīt Inženierijas vadītāju un Juridisko komandu. Ideja ir ieviest soļus: vispirms ļaujiet vienai personai to atrisināt, pēc tam — rezerves, ja nepieciešams.
Nesodīt par eskalāciju: Lietotāja pieredzes dizainā pārformulējums ir tāds, ka eskalācija vai pārskatīšanas pieprasījums nav kļūme, bet gan normāla pārvaldības daļa. Padariet to bezslogu komandas dalībniekiem, lai tie varētu signalizēt (pogas UI, skaidras veidlapas utt.). Piemēram, viens emuārs iesaka uzskatīt MI-cilvēka nodošanu kā darba plūsmas funkciju, nevis sistēmas sabrukumu (graph.digital).

Praksē: Izstrādājot procesu, skaidri izklāstiet šos protokolus. Iekļaujiet tos dokumentācijā, lai visi zinātu: “Ja MI jautā “Vai man jāizvieto?”, tikai persona X var atbildēt apstiprinoši.” Vai arī UI padomos varētu būt teikts “Nodot vecākajai pārskatīšanai”, kad kāds noklikšķina uz neskaidra ieteikuma. Laika gaitā šie eskalācijas noteikumi ir jāpārbauda un jāprecizē (pēcincidentu analīzes, auditi), lai nodrošinātu, ka neskaidri uzdevumi vienmēr nonāk cilvēku redzeslokā.

Secinājums

Rezumējot, autonomijas un uzraudzības kalibrēšana nozīmē apzinātu lēmumu pieņemšanu par to, ko MI var darīt pats un kas ir jāpārbauda cilvēkiem (www.propelcode.ai) (www.clarityarc.com). Nodrošiniet saskarnes, kas izskaidro MI lēmumus un izceļ nenoteiktību, lai lietotāji saglabātu kontroli (www.uxatlas.io) (www.codeant.ai). Vāciet metriku, piemēram, pieņemšanas rādītājus un defektu izvairīšanos, lai nodrošinātu, ka process nepārslogo pārskatītājus (graphite.com) (www.propelcode.ai). Un vienmēr nodrošiniet skaidru eskalācijas ceļu sarežģītiem vai augsta riska gadījumiem, lai neviens nepaliktu bezspēcīgs cilpā (www.systemsintegrity.org) (www.clarityarc.com).

Šī līdzsvarotā pieeja ir īpaši noderīga komandām, kas ir jaunas MI rīku lietošanā. Sākot ar maziem soļiem (piemēram, ļaujot MI labot lintinga problēmas un mērot rezultātu), pat tie, kas nav kodētāji, var veidot pārliecību. Pirmais solis ir kartēt jūsu darba plūsmu: uzskaitiet savus tipiskos uzdevumus, atzīmējiet to riska līmeņus un izlemiet, kurus no tiem MI var apstrādāt autonomi. Pēc tam ieviesiet vienkāršas pārbaudes un pakāpeniski atkārtojiet. Ar skaidriem ierobežojumiem un komunikāciju MI kļūst par turbokompresoru – paātrinot attīstību, neupurējot kvalitāti vai drošību.

Nākamie soļi: Lai sāktu, izvēlieties pieticīgu projektu vai moduli. Definējiet divus vai trīs lēmumu pieņemšanas punktus (piemēram, “stila labojumi”, “rutīnas aprēķini” un “drošības pārbaudes”) un piešķiriet tos MI vai cilvēkam, kā apspriests. Izmantojiet rezultātu kartes vai vienkāršas izklājlapas, lai izsekotu rezultātiem (atklāto problēmu skaits, pavadītais laiks). Šis praktiskais izmēģinājums atklās, kā precīzi noregulēt jūsu autonomijas/uzraudzības kombināciju. Laika gaitā jūs izstrādāsiet pārvaldību ar pareizo cilvēka iesaistes apjomu, ļaujot radošumam un produktivitātei plaukt, nezaudējot kontroli.