Agentiškas AI yra pasirengęs pakeisti klientų patirtį ir veiklos efektyvumą, todėl vadovybė reikalauja naujo strateginio požiūrio. Ši dirbtinio intelekto raida suteikia sistemoms galimybę planuoti, vykdyti ir atkakliai atlikti užduotis, o ne tik rekomendacijas, bet ir aktyvius veiksmus. UX komandoms, produktų vadybininkams ir vadovams labai svarbu suprasti šį pokytį, norint atverti naujovių galimybes, supaprastinti darbo eigą ir iš naujo apibrėžti, kaip technologijos tarnauja žmonėms. Nesunku supainioti „Agentic AI“ su robotų procesų automatizavimu (RPA), kuri yra technologija, orientuota į taisyklėmis pagrįstas užduotis, atliekamas kompiuteriuose. Skirtumas yra nelankstumas ir samprotavimas. RPA puikiai sekasi laikytis griežto scenarijaus: jei atsitinka X, darykite Y. Jis imituoja žmogaus rankas. Agentinis AI imituoja žmogaus samprotavimus. Jis nesilaiko linijinio scenarijaus; jis sukuria vieną. Apsvarstykite įdarbinimo darbo eigą. RPA robotas gali nuskaityti gyvenimo aprašymą ir įkelti jį į duomenų bazę. Jis puikiai atlieka pasikartojančią užduotį. Agentų sistema peržiūri gyvenimo aprašymą, pastebi, kad kandidatas pateikia konkretų sertifikatą, pateikia kryžmines nuorodas su nauju kliento reikalavimu ir nusprendžia parengti asmeninį informavimo el. laišką, kuriame pabrėžiama ši atitiktis. RPA vykdo iš anksto nustatytą planą; Agentiškas AI suformuluoja planą pagal tikslą. Ši autonomija atskiria agentus nuo nuspėjimo įrankių, kuriuos naudojome pastarąjį dešimtmetį. Kitas pavyzdys – susitikimų konfliktų valdymas. Nuspėjamasis modelis, integruotas į jūsų kalendorių, gali analizuoti jūsų susitikimų tvarkaraštį ir kolegų tvarkaraščius. Tada jis gali pasiūlyti galimus konfliktus, pvz., du svarbius susitikimus, suplanuotus tuo pačiu metu, arba susitikimą, suplanuotą, kai pagrindinis dalyvis atostogauja. Ji suteikia jums informacijos ir pažymi galimas problemas, tačiau jūs esate atsakingi už veiksmų atlikimą. Agentinis AI pagal tą patį scenarijų neapsiribotų tik konfliktų, kurių reikia vengti, siūlymas. Nustatęs konfliktą su pagrindiniu dalyviu, agentas gali veikti taip:
Visų reikiamų dalyvių prieinamumo patikrinimas. Alternatyvių laiko tarpsnių, tinkamų visiems, nustatymas. Siūlomų naujų susitikimo kvietimų išsiuntimas visiems dalyviams. Jei konfliktas kyla su išoriniu dalyviu, agentas gali parengti ir išsiųsti el. laišką, kuriame paaiškinama, kad reikia pakeisti tvarkaraštį, ir pasiūlytų alternatyvų laiką. Kai patvirtinsite, atnaujinsite savo ir kolegų kalendorius su nauja susitikimo informacija.
Šis agentinis AI supranta tikslą (susitikimo konflikto išsprendimą), planuoja veiksmus (pasiekiamumo tikrinimas, alternatyvų radimas, kvietimų siuntimas), atlieka tuos veiksmus ir tęsiasi tol, kol konfliktas bus išspręstas, visa tai su minimaliu tiesioginiu vartotojo įsikišimu. Tai parodo „agentinį“ skirtumą: sistema imasi aktyvių veiksmų už vartotoją, o ne tik teikia informaciją vartotojui. Agentinės AI sistemos supranta tikslą, suplanuoja eilę žingsnių jam pasiekti, atlieka tuos veiksmus ir netgi prisitaiko, jei kas nutiktų ne taip. Pagalvokite apie tai kaip apie aktyvų skaitmeninį asistentą. Pagrindinė technologija dažnai derina didelius kalbos modelius (LLM), kad suprastų ir mąstytų, su planavimo algoritmais, kurie sudėtingas užduotis suskaido į valdomus veiksmus. Šie agentai gali sąveikauti su įvairiais įrankiais, API ir net kitais AI modeliais, kad pasiektų savo tikslus, o kritiškai tariant, jie gali išlaikyti nuolatinę būseną, tai reiškia, kad jie prisimena ankstesnius veiksmus ir laikui bėgant toliau siekia tikslo. Dėl to jie iš esmės skiriasi nuo įprasto generatyvaus AI, kuris paprastai užpildo vieną užklausą ir tada nustato iš naujo. Paprasta agentų elgesio taksonomija Agento elgesį galime suskirstyti į keturis skirtingus savarankiškumo būdus. Nors jie dažnai atrodo kaip progresas, jie veikia kaip nepriklausomi veikimo režimai. Vartotojas gali pasitikėti agentu, kad jis veiks savarankiškai planuodamas, tačiau finansinėms operacijoms palikti jį „pasiūlymo režimu“. Šiuos lygius išvedėme pritaikydami autonominių transporto priemonių pramonės standartus (SAE lygius) prie skaitmeninių naudotojų patirties kontekstų. Stebėkite ir siūlykite Agentas veikia kaip monitorius. Ji analizuoja duomenų srautus ir pažymi anomalijas ar galimybes, bet nesiima jokių veiksmų. Skirtumas Skirtingai nuo kito lygio, agentas nesukuria sudėtingo plano. Tai rodo problemą. PavyzdysA DevOps agentas pastebi serverio procesoriaus šuolį ir įspėja budintį inžinierių. Ji nežino, kaip ar bando tai ištaisyti, bet žino, kad kažkas negerai. Poveikis projektavimui ir priežiūrai Šiame lygyjekuriant ir prižiūrint pirmenybė turėtų būti teikiama aiškiems, neįkyriems pranešimams ir aiškiai apibrėžtam procesui, kuriuo naudotojai gali imtis veiksmų pagal pasiūlymus. Pagrindinis dėmesys skiriamas naudotojo įgalinimui laiku gauti svarbią informaciją, neperimant kontrolės. UX praktikai turėtų sutelkti dėmesį į tai, kad pasiūlymai būtų aiškūs ir lengvai suprantami, o produktų vadybininkai turi užtikrinti, kad sistema suteiktų vertę ir neužgožtų vartotojo. Planuokite ir pasiūlykite Agentas nustato tikslą ir sukuria kelių žingsnių strategiją jam pasiekti. Jame pateikiamas visas žmonių peržiūros planas. Diferenciacija Agentas veikia kaip strategas. Jis nevykdo; jis laukia patvirtinimo visam požiūriui. PavyzdysTas pats „DevOps“ agentas pastebi procesoriaus smaigalį, analizuoja žurnalus ir pasiūlo ištaisymo planą:
Sukurkite du papildomus egzempliorius. Iš naujo paleiskite apkrovos balansavimo priemonę. Archyvuokite senus žurnalus.
Žmogus peržiūri logiką ir paspaudžia „Patvirtinti planą“. Poveikis projektavimui ir priežiūrai Planuojantiems ir siūlantiems agentams projektavimas turi užtikrinti, kad siūlomi planai būtų lengvai suprantami ir kad vartotojai turėtų intuityvius būdus juos keisti arba atmesti. Priežiūra yra labai svarbi stebint pasiūlymų kokybę ir agento planavimo logiką. UX specialistai turėtų sukurti aiškias siūlomų planų vizualizacijas, o produktų vadovai turi nustatyti aiškias peržiūros ir patvirtinimo darbo eigas. Veikti su patvirtinimu Agentas užbaigia visus parengiamuosius darbus ir pateikia galutinį veiksmą į sceninę būseną. Jis veiksmingai išlaiko duris atidarytas, laukdamas linktelėjimo. AtskyrimasTai skiriasi nuo „Planuok ir siūlyk“, nes darbas jau atliktas ir suplanuotas. Tai sumažina trintį. Vartotojas patvirtina rezultatą, o ne strategiją. PavyzdysĮdarbinimo agentas parengia penkis kvietimus į pokalbį, kalendoriuose suranda darbo laiką ir sukuria kalendoriaus įvykius. Jame yra mygtukas „Siųsti viską“. Vartotojas suteikia galutinį leidimą pradėti išorinį veiksmą. Poveikis projektavimui ir priežiūrai Kai agentai veikia su patvirtinimu, projekte turi būti pateiktos skaidrios ir glaustos numatomo veiksmo santraukos, aiškiai nurodant galimas pasekmes. Priežiūra turi patikrinti, ar patvirtinimo procesas yra patikimas ir ar naudotojai nėra raginami aklai patvirtinti veiksmus. UX praktikai turėtų sukurti aiškius patvirtinimo raginimus, kuriuose būtų pateikta visa reikalinga informacija, o produktų vadovai turėtų teikti pirmenybę patikimai visų patvirtintų veiksmų audito sekai. Veik-Autonomiškai Agentas savarankiškai vykdo užduotis apibrėžtose ribose. Atskyrimas Vartotojas peržiūri veiksmų istoriją, o ne pačius veiksmus. PavyzdysĮdarbinimo agentas mato konfliktą, perkelia pokalbį į atsarginį laikotarpį, atnaujina kandidatą ir praneša samdos vadovui. Žmogus mato tik pranešimą: pokalbis perkeltas į antradienį. Poveikis projektavimui ir priežiūrai Savarankiškiems agentams projektuojant reikia nustatyti aiškias iš anksto patvirtintas ribas ir pateikti patikimus stebėjimo įrankius. Priežiūra reikalauja nuolatinio agento našumo įvertinimo neperžengiant šių ribų, būtinybės užtikrinti patikimą registravimą, aiškius nepaisymo mechanizmus ir vartotojo apibrėžtus užmušimo jungiklius, kad būtų išlaikyta vartotojo kontrolė ir pasitikėjimas. UX praktikai turėtų sutelkti dėmesį į veiksmingų autonominio agento elgesio stebėjimo prietaisų skydelių kūrimą, o produktų vadovai turi užtikrinti, kad būtų laikomasi aiškių valdymo ir etikos gairių.
Pažvelkime į realų žmogiškųjų išteklių technologijos taikomąją programą, kad pamatytume, kaip šie režimai veikia. Apsvarstykite „Interviu koordinavimo agentą“, skirtą įdarbinimo logistikai tvarkyti.
Pasiūlymo režimu Agentas pastebi, kad pašnekovas užsisakė du kartus. Jame pabrėžiamas konfliktas verbuotojo prietaisų skydelyje: „Įspėjimas: Sara du kartus užsakyta pokalbiui 14 val.“. Planavimo režimu agentas analizuoja Saros kalendorių ir kandidato pasiekiamumą. Jame pateikiamas sprendimas: „Rekomenduoju perkelti interviu į ketvirtadienį 10 val. Tam reikia perkelti Sarą santykiu 1:1 su jos vadovu. Darbuotojas peržiūri šią logiką. Patvirtinimo režimu agentas parengia el. laiškus kandidatui ir vadovui. Jis užpildo kalendoriaus kvietimus. Darbuotojas mato santrauką: „Pasiruošę perkelti į ketvirtadienį. Siųsti naujienas?“ Darbuotojas spusteli „Patvirtinti“. Autonominiame režime agentas konfliktą tvarko akimirksniu. Jame laikomasi iš anksto nustatytos taisyklės: „Visada pirmenybę teikite kandidatų pokalbiams, o ne vidiniams 1:1“. Jis perkelia susitikimą ir siunčia pranešimus. Darbuotojas mato žurnalo įrašą: „Išspręstagrafiko konfliktas kandidatui B.
Tyrimų pradžiamokslis: ką ir kaip tirti Norint sukurti veiksmingą agentinį AI, reikia kitokio tyrimo metodo, palyginti su tradicine programine įranga ar net generuojamuoju AI. Savarankiškas AI agentų pobūdis, jų gebėjimas priimti sprendimus ir aktyvių veiksmų potencialas reikalauja specializuotų metodikų, leidžiančių suprasti vartotojų lūkesčius, nustatyti sudėtingą agentų elgesį ir numatyti galimas nesėkmes. Toliau pateiktame tyrimo pradmenyje pateikiami pagrindiniai metodai, skirti matuoti ir įvertinti šiuos unikalius agentinio AI aspektus. Psichikos modelio interviu Šie interviu atskleidžia išankstines vartotojų nuostatas apie tai, kaip turėtų elgtis AI agentas. Užuot tiesiog klausę, ko nori vartotojai, dėmesys sutelkiamas į jų vidinių agento galimybių ir apribojimų modelių supratimą. Turėtume vengti vartoti žodį „agentas“ su dalyviais. Jame gabenamas mokslinės fantastikos bagažas arba terminas pernelyg lengvai painiojamas su žmogiškuoju agentu, siūlančiu pagalbą ar paslaugas. Vietoj to, diskutuokite apie „asistentus“ arba „sistemą“. Turime išsiaiškinti, kur vartotojai nubrėžia ribą tarp naudingo automatizavimo ir įkyraus valdymo.
Metodas: paprašykite vartotojų apibūdinti, nupiešti arba papasakoti numatomą sąveiką su agentu įvairiais hipotetiniais scenarijais. Pagrindiniai zondai (atspindintys įvairias pramonės šakas): Norėdami suprasti pageidaujamo automatizavimo ribas ir galimą nerimą dėl per didelio automatizavimo, paklauskite: Jei jūsų skrydis būtų atšauktas, ką norėtumėte, kad sistema padarytų automatiškai? Kas jus jaudintų, jei tai padarytų be jūsų aiškaus nurodymo?
Norėdami išsiaiškinti, kaip vartotojas supranta agento vidinius procesus ir reikalingą komunikaciją, paklauskite: Įsivaizduokite, kad skaitmeninis asistentas tvarko jūsų išmaniuosius namus. Jei siuntinys pristatomas, kokių veiksmų, jūsų manymu, reikia, ir kokią informaciją tikitės gauti?
Norėdami atskleisti lūkesčius, susijusius su kontrole ir sutikimu per kelių etapų procesą, paklauskite: Jei paprašysite savo skaitmeninio asistento suplanuoti susitikimą, kokių veiksmų įsivaizduojate? Kokiais klausimais norėtumėte, kad su jumis būtų konsultuojamasi ar jums būtų suteikta galimybė rinktis?
Metodo pranašumai: atskleidžia netiesiogines prielaidas, pabrėžia sritis, kuriose planuojamas agento elgesys gali skirtis nuo vartotojo lūkesčių, ir informuoja apie tinkamų valdiklių ir grįžtamojo ryšio mechanizmų dizainą.
Agento kelionės žemėlapis: Panašiai kaip tradicinis naudotojo kelionės žemėlapis, agento kelionės žemėlapiuose daugiausia dėmesio skiriama numatomiems paties AI agento veiksmams ir sprendimo taškams, kartu su vartotojo sąveika. Tai padeda aktyviai nustatyti galimus spąstus.
Metodas: Sukurkite vaizdinį žemėlapį, kuriame būtų išdėstyti įvairūs agento veiklos etapai nuo inicijavimo iki užbaigimo, įskaitant visus galimus veiksmus, sprendimus ir sąveiką su išorinėmis sistemomis ar vartotojais. Pagrindiniai žemėlapio elementai: Agento veiksmai: kokias konkrečias užduotis ar sprendimus atlieka agentas? Informacijos įvestis / išvestis: kokių duomenų reikia agentui ir kokią informaciją jis generuoja arba perduoda? Sprendimo taškai: kur agentas pasirenka ir kokie yra tų pasirinkimų kriterijai? Naudotojo sąveikos taškai: kur naudotojas pateikia įvestį, peržiūri ar patvirtina veiksmus? Nesėkmės taškai: labai svarbu nustatyti konkrečius atvejus, kai agentas gali neteisingai interpretuoti instrukcijas, priimti neteisingą sprendimą arba bendrauti su netinkamu subjektu. Pavyzdžiai: neteisingas gavėjas (pvz., neskelbtinos informacijos siuntimas netinkamam asmeniui), overdraftas (pvz., automatinis mokėjimas, viršijantis turimas lėšas), klaidingas ketinimo aiškinimas (pvz., skrydžio užsakymas netinkamai datai dėl dviprasmiškos kalbos).
Atkūrimo keliai: kaip agentas arba vartotojas gali atsigauti po šių gedimų? Kokie yra korekcijos ar įsikišimo mechanizmai?
Metodo pranašumai: suteikia holistinį agento veiklos srauto vaizdą, atskleidžia paslėptas priklausomybes ir leidžia aktyviai kurti apsaugos priemones, tvarkyti klaidas ir naudotojo įsikišimo taškus, siekiant užkirsti kelią neigiamiems rezultatams arba juos sumažinti.
Imituotas netinkamo elgesio testas: Šis metodas skirtas sistemos testavimui nepalankiausiomis sąlygomis ir vartotojų reakcijai stebėti, kai dirbtinio intelekto agentas sugenda arba nukrypsta nuo lūkesčių. Tai supratimas apie pasitikėjimo atstatymą ir emocines reakcijas nepalankiose situacijose.
Metodas: Kontroliuojamuose laboratoriniuose tyrimuose sąmoningai įveskite scenarijus, kai agentas padaro klaidą, neteisingai interpretuoja komandą arba elgiasi netikėtai. Imituotinos „netinkamo elgesio“ rūšys: komandąKlaidingas aiškinimas: agentas atlieka veiksmą, kuris šiek tiek skiriasi nuo vartotojo ketinimo (pvz., užsako du, o ne vieną). Informacijos perteklius / nepakankamas apkrovimas: agentas pateikia per daug nereikšmingos informacijos arba nepakankamai svarbios informacijos. Nepageidaujamas veiksmas: agentas atlieka veiksmą, kurio vartotojas aiškiai nenorėjo arba nesitikėjo (pvz., perka akcijas be patvirtinimo). Sistemos gedimas: agentas užstringa, nebereaguoja arba pateikia klaidos pranešimą. Etinės dilemos: agentas priima sprendimą, turintį etinių pasekmių (pvz., teikia pirmenybę vienai užduočiai prieš kitą, remdamasis nenumatyta metrika).
Stebėjimo dėmesys: Vartotojų reakcijos: kaip vartotojai reaguoja emociškai (nusivylimas, pyktis, sumišimas, pasitikėjimo praradimas)? Atkūrimo bandymai: kokių veiksmų imasi vartotojai, kad ištaisytų agento elgesį arba anuliuotų jo veiksmus? Pasitikėjimo taisymo mechanizmai: ar sistemoje integruoti atkūrimo arba grįžtamojo ryšio mechanizmai padeda atkurti pasitikėjimą? Kaip vartotojai nori būti informuoti apie klaidas? Psichikos modelio pasikeitimas: ar netinkamas elgesys pakeičia vartotojo supratimą apie agento galimybes ar apribojimus?
Metodo privalumai: itin svarbus nustatant projektavimo spragas, susijusias su klaidų atkūrimu, atsiliepimais ir vartotojo kontrole. Ji suteikia įžvalgų apie tai, kaip vartotojai yra atsparūs agentų gedimams ir ko reikia norint išlaikyti arba atkurti pasitikėjimą, o tai leidžia sukurti tvirtesnes ir atlaidesnes agentų sistemas.
Integruodami šias tyrimų metodikas, UX praktikai gali ne tik paversti agentų sistemas tinkamomis naudoti, bet ir padaryti jas patikimomis, kontroliuojamomis ir atskaitingomis, taip skatindami teigiamus ir produktyvius vartotojų ir jų AI agentų santykius. Atminkite, kad tai nėra vieninteliai metodai, svarbūs veiksmingai tiriant agentinį AI. Yra daug kitų metodų, tačiau artimiausiu metu jie bus labiausiai prieinami specialistams. Anksčiau aprašiau Wizard of Oz metodą, šiek tiek pažangesnį koncepcijos testavimo metodą, kuris taip pat yra vertingas įrankis tiriant agentines AI koncepcijas. Etiniai svarstymai tyrimo metodikoje Tiriant agentinį AI, ypač kai imituojamas netinkamas elgesys ar klaidos, labai svarbu atsižvelgti į etinius sumetimus. Yra daug leidinių, kuriuose daugiausia dėmesio skiriama etiniams UX tyrimams, įskaitant straipsnį, kurį parašiau Smashing Magazine, šias UX dizaino instituto gaires ir šį įtraukiojo dizaino įrankių rinkinio puslapį. Pagrindinės Agentinio AI metrikos Jums reikės išsamaus pagrindinių metrikų rinkinio, kad galėtumėte efektyviai įvertinti agentinių AI sistemų našumą ir patikimumą. Šios metrikos suteikia įžvalgų apie vartotojų pasitikėjimą, sistemos tikslumą ir bendrą vartotojo patirtį. Stebėdami šiuos rodiklius kūrėjai ir dizaineriai gali nustatyti tobulinimo sritis ir užtikrinti, kad dirbtinio intelekto agentai veiktų saugiai ir efektyviai. 1. Intervencijos rodiklis Savarankiškų agentų sėkmę vertiname pagal tylą. Jei agentas vykdo užduotį, o vartotojas nesikiša arba neatšaukia veiksmo per nustatytą langą (pvz., per 24 valandas), tai laikome priėmimu. Stebime įsikišimo greitį: kaip dažnai žmogus įšoka, kad sustabdytų ar pataisytų agentą? Didelis įsikišimo rodiklis rodo pasitikėjimo ar logikos neatitikimą. 2. Nenumatytų veiksmų dažnis 1 000 užduočių. Ši kritinė metrika kiekybiškai įvertina AI agento atliktų veiksmų, kurių vartotojas nenorėjo arba kurių nesitikėjo, skaičių, normalizuotą 1 000 atliktų užduočių. Mažas nenumatytų veiksmų dažnis reiškia gerai suderintą AI, kuris tiksliai interpretuoja vartotojo ketinimus ir veikia neperžengiant nustatytų ribų. Ši metrika yra glaudžiai susijusi su AI supratimu apie kontekstą, gebėjimu atskirti komandas ir saugos protokolų patikimumu. 3. Atšaukimo arba anuliavimo rodikliaiŠi metrika stebi, kaip dažnai naudotojams reikia atšaukti arba anuliuoti AI atliktą veiksmą. Didelis atšaukimo rodiklis rodo, kad AI dažnai daro klaidas, neteisingai interpretuoja instrukcijas arba elgiasi taip, kaip neatitinka vartotojo lūkesčių. Išanalizavus šių atšaukimų priežastis, galima gauti vertingų atsiliepimų, padedančių tobulinti AI algoritmus, suprasti vartotojo nuostatas ir jos gebėjimą numatyti norimus rezultatus. Norėdami suprasti, kodėl, turite atlikti anuliavimo veiksmo mikrotyrimą. Pavyzdžiui, kai naudotojas atšaukia tvarkaraščio pakeitimą, paprastas raginimas gali paklausti: „Ne laikas? Netinkamas asmuo? Ar tiesiog norėjote tai padaryti pats?“ Leidžia vartotojui spustelėti parinktį, kuri geriausiai atitinka jo samprotavimus. 4. Laikas iki sprendimo po klaidosŠi metrikamatuoja trukmę, per kurią vartotojas ištaiso AI padarytą klaidą arba kol pati AI sistema atsigauna po klaidingos būsenos. Trumpas laikas iki išsprendimo rodo efektyvų ir patogų klaidų atkūrimo procesą, kuris gali sumažinti vartotojo nusivylimą ir išlaikyti produktyvumą. Tai apima klaidos identifikavimo paprastumą, anuliavimo ar taisymo mechanizmų prieinamumą ir AI teikiamų klaidų pranešimų aiškumą.
Norint rinkti šią metriką, reikia įdiegti sistemą, kad būtų galima stebėti agento veiksmų ID. Kiekvienas atskiras agento veiksmas, pvz., tvarkaraščio pasiūlymas ar skrydžio užsakymas, turi sugeneruoti unikalų ID, kuris išlieka žurnaluose. Norėdami išmatuoti įsikišimo greitį, neieškome tiesioginės vartotojo reakcijos. Mes ieškome atsakomųjų veiksmų nebuvimo apibrėžtame lange. Jei veiksmo ID sugeneruojamas 9:00 val. ir joks vartotojas to konkretaus ID nepakeičia ar negrąžina iki kitos dienos 9:00 val., sistema logiškai pažymi jį kaip Priimta. Tai leidžia mums kiekybiškai įvertinti sėkmę remiantis vartotojo tylėjimu, o ne aktyviu patvirtinimu. Atšaukimo rodikliams neapdorotų skaičių nepakanka, nes jiems trūksta konteksto. Norėdami užfiksuoti pagrindinę priežastį, savo programos anuliavimo arba grąžinimo funkcijoms turite įdiegti perėmimo logiką. Kai vartotojas atšaukia agento inicijuotą veiksmą, suaktyvinkite lengvą mikroapklausą. Tai gali būti paprastas trijų parinkčių būdas, kuriuo naudotojas prašoma priskirti klaidą faktiškai neteisingai, be konteksto arba paprasčiausia pasirinkti užduotį atlikti rankiniu būdu. Tai sujungia kiekybinę telemetriją su kokybine įžvalga. Tai leidžia inžinierių komandoms atskirti neveikiantį algoritmą ir vartotojo pageidavimų neatitikimą. Šios metrikos, nuosekliai stebimos ir visapusiškai analizuojamos, suteikia tvirtą pagrindą, leidžiantį įvertinti agentinių AI sistemų veikimą, leidžiantį nuolat tobulinti kontrolę, sutikimą ir atskaitomybę. Projektavimas prieš apgaulę Kadangi agentai tampa vis pajėgesni, susiduriame su nauja rizika: agentiniu dumblu. Tradicinis dumblas sukuria trintį, dėl kurios sunku atšaukti prenumeratą arba ištrinti paskyrą. Agentinis dumblas veikia atvirkščiai. Tai pašalina trintį iki gedimo, todėl vartotojui per lengva sutikti su veiksmu, kuris naudingas verslui, o ne savo interesams. Apsvarstykite agentą, kuris padės užsakyti kelionę. Be aiškių apsauginių turėklų sistema gali teikti pirmenybę partnerių oro linijoms arba didesnio pelno viešbučiui. Šis pasirinkimas pateikiamas kaip optimalus kelias. Vartotojas, pasitikėdamas sistemos autoritetu, priima rekomendaciją be patikrinimo. Tai sukuria apgaulingą modelį, kai sistema optimizuoja pajamas prisidengdama patogumu. Klaidingai įsivaizduotos kompetencijos rizika Apgaulė negali kilti iš piktų ketinimų. Tai dažnai AI pasireiškia kaip įsivaizduojama kompetencija. Dideli kalbų modeliai dažnai skamba autoritetingai, net jei jie neteisingi. Jie pateikia klaidingą užsakymo patvirtinimą arba netikslią santrauką su tokiu pat pasitikėjimu kaip ir patikrintas faktas. Natūralu, kad vartotojai gali pasitikėti šiuo pasitikinčiu tonu. Šis neatitikimas sukuria pavojingą atotrūkį tarp sistemos galimybių ir vartotojo lūkesčių. Turime specialiai sukurti, kad užpildytume šią spragą. Jei agentui nepavyksta atlikti užduoties, sąsaja turi aiškiai apie tai pranešti. Jei sistema nėra tikra, ji turi išreikšti netikrumą, o ne maskuoti ją nušlifuota proza. Skaidrumas per primityvus Priešnuodis ir dumblui, ir haliucinacijoms yra kilmė. Kiekvienam savarankiškam veiksmui reikalinga konkreti metaduomenų žyma, paaiškinanti sprendimo kilmę. Vartotojai turi turėti galimybę patikrinti rezultato loginę grandinę. Norėdami tai pasiekti, primityvus turime paversti praktiškais atsakymais. Programinės įrangos inžinerijoje primityvai reiškia pagrindinius informacijos ar veiksmų, kuriuos atlieka agentas, vienetus. Inžinieriui tai atrodo kaip API iškvietimas arba loginiai vartai. Vartotojui tai turi atrodyti kaip aiškus paaiškinimas. Projektavimo iššūkis yra susieti šiuos techninius žingsnius pagal žmogui suprantamus loginius pagrindus. Jei agentas rekomenduoja konkretų skrydį, vartotojas turi žinoti, kodėl. Sąsaja negali pasislėpti už bendrų pasiūlymų. Ji turi atskleisti pagrindinį primityvą: Logika: Pigiausias_tiesioginis_skrydis arba Logika: Partner_Airline_Priority. 4 paveiksle parodytas šis vertimo srautas. Paimame neapdorotą sistemos primityvą – tikrąją kodo logiką – ir susiejame ją su vartotojui skirta eilute. Pavyzdžiui, primityvus susitikimo kalendoriaus tikrinimas tampa aiškiu pareiškimu: aš pasiūliau 16 val.susitikimas. Toks skaidrumo lygis užtikrina, kad agento veiksmai atrodytų logiški ir naudingi. Tai leidžia vartotojui patikrinti, ar agentas veikė geriausiais jo interesais. Atskleidę primityvus, juodąją dėžę paverčiame stikline dėže, užtikrindami, kad vartotojai liktų galutine savo skaitmeninio gyvenimo autoritetu.
Dizaino scenos nustatymas Agentinės sistemos kūrimui reikalingas naujas psichologinio ir elgesio supratimo lygis. Tai verčia mus pereiti nuo įprasto tinkamumo testavimo ir pereiti prie pasitikėjimo, sutikimo ir atskaitomybės sferos. Tyrimo metodai, kuriuos aptarėme, nuo psichikos modelių tyrimo iki netinkamo elgesio modeliavimo ir naujų metrikų nustatymo, yra būtinas pagrindas. Šios praktikos yra pagrindinės priemonės, leidžiančios aktyviai nustatyti, kur autonominė sistema gali sugesti, ir, dar svarbiau, kaip ištaisyti vartotojo ir agento ryšį, kai taip nutinka. Perėjimas prie agentinio AI yra vartotojo ir sistemos santykių iš naujo apibrėžimas. Mes nebekuriame įrankių, kurie tiesiog reaguoja į komandas; kuriame partneriams, kurie veikia mūsų vardu. Tai pakeičia dizaino poreikį nuo efektyvumo ir naudojimo paprastumo iki skaidrumo, nuspėjamumo ir valdymo. Kai dirbtinis intelektas gali užsisakyti skrydį arba prekiauti akcijomis be paskutinio spustelėjimo, jo „ant rampos“ ir „off rampos“ dizainas tampa itin svarbus. Mes esame atsakingi už tai, kad naudotojai jaustųsi esantys vairuotojo vietoje, net kai jie perdavė vairą. Ši nauja realybė taip pat padidina UX tyrinėtojo vaidmenį. Mes tampame vartotojų pasitikėjimo saugotojais, bendradarbiaudami su inžinieriais ir produktų vadybininkais, siekdami apibrėžti ir išbandyti agento autonomijos apsauginius turėklus. Mes ne tik esame mokslininkai, bet ir tampame vartotojų kontrolės, skaidrumo ir etinių apsaugos priemonių šalininkais kūrimo procese. Primityvus paversdami praktiniais klausimais ir modeliuodami blogiausius scenarijus, galime sukurti tvirtas sistemas, kurios yra ir galingos, ir saugios. Šiame straipsnyje aprašyta „kas“ ir „kodėl“ tiriant agentinį AI. Tai parodė, kad mūsų tradicinių priemonių rinkinių nepakanka ir kad turime priimti naujas, į ateitį nukreiptas metodikas. Kitame straipsnyje bus remiamasi šiuo pagrindu, pateikiant konkrečius projektavimo modelius ir organizacinę praktiką, dėl kurių agento naudingumas tampa skaidrus vartotojams, užtikrinant, kad jie galėtų pasitikėti ir kontroliuoti agentinio AI galią. UX ateitis – tai sistemų patikimumas. Norėdami geriau suprasti agentinį AI, galite tyrinėti šiuos išteklius:
„Google“ AI tinklaraštis apie „Agentic AI“. „Microsoft“ AI agentų tyrimas
