DI sauga: verslo augimas prasideda nuo ribų

Mažai įmonei verta pradėti nuo aiškių dirbtinio intelekto įgaliojimų ir klaidų paieškos, kol jų dar nepastebėjo klientas.

DI sauga prasideda tą akimirką, kai įrankiui leidžiama ne tik pasiūlyti atsakymą, bet ir ką nors pakeisti. Įsivaizduokime nedidelę elektroninę parduotuvę: sistema puikiai rengia laiškus klientams, todėl jai patikima savarankiškai spręsti dėl pinigų grąžinimo. Patogus pagalbininkas gauna teisę priimti sprendimą, kurio pasekmes apmokės verslas. Būtent šį perėjimą verta išnagrinėti dar prieš spaudžiant įjungimo mygtuką.

Smulkiajam verslui nereikia rinktis tarp aklo pasitikėjimo technologija ir atsisakymo ja naudotis. Naudingesnis klausimas daug konkretesnis: kokią klaidą įmonė gali sau leisti, kas ją pastebės ir kaip sustabdys veiksmą? Mano vertinimu, nuo šių atsakymų priklauso, ar automatizavimas taps patikima atrama, ar papildomu darbu vadovui.

Leidimai svarbesni už įspūdingą atsakymą

Y Combinator pokalbio „AI Safety Fact vs. Fiction“ aprašyme sauga pristatoma kaip inžinerijos ir tyrimų sritis. Programoje greta kalbos modelių numatyti formalusis tikrinimas, aviacijos sistemų bandymai ir veikimo stebėsena. Verslui čia naudingas pats klausimo formulavimas: kaip patikrinti sistemos patikimumą, užuot pasitenkinus sklandžiu jos atsakymu?

Parduotuvės pavyzdyje verta atskirti tris skirtingus įgaliojimus: perskaityti užsakymo duomenis, parengti pasiūlymą ir atlikti grąžinimą. Pirmajam bandymui siūlyčiau suteikti tik tuos leidimus, kurių reikia aiškiai apibrėžtai užduočiai. Jeigu tikslas yra sutrumpinti laiško rengimą, teisė keisti mokėjimą prie jo nieko neprideda.

Toks atskyrimas padeda ir susitarti, kas laikoma geru rezultatu. Laiško juodraštį darbuotojas gali pataisyti prieš išsiųsdamas. Savarankiškai atliktą mokėjimą jau tenka taisyti kitu veiksmu. Todėl abiejų užduočių nereikėtų vertinti vien pagal atsakymo tikslumą: svarbi ir klaidos pasekmė, ir galimybė ją laiku pastebėti.

Šis sprendimas glaudžiai susijęs su žmogaus darbo vaidmeniu diegiant dirbtinį intelektą. Vadovui verta iš anksto paskirti, kas tvirtins neįprastus atvejus. Miglotas pažadas, kad „prireikus įsitrauks žmogus“, dar nepasako darbuotojui, kada sustoti ir kam perduoti užduotį.

Išbandykite nepatogų klientą prieš tikrąjį

Pagal paskelbtą programą, nuo 32:11 nagrinėjamas adaptyvusis nepalankių scenarijų testavimas ir jo taikymas nuo aviacijos iki kalbos modelių. Pats pavadinimas skamba akademiškai, tačiau verslo bandymui galima pasirinkti paprastą tikslą: sąmoningai ieškoti aplinkybių, kuriomis sistema suklystų. Tai būtų praktinis įmonės bandymas, o ne aviacijos patikimumo įrodymo pakaitalas.

Užuot pateikus vien mandagų klausimą apie pristatymą, verta parengti prieštaringą užklausą. Pavyzdžiui, išgalvotas klientas prašo pakeisti gavėją ir kartu pateikia su užsakymu nesutampančius duomenis. Kitu bandymu galima paprašyti išimties, kurios įmonės taisyklėse nėra. Tikslas būtų patikrinti, ar sistema sustoja ties savo įgaliojimų riba.

Lietuviškai klientus aptarnaujančiai įmonei siūlyčiau įtraukti trumpinius, rašybos klaidas ir kelias viename laiške sumaišytas problemas. Tai nėra teiginys, kad konkretus modelis tokių užklausų nesupras. Tai būdas patikrinti būtent savo darbo aplinką, užuot sėkmę sprendus pagal kruopščiai parinktą demonstracinį klausimą.

