Projektēšana autonomiem aģentiem rada unikālu vilšanos. Mēs nododam AI sarežģītu uzdevumu, tas pazūd uz 30 sekundēm (vai 30 minūtēm) un pēc tam atgriežas ar rezultātu. Mēs skatāmies uz ekrānu. Vai tas izdevās? Vai tas radīja halucinācijas? Vai tas pārbaudīja atbilstības datu bāzi vai izlaida šo darbību? Mēs parasti reaģējam uz šo trauksmi ar vienu no divām galējībām. Mēs vai nu saglabājam sistēmu kā melno kasti, slēpjot visu, lai saglabātu vienkāršību, vai arī mēs esam panikā un nodrošinām datu izdruku, straumējot katru žurnāla rindiņu un API zvanu lietotājam. Neviena pieeja tieši neattiecas uz niansēm, kas nepieciešamas, lai nodrošinātu lietotājiem ideālu pārredzamības līmeni. Black Box ļauj lietotājiem justies bezspēcīgi. Data Dump rada paziņojumu aklumu, iznīcinot efektivitāti, ko aģents solīja nodrošināt. Lietotāji ignorē pastāvīgo informācijas plūsmu, līdz kaut kas sabojājas, un tad viņiem trūkst konteksta, lai to labotu. Mums ir nepieciešams organizēts veids, kā atrast līdzsvaru. Manā iepriekšējā rakstā “Designing for Agentic AI” mēs apskatījām interfeisa elementus, kas veido uzticību, piemēram, iepriekš parādot AI paredzēto darbību (Intent Previews) un ļaujot lietotājiem kontrolēt, cik daudz AI veic pats (Autonomy Dials). Taču zināt, kurus elementus izmantot, ir tikai daļa no izaicinājuma. Grūtākais jautājums dizaineriem ir zināt, kad tos izmantot. Kā zināt, kurā konkrētajā 30 sekunžu darbplūsmas brīdī ir nepieciešams nolūka priekšskatījums un kuru var apstrādāt, veicot vienkāršu žurnāla ierakstu? Šajā rakstā ir sniegta metode, kā atbildēt uz šo jautājumu. Mēs apskatīsim Lēmumu mezgla auditu. Šajā procesā dizaineri un inženieri nonāk vienā telpā, lai savienotu aizmugursistēmas loģiku ar lietotāja interfeisu. Jūs uzzināsit, kā precīzi noteikt brīžus, kad lietotājam ir nepieciešams atjauninājums par AI darbību. Mēs apskatīsim arī ietekmes/riska matricu, kas palīdzēs noteikt prioritāti, kuri lēmuma mezgli ir jāparāda, un visi saistītie dizaina modeļi, kas jāsavieno ar šo lēmumu. Pārredzamības momenti: gadījuma izpētes piemērs Apsveriet iespēju Meridian (nevis īstajā vārdā) — apdrošināšanas sabiedrību, kas izmanto aģentu AI, lai apstrādātu sākotnējos nelaimes gadījumu pieteikumus. Lietotājs augšupielādē fotogrāfijas ar transportlīdzekļa bojājumiem un policijas ziņojumu. Pēc tam aģents uz minūti pazūd, pirms atgriežas ar riska novērtējumu un piedāvāto izmaksu diapazonu. Sākotnēji Meridian saskarne vienkārši parādīja prasības statusa aprēķināšanu. Lietotāji kļuva neapmierināti. Viņi bija iesnieguši vairākus detalizētus dokumentus un jutās neskaidri par to, vai AI vispār ir izskatījusi policijas ziņojumu, kurā bija ietverti atbildību mīkstinoši apstākļi. Melnā kaste radīja neuzticību. Lai to novērstu, projektēšanas komanda veica Lēmuma mezgla auditu. Viņi atklāja, ka AI veica trīs atšķirīgas, uz varbūtību balstītas darbības, kurās bija iestrādāti daudzi mazāki soļi:
Attēlu analīze Lai novērtētu remonta izmaksas, aģents salīdzināja bojājumu fotoattēlus ar tipisku autoavārijas scenāriju datubāzi. Tas ietvēra pārliecības rādītāju. Textual ReviewIt skenēja policijas ziņojumu, meklējot atslēgvārdus, kas ietekmē atbildību (piemēram, vaina, laika apstākļi, prātīgums). Tas ietvēra juridiskā statusa varbūtības novērtējumu. Policy Cross ReferenceIt saskaņoja prasības informāciju ar lietotāja konkrētajiem politikas noteikumiem, meklējot izņēmumus vai seguma ierobežojumus. Tas ietvēra arī varbūtības saskaņošanu.
Komanda pārvērta šos soļus caurspīdīguma brīžos. Interfeisa secība tika atjaunināta uz:
Bojājumu fotoattēlu novērtēšana: salīdzinājums ar 500 transportlīdzekļu trieciena profiliem. Policijas ziņojuma pārskatīšana: atbildības atslēgvārdu un juridiskā precedenta analīze. Politikas pārklājuma pārbaude: pārbaudiet, vai jūsu plānā nav iekļauti konkrēti izņēmumi.
Sistēma joprojām prasīja tikpat daudz laika, taču skaidra saziņa par aģenta iekšējo darbību atjaunoja lietotāju uzticību. Lietotāji saprata, ka AI veic sarežģīto uzdevumu, kam tas bija paredzēts, un viņi precīzi zināja, kur pievērst uzmanību, ja galīgais novērtējums šķiet neprecīzs. Šī dizaina izvēle pārveidoja satraukuma brīdi par saiknes brīdi ar lietotāju. Ietekmes/riska matricas izmantošana: ko mēs izvēlējāmies slēpt Lielākajai daļai AI pieredzes netrūkst notikumu un lēmumu pieņemšanas mezglu, kas varētu tikt parādīti apstrādes laikā. Viens no vissvarīgākajiem revīzijas rezultātiem bija izlemt, ko paturēt neredzamu. Meridiāna piemērā aizmugursistēmas žurnāli ģenerēja vairāk nekā 50 notikumus katrai pretenzijai. Mēs varētu būt pēc noklusējuma rādīt katru notikumu, jo tie tika apstrādāti kā daļa no lietotāja interfeisa. Tā vietā mēs izmantojām riska matricu, lai tās apgrieztu:
Reģistrācijas notikums: nosūtīšanas serverisWest-2 atlaišanas pārbaudei. Filtrēšanas spriedums: Slēpt. (Zemas likmes, augsta tehnika).
Notikuma žurnāls: remonta aplēses salīdzināšana ar BlueBook vērtību. Filtrs Verdikts: Rādīt. (Lielas likmes ietekmē lietotāja izmaksu).
Izslēdzot nevajadzīgās detaļas, svarīga informācija, piemēram, pārklājuma pārbaude, bija ietekmīgāka. Mēs izveidojām atvērtu saskarni un izstrādājām atvērtu pieredzi. Šī pieeja izmanto ideju, ka cilvēki jūtas labāk par pakalpojumu, kad viņi redz, kā darbs tiek veikts. Parādot konkrētas darbības (novērtēšana, pārskatīšana, pārbaude), mēs mainījām 30 sekunžu gaidīšanu no satraukuma brīža (“Vai tas ir bojāts?”) uz laiku, kad sajūta, ka tiek radīts kaut kas vērtīgs (“Tas ir domāšana”). Tagad pievērsīsimies tuvāk tam, kā mēs varam pārskatīt lēmumu pieņemšanas procesu savos produktos, lai noteiktu galvenos momentus, kuros nepieciešama skaidra informācija. Lēmuma mezgla audits Caurspīdīgums neizdodas, ja mēs to uztveram kā stila izvēli, nevis funkcionālu prasību. Mums ir tendence jautāt: "Kādam vajadzētu izskatīties lietotāja interfeisam?" pirms mēs jautājam: "Ko aģents patiesībā izlemj?" Lēmuma mezgla audits ir vienkāršs veids, kā padarīt AI sistēmas vieglāk saprotamas. Tas darbojas, rūpīgi plānojot sistēmas iekšējo procesu. Galvenais mērķis ir atrast un skaidri definēt precīzus brīžus, kad sistēma pārstāj sekot saviem noteiktajiem noteikumiem un tā vietā izdara izvēli, pamatojoties uz nejaušību vai aplēsēm. Kartējot šo struktūru, veidotāji var parādīt šos nenoteiktības punktus tieši cilvēkiem, kuri izmanto sistēmu. Tas maina sistēmas atjauninājumus no neskaidriem paziņojumiem uz konkrētiem, uzticamiem ziņojumiem par to, kā AI nonāca pie secinājuma. Papildus iepriekš minētajam apdrošināšanas gadījuma pētījumam es nesen strādāju ar komandu, kas veido iepirkumu aģentu. Sistēma pārskatīja pārdevēja līgumus un atzīmēja riskus. Sākotnēji ekrānā bija redzama vienkārša progresa josla: “Līgumu pārskatīšana”. Lietotāji to ienīda. Mūsu pētījums liecināja, ka viņi bija noraizējušies par trūkstošās klauzulas juridiskajām sekām. Mēs to novērsām, veicot Lēmuma mezgla auditu. Šī raksta beigās esmu iekļāvis detalizētu kontrolsarakstu šīs revīzijas veikšanai. Mēs vadījām sesiju ar inženieriem un izklāstījām, kā sistēma darbojas. Mēs identificējām “lēmuma punktus” — brīžus, kad AI bija jāizvēlas starp divām labām iespējām. Standarta datorprogrammās process ir skaidrs: ja notiek A, tad B vienmēr notiks. AI sistēmās process bieži vien ir balstīts uz nejaušību. AI uzskata, ka A, iespējams, ir labākā izvēle, taču tā var būt tikai 65% droša. Līgumu sistēmā mēs atradām brīdi, kad AI pārbaudīja atbildības nosacījumu atbilstību mūsu uzņēmuma noteikumiem. Tas reti bija ideāls mačs. AI bija jāizlemj, vai 90% atbilstība ir pietiekami laba. Tas bija galvenais lēmuma pieņemšanas punkts.
Kad mēs identificējām šo mezglu, mēs to atklājām lietotājam. “Līgumu pārskatīšanas” vietā interfeiss tika atjaunināts, lai teiktu: “Atbildības klauzula atšķiras no standarta veidnes. Riska līmeņa analīze.” Šis konkrētais atjauninājums sniedza lietotājiem pārliecību. Viņi zināja, ka aģents ir pārbaudījis atbildības klauzulu. Viņi saprata kavēšanās iemeslu un ieguva pārliecību, ka vēlamā darbība notiek aizmugurē. Viņi arī zināja, kur iedziļināties, tiklīdz aģents bija izveidojis līgumu. Lai pārbaudītu, kā AI pieņem lēmumus, jums ir cieši jāsadarbojas ar saviem inženieriem, produktu vadītājiem, biznesa analītiķiem un galvenajiem cilvēkiem, kuri izdara (bieži vien slēptās) izvēles, kas ietekmē AI rīka darbību. Uzzīmējiet rīka darbības. Atzīmējiet katru vietu, kur process maina virzienu, jo pastāv varbūtība. Šīs ir vietas, kur jums vajadzētu koncentrēties uz pārredzamību. Kā parādīts 2. attēlā, Lēmuma mezgla audits ietver šādas darbības:
Salieciet komandu: iesaistiet produktu īpašniekus, biznesa analītiķus, dizainerus, galvenos lēmumu pieņēmējus un inženierus, kuri ir izveidojuši AI. Piemēram, Padomājiet par produktu komandu, kas veido AI rīku, kas paredzēts nekārtīgu juridisko līgumu pārskatīšanai. Komandā ietilpst UX dizaineris, produktu vadītājs, UX pētnieks, praktizējoša juriste, kas darbojas kā tēmas eksperts, un aizmugures inženieris, kurš uzrakstīja teksta analīzes kodu.
Uzzīmējiet visu procesu: dokumentējiet katru AI darbību, sākot no lietotāja pirmās darbības līdz gala rezultātam. Komanda stāv pie tāfeles un ieskicē visu secību galvenajai darbplūsmai, kas ietver AI, meklējot saistību klauzulu sarežģītā līgumā. Advokāts augšupielādēpiecdesmit lappušu PDF → Sistēma pārvērš dokumentu lasāmā tekstā. → AI skenē lapas, lai atrastu atbildības klauzulas. → Lietotājs gaida. → Brīdi vai minūtes vēlāk rīks lietotāja interfeisā izceļ atrastās rindkopas dzeltenā krāsā. Viņi to dara arī daudzām citām darbplūsmām, kuras nodrošina arī rīks.
Atrodiet, kur lietas ir neskaidras: skatiet procesu kartē jebkuru vietu, kur AI salīdzina opcijas vai ievades, kurām nav ideālas atbilstības. Komanda skatās uz tāfeli, lai pamanītu neskaidros soļus. Attēla pārveidošana tekstā atbilst stingriem noteikumiem. Konkrētas atbildības klauzulas atrašana ir saistīta ar minējumiem. Katrs uzņēmums raksta šīs klauzulas atšķirīgi, tāpēc AI ir jāizsver vairākas iespējas un jāizdara prognoze, nevis jāatrod precīza vārda atbilstība.
Nosakiet “labākā minējuma” darbības: katrai neskaidrajai vietai pārbaudiet, vai sistēma izmanto ticamības rādītāju (piemēram, vai tas ir pārliecināts par 85%?). Šie ir punkti, kuros AI izdara galīgo izvēli. Sistēmai ir jāuzmin (jānorāda varbūtība), kurš(-i) rindkopas(-as) ļoti līdzinās standarta atbildības klauzulai. Tā vislabākajam minējumam piešķir ticamības punktu. Šis minējums ir lēmuma mezgls. Interfeisam ir jāpaziņo juristam, ka tā izceļ iespējamo atbilstību, nevis norāda, ka tā ir atradusi galīgo klauzulu.
Izpētiet izvēli: katram izvēles punktam izdomājiet konkrēto iekšējo matemātiku vai salīdzinājumu, kas tiek veikts (piemēram, līguma daļas saskaņošana ar polisi vai salūzušas automašīnas attēla salīdzināšana ar bojātu automašīnu fotoattēlu bibliotēku). Inženieris paskaidro, ka sistēma salīdzina dažādus punktus ar standarta atbildības klauzulu datu bāzi no iepriekšējiem stingrajiem gadījumiem. Tas aprēķina teksta līdzības rezultātu, lai izlemtu par atbilstību, pamatojoties uz varbūtībām.
Uzrakstiet skaidrus paskaidrojumus: izveidojiet lietotājam ziņojumus, kas skaidri apraksta konkrētu iekšējo darbību, kas notiek, kad AI izdara izvēli. Satura dizainers raksta konkrētu ziņojumu tieši šim brīdim. Teksts skan: Dokumenta teksta salīdzināšana ar standarta stingrām klauzulām, lai identificētu iespējamos atbildības riskus.
Atjauniniet ekrānu: ievietojiet šos jaunos, skaidrus skaidrojumus lietotāja saskarnē, aizstājot neskaidrus ziņojumus, piemēram, “Līgumu pārskatīšana”. Dizaineru komanda noņem vispārējo PDF apstrādes procesu. Viņi ievieto jauno skaidrojumu statusa joslā, kas atrodas tieši virs dokumentu skatītāja, kamēr AI domā.
Pārbaudiet uzticību: pārliecinieties, vai jaunie ekrāna ziņojumi lietotājiem sniedz vienkāršu iemeslu gaidīšanas laikam vai rezultātam, lai viņi justos pārliecinātāki un uzticamāki.
Ietekmes/riska matrica Kad jūs rūpīgi aplūkosit AI procesu, jūs, iespējams, atradīsit daudzus punktus, kuros tas izdara izvēli. AI var izdarīt desmitiem mazu izvēļu vienam sarežģītam uzdevumam. To visu parādīšana rada pārāk daudz nevajadzīgas informācijas. Šīs izvēles ir jāgrupē. Varat izmantot ietekmes/riska matricu, lai sakārtotu šīs izvēles, pamatojoties uz AI veikto darbību veidu(-ām). Šeit ir ietekmes/riska matricu piemēri: Pirmkārt, meklējiet zemas likmes un zemas ietekmes lēmumus. Zemas likmes / zema ietekme
Piemērs: faila struktūras sakārtošana vai dokumenta pārdēvēšana. Nepieciešamība pēc caurspīdīguma: minimāla. Pietiek ar smalku tostu vai žurnāla ierakstu. Lietotāji var viegli atsaukt šīs darbības.
Pēc tam nosakiet augstas likmes un ietekmīgos lēmumus. Augstas likmes / liela ietekme
Piemērs: aizdevuma pieteikuma noraidīšana vai akciju tirdzniecības veikšana. Nepieciešamība pēc caurspīdīguma: augsta. Šīm darbībām ir nepieciešams darba apliecinājums. Sistēmai pirms vai tūlīt pēc darbības ir jāparāda pamatojums.
Apsveriet iespēju izveidot finanšu tirdzniecības robotu, kas visus pirkšanas/pārdošanas pasūtījumus apstrādā vienādi. Tas veic 5 USD darījumu ar tādu pašu necaurredzamību kā USD 50 000 darījums. Lietotāji varētu apšaubīt, vai rīks atzīst pārredzamības iespējamo ietekmi uz tirdzniecību ar lielu dolāru summu. Viņiem ir nepieciešams, lai sistēma apturētu un parādītu savu darbu augsto likmju darījumos. Risinājums ir ieviest pārskatīšanas loģikas stāvokli jebkuram darījumam, kas pārsniedz noteiktu dolāru summu, ļaujot lietotājam pirms izpildes redzēt faktorus, kas nosaka lēmumu. Mezglu kartēšana uz modeļiem: dizaina modeļa atlases rubrika Kad esat identificējis savas pieredzes galvenos lēmumu pieņemšanas mezglus, jums ir jāizlemj, kurš lietotāja interfeisa modelis attiecas uz katru no tiem, ko parādīsit. Sadaļā Designing For Agentic AI mēs ieviesām tādus modeļus kā Intent Preview (augstu likmju kontrolei) un Action Audit (retrospektīvai drošībai). Izšķirošais faktors, izvēloties starp tiem, ir atgriezeniskums. Mēs filtrējam katrulēmuma mezglu, izmantojot ietekmes matricu, lai piešķirtu pareizo modeli: Augstas likmes un neatgriezeniski: šiem mezgliem ir nepieciešams nolūka priekšskatījums. Tā kā lietotājs nevar viegli atsaukt darbību (piemēram, neatgriezeniski dzēst datubāzi), caurspīdīguma brīdim ir jānotiek pirms izpildes. Sistēmai ir jāaptur, jāpaskaidro tās nodoms un jāpieprasa apstiprinājums. Augstas likmes un atgriezeniski: šie mezgli var paļauties uz darbību audita un atsaukšanas modeli. Ja ar mākslīgo intelektu darbināmais tirdzniecības aģents pārvieto potenciālo pirkumu uz citu konveijeru, tas var to darīt autonomi, ja vien tas informē lietotāju un piedāvā tūlītēju atsaukšanas pogu. Šādi stingri klasificējot mezglus, mēs izvairāmies no "trauksmes noguruma". Mēs rezervējam augstas berzes nolūka priekšskatījumu tikai patiesi neatgriezeniskiem brīžiem, vienlaikus paļaujoties uz darbību auditu, lai saglabātu ātrumu visam pārējam.
Atgriezenisks Neatgriezenisks Zema ietekme Tips: Auto-ExecuteUI: pasīvs grauzdiņš / LogEx: faila pārdēvēšana Tips: ConfirmUI: vienkārša atsaukšanas iespēja, piemēram: e-pasta arhivēšana Augsta ietekme Veids: ReviewUI: paziņojums + pārskats TrailEx: melnraksta nosūtīšana klientam Veids: nolūka priekšskatījuma lietotāja saskarne: modāla/precīza atļaujaPiemērs: servera dzēšana
1. tabula. Ietekmes un atgriezeniskuma matricu pēc tam var izmantot, lai kartētu jūsu caurspīdīguma momentus ar dizaina modeļiem. Kvalitatīva apstiprināšana: "Pagaidiet, kāpēc?" Pārbaude Jūs varat identificēt potenciālos mezglus uz tāfeles, taču jums tie ir jāapstiprina ar cilvēka uzvedību. Jums ir jāpārbauda, vai jūsu karte atbilst lietotāja garīgajam modelim. Es izmantoju protokolu ar nosaukumu "Pagaidiet, kāpēc?" Pārbaude. Lūdziet lietotājam skatīties, kā aģents veic uzdevumu. Uzdodiet viņiem runāt skaļi. Ikreiz, kad viņi uzdod jautājumu: "Pagaidiet, kāpēc tas tā darīja?" vai "Vai tas ir iestrēdzis?" vai "Vai tas mani dzirdēja?" — jūs atzīmējat laikspiedolu. Šie jautājumi norāda uz lietotāja apjukumu. Lietotājs jūt, ka viņu kontrole izslīd. Piemēram, pētījumā par veselības aprūpes plānošanas palīgu lietotāji skatījās, kā aģents rezervēja tikšanos. Ekrāns četras sekundes palika nekustīgs. Dalībnieki pastāvīgi jautāja: "Vai tas pārbauda manu vai ārsta kalendāru?"
Šis jautājums atklāja trūkstošo Pārredzamības brīdi. Sistēmai bija jāsadala šī četru sekunžu gaidīšana divās atšķirīgās darbībās: “Pieejamības pārbaude”, kam sekoja “Sinhronizācija ar pakalpojumu sniedzēja grafiku”. Šīs nelielās izmaiņas samazināja lietotāju izteikto trauksmes līmeni. Caurspīdība neizdodas, ja tā apraksta tikai sistēmas darbību. Interfeisam ir jāsavieno tehniskais process ar lietotāja konkrēto mērķi. Ekrāns, kurā redzams “Pārbauda pieejamību”, izkrīt, jo tam trūkst konteksta. Lietotājs saprot, ka AI skatās kalendāru, bet nezina, kāpēc. Mums darbība ir jāsavieno ar rezultātu. Sistēmai šī četru sekunžu gaidīšana ir jāsadala divos atšķirīgos posmos. Pirmkārt, saskarnē tiek parādīts ziņojums “Pārbauda kalendāru, lai atrastu darba laikus”. Pēc tam tas tiek atjaunināts uz “Sinhronizācija ar pakalpojumu sniedzēja grafiku, lai nodrošinātu jūsu tikšanos”. Tas pamato tehnisko procesu lietotāja faktiskajā dzīvē. Apsveriet iespēju AI pārvaldīt vietējās kafejnīcas inventāru. Sistēma saskaras ar piegādes trūkumu. Interfeiss, kas lasa “sazināšanās ar pārdevēju” vai “opciju pārskatīšana”, rada trauksmi. Vadītājs interesējas, vai sistēma atceļ pasūtījumu vai pērk dārgu alternatīvu. Labāka pieeja ir izskaidrot paredzēto rezultātu: "Alternatīvu piegādātāju novērtēšana, lai saglabātu piektdienas piegādes grafiku." Tas lietotājam precīzi norāda, ko AI cenšas sasniegt. Revīzijas operacionalizācija Jūs esat pabeidzis Lēmuma mezgla auditu un filtrējis savu sarakstu, izmantojot ietekmes un riska matricu. Tagad jums ir saraksts ar svarīgiem brīžiem, lai būtu caurspīdīgs. Pēc tam tie ir jāizveido lietotāja saskarnē. Šis solis prasa komandas darbu dažādās nodaļās. Jūs nevarat izveidot caurspīdīgumu pats, izmantojot dizaina rīku. Jums ir jāsaprot, kā sistēma darbojas aizkulisēs. Sāciet ar loģikas pārskatu. Sazinieties ar savu vadošo sistēmu izstrādātāju. Ņemiet līdzi savu lēmumu pieņemšanas mezglu karti. Jums ir jāapstiprina, ka sistēma faktiski var koplietot šos stāvokļus. Es bieži atklāju, ka tehniskā sistēma neatklāj precīzu stāvokli, kādu es vēlos parādīt. Inženieris varētu teikt, ka sistēma vienkārši atgriež vispārēju “darba” statusu. Jums ir jāpiespiež detalizēts atjauninājums. Lai nosūtītu īpašu paziņojumu, jums ir nepieciešama sistēmakad tas pārslēdzas no teksta lasīšanas uz noteikumu pārbaudi. Bez šī tehniskā savienojuma jūsu dizainu nav iespējams izveidot. Pēc tam iesaistiet satura dizaina komandu. Jums ir AI darbības tehniskais iemesls, taču jums ir nepieciešams skaidrs, cilvēkiem draudzīgs skaidrojums. Inženieri nodrošina pamatā esošo procesu, bet satura dizaineri nodrošina veidu, kā tas tiek paziņots. Nerakstiet šīs ziņas vienatnē. Izstrādātājs var uzrakstīt "Izpildes funkciju 402", kas ir tehniski pareizi, bet lietotājam bezjēdzīgi. Dizaineris var uzrakstīt “Domāšana”, kas ir draudzīgs, bet pārāk neskaidrs. Satura stratēģis atrod pareizo vidusceļu. Tie rada īpašas frāzes, piemēram, “Atbildības risku meklēšana”, kas parāda, ka AI darbojas, nemulsinot lietotāju. Visbeidzot pārbaudiet savu ziņojumu caurspīdīgumu. Negaidiet, līdz tiks izveidots galaprodukts, lai redzētu, vai teksts darbojas. Es veicu vienkāršu prototipu salīdzināšanas testus, kur vienīgais, kas mainās, ir statusa ziņojums. Piemēram, es parādu vienai grupai (A grupa) ziņojumu, kurā teikts “Identitātes pārbaude”, bet citai grupai (B grupa) ziņojumu ar tekstu “Pārbauda valdības datu bāzes” (tie ir izdomāti piemēri, bet jūs saprotat būtību). Tad es viņiem jautāju, kurš AI jūtas drošāks. Jūs bieži atklāsit, ka daži vārdi rada bažas, bet citi vairo uzticību. Jums ir jāizturas pret formulējumu kā pret kaut ko, kas jums jāpārbauda un jāpierāda efektivitāte. Kā tas maina projektēšanas procesu Šo auditu veikšana var uzlabot komandas sadarbību. Mēs pārtraucam noslīpētu dizaina failu izsniegšanu. Mēs sākam izmantot nekārtīgus prototipus un koplietotas izklājlapas. Galvenais rīks kļūst par caurspīdīguma matricu. Inženieri un satura dizaineri kopā rediģē šo izklājlapu. Viņi precīzi atbilst tehniskajiem kodiem vārdiem, kurus lietotājs lasīs. Loģiskas pārbaudes laikā komandas piedzīvos berzi. Iedomājieties dizaineru, kurš jautā inženierim, kā AI nolemj noraidīt darījumu, kas iesniegts izdevumu pārskatā. Inženieris varētu teikt, ka aizmugursistēma izvada tikai vispārēju statusa kodu, piemēram, “Kļūda: trūkst datu”. Dizaineris norāda, ka šī informācija ekrānā nav izmantojama. Projektētājs veic pārrunas ar inženieri, lai izveidotu konkrētu tehnisko āķi. Inženieris uzraksta jaunu kārtulu, lai sistēma ziņotu tieši par trūkstošo, piemēram, trūkstošo kvīts attēlu. Šajā posmā satura veidotāji darbojas kā tulkotāji. Izstrādātājs var uzrakstīt tehniski precīzu virkni, piemēram, “Uzticības sliekšņa aprēķināšana piegādātāja saskaņošanai”. Satura dizainers pārvērš šo virkni frāzē, kas vairo uzticību konkrētam rezultātam. Stratēģis to pārraksta kā “Vietējo pārdevēju cenu salīdzināšana, lai nodrošinātu piektdienas piegādi”. Lietotājs saprot darbību un rezultātu. Visa starpfunkcionālā komanda piedalās lietotāju testēšanas sesijās. Viņi skatās, kā reāla persona reaģē uz dažādiem statusa ziņojumiem. Redzot lietotāja paniku, jo ekrānā ir uzraksts “Tirdzniecības izpilde”, komanda liek pārdomāt savu pieeju. Inženieri un dizaineri pieskaņojas labākam formulējumam. Pirms akciju iegādes viņi maina tekstu uz “Pārbauda pietiekami daudz līdzekļu”. Kopīga pārbaude garantē, ka gala saskarne kalpo gan sistēmas loģikai, gan lietotāja sirdsmieram. Ir nepieciešams laiks, lai šīs papildu aktivitātes iekļautu komandas kalendārā. Tomēr gala rezultātam vajadzētu būt komandai, kas sazinās atklātāk, un lietotājiem, kuriem ir labāka izpratne par to, ko viņu ar AI darbināmi rīki dara viņu vārdā (un kāpēc). Šī integrētā pieeja ir patiesi uzticamas AI pieredzes izstrādes stūrakmens. Uzticība ir dizaina izvēle Mēs bieži uzskatām, ka uzticēšanās ir labas lietotāja pieredzes emocionāls blakusprodukts. Uzticību ir vieglāk uzskatīt par paredzamas komunikācijas mehānisku rezultātu. Mēs veidojam uzticību, īstajā laikā parādot pareizo informāciju. Mēs to iznīcinām, nomācot lietotāju vai pilnībā paslēpjot iekārtu. Sāciet ar Lēmumu mezgla auditu, jo īpaši attiecībā uz aģentu AI rīkiem un produktiem. Atrodiet brīžus, kad sistēma pieņem spriedumu. Kartē šos mirkļus riska matricā. Ja likmes ir augstas, atveriet kastīti. Parādiet darbu. Nākamajā rakstā mēs apskatīsim, kā izveidot šos momentus: kā uzrakstīt kopiju, strukturēt lietotāja interfeisu un rīkoties ar neizbēgamajām kļūdām, kad aģents to kļūdās. Pielikums: Lēmuma mezgla audita kontrolsaraksts 1. fāze: iestatīšana un kartēšana ✅ Salieciet komandu: iesaistiet produktu īpašniekus, biznesa analītiķus, dizainerus,galvenie lēmumu pieņēmēji un inženieri, kas izveidoja AI. Padoms: jums ir nepieciešami inženieri, lai izskaidrotu faktisko aizmugures loģiku. Nemēģiniet šo soli vienatnē. ✅ Uzzīmējiet visu procesu: dokumentējiet katru AI darbību, sākot no lietotāja pirmās darbības līdz gala rezultātam. Padoms. Fiziskā tāfeles sesija bieži vien ir vispiemērotākā šo sākotnējo darbību veikšanai. 2. fāze: slēptās loģikas atrašanās vietas noteikšana ✅ Atrodiet, kur lietas ir neskaidras: skatiet procesa kartē jebkuru vietu, kur AI salīdzina opcijas vai ievades, kurām nav ideālas atbilstības. ✅ Nosakiet labākās minējuma darbības: katrai neskaidrajai vietai pārbaudiet, vai sistēma izmanto ticamības rādītāju. Piemēram, jautājiet, vai sistēma ir pārliecināta par 85 procentiem. Šie ir punkti, kuros AI izdara galīgo izvēli. ✅ Pārbaudi izvēli: katram izvēles punktam izdomā konkrēto iekšējo matemātiku vai salīdzinājumu, kas tiek veikts. Piemērs ir līguma daļas saskaņošana ar polisi. Vēl viens piemērs ir salūzušas automašīnas attēla salīdzināšana ar bojātu automašīnu fotoattēlu bibliotēku. 3. fāze: lietotāja pieredzes izveide ✅ Rakstiet skaidrus paskaidrojumus: izveidojiet lietotājam ziņojumus, kas skaidri apraksta konkrētu iekšējo darbību, kas notiek, kad AI izdara izvēli. Padoms: pamatojiet savus ziņojumus konkrētā realitātē. Ja mākslīgais intelekts rezervē tikšanos ar klientu vietējā kafejnīcā, pastāstiet lietotājam, ka sistēma pārbauda kafejnīcas rezervēšanas sistēmu. ✅ Atjauniniet ekrānu: ievietojiet šos jaunos, skaidrus skaidrojumus lietotāja saskarnē. Aizstājiet neskaidrus ziņojumus, piemēram, Līgumu pārskatīšana, ar konkrētiem paskaidrojumiem. ✅ Pārbaudiet uzticību: pārliecinieties, vai jaunie ekrāna ziņojumi lietotājiem sniedz vienkāršu iemeslu gaidīšanas laikam vai rezultātam. Tam vajadzētu likt viņiem justies pārliecinātiem un uzticamiem. Padoms: pārbaudiet šos ziņojumus ar faktiskajiem lietotājiem, lai pārliecinātos, ka viņi saprot konkrēto sasniegto rezultātu.
