Projektavimas autonominiams agentams kelia nepakartojamą nusivylimą. Mes perduodame AI sudėtingą užduotį, ji išnyksta 30 sekundžių (arba 30 minučių), o tada grįžta su rezultatu. Mes žiūrime į ekraną. Ar pavyko? Ar tai haliucinavo? Ar jis patikrino atitikties duomenų bazę, ar praleido šį veiksmą? Į šį nerimą paprastai reaguojame vienu iš dviejų kraštutinumų. Mes arba laikome sistemą juodąja dėže, viską paslepiame, kad išlaikytume paprastumą, arba puolame į paniką ir pateikiame duomenų išklotinę, transliuojančią kiekvieną žurnalo eilutę ir API iškvietimą vartotojui. Nė vienas iš metodų tiesiogiai neatspindi niuansų, reikalingų, kad vartotojams būtų užtikrintas idealus skaidrumo lygis. Dėl Black Box naudotojai jaučiasi bejėgiai. Duomenų išmetimas sukuria pranešimų aklumą, sunaikindamas agento pažadėtą efektyvumą. Vartotojai nepaiso nuolatinio informacijos srauto, kol kažkas sugenda, tada jiems trūksta konteksto, kad tai ištaisytų. Mums reikia organizuoto būdo rasti pusiausvyrą. Ankstesniame mano straipsnyje „Designing for Agentic AI“ apžvelgėme sąsajos elementus, kurie stiprina pasitikėjimą, pvz., iš anksto rodomi AI numatyti veiksmai (intent Previews) ir suteikiame vartotojams galimybę valdyti, kiek dirbtinis intelektas atlieka pats (autonominiai rinkimai). Tačiau žinoti, kuriuos elementus naudoti, yra tik dalis iššūkio. Sunkesnis dizainerių klausimas yra žinoti, kada juos naudoti. Kaip žinoti, kuriam konkrečiam 30 sekundžių darbo eigos momentui reikia „Intent Preview“ ir kurį galima tvarkyti įvedus paprastą žurnalo įrašą? Šiame straipsnyje pateikiamas būdas atsakyti į šį klausimą. Peržiūrėsime Sprendimų mazgo auditą. Vykdydami šį procesą dizaineriai ir inžinieriai sujungiami į vieną patalpą, kad galėtų susieti užpakalinės sistemos logiką su vartotojo sąsaja. Sužinosite, kaip tiksliai nustatyti momentus, kai vartotojui reikia atnaujinti AI veiklą. Taip pat apžvelgsime poveikio / rizikos matricą, kuri padės nustatyti pirmenybę, kuriuos sprendimo mazgus rodyti, ir bet kokį susijusį dizaino modelį, kurį reikia susieti su šiuo sprendimu. Skaidrumo akimirkos: atvejo analizės pavyzdys Apsvarstykite „Meridian“ (ne tikrasis vardas) – draudimo bendrovę, kuri naudoja agentinį AI, kad apdorotų pradines paraiškas dėl nelaimingų atsitikimų. Vartotojas įkelia automobilio apgadinimo nuotraukas ir policijos pranešimą. Tada agentas minutei dingsta ir grįžta su rizikos įvertinimu ir siūlomu išmokėjimo diapazonu. Iš pradžių „Meridian“ sąsaja tiesiog rodė pretenzijos būsenos apskaičiavimą. Vartotojai tapo nusivylę. Jie buvo pateikę keletą išsamių dokumentų ir jautėsi neaiškūs, ar AI iš viso peržiūrėjo policijos ataskaitą, kurioje nurodytos lengvinančios aplinkybės. Juodoji dėžė sukėlė nepasitikėjimą. Norėdami tai išspręsti, projektavimo komanda atliko sprendimų mazgo auditą. Jie nustatė, kad AI atliko tris skirtingus tikimybe pagrįstus veiksmus su daugybe mažesnių žingsnių:
Vaizdo analizė Agentas palygino žalos nuotraukas su tipiškų automobilio avarijų scenarijų duomenų baze, kad įvertintų remonto išlaidas. Tai apėmė pasitikėjimo balą. Tekstinė apžvalgaJis nuskaitė policijos ataskaitą, ieškodama raktinių žodžių, turinčių įtakos atsakomybei (pvz., kaltė, oro sąlygos, blaivumas). Tai apėmė teisinės padėties tikimybės vertinimą. Policy Cross ReferenceIt atitiko išsamią paraiškos informaciją su konkrečiomis naudotojo politikos sąlygomis, ieškodama išimčių arba aprėpties apribojimų. Tai taip pat apėmė tikimybinį atitikimą.
Komanda šiuos žingsnius pavertė skaidrumo akimirkomis. Sąsajos seka buvo atnaujinta į:
Žalos nuotraukų įvertinimas: palyginimas su 500 transporto priemonių smūgių profilių. Policijos ataskaitos peržiūra: atsakomybės raktinių žodžių ir teisinio precedento analizė. Politikos aprėpties tikrinimas: patikrinkite, ar jūsų plane nėra konkrečių išimčių.
Sistema vis tiek užtruko tiek pat laiko, tačiau aiškus pranešimas apie agento vidinį darbą grąžino vartotojų pasitikėjimą. Vartotojai suprato, kad dirbtinis intelektas atlieka sudėtingą užduotį, kuriai buvo sukurta, ir tiksliai žinojo, kur sutelkti dėmesį, jei galutinis įvertinimas atrodė netikslus. Šis dizaino pasirinkimas nerimo akimirką pavertė ryšio su vartotoju akimirka. Poveikio / rizikos matricos taikymas: ką pasirinkome slėpti Daugumoje AI patirties netrūksta įvykių ir sprendimų mazgų, kurie gali būti rodomi apdorojimo metu. Vienas iš svarbiausių audito rezultatų buvo nuspręsti, ką palikti nematomą. „Meridian“ pavyzdyje pagalbiniai žurnalai sugeneravo 50 ir daugiau įvykių vienai paraiškai. Galėjome pagal numatytuosius nustatymus rodyti kiekvieną įvykį, kai jie buvo apdoroti kaip vartotojo sąsajos dalis. Vietoj to, norėdami juos genėti, pritaikėme rizikos matricą:
Žurnalo įvykis: Pinging serverisWest-2 atleidimo patikrinimui. Filtruoti Verdiktas: Slėpti. (Mažas statymas, aukštas techniškumas).
Įvykio žurnalas: remonto sąmatos palyginimas su BlueBook verte. Filtruoti Verdiktas: Rodyti. (Dideli statymai, turi įtakos vartotojo išmokėjimui).
Atsisakius nereikalingų detalių, svarbi informacija, pvz., aprėpties patikrinimas, buvo paveikesnė. Sukūrėme atvirą sąsają ir atvirą patirtį. Šis metodas remiasi idėja, kad žmonės geriau jaučiasi gavę paslaugą, kai mato atliekamą darbą. Parodydami konkrečius veiksmus (vertinimas, peržiūra, tikrinimas), 30 sekundžių laukimą pakeitėme iš nerimo („Ar jis sugedo?“) į jausmą, kad kažkas vertingo kuriama („Galvojau“). Dabar atidžiau pažiūrėkime, kaip galime peržiūrėti sprendimų priėmimo procesą mūsų produktuose, kad nustatytų pagrindinius momentus, kuriems reikia aiškios informacijos. Sprendimo mazgo auditas Skaidrumas žlunga, kai jį traktuojame kaip stiliaus pasirinkimą, o ne funkcinį reikalavimą. Mes linkę klausti: „Kaip turėtų atrodyti vartotojo sąsaja? prieš klausdami: „Ką iš tikrųjų sprendžia agentas? Sprendimo mazgo auditas yra paprastas būdas dirbtinio intelekto sistemas lengviau suprasti. Jis veikia kruopščiai nubrėždamas vidinį sistemos procesą. Pagrindinis tikslas yra surasti ir aiškiai apibrėžti tikslius momentus, kai sistema nustoja laikytis nustatytų taisyklių, o pasirenka atsitiktinumu ar įvertinimu. Sudarydami šios struktūros žemėlapius, kūrėjai gali parodyti šiuos neapibrėžtumo taškus tiesiogiai sistema besinaudojantiems žmonėms. Tai pakeičia sistemos atnaujinimus iš neaiškių teiginių į konkrečias, patikimas ataskaitas apie tai, kaip AI padarė išvadą. Be anksčiau pateikto draudimo atvejo tyrimo, neseniai dirbau su pirkimo agento komanda. Sistema peržiūrėjo pardavėjo sutartis ir pažymėjo rizikas. Iš pradžių ekrane buvo rodoma paprasta eigos juosta: „Sutarčių peržiūra“. Vartotojai to nekentė. Mūsų tyrimas parodė, kad jie jautė nerimą dėl trūkstamos sąlygos teisinių pasekmių. Tai ištaisėme atlikdami sprendimų mazgo auditą. Šio straipsnio pabaigoje įtraukiau nuoseklų šio audito atlikimo kontrolinį sąrašą. Surengėme sesiją su inžinieriais ir apibūdinome, kaip veikia sistema. Mes nustatėme „Sprendimo taškus“ - momentus, kai AI turėjo pasirinkti vieną iš dviejų gerų variantų. Standartinėse kompiuterinėse programose procesas aiškus: jei įvyksta A, tai B visada įvyks. AI sistemose procesas dažnai grindžiamas atsitiktinumu. AI mano, kad A tikriausiai yra geriausias pasirinkimas, tačiau tai gali būti tik 65% tikras. Sutarčių sistemoje radome momentą, kai AI patikrino atsakomybės sąlygas pagal mūsų įmonės taisykles. Tai retai buvo tobula. AI turėjo nuspręsti, ar 90% atitiktis yra pakankamai gera. Tai buvo pagrindinis sprendimo taškas.
Kai identifikavome šį mazgą, mes jį parodėme vartotojui. Vietoj „Sutarčių peržiūra“ sąsaja atnaujinta taip: „Atsakomybės sąlyga skiriasi nuo standartinio šablono. Rizikos lygio analizė“. Šis konkretus atnaujinimas suteikė vartotojams pasitikėjimo. Jie žinojo, kad agentas patikrino atsakomybės sąlygą. Jie suprato vėlavimo priežastį ir įgijo pasitikėjimą, kad norimas veiksmas įvyksta užpakalinėje dalyje. Jie taip pat žinojo, kur pasigilinti, kai agentas sudarė sutartį. Norėdami patikrinti, kaip AI priima sprendimus, turite glaudžiai bendradarbiauti su savo inžinieriais, produktų vadybininkais, verslo analitikais ir pagrindiniais žmonėmis, kurie pasirenka (dažnai paslėptus), kurie turi įtakos AI įrankio veikimui. Nubrėžkite įrankio veiksmus. Pažymėkite kiekvieną vietą, kur procesas keičia kryptį, nes yra tikimybė. Tai yra vietos, kur turėtumėte sutelkti dėmesį į skaidrumą. Kaip parodyta 2 pav., Sprendimo mazgo auditas apima šiuos veiksmus:
Suburkite komandą: įtraukite produktų savininkus, verslo analitikus, dizainerius, pagrindinius sprendimus priimančius asmenis ir AI sukūrusius inžinierius. Pavyzdžiui, Pagalvokite apie produkto komandą, kurianti AI įrankį, skirtą nepatogioms teisinėms sutartims peržiūrėti. Komandą sudaro UX dizaineris, produkto vadovas, UX tyrinėtojas, praktikuojantis teisininkas, kuris veikia kaip dalyko ekspertas, ir užpakalinės programos inžinierius, parašęs teksto analizės kodą.
Nubraižykite visą procesą: dokumentuokite kiekvieną AI žingsnį, nuo pirmojo vartotojo veiksmo iki galutinio rezultato. Komanda stovi prie lentos ir nubraižo visą pagrindinės darbo eigos seką, kai dirbtinis intelektas ieško atsakomybės sąlygos sudėtingoje sutartyje. Advokatas įkeliapenkiasdešimties puslapių PDF → Sistema konvertuoja dokumentą į skaitomą tekstą. → AI nuskaito puslapius dėl atsakomybės sąlygų. → Vartotojas laukia. → Po kelių akimirkų ar minučių įrankis naudotojo sąsajoje paryškina rastas pastraipas geltonai. Jie tai atlieka daugelyje kitų darbo eigų, kurias taip pat galima pritaikyti įrankiui.
Raskite, kur viskas yra neaiški: peržiūrėkite proceso žemėlapį, kur AI lygina parinktis arba įvestis, kurios neturi idealios atitikties. Komanda žiūri į lentą, kad pastebėtų dviprasmiškus žingsnius. Vaizdo konvertavimas į tekstą laikomasi griežtų taisyklių. Norint rasti konkrečią atsakomybės sąlygą, reikia spėlioti. Kiekviena įmonė šias sąlygas rašo skirtingai, todėl dirbtinis intelektas turi pasverti keletą variantų ir nuspėti, o ne rasti tikslią žodžio atitiktį.
Nustatykite „geriausio spėjimo“ veiksmus: kiekvienoje neaiškioje vietoje patikrinkite, ar sistema naudoja patikimumo balą (pavyzdžiui, ar jis 85 % tikras?). Tai yra taškai, kuriuose AI daro galutinį pasirinkimą. Sistema turi atspėti (suteikti tikimybę), kuri pastraipa (-os) labai panaši (-os) į standartinę atsakomybės sąlygą. Geriausiam spėjimui jis priskiria pasitikėjimo balą. Šis spėjimas yra sprendimo mazgas. Sąsaja turi pasakyti advokatui, kad ji pabrėžia galimą atitiktį, o ne nurodo, kad rado galutinę sąlygą.
Išnagrinėkite pasirinkimą: kiekvienam pasirinkimo taškui išsiaiškinkite konkrečią atliekamą vidinę matematiką arba palyginimą (pvz., sutarties dalies suderinimas su polisu arba sugedusio automobilio paveikslėlio palyginimas su sugadintų automobilių nuotraukų biblioteka). Inžinierius paaiškina, kad sistema palygina įvairias pastraipas su standartinių atsakomybės sąlygų duomenų baze iš ankstesnių įmonių atvejų. Jis apskaičiuoja teksto panašumo balą, kad pagal tikimybes nuspręstų, ar atitiktis.
Rašykite aiškius paaiškinimus: sukurkite vartotojui pranešimus, kuriuose aiškiai aprašomas konkretus vidinis veiksmas, vykstantis, kai AI pasirenka. Turinio dizaineris rašo konkrečią žinutę būtent šiam momentui. Tekstas skamba taip: Dokumento teksto palyginimas su standartinėmis tvirtomis sąlygomis, siekiant nustatyti galimą atsakomybės riziką.
Atnaujinkite ekraną: įdėkite šiuos naujus aiškius paaiškinimus į vartotojo sąsają, pakeisdami neaiškius pranešimus, pvz., „Sutarčių peržiūra“. Dizainerių komanda pašalina bendrąjį apdorojimo PDF įkėlimo suktuką. Jie įterpia naują paaiškinimą į būsenos juostą, esančią tiesiai virš dokumentų peržiūros priemonės, kol AI mąsto.
Patikrinkite pasitikėjimą: įsitikinkite, kad nauji ekrano pranešimai naudotojams pateikia paprastą laukimo laiko ar rezultato priežastį, todėl jie turėtų jaustis labiau pasitikintys ir pasitikėti.
Poveikio/rizikos matrica Atidžiai pažvelgę į AI procesą, greičiausiai rasite daug taškų, kuriuose jis pasirenka. Dirbtinis intelektas gali padaryti daugybę mažų pasirinkimų vienai sudėtingai užduočiai atlikti. Parodant juos visus sukuriama per daug nereikalingos informacijos. Šiuos pasirinkimus turite sugrupuoti. Galite naudoti poveikio / rizikos matricą, kad surūšiuotumėte šiuos pasirinkimus pagal AI atliekamų veiksmų (-ių) tipą. Čia yra poveikio / rizikos matricų pavyzdžiai: Pirma, ieškokite mažo įnašo ir mažo poveikio sprendimų. Mažas statymas / mažas poveikis
Pavyzdys: failo struktūros tvarkymas arba dokumento pervadinimas. Skaidrumo poreikis: minimalus. Pakanka subtilaus tosto pranešimo arba žurnalo įrašo. Vartotojai gali lengvai anuliuoti šiuos veiksmus.
Tada nustatykite svarbius ir didelio poveikio sprendimus. Didelis statymas / didelis poveikis
Pavyzdys: paskolos paraiškos atmetimas arba akcijų sandorio vykdymas. Skaidrumo poreikis: didelis. Šiems veiksmams reikalingas darbo įrodymas. Sistema turi parodyti loginį pagrindą prieš veikdama arba iš karto.
Apsvarstykite finansinės prekybos robotą, kuris visus pirkimo / pardavimo pavedimus traktuoja vienodai. Jis vykdo 5 USD sandorį su tokiu pat neskaidrumu kaip ir 50 000 USD sandoris. Vartotojai gali suabejoti, ar įrankis atpažįsta galimą skaidrumo poveikį prekybai didele dolerio suma. Jiems reikia, kad sistema pristabdytų ir parodytų savo darbą aukštų statymų sandoriams. Sprendimas yra įvesti peržiūros logikos būseną bet kokiai operacijai, viršijančiai konkrečią dolerio sumą, leidžiančią vartotojui pamatyti veiksnius, lemiančius sprendimą prieš vykdymą. Mazgų susiejimas su šablonais: dizaino modelio pasirinkimo rubrika Kai nustatysite pagrindinius savo patirties sprendimų mazgus, turite nuspręsti, kuris vartotojo sąsajos modelis taikomas kiekvienam rodomam mazgui. Straipsnyje „Designing For Agentic AI“ pristatėme tokius modelius kaip „Intent Preview“ (didelių sumų valdymui) ir „Action Audit“ (saugumui atgaline data). Lemiamas veiksnys renkantis tarp jų yra grįžtamumas. Filtruojame kiekvienąsprendimo mazgas per poveikio matricą, kad būtų priskirtas teisingas modelis: Dideli statymai ir negrįžtami: šiems mazgams reikalinga „Intent Preview“. Kadangi vartotojas negali lengvai anuliuoti veiksmo (pvz., visam laikui ištrinti duomenų bazę), skaidrumo momentas turi įvykti prieš vykdymą. Sistema turi pristabdyti, paaiškinti savo ketinimą ir reikalauti patvirtinimo. Dideli statymai ir grįžtami: šie mazgai gali pasikliauti veiksmų audito ir anuliavimo modeliu. Jei dirbtinio intelekto veikiantis pardavimo agentas perkelia potencialųjį klientą į kitą dujotiekį, jis gali tai padaryti savarankiškai, kol apie tai praneš vartotojui ir iškart pasiūlo mygtuką Anuliuoti. Taip griežtai skirstydami mazgus į kategorijas, išvengiame „sudėtingo nuovargio“. Didelės trinties ketinimų peržiūrą skiriame tik tikrai negrįžtamoms akimirkoms, o pasikliaujame veiksmo auditu, kad visa kita išlaikytų greitį.
Grįžtamasis Negrįžtamas Mažas poveikis Tipas: Auto-ExecuteUI: Pasyvus skrudinimas / LogEx: Failo pervadinimas Tipas: ConfirmUI: paprasta anuliavimo parinktis, pvz.: el. laiško archyvavimas Didelis poveikis Tipas: peržiūros vartotojo sąsaja: pranešimas + peržiūra TrailEx: juodraščio siuntimas klientui Tipas: Intent previewUI: Modal / Explicit PermissionEx: Serverio ištrynimas
1 lentelė: Poveikio ir grįžtamumo matrica gali būti naudojama norint susieti skaidrumo momentus su dizaino modeliais. Kokybinis patvirtinimas: „Palauk, kodėl? Testas Galite nustatyti galimus mazgus lentoje, tačiau turite juos patvirtinti pagal žmogaus elgesį. Turite patikrinti, ar jūsų žemėlapis atitinka vartotojo psichikos modelį. Aš naudoju protokolą pavadinimu „Palauk, kodėl? Testas. Paprašykite vartotojo stebėti, kaip agentas atlieka užduotį. Nurodykite jiems kalbėti garsiai. Kai jie užduoda klausimą: „Palauk, kodėl tai padarė? arba "Ar tai įstrigo?" arba „Ar mane išgirdo? - pažymi laiko žymą. Šie klausimai rodo vartotojo painiavą. Vartotojas jaučia, kad jo kontrolė praslysta. Pavyzdžiui, sveikatos priežiūros planavimo asistento tyrime vartotojai stebėjo, kaip agentas užsisakė susitikimą. Ekranas nejudėjo keturias sekundes. Dalyviai nuolat klausdavo: „Ar tai tikrina mano ar gydytojo kalendorių?
Šis klausimas atskleidė trūkstamą Skaidrumo akimirką. Sistema turėjo padalyti tą keturių sekundžių laukimą į du skirtingus veiksmus: „Patikrinti pasiekiamumą“, po to „Sinchronizuojama su teikėjo tvarkaraščiu“. Šis nedidelis pokytis sumažino vartotojų išreikštą nerimo lygį. Skaidrumas nepavyksta, kai jis apibūdina tik sistemos veiksmą. Sąsaja turi susieti techninį procesą su konkrečiu vartotojo tikslu. Ekranas su užrašu „Tikrinamas pasiekiamumas“ nukrenta, nes trūksta konteksto. Vartotojas supranta, kad AI žiūri į kalendorių, bet nežino kodėl. Turime susieti veiksmą su rezultatu. Sistema turi padalyti tą keturių sekundžių laukimą į du skirtingus veiksmus. Pirma, sąsajoje rodoma „Kalendoriaus tikrinimas, norint rasti darbo laiką“. Tada jis atnaujinamas į „Sinchronizuojama su teikėjo tvarkaraščiu, kad būtų užtikrintas jūsų susitikimas“. Tai pagrindžia techninį procesą realiame vartotojo gyvenime. Apsvarstykite galimybę AI valdyti vietinės kavinės inventorių. Sistema susiduria su tiekimo trūkumu. Sąsaja „susisiekimas su pardavėju“ arba „parinkčių peržiūra“ sukelia nerimą. Vadovas svarsto, ar sistema atšaukia užsakymą, ar perka brangią alternatyvą. Geresnis būdas yra paaiškinti numatomą rezultatą: „Alternatyvių tiekėjų įvertinimas, kad būtų išlaikytas penktadienio pristatymo grafikas“. Tai tiksliai nurodo vartotojui, ką AI bando pasiekti. Audito operatyvizavimas Baigėte Sprendimo mazgo auditą ir išfiltravote sąrašą naudodami poveikio ir rizikos matricą. Dabar turite sąrašą svarbiausių momentų, kad būtumėte skaidrūs. Tada turite juos sukurti vartotojo sąsajoje. Šis žingsnis reikalauja komandinio darbo įvairiuose skyriuose. Negalite patys sukurti skaidrumo naudodami projektavimo įrankį. Turite suprasti, kaip sistema veikia užkulisiuose. Pradėkite nuo logikos apžvalgos. Susipažinkite su savo pagrindinės sistemos dizaineriu. Atsineškite savo sprendimo mazgų žemėlapį. Turite patvirtinti, kad sistema iš tikrųjų gali dalytis šiomis būsenomis. Dažnai pastebiu, kad techninė sistema neatskleidžia tikslios būsenos, kurią noriu parodyti. Inžinierius gali pasakyti, kad sistema tiesiog grąžina bendrą „darbo“ būseną. Turite siekti išsamaus atnaujinimo. Norint išsiųsti konkretų pranešimą, jums reikia sistemoskai nuo teksto skaitymo pereinama prie taisyklių tikrinimo. Be šio techninio ryšio jūsų projekto neįmanoma sukurti. Tada įtraukite turinio dizaino komandą. Turite techninę AI veiksmų priežastį, bet jums reikia aiškaus, žmogui palankaus paaiškinimo. Inžinieriai pateikia pagrindinį procesą, bet turinio kūrėjai pateikia būdą, kaip jis perduodamas. Nerašykite šių pranešimų vieni. Kūrėjas gali parašyti „Vykdoma funkcija 402“, kuri yra techniškai teisinga, bet vartotojui beprasmė. Dizaineris gali parašyti „Mąstymas“, kuris yra draugiškas, bet pernelyg neaiškus. Turinio strategas randa tinkamą vidurį. Jie sukuria konkrečias frazes, pvz., „Atsakomybės rizikos nuskaitymas“, kurios parodo, kad AI veikia nesupainiodamas vartotojo. Galiausiai patikrinkite savo pranešimų skaidrumą. Nelaukite, kol bus sukurtas galutinis produktas, kad pamatytumėte, ar tekstas veikia. Atlieku paprastų prototipų palyginimo testus, kur keičiasi tik būsenos pranešimas. Pavyzdžiui, vienai grupei (A grupei) rodau pranešimą, kuriame sakoma „Tikrinamas tapatybė“, o kitai grupei (B grupei) – „Tikrinamas vyriausybės duomenų bazės“ (tai yra sugalvoti pavyzdžiai, bet jūs suprantate esmę). Tada paklausiu, kuris DI jaučiasi saugesnis. Dažnai pastebėsite, kad tam tikri žodžiai kelia nerimą, o kiti kuria pasitikėjimą. Turite traktuoti formuluotę kaip kažką, ką turite patikrinti ir įrodyti, kad jis veiksmingas. Kaip tai keičia projektavimo procesą Šių auditų atlikimas gali sustiprinti komandos darbą. Nustojame perduoti nugludintus dizaino failus. Pradedame naudoti netvarkingus prototipus ir bendras skaičiuokles. Pagrindinis įrankis tampa skaidrumo matrica. Inžinieriai ir turinio kūrėjai kartu redaguoja šią skaičiuoklę. Jie susieja tikslius techninius kodus su žodžiais, kuriuos vartotojas perskaitys. Logikos peržiūros metu komandos patirs trintį. Įsivaizduokite, kad dizaineris klausia inžinieriaus, kaip AI nusprendžia atmesti operaciją, pateiktą išlaidų ataskaitoje. Inžinierius gali pasakyti, kad užpakalinė programa išveda tik bendrą būsenos kodą, pvz., „Klaida: trūksta duomenų“. Dizaineris teigia, kad tai nėra ekrane rodoma informacija. Dizaineris derasi su inžinieriumi, kad sukurtų konkretų techninį kabliuką. Inžinierius parašo naują taisyklę, kad sistema tiksliai praneštų, ko trūksta, pvz., trūkstamą kvito vaizdą. Turinio kūrėjai šiame etape veikia kaip vertėjai. Kūrėjas gali parašyti techniškai tikslią eilutę, pvz., „Pardavėjo atitikties patikimumo slenksčio apskaičiavimas“. Turinio dizaineris šią eilutę paverčia fraze, kuri sukuria pasitikėjimą konkrečiam rezultatui. Strategas perrašo jį taip: „Vietinių pardavėjų kainų palyginimas, siekiant užtikrinti pristatymą penktadienį“. Vartotojas supranta veiksmą ir rezultatą. Visa daugiafunkcinė komanda dalyvauja naudotojų testavimo seansuose. Jie stebi, kaip realus žmogus reaguoja į skirtingus būsenos pranešimus. Pamatę naudotojo paniką, nes ekrane parašyta „Vykdoma prekyba“, komanda verčia permąstyti savo požiūrį. Inžinieriai ir dizaineriai laikosi geresnės formuluotės. Prieš pirkdami akcijas, jie pakeičia tekstą į „Pakankamų lėšų patikrinimas“. Bandymai kartu garantuoja, kad galutinė sąsaja tarnaus ir sistemos logikai, ir vartotojo ramybei. Norint įtraukti šias papildomas veiklas į komandos kalendorių, reikia laiko. Tačiau galutinis rezultatas turėtų būti komanda, kuri bendrauja atviriau, ir vartotojai, kurie geriau supranta, ką jų AI varomi įrankiai veikia jų vardu (ir kodėl). Šis integruotas požiūris yra kertinis akmuo kuriant tikrai patikimą AI patirtį. Pasitikėjimas yra dizaino pasirinkimas Pasitikėjimą dažnai vertiname kaip emocinį geros vartotojo patirties šalutinį produktą. Pasitikėjimą lengviau vertinti kaip mechaninį nuspėjamo bendravimo rezultatą. Mes kuriame pasitikėjimą rodydami reikiamą informaciją tinkamu laiku. Mes jį sunaikiname priblokšdami vartotoją arba visiškai paslėpdami techniką. Pradėkite nuo sprendimų mazgo audito, ypač skirtų agentiniams AI įrankiams ir produktams. Raskite momentus, kai sistema priima sprendimą. Nurodykite šias akimirkas į rizikos matricą. Jei statymas didelis, atidarykite dėžutę. Parodyk darbą. Kitame straipsnyje apžvelgsime, kaip sukurti šiuos momentus: kaip parašyti kopiją, struktūrizuoti vartotojo sąsają ir tvarkyti neišvengiamas klaidas, kai agentas suklysta. Priedas: Sprendimo mazgo audito kontrolinis sąrašas 1 etapas: sąranka ir atvaizdavimas ✅ Suburkite komandą: pakvieskite produktų savininkus, verslo analitikus, dizainerius,pagrindiniai sprendimų priėmėjai ir AI sukūrę inžinieriai. Patarimas: jums reikia, kad inžinieriai paaiškintų tikrąją užpakalinės sistemos logiką. Nemėginkite šio žingsnio vienas. ✅ Nubraižykite visą procesą: dokumentuokite kiekvieną AI žingsnį – nuo pirmojo vartotojo veiksmo iki galutinio rezultato. Patarimas: fizinės lentos seansas dažnai geriausiai tinka norint nubrėžti šiuos pradinius veiksmus. 2 etapas: paslėptos logikos nustatymas ✅ Raskite, kur viskas neaiški: peržiūrėkite proceso žemėlapį, kur AI lygina parinktis arba įvestis, kurios neturi vieno tobulo atitikimo. ✅ Nustatykite geriausius spėjimo žingsnius: kiekvienoje neaiškioje vietoje patikrinkite, ar sistema naudoja patikimumo balą. Pavyzdžiui, paklauskite, ar sistema yra 85 proc. Tai yra taškai, kuriuose AI daro galutinį pasirinkimą. ✅ Išnagrinėkite pasirinkimą: kiekvienam pasirinkimo taškui išsiaiškinkite konkrečią atliekamą vidinę matematiką arba palyginimą. Pavyzdys yra sutarties dalies suderinimas su politika. Kitas pavyzdys – sugedusio automobilio nuotraukos palyginimas su apgadintų automobilių nuotraukų biblioteka. 3 etapas: vartotojo patirties kūrimas ✅ Rašykite aiškius paaiškinimus: sukurkite vartotojui pranešimus, kuriuose aiškiai aprašomas konkretus vidinis veiksmas, vykstantis, kai DI pasirenka. Užuomina: pagrįskite savo pranešimus konkrečioje realybėje. Jei dirbtinis intelektas užsako susitikimą su klientu vietinėje kavinėje, pasakykite vartotojui, kad sistema tikrina kavinės rezervavimo sistemą. ✅ Atnaujinkite ekraną: įdėkite šiuos naujus aiškius paaiškinimus į vartotojo sąsają. Neaiškius pranešimus, pvz., Sutarčių peržiūra, pakeiskite konkrečiais paaiškinimais. ✅ Patikrinkite pasitikėjimą: įsitikinkite, kad nauji ekrano pranešimai naudotojams pateikia paprastą laukimo laiko ar rezultato priežastį. Tai turėtų padėti jiems jaustis pasitikinčiais ir pasitikinčiais. Patarimas: išbandykite šiuos pranešimus su tikrais vartotojais, kad įsitikintumėte, jog jie supranta konkretų pasiekiamą rezultatą.