Kiekvienam bandymui naudinga iš anksto parašyti priimtiną veiksmą: atsakyti, paprašyti patikslinimo arba perduoti darbuotojui. Jei komanda pati nesutaria, ką sistema turėtų daryti, bandymas atskleidžia ir proceso spragą. Tokiu atveju pirmas pataisymas turėtų būti aiškesnė įmonės taisyklė.

Matematinis įrodymas turi konkrečią taikymo ribą

Programoje nuo 20:35 numatyta kodo teisingumo įrodymo naudojant „Lean“ tema. Tai verta atskirti nuo bendro pažado, kad visa paslauga yra saugi. Vertinant tokį pasiūlymą, pirkėjui reikėtų prašyti konkretaus atsakymo: kokia savybė tikrinama, kokiai sistemos daliai ir kokiomis prielaidomis?

Tarkime, tiekėjas siūlo patikrintą užsakymo sumos skaičiavimo komponentą. Verslui vis tiek reikėtų atskirai įvertinti, kas gali pakeisti pradinius duomenis ir kas patvirtina išmokėjimą. Tai hipotetinis pirkimo vertinimo pavyzdys: vieno komponento aprašymas neturėtų užpildyti visos saugos klausimyno eilutės.

Panašiai verta vertinti ir sistemos atsakymą, kad ji „patikrino“ savo darbą. Priėmimo sąlyga turėtų būti įmonei suprantamas rezultatas: teisingai pritaikyta taisyklė, išsaugotas patvirtinimas ar sustabdytas neleistinas veiksmas. Pasitikėjimui reikia kriterijaus, kurį galima patikrinti nepriklausomai nuo gražiai parašyto paaiškinimo.

Atsakomybę paskirkite prieš paleisdami sistemą

Techninį bandymą verta papildyti trumpu atsakomybės susitarimu. Kas gali suteikti naujus leidimus? Kas peržiūri klaidas? Kas turi teisę išjungti automatinius veiksmus? Šie klausimai priklauso ir vadovybės sprendimams dėl dirbtinio intelekto, nes darbuotojas neturėtų vienas nuspręsti, kokią finansinę riziką priima įmonė.

Pradžiai siūlyčiau sutarti, kad sistema perduoda žmogui užduotį, kai trūksta būtinos informacijos arba prašomas veiksmas viršija jos leidimus. Kartu reikėtų numatyti, kur tokia užduotis patenka. Jei ji tiesiog dingsta bendrame pašto sraute, numatytas saugiklis klientui mažai padės.

Prieš suteikiant prieigą prie klientų duomenų, verta atskirai peržiūrėti paskyras ir prisijungimo teises. Šalia naujos technologijos išlieka ir įprasti klausimai, kuriuos primena duomenų nutekėjimo bei slaptažodžių tema. Mano siūlymas paprastas: diegimo biudžete numatyti laiko abiem patikroms, o ne viską skirti modelio pasirinkimui.

Pagrindinė pamoka: plėskite įgaliojimus pagal įrodymus

DI sauga turėtų būti kasdienio darbo susitarimas: aiški užduotis, riboti leidimai, nepatogūs bandymai ir paskirtas sprendimo savininkas. Pradėti galima nuo vieno proceso, kuriame darbuotojas dar patvirtina galutinį veiksmą. Tada vertinti, ką sistema atlieka patikimai ir kur žmogui tenka taisyti rezultatą.

Mažai įmonei siūlyčiau daugiau savarankiškumo suteikti tik tada, kai ji gali paaiškinti, kuo grindžia tokį sprendimą. Saugos tikslas čia labai praktiškas: sudaryti sąlygas drąsiau naudoti naudingą technologiją. Įgaliojimus verta plėsti pagal bandymų rezultatus, o ne pagal demonstracijos įspūdį.

Įgaliojimus verta plėsti pagal bandymų rezultatus, o ne pagal demonstracijos įspūdį.

▶

Žiūrėkite originalų epizodą „YouTube“: Y Combinator.

Šaltiniai

• Y Combinator: „AI Safety Fact vs. Fiction | YC Paper Club“ — Remiamasi pateiktu laidos aprašymu ir skyrių programa, o ne stenograma. Susijusios temos: kodo teisingumo įrodymas nuo 20:35, adaptyvusis nepalankių scenarijų testavimas nuo 32:11 ir veikimo stebėsena nuo 40:30.