Pirmoje šios serijos dalyje nustatėme esminį perėjimą nuo generatyvinio prie agentinio dirbtinio intelekto. Ištyrėme, kodėl šis šuolis nuo siūlymo prie vaidybos reikalauja naujo psichologinio ir metodinio įrankių rinkinio UX tyrinėtojams, produktų vadybininkams ir lyderiams. Mes apibrėžėme agentų elgesio taksonomiją nuo siūlymo iki savarankiško veikimo, apibūdinome esminius tyrimo metodus, apibrėžėme agentinio dumblo riziką ir nustatėme atskaitomybės metriką, reikalingą naršyti šioje naujoje teritorijoje. Mes aptarėme, kas ir kodėl. Dabar pereiname nuo pagrindinio prie funkcinio. Šiame straipsnyje pateikiama, kaip: konkretūs projektavimo modeliai, veiklos sistemos ir organizacinė praktika, būtinos kuriant agentų sistemas, kurios yra ne tik galingos, bet ir skaidrios, kontroliuojamos ir vertos vartotojų pasitikėjimo. Jei mūsų tyrimai yra diagnostikos priemonė, šie modeliai yra gydymo planas. Tai yra praktiniai mechanizmai, per kuriuos galime suteikti vartotojams apčiuopiamą kontrolės jausmą, net jei suteikiame AI precedento neturintį savarankiškumą. Tikslas yra sukurti patirtį, kurioje autonomija jaustųsi kaip vartotojo suteikta privilegija, o ne sistemos užgrobta teisė. Pagrindiniai UX modeliai, skirti agentų sistemoms Kuriant agentiniam AI – tai santykiams kurti. Šie santykiai, kaip ir bet kuri sėkminga partnerystė, turi būti grindžiami aiškiu bendravimu, tarpusavio supratimu ir nustatytomis ribomis. Norėdami valdyti perėjimą nuo pasiūlymo prie veiksmo, naudojame šešis modelius, kurie atitinka agentinės sąveikos funkcinį gyvavimo ciklą:
Išankstinis veiksmas (ketinimo nustatymas) Ketinimo peržiūra ir autonomijos rinkimas užtikrina, kad vartotojas apibrėžia planą ir agento ribas, kol kas nors neįvyksta. Veikimas (pateikiamas kontekstas) Paaiškinamas loginis pagrindas ir pasitikėjimo signalas išlaiko skaidrumą, kol agentas dirba, parodydamas „kodėl“ ir „kaip tikrai“. Po veiksmo (saugumas ir atkūrimas) Veiksmų auditas ir anuliavimas bei eskalavimo kelias yra apsauginis tinklas, apsaugantis nuo klaidų ar labai dviprasmiškų momentų.
Toliau išsamiai apžvelgsime kiekvieną modelį, įskaitant sėkmės metrikos rekomendacijas. Šie tikslai yra tipiniai etalonai, pagrįsti pramonės standartais; pakoreguokite juos atsižvelgdami į konkrečią domeno riziką. 1. Tikslo peržiūra: paaiškinimas, kas ir kaip Šis modelis yra pokalbio atitikmuo sakymui: „Štai ką aš ketinu daryti. Ar tau tai gerai? Tai pagrindinis momentas ieškant sutikimo vartotojo ir agento santykiuose. Prieš agentui imdamasi kokių nors reikšmingų veiksmų, vartotojas turi turėti aiškų ir nedviprasmišką supratimą apie tai, kas įvyks. Ketinimo peržiūra arba plano suvestinė suteikia informuotą sutikimą. Tai pokalbio pauzė prieš veiksmą, paverčianti juodą autonominių procesų dėžę į skaidrų, peržiūrimą planą. Psichologinis pagrindas Plano pateikimas prieš veiksmą sumažina kognityvinį krūvį ir pašalina nuostabą, todėl naudotojai turi laiko patikrinti, ar agentas tikrai supranta jų ketinimus. Efektyvaus ketinimo anatomija:
Aiškumas ir glaustumas Peržiūra turi būti iš karto suprantama. Pagrindiniai veiksmai ir rezultatai turėtų būti apibendrinti paprasta kalba, vengiant techninio žargono. Pavyzdžiui, vietoj „Vykdomas API iškvietimas į cancel_booking(id: 4A7B)“ turėtų būti nurodyta „Atšaukti skrydį AA123 į San Franciską“. Nuosekli žingsniai Atliekant kelių etapų operacijas, peržiūroje turėtų būti nurodyti pagrindiniai etapai. Tai atskleidžia agento logiką ir leidžia vartotojams pastebėti galimas problemas siūlomoje sekoje. Aiškūs vartotojo veiksmaiPeržiūra yra sprendimo taškas, o ne tik pranešimas. Jį turi lydėti aiškus pasirinkimų rinkinys. Tai tyčinės trinties akimirka, proceso „greičio guolis“, skirtas užtikrinti, kad vartotojas sąmoningai pasirinktų, ypač kai reikia atlikti negrįžtamus ar daug pinigų reikalaujančius veiksmus.
Peržiūrėkime savo kelionių asistento scenarijų iš pirmosios šios serijos dalies. Naudojame šį aktyvų asistentą, norėdami parodyti, kaip agentas tvarko skrydžio atšaukimą. Agentas aptiko skrydžio atšaukimą ir parengė atkūrimo planą. Tikslo peržiūra atrodytų maždaug taip: Siūlomas kelionės sutrikimo planas Pastebėjau, kad jūsų 10:05 val. skrydis buvo atšauktas. Štai ką aš ketinu daryti: Atšaukti skrydį UA456Apdorokite pinigų grąžinimą ir patvirtinkite atšaukimo informaciją.Pakartotinai užsisakykite skrydį DL789Užsisakykite patvirtintą vietą 14.30 val. be persėdimų skrydžiui, nes tai yra kitas laisvas skrydis be sustojimų.patvirtinta vieta.Atnaujinti viešbučio rezervavimąPraneškite „Marriott“, kad atvyksite vėlai.Atnaujintas maršrutas el. paštu. Išsiųskite informaciją apie naują skrydį ir viešbutį jums ir jūsų padėjėjai Jane Doe.[ Tęskite šį planą ] [ Redaguoti planą ] [ Tvarkykite tai pats ]
Ši peržiūra yra efektyvi, nes joje pateikiamas išsamus vaizdas nuo atšaukimo iki bendravimo ir siūlomi trys skirtingi keliai į priekį: visiškas sutikimas (tęsti), noras keisti (redaguoti planą) arba visiškas nepaisymas (tvarkykite tai pats). Ši daugialypė kontrolė yra pasitikėjimo pagrindas.
Kada teikti pirmenybę šiam modeliui. Dėl šio modelio negalima derėtis atliekant bet kokį veiksmą, kuris yra negrįžtamas (pvz., vartotojo duomenų ištrynimas), susijęs su bet kokios sumos finansine operacija, dalijamasi informacija su kitais žmonėmis ar sistemomis arba atlieka reikšmingus pakeitimus, kurių vartotojas negali lengvai anuliuoti. Praleidimo rizika Be to naudotojai jaučiasi sugauti tarp agento veiksmų ir išjungs funkciją, kad atgautų kontrolę. Sėkmės metrika:
Priėmimo koeficiento planai, priimti be redagavimo / rodomi visi planai. Tikslas > 85 %. Nepaisyti dažnioViso Tvarkykite pats paspaudimų / iš viso rodomų planų. Kai rodiklis > 10 %, suaktyvinamas modelio peržiūra. Prisiminkite AccuracyProcentas testo dalyvių, kurie gali teisingai išvardyti plano veiksmus praėjus 10 sekundžių po to, kai peržiūra buvo paslėpta.
Tai taikymas didelių statymų domenams Nors kelionių planai yra palyginamas pradinis taškas, šis modelis tampa būtinas sudėtingose, daug pinigų reikalaujančiose aplinkose, kur klaida sukelia daugiau nei nepatogumų keliaujančiam asmeniui. Daugelis iš mūsų dirbame aplinkoje, kur dėl neteisingų sprendimų gali nutrūkti sistema, kelti pavojų paciento saugumui arba sukelti daugybę kitų katastrofiškų padarinių, kuriuos gali sukelti nepatikimos technologijos. Apsvarstykite galimybę naudoti „DevOps“ leidimų agentą, kuriam pavesta valdyti debesų infrastruktūrą. Šiame kontekste „Intent Preview“ veikia kaip apsauginis barjeras nuo atsitiktinių prastovų.
Šioje sąsajoje specifinė terminologija (Eismo nutekėjimas, Atšaukimas) pakeičia bendruosius dalykus, o veiksmai yra dvejetainiai ir paveikūs. Naudotojas, remdamasis agento logika, leidžia atlikti didelį operatyvinį pakeitimą, o ne patvirtinti pasiūlymą. 2. Autonomy Dial: pasitikėjimo kalibravimas naudojant laipsnišką leidimą Visi sveiki santykiai turi ribas. „Autonomy Dial“ yra tai, kaip vartotojas jį nustato su savo agentu, apibrėždamas, kas jam patinka, kai agentas tvarko vienas. Pasitikėjimas nėra dvejetainis jungiklis; tai spektras. Vartotojas gali pasitikėti agentu, kad jis savarankiškai atliks mažų sumų reikalaujančias užduotis, tačiau reikalauti visiško patvirtinimo, kai priimami dideli sprendimai. Autonomy Dial, laipsniško autorizavimo forma, leidžia vartotojams nustatyti pageidaujamą agento nepriklausomumo lygį, todėl jie aktyviai dalyvauja apibrėžiant santykius. Psichologinis pagrindas Leidžiant vartotojams sureguliuoti agento autonomiją, jiems suteikiama kontrolės vieta, leidžianti suderinti sistemos elgesį su jų asmenine tolerancija rizikai. ĮdiegimasTai gali būti įdiegtas kaip paprastas, aiškus nustatymas programoje, idealiu atveju kiekvienos užduoties tipo pagrindu. Naudojant mūsų pirmojo straipsnio taksonomiją, nustatymai gali būti tokie:
Stebėti ir siūlyti Noriu būti įspėtas apie galimybes ar problemas, bet agentas niekada nepasiūlys plano. Planuoti ir siūlyti Agentas gali kurti planus, bet prieš imdamasis kokių nors veiksmų privalau juos peržiūrėti. Veikti su patvirtinimu Atliekant pažįstamas užduotis, agentas gali paruošti veiksmus, o aš pateiksiu galutinį patvirtinimą, kad eiti/nevykti. Veikti savarankiškai Atliekant iš anksto patvirtintas užduotis (pvz., užginčyti mokesčius, mažesnius nei 50 USD), agentas gali veikti savarankiškai ir pranešti man po to.
Pavyzdžiui, el. pašto asistentas gali turėti atskirą autonominį ratuką susitikimų planavimui, o ne el. laiškų siuntimui vartotojo vardu. Šis detalumas yra labai svarbus, nes jis atspindi niuansuotą vartotojo pasitikėjimo tikrovę. Kada teikti pirmenybę šiam modeliui Pirmenybę teikite sistemose, kuriose užduočių rizika ir asmeniniai pageidavimai labai skiriasi (pvz., finansų valdymo įrankiai, komunikacijos platformos). Tai būtina norint pradėti naudotis, nes naudotojai gali pradėti nuo mažos autonomijos ir didinti jų pasitikėjimą savimi. Praleidimo rizika Be to vartotojai, patyrę vieną gedimą, visiškai atsisakys agento, o ne tiesiog susigrąžins jo leidimus. Sėkmės metrika:
Pasitikėjimo tankis Naudotojų procentinė dalis pagal nustatymą (pvz., 20 % pasiūlymas, 50 % patvirtinimas, 30 % automatinis). Setting ChurnNustatymo pakeitimų skaičius / Bendras aktyvių naudotojų skaičius per mėnesį. Didelis susitraukimas rodo pasitikėjimąnepastovumas.
3. Paaiškinamas pagrindas: atsakymas Kodėl? Po veiksmo geras partneris paaiškina savo samprotavimus. Šis modelis yra atviras bendravimas, vykstantis po veiksmo, atsakant į klausimą Kodėl? net nepaklausus. „Tai padariau, nes anksčiau man sakei, kad tau labiau patinka X. Kai agentas veikia, ypač autonomiškai, vartotojui dažnai kyla klausimas: kodėl jis tai padarė? Paaiškinamo pagrindo modelis aktyviai atsako į šį klausimą, pateikdamas glaustą agento sprendimų pagrindimą. Tai nėra techninis žurnalo failas. Pirmajame šios serijos straipsnyje aptarėme sistemos primityvų vertimą į vartotojui skirtą kalbą, kad išvengtume apgaulės. Šis modelis yra praktinis šio principo taikymas. Ji paverčia neapdorotą logiką į žmogui suprantamą paaiškinimą, pagrįstą paties vartotojo nurodytomis nuostatomis ir ankstesnėmis įvestimis. Psichologinis pagrindas Kai agento veiksmai yra paaiškinami, jie jaučiasi logiški, o ne atsitiktiniai, o tai padeda vartotojui sukurti tikslų psichikos modelį, kaip agentas mąsto. Veiksmingi pagrindai:
Grounded in PrecedentGeriausi paaiškinimai yra susiję su taisykle, nuostata ar ankstesniu veiksmu. Paprasta ir tiesioginė Venkite sudėtingos sąlyginės logikos. Naudokite paprastą struktūrą „Kadangi tu sakei X, aš padariau Y“.
Grįžtant prie kelionės pavyzdžio, po to, kai skrydis perskirstomas savarankiškai, naudotojas gali matyti tai savo pranešimų sklaidos kanale: Iš naujo rezervavau jūsų atšauktą skrydį.Naujas skrydis: Delta 789, išvyksta 14:30.Kodėl ėmiausi šio veiksmo:Oro linijų bendrovė atšaukė jūsų pradinį skrydį.Jūs iš anksto patvirtinote savarankišką rezervavimą tos pačios dienos skrydžiams be sustojimų.[ Peržiūrėti naują maršrutą ] [Anuliuoti šį veiksmą]
Loginis pagrindas yra aiškus, pagrįstas ir sustiprina mintį, kad agentas veikia vartotojo nustatytose ribose. Kada teikti pirmenybę šiam modeliui Suteikite jam pirmenybę bet kokiam savarankiškam veiksmui, kai motyvai nėra iš karto akivaizdūs iš konteksto, ypač veiksmams, kurie atliekami fone arba kuriuos sukelia išorinis įvykis (pvz., skrydžio atšaukimo pavyzdys). Praleidimo rizika Be šito naudotojai teisingus savarankiškus veiksmus interpretuoja kaip atsitiktinį elgesį arba „klaidas“, neleidžiančias jiems suformuoti teisingo psichikos modelio. Sėkmės metrika:
Kodėl? Bilietų apimtis Palaikymo bilietų, pažymėtų „Agento elgsena – neaiški“, skaičius 1 000 aktyvių vartotojų. Loginis patvirtinimas Naudotojų, įvertinusių paaiškinimą kaip „Naudingą“, procentas atliekant mikroapklausas po sąveikos.
4. Pasitikėjimo signalas Šis modelis yra susijęs su agento suvokimu santykiuose. Perduodamas savo pasitikėjimą, jis padeda vartotojui nuspręsti, kada pasitikėti savo sprendimu, o kada taikyti išsamesnį patikrinimą. Kad padėtų vartotojams kalibruoti savo pasitikėjimą, agentas turėtų parodyti savo pasitikėjimą savo planais ir veiksmais. Dėl to tarpininko vidinė būsena tampa lengviau įskaitoma ir vartotojas gali nuspręsti, kada atidžiau išnagrinėti sprendimą. Psichologinis pagrindas Netikrumas padeda išvengti automatizavimo šališkumo, skatina vartotojus atidžiai išnagrinėti žemo pasitikėjimo planus, o ne aklai juos priimti. Įgyvendinimas:
Pasitikėjimo balasPaprastas procentas (pvz., Pasitikėjimas: 95 %) gali būti greitas, nuskaitomas rodiklis. Apimties deklaracija Aiškus agento kompetencijos srities pareiškimas (pvz., Apimtis: tik kelionių užsakymai) padeda valdyti vartotojų lūkesčius ir neleidžia jiems prašyti agento atlikti užduotis, kurioms jis nėra skirtas. Vizualiniai ženklai Žalia varnelė gali reikšti didelį pasitikėjimą, o geltonas klaustukas gali reikšti netikrumą, todėl vartotojas gali atidžiau peržiūrėti.
Kada teikti pirmenybę šiam modeliui Suteikite pirmenybę, kai agento našumas gali labai skirtis, atsižvelgiant į įvesties duomenų kokybę arba užduoties dviprasmiškumą. Jis ypač vertingas ekspertinėse sistemose (pvz., medicinos pagalbos priemonėse, kodų pagalbinėse priemonėse), kur žmogus turi kritiškai įvertinti AI produkciją. Praleidimo rizika Be to vartotojai taps automatizavimo šališkumo aukomis, aklai priims žemo pasitikėjimo haliucinacijas arba su nerimu dar kartą patikrins didelio pasitikėjimo darbą. Sėkmės metrika:
Kalibravimo balas Pearson koreliacija tarp modelio pasitikėjimo balo ir naudotojo priėmimo rodiklio. Tikslas > 0,8. Tikrinimo delta Skirtumas tarp žemo patikimumo planų ir didelio patikimumo planų vidutinio peržiūros laiko. Tikimasi, kad bus teigiamas (pvz., +12 sekundžių).
5. Veiksmų auditas ir anuliavimas: didžiausias saugos tinklas Pasitikėjimas reikalauja žinoti, kad galite atsigauti po klaidos. Anuliuotifunkcija yra pagrindinis santykių apsaugos tinklas, užtikrinantis vartotoją, kad net jei agentas neteisingai supras, pasekmės nebus katastrofiškos. Pats galingiausias vartotojo pasitikėjimo stiprinimo mechanizmas yra galimybė lengvai pakeisti agento veiksmus. Patvarus, lengvai skaitomas veiksmų audito žurnalas su aiškiai matomu mygtuku Anuliuoti kiekvieną įmanomą veiksmą yra didžiausias apsaugos tinklas. Tai žymiai sumažina suvokiamą autonomijos suteikimo riziką. Psichologinis pagrindas Žinojimas, kad klaida gali būti lengvai atšaukta, sukuria psichologinį saugumą, skatina vartotojus deleguoti užduotis, nebijant negrįžtamų pasekmių. Geriausia dizaino praktika:
Laiko juostos vaizdas Chronologinis visų agento inicijuotų veiksmų žurnalas yra pats intuityviausias formatas. Išvalyti būsenos indikatorius Rodykite, ar veiksmas buvo sėkmingas, vykdomas ar buvo anuliuotas. Laiku ribojamas atšaukimas Veiksmams, kurie po tam tikro momento tampa negrįžtami (pvz., užsakymas, kurio pinigai negrąžinami), vartotojo sąsaja turi aiškiai pranešti apie šį laiko langą (pvz., Anuliuoti galima 15 minučių). Šis sistemos apribojimų skaidrumas yra toks pat svarbus kaip ir pati atšaukimo galimybė. Sąžiningumas, kai veiksmas tampa nuolatinis, sukuria pasitikėjimą.
Kada teikti pirmenybę šiam modeliui Tai yra pagrindinis modelis, kuris turėtų būti įgyvendintas beveik visose agentų sistemose. Tai visiškai nediskutuotina diegiant autonomines funkcijas arba kai klaidos kaina (finansinė, socialinė ar su duomenimis susijusi) yra didelė. Praleidimo rizika Be to viena klaida visam laikui sugriauna pasitikėjimą, nes vartotojai supranta, kad neturi apsauginio tinklo. Sėkmės metrika:
Grąžinimo rodiklisAtšaukti veiksmai / Iš viso atliktų veiksmų. Jei konkrečios užduoties grąžinimo rodiklis > 5%, išjunkite tos užduoties automatizavimą. Saugos tinklo konversijaProcentas naudotojų, kurie atnaujina į savarankišką veiksmą per 7 dienas nuo sėkmingo anuliavimo naudojimo.
6. Eskalavimo kelias: dailiai elkitės su neapibrėžtumu Protingas partneris žino, kada kreiptis pagalbos, o ne spėlioti. Šis modelis leidžia agentui grakščiai susidoroti su dviprasmybėmis, eskaluojant vartotoją, demonstruodamas nuolankumą, kuris stiprina, o ne griauna pasitikėjimą. Netgi pažangiausias agentas susidurs su situacijomis, kai nėra tikras dėl vartotojo ketinimų ar geriausio veiksmų būdo. Tai, kaip ji susidoroja su šiuo netikrumu, yra lemiamas momentas. Gerai suplanuotas agentas neatspėja; tai eskaluoja. Psichologinis pagrindas Kai agentas pripažįsta savo ribas, o ne spėlioja, jis sukuria pasitikėjimą gerbdamas vartotojo autoritetą dviprasmiškose situacijose. Eskalavimo modeliai apima:
Prašymas paaiškinti „Paminėjote „kitą antradienį“. Ar turite omenyje rugsėjo 30 d. ar spalio 7 d.? Pristatome parinktis „Radau tris skrydžius, atitinkančius jūsų kriterijus. Kuris jums atrodo geriausias?“ Žmogaus įsikišimo prašymas Atliekant didelius ar labai dviprasmiškus darbus, agentas turi turėti aiškų kelią, kaip pasitelkti ekspertą arba pagalbinį agentą. Raginimas gali būti toks: „Ši operacija atrodo neįprasta, ir aš nesu įsitikinęs, kaip elgtis toliau. Ar norėtumėte, kad tai pažymėčiau, kad agentas peržiūrėtų?
Kada teikti pirmenybę šiam modeliui Pirmenybę teikite domenams, kuriuose naudotojo ketinimai gali būti dviprasmiški arba labai priklausomi nuo konteksto (pvz., natūralios kalbos sąveika, sudėtingos duomenų užklausos). Naudokite tai, kai agentas dirba su nepilna informacija arba kai yra keli teisingi keliai. Praleidimo rizika Be to agentas galiausiai padarys patikimą, katastrofišką spėjimą, kuris atstumia vartotoją. Sėkmės metrika:
Escalation FrequencyAgent Requests for Help / Total Tasks. Sveikas diapazonas: 5-15%. Atkūrimo sėkmės rodiklio užduotys, baigtos po eskalavimo / bendras eskalavimas. Tikslas > 90 proc.
Šablonas Geriausias Pirminė rizika Pagrindinė metrika Tikslo peržiūra Negrįžtami arba finansiniai veiksmai Vartotojas jaučiasi apgautas >85 % priėmimo rodiklis Autonomijos rinkimas Užduotys su kintamu rizikos lygiu Visiškas funkcijų atsisakymas Churn nustatymas Paaiškinamas pagrindimas Foninės arba savarankiškos užduotys Vartotojas pastebi klaidas "Kodėl?" Bilietų tūris Pasitikėjimo signalas Ekspertų arba didelių statymų sistemos Automatikos šališkumas Tikrinimas Delta Veiksmo patikrinimas ir anuliavimas Visos agentinės sistemos Nuolatinis pasitikėjimo praradimas <5 %Grįžimo koeficientas Eskalavimo kelias Dviprasmiškas vartotojo tikslas Pasitikintys, katastrofiški spėjimai >90% sėkmingo atkūrimo
1 lentelė: Agentinio AI UX modelių suvestinė. Nepamirškite pakoreguoti metrikos pagal konkrečią domeno riziką ir poreikius. Projektavimas remontui ir taisymui Taip išmokstama veiksmingai atsiprašyti. Geras atsiprašymas pripažįsta klaidą, ištaiso žalą ir pažada iš jos pasimokyti. Klaidos nėra galimybės; jie yra neišvengiamybė. Ilgalaikė agentinės sistemos sėkmė mažiau priklauso nuo jos gebėjimo būti tobulai, o nuo jos gebėjimo grakščiai atsigauti, kai nepavyksta. Tvirta taisymo ir žalos atlyginimo sistema yra pagrindinė savybė, o ne pasekmė. Empatiški atsiprašymai ir aiškus ištaisymas Kai agentas padaro klaidą, klaidos pranešimas yra atsiprašymas. Jis turi būti sukurtas psichologiškai tiksliai. Ši akimirka yra labai svarbi galimybė parodyti atsakomybę. Žvelgiant iš paslaugų dizaino perspektyvos, čia įmonės gali pasinaudoti paslaugų atkūrimo paradoksu: reiškiniu, kai klientas, patyręs paslaugos gedimą, po kurio sėkmingai ir empatiškai atsigauna, iš tikrųjų gali tapti lojalesni nei klientas, kuris niekada nepatyrė nesėkmės. Gerai ištaisyta klaida gali būti galingesnis pasitikėjimą ugdantis įvykis nei ilga nepriekaištingo vykdymo istorija. Svarbiausia yra traktuoti klaidą kaip santykių nutrūkimą, kurį reikia ištaisyti. Tai apima:
Patvirtinkite klaidą Pranešime turėtų būti aiškiai ir paprastai nurodyta, kad buvo padaryta klaida.Pavyzdys: neteisingai pervedžiau lėšas. Nurodykite neatidėliotiną pataisymą Nedelsdami imkitės taisomųjų veiksmų.Pavyzdys: atšaukiau veiksmą ir lėšos buvo grąžintos į jūsų sąskaitą. Pateikite tolesnės pagalbos kelią Visada pasiūlykite aiškią nuorodą į žmonių pagalbą. Tai sumažina nusivylimą ir parodo, kad yra atskaitomybės sistema už paties agento ribų.
Gerai suprojektuota taisymo vartotojo sąsaja gali atrodyti taip: Neseniai pervesdami padarėme klaidą. Atsiprašau. Pervedžiau 250 USD į netinkamą sąskaitą.✔ Taisomosios priemonės: pervedimas atšauktas, o 250 USD grąžinta.✔ Kiti veiksmai: incidentas pažymėtas vidiniam peržiūrai, kad jis nepasikartotų. Reikia daugiau pagalbos? [Susisiekite su palaikymo komanda]
Saugių inovacijų valdymo variklio kūrimas Aukščiau aprašyti dizaino modeliai yra vartotojui skirti valdikliai, tačiau jie negali efektyviai veikti be tvirtos vidinės atramos struktūros. Tai ne apie biurokratinių kliūčių kūrimą; kalbama apie strateginio pranašumo sukūrimą. Subrendusią valdymo sistemą turinti organizacija gali greičiau ir patikimiau pristatyti ambicingesnes agentų funkcijas, žinodama, kad yra sukurti būtini apsauginiai turėklai, siekiant sumažinti prekės ženklo riziką. Šis valdymo variklis paverčia saugą iš kontrolinio sąrašo į konkurencinį turtą. Šis variklis turėtų veikti kaip oficialus valdymo organas – Agentinė AI etikos taryba, kurią sudaro daugiafunkcinis UX, produkto ir inžinerijos aljansas, kuriam reikalinga teisinė, atitikties ir palaikymo tarnyba. Mažesnėse organizacijose šie „Tarybos“ vaidmenys dažnai susitraukia į vieną produkto, inžinerijos ir dizaino vadovų triadą. Kontrolinis valdymo sąrašas
Teisė / atitiktisŠi komanda yra pirmoji gynybos linija, užtikrinanti, kad galimi agento veiksmai neviršytų reguliavimo ir teisinių ribų. Jie padeda apibrėžti autonominio veikimo zonas, kuriose draudžiama judėti. Produktas Produkto vadovas yra agento tikslo prižiūrėtojas. Jie apibrėžia ir stebi jo veiklos ribas taikydami formalią autonomijos politiką, kuri dokumentuoja, ką agentas yra ir kam neleidžiama daryti. Jiems priklauso agento rizikos registras. UX tyrimaiŠi komanda yra vartotojo pasitikėjimo ir nerimo balsas. Jie yra atsakingi už pasikartojantį pasitikėjimo kalibravimo tyrimų, imituojamų netinkamo elgesio testų ir kokybinių interviu procesą, kad suprastų besikeičiantį vartotojo psichinį agento modelį. Inžinerija Ši komanda kuria techninius pasitikėjimo pagrindus. Jie turi sukurti sistemą, kad būtų užtikrintas patikimas registravimas, vieno paspaudimo atšaukimo funkcija ir kabliukai, reikalingi aiškiems, paaiškinamiems pagrindams sukurti. Palaikymas Šios komandos atsidūrė priešakinėse nesėkmių linijose. Jie turi būti apmokyti ir aprūpinti incidentus, sukeltus agento klaidų, ir turėti tiesioginį grįžtamąjį ryšį su Etikos taryba, kad praneštų apie realaus pasaulio gedimų modelius.
Ši valdymo struktūra turėtų išlaikyti agyvų dokumentų rinkinys, įskaitant agento rizikos registrą, kuris aktyviai nustato galimų gedimų režimus, Veiksmų audito žurnalus, kurie yra reguliariai peržiūrimi, ir oficialią autonomijos politikos dokumentaciją. Nuo ko pradėti: laipsniškas produktų lyderių požiūris Produktų vadovams ir vadovams agentinio AI integravimas gali atrodyti kaip didžiulė užduotis. Svarbiausia tai vertinti ne kaip vieną paleidimą, o kaip laipsnišką kelionę kuriant technines galimybes ir vartotojų pasitikėjimą lygiagrečiai. Šis planas leidžia jūsų organizacijai mokytis ir prisitaikyti, užtikrinant, kad kiekvienas žingsnis būtų pastatytas ant tvirto pagrindo. 1 etapas: pagrindinė sauga (pasiūlyti ir pasiūlyti) Pradinis tikslas yra sukurti pasitikėjimo pagrindą nepriimant didelės savarankiškos rizikos. Šiame etape agento galia apsiriboja analize ir pasiūlymais.
Įdiekite tvirtą „Intent“ peržiūrą: tai yra jūsų pagrindinis sąveikos modelis. Įsitikinkite, kad agentas formuoja planus, o naudotojas gali visiškai kontroliuoti vykdymą. Sukurkite veiksmų audito ir anuliavimo infrastruktūrą: net jei agentas dar neveikia savarankiškai, pastatykite techninius pastolius, skirtus registravimui ir atšaukimui. Tai paruošia jūsų sistemą ateičiai ir padidina vartotojų pasitikėjimą, kad saugos tinklas yra.
2 etapas: sukalibruota autonomija (veiksmas su patvirtinimu) Kai naudotojai bus patenkinti agento pasiūlymais, galite pradėti diegti mažos rizikos autonomiją. Šis etapas skirtas mokyti vartotojus, kaip agentas galvoja, ir leisti jiems nustatyti savo tempą.
Pristatykite autonominį rinkimą su ribotais nustatymais: pradėkite leisdami vartotojams suteikti agentui teisę veikti su patvirtinimu. Taikykite paaiškinamą pagrindimą: kiekvienam agento paruoštam veiksmui pateikite aiškų paaiškinimą. Tai išsklaido agento logiką ir patvirtina, kad jis veikia pagal paties vartotojo pageidavimus.
3 etapas: aktyvus delegavimas (veikite savarankiškai) Tai paskutinis žingsnis, atliekamas tik tada, kai turite aiškių ankstesnių etapų duomenų, įrodančių, kad vartotojai pasitiki sistema.
Įgalinti savarankišką veiksmų atlikimą konkrečioms, iš anksto patvirtintoms užduotims: naudokite 2 etapo duomenis (pvz., didelius vykdymo rodiklius, mažus anuliavimo rodiklius), kad nustatytumėte pirmąjį mažos rizikos užduočių, kurias galima visiškai automatizuoti, rinkinį. Stebėkite ir kartokite: autonominių funkcijų paleidimas yra ne pabaiga, o nuolatinio našumo stebėjimo, vartotojų atsiliepimų rinkimo ir agento taikymo srities bei elgesio tobulinimo, remiantis realaus pasaulio duomenimis, ciklo pradžia.
Dizainas kaip didžiausia saugos svirtis Agentinio AI atsiradimas yra nauja žmogaus ir kompiuterio sąveikos riba. Tai žada ateitį, kurioje technologijos gali aktyviai sumažinti mūsų naštą ir supaprastinti mūsų gyvenimą. Tačiau ši galia apima didelę atsakomybę. Savarankiškumas yra techninės sistemos rezultatas, o patikimumas yra projektavimo proceso rezultatas. Mūsų iššūkis yra užtikrinti, kad naudotojo patirtis būtų ne techninių galimybių auka, o pagrindinis jos naudos gavėjas. Mūsų, kaip UX profesionalų, produktų vadybininkų ir lyderių, vaidmuo yra veikti kaip šio pasitikėjimo valdytojai. Taikydami aiškius valdymo ir sutikimo projektavimo modelius, kurdami apgalvotus remonto būdus ir kurdami tvirtas valdymo sistemas, sukuriame esminius saugos svertus, kurie daro agentinį AI gyvybingą. Mes ne tik kuriame sąsajas; mes kuriame santykius. AI naudingumo ir priimtinumo ateitis priklauso nuo mūsų gebėjimo kurti šias sudėtingas sistemas išmintingai, įžvalgiai ir giliai gerbiant aukščiausią vartotojo autoritetą.
