Autonoomsete agentide jaoks kavandamine tekitab ainulaadset pettumust. Anname tehisintellektile keeruka ülesande, see kaob 30 sekundiks (või 30 minutiks) ja naaseb siis tulemusega. Vaatame ekraani. Kas see töötas? Kas see tekitas hallutsinatsiooni? Kas see kontrollis vastavusandmebaasi või jättis selle sammu vahele? Tavaliselt reageerime sellele ärevusele ühega kahest äärmusest. Kas hoiame süsteemi musta kasti, peidame kõik lihtsuse säilitamiseks, või paanitseme ja pakume andmeväljavõtet, voogesitades kasutajale iga logirida ja API-kõne. Kumbki lähenemisviis ei käsitle otseselt nüansse, mis on vajalik kasutajatele ideaalse läbipaistvuse taseme tagamiseks. Black Box jätab kasutajad jõuetuks. Data Dump loob teavituspimeduse, hävitades tõhususe, mida agent lubas pakkuda. Kasutajad ignoreerivad pidevat teabevoogu, kuni midagi puruneb, siis puudub neil selle parandamiseks kontekst. Vajame tasakaalu leidmiseks organiseeritud viisi. Minu eelmises artiklis „Designing For Agentic AI” vaatlesime usaldust loovaid liidese elemente, nagu näiteks tehisintellekti kavandatud toimingu eelnevalt näitamine (Intent Previews) ja kasutajatele kontrolli andmine selle üle, kui palju AI ise teeb (autonoomiavalimised). Kuid teadmine, milliseid elemente kasutada, on vaid osa väljakutsest. Disainerite jaoks on raskem küsimus teada, millal neid kasutada. Kuidas teate, milline konkreetne hetk 30-sekundilises töövoos nõuab kavatsuse eelvaadet ja mida saab hallata lihtsa logikirjega? See artikkel pakub meetodit sellele küsimusele vastamiseks. Vaatame läbi otsustussõlme auditi. See protsess viib disainerid ja insenerid samasse ruumi, et vastendada taustaloogika kasutajaliidesega. Saate teada, kuidas täpselt kindlaks teha hetked, mil kasutaja vajab tehisintellekti tegemiste kohta värskendust. Samuti käsitleme mõju/riski maatriksit, mis aitab seada prioriteediks, milliseid otsustussõlme kuvada ja mis tahes seotud disainimustrit selle otsusega siduda. Läbipaistvuse hetked: juhtumiuuringu näide Mõelge Meridianile (mitte pärisnimele), kindlustusfirmale, mis kasutab esialgsete õnnetusjuhtumite nõuete menetlemiseks AI-d. Kasutaja laadib üles fotod sõiduki kahjustustest ja politseiraportist. Seejärel kaob agent minutiks, enne kui ta naaseb koos riskihinnangu ja väljamaksete vahemikuga. Algselt näitas Meridiani liides lihtsalt Nõude oleku arvutamine. Kasutajad olid pettunud. Nad olid esitanud mitu üksikasjalikku dokumenti ja tundsid ebakindlust, kas tehisintellekt oli üldse läbi vaadanud politseiraporti, mis sisaldas kergendavaid asjaolusid. Must Kast tekitas usaldamatuse. Selle parandamiseks viis disainimeeskond läbi otsustussõlme auditi. Nad leidsid, et tehisintellekt teostas kolm erinevat, tõenäosuspõhist sammu, millesse oli manustatud arvukalt väiksemaid samme:
PildianalüüsAgent võrdles kahjustuste fotosid tüüpiliste autoõnnetuste stsenaariumide andmebaasiga, et hinnata remondikulusid. See hõlmas usaldusskoori. Textual ReviewIt skaneeris politseiraportist vastutust mõjutavaid märksõnu (nt süü, ilmastikutingimused, kainus). See hõlmas õigusliku staatuse tõenäosuse hindamist. Policy Cross ReferenceIt sobitas nõude üksikasjad kasutaja konkreetsete poliitikatingimustega, otsides erandeid või katvuse piiranguid. See hõlmas ka tõenäosuslikku sobitamist.
Meeskond muutis need sammud läbipaistvuse hetkedeks. Liidese järjestust värskendati järgmiselt:
Kahjustuste fotode hindamine: võrrelda 500 sõiduki kokkupõrkeprofiiliga. Politseiaruande läbivaatamine: vastutuse märksõnade ja juriidilise pretsedendi analüüs. Eeskirjade katvuse kontrollimine: kontrollige, kas teie plaanis on konkreetseid välistusi.
Süsteem võttis ikka sama palju aega, kuid selgesõnaline suhtlus agendi sisemise töö kohta taastas kasutajate usalduse. Kasutajad mõistsid, et tehisintellekt täidab keerulist ülesannet, mille jaoks see oli loodud, ja teadsid täpselt, kuhu oma tähelepanu suunata, kui lõplik hinnang tundus ebatäpne. See disainivalik muutis ärevuse hetkeks ühenduse hetkeks kasutajaga. Mõju-/riskimaatriksi rakendamine: mida me otsustasime peita Enamikul tehisintellekti kogemustel pole puudust sündmustest ja otsustussõlmedest, mida võidakse töötlemise ajal kuvada. Auditi üks kriitilisemaid tulemusi oli otsustada, mida jätta nähtamatuks. Meridiani näites genereerisid taustalogid 50+ sündmust nõude kohta. Oleksime võinud vaikimisi kuvada iga sündmuse, kui neid kasutajaliidese osana töödeldi. Selle asemel kasutasime nende kärpimiseks riskimaatriksit:
Logisündmus: pingiserverWest-2 koondamise kontrollimiseks. Filtri otsus: peida. (Madalad panused, kõrge tehnilisus).
Logisündmus: remondihinnangu võrdlemine BlueBooki väärtusega. Filtri otsus: Näita. (Suured panused mõjutavad kasutaja väljamakseid).
Mittevajalike üksikasjade väljajätmisega oli oluline teave, nagu katvuse kontrollimine, mõjuvam. Lõime avatud liidese ja kujundasime avatud kogemuse. See lähenemisviis kasutab ideed, et inimesed tunnevad end teenuses paremini, kui nad näevad, kuidas tööd tehakse. Näidates konkreetseid samme (hindamine, ülevaatamine, kontrollimine), muutsime 30-sekundilise ooteaja murest ("Kas see on katki?") ajaks, mil tunneme, et midagi väärtuslikku luuakse ("See mõtleb"). Vaatame nüüd lähemalt, kuidas saame oma toodete otsustusprotsessi üle vaadata, et tuvastada võtmehetked, mis nõuavad selget teavet. Otsustussõlme audit Läbipaistvus ebaõnnestub, kui käsitleme seda pigem stiilivaliku kui funktsionaalse nõudena. Meil on kalduvus küsida: "Milline kasutajaliides peaks välja nägema?" enne kui küsime: "Mida agent tegelikult otsustab?" Otsustussõlme audit on lihtne viis tehisintellektisüsteemide arusaadavaks muutmiseks. See toimib, kaardistades hoolikalt süsteemi sisemise protsessi. Peamine eesmärk on leida ja selgelt määratleda täpsed hetked, mil süsteem lõpetab oma seatud reeglite järgimise ning teeb valiku juhuse või hinnangu põhjal. Seda struktuuri kaardistades saavad loojad neid ebakindluse punkte otse süsteemi kasutavatele inimestele näidata. See muudab süsteemivärskendused ebamäärasetest väidetest konkreetseteks usaldusväärseteks aruanneteks selle kohta, kuidas tehisintellekt oma järeldusele jõudis. Lisaks ülaltoodud kindlustusjuhtumi uuringule töötasin hiljuti hankeagendi loomise meeskonnaga. Süsteem vaatas üle müüjalepingud ja märgistas riskid. Algselt kuvas ekraanil lihtne edenemisriba: "Lepingute ülevaatamine". Kasutajad vihkasid seda. Meie uurimus näitas, et nad tundsid muret puuduva klausli õiguslike tagajärgede pärast. Parandasime selle, viies läbi otsustussõlme auditi. Lisasin selle artikli lõppu selle auditi läbiviimiseks samm-sammulise kontrollnimekirja. Korraldasime inseneridega sessiooni ja kirjeldasime, kuidas süsteem töötab. Tuvastasime "otsustuspunktid" - hetked, mil tehisintellekt pidi valima kahe hea valiku vahel. Tavalistes arvutiprogrammides on protsess selge: kui juhtub A, siis juhtub B alati. AI-süsteemides põhineb protsess sageli juhusel. AI arvab, et A on tõenäoliselt parim valik, kuid see võib olla ainult 65% kindel. Lepingusüsteemis leidsime hetke, mil tehisintellekt kontrollis vastutuse tingimusi meie ettevõtte reeglite järgi. See sobis harva ideaalselt. AI pidi otsustama, kas 90% vaste on piisavalt hea. See oli otsustava tähtsusega punkt.
Kui me selle sõlme tuvastasime, avalikustasime selle kasutajale. Selle asemel, et "Lepingud üle vaadata", värskendati liidest järgmiselt: "Vastutusklausel erineb standardmallist. Riskitaseme analüüsimine." See konkreetne värskendus andis kasutajatele kindlustunde. Nad teadsid, et agent kontrollis vastutusklauslit. Nad mõistsid viivituse põhjust ja saavutasid usalduse, et soovitud toiming toimus tagaosas. Samuti teadsid nad, kuhu kaevata, kui agent oli lepingu sõlminud. Et kontrollida, kuidas AI otsuseid teeb, peate tegema tihedat koostööd oma inseneride, tootejuhtide, ärianalüütikute ja võtmeisikutega, kes teevad valikuid (sageli varjatud), mis mõjutavad tehisintellekti tööriista toimimist. Joonistage tööriista sammud. Märkige iga koht, kus protsess muudab suunda, kuna tõenäosus on täidetud. Need on kohad, kus peaksite keskenduma läbipaistvamaks muutumisele. Nagu on näidatud alloleval joonisel 2, hõlmab otsustussõlme audit järgmisi samme.
Pange meeskond kokku: tooge kaasa tooteomanikud, ärianalüütikud, disainerid, peamised otsustajad ja tehisintellekti loonud insenerid. Näiteks Mõelge tootemeeskonnale, kes loob tehisintellekti tööriista, mis on loodud segaste juriidiliste lepingute ülevaatamiseks. Meeskonda kuuluvad UX-i disainer, tootejuht, UX-i uurija, praktiseeriv jurist, kes tegutseb teemaeksperdina, ja taustainsener, kes kirjutas tekstianalüüsi koodi.
Joonistage kogu protsess: dokumenteerige tehisintellekti iga samm, alates kasutaja esimesest toimingust kuni lõpptulemuseni. Meeskond seisab tahvli ääres ja visandab peamise töövoo kogu jada, mille käigus tehisintellekt otsib keerulises lepingus vastutusklauslit. Advokaat laadib ülesviiekümneleheküljeline PDF → Süsteem teisendab dokumendi loetavaks tekstiks. → AI skannib lehekülgi vastutusklauslite leidmiseks. → Kasutaja ootab. → Hetked või minutid hiljem tõstab tööriist leitud lõigud kasutajaliidesel kollase värviga esile. Nad teevad seda ka paljude muude töövoogude jaoks, mida tööriist samuti mahutab.
Otsige üles, kus asjad on ebaselged: vaadake protsessikaardilt kohta, kus tehisintellekt võrdleb valikuid või sisendeid, millel pole täiuslikku vastet. Meeskond vaatab tahvlit, et märgata ebaselgeid samme. Pildi teisendamine tekstiks järgib rangeid reegleid. Konkreetse vastutusklausli leidmine hõlmab oletamist. Iga ettevõte kirjutab neid klausleid erinevalt, nii et tehisintellekt peab kaaluma mitut võimalust ja tegema ennustuse, selle asemel, et leida täpset sõna vastet.
Tehke kindlaks parima arvamise etapid: iga ebaselge koha puhul kontrollige, kas süsteem kasutab usaldusskoori (näiteks kas see on 85% kindel?). Need on punktid, kus tehisintellekt teeb lõpliku valiku. Süsteem peab ära arvama (andma tõenäosuse), millised lõigud sarnanevad väga standardse vastutusklausliga. See määrab oma parimale arvamisele usaldusskoori. See oletus on otsustussõlm. Liides peab advokaadile ütlema, et see tõstab esile võimaliku vaste, selle asemel et öelda, et see leidis lõpliku klausli.
Kontrollige valikut: iga valikupunkti puhul mõelge välja konkreetne sisemine matemaatika või võrdlus (nt lepingu osa sobitamine poliisiga või katkise auto pildi võrdlemine kahjustatud auto fotode raamatukoguga). Insener selgitab, et süsteem võrdleb erinevaid lõike varasemate kindlate juhtumite standardsete vastutusklauslite andmebaasiga. See arvutab teksti sarnasuse skoori, et otsustada tõenäosuste põhjal sobivuse üle.
Kirjutage selged selgitused: looge kasutajale sõnumeid, mis kirjeldavad selgelt konkreetset sisemist tegevust, mis toimub siis, kui AI teeb valiku. Sisu kujundaja kirjutab konkreetse sõnumi just selle hetke jaoks. Tekst kõlab järgmiselt: Dokumendi teksti võrdlemine standardsete kindlate klauslitega, et tuvastada võimalikud vastutusriskid.
Ekraani värskendamine: lisage need uued selged selgitused kasutajaliidesesse, asendades ebamäärased sõnumid, nagu „Lepingute ülevaatamine”. Disainimeeskond eemaldab üldise PDF-i laadimiskeeruri. Nad lisavad uue selgituse olekuribale, mis asub otse dokumendivaaturi kohal, kui tehisintellekt mõtleb.
Kontrollige usaldust: veenduge, et uued ekraaniteated annaksid kasutajatele ooteaja või tulemuse jaoks lihtsa põhjuse, mis peaks muutma nad end enesekindlamaks ja usaldavamaks.
Mõju/riski maatriks Kui vaatate AI protsessi tähelepanelikult, leiate tõenäoliselt palju punkte, kus see valiku teeb. AI võib ühe keeruka ülesande jaoks teha kümneid väikeseid valikuid. Nende kõigi näitamine loob liiga palju tarbetut teavet. Peate need valikud rühmitama. Saate kasutada mõju-/riskimaatriksit, et sortida need valikud tehisintellekti toimingu(te) alusel. Siin on näited mõju/riski maatriksitest: Esiteks otsige madala panusega ja väikese mõjuga otsuseid. Madalad panused / madal mõju
Näide: failistruktuuri korrastamine või dokumendi ümbernimetamine. Läbipaistvuse vajadus: minimaalne. Piisab peenest toostiteatisest või logikirjest. Kasutajad saavad neid toiminguid hõlpsalt tagasi võtta.
Seejärel tehke kindlaks kõrge panusega ja suure mõjuga otsused. Kõrged panused / suur mõju
Näide: laenutaotluse tagasilükkamine või aktsiatehingu sooritamine. Läbipaistvuse vajadus: suur. Need toimingud nõuavad töötõendit. Süsteem peab näitama põhjendust enne või vahetult pärast tegutsemist.
Kaaluge finantskauplemisbotti, mis käsitleb kõiki ostu- ja müügikorraldusi ühtemoodi. See teostab 5-dollarise tehingu sama läbipaistmatusega kui 50 000-dollarine tehing. Kasutajad võivad küsida, kas tööriist tunneb ära läbipaistvuse võimaliku mõju suure dollarisummaga kauplemisele. Nad vajavad, et süsteem peataks ja näitaks oma tööd kõrgete panustega tehingute puhul. Lahenduseks on kehtestada ülevaatamise loogika olek iga tehingu jaoks, mis ületab teatud dollarisummat, võimaldades kasutajal enne täitmist näha otsuse tegemise tegureid. Sõlmede vastendamine mustritega: kujundusmustri valimise rubriik Kui olete oma kogemuse peamised otsustussõlmed tuvastanud, peate otsustama, milline kasutajaliidese muster kehtib iga kuvatava kohta. Teoses Designing For Agentic AI tutvustasime selliseid mustreid nagu Intent Preview (suure panusega kontrolli jaoks) ja Action Audit (tagantjärele ohutuse tagamiseks). Nende vahel valiku tegemisel on otsustav tegur pöörduvus. Filtreerime igaotsustussõlm mõjumaatriksi kaudu, et määrata õige muster: Suured panused ja pöördumatud: need sõlmed nõuavad kavatsuse eelvaadet. Kuna kasutaja ei saa toimingut hõlpsasti tagasi võtta (nt andmebaasi jäädavalt kustutada), peab läbipaistvusmoment toimuma enne käivitamist. Süsteem peab peatuma, selgitama oma kavatsust ja nõudma kinnitust. Kõrged panused ja pöörduvad: need sõlmed võivad tugineda toimingu auditi ja tagasivõtmise mustrile. Kui tehisintellektil töötav müügiagent viib müügivihje teisele torujuhtmele, saab ta seda teha iseseisvalt, kuni teavitab kasutajat ja pakub viivitamatut tühistamisnuppu. Sel viisil sõlmede rangelt kategoriseerides väldime "erksat väsimust". Jätame suure hõõrdumisega kavatsuste eelvaate ainult tõeliselt pöördumatute hetkede jaoks, samas toetume tegevusauditile, et säilitada kiirus kõige muu jaoks.
Pööratav Pöördumatu Madal mõju Tüüp: Auto-ExecuteUI: Passive Toast / LogEx: faili ümbernimetamine Tüüp: ConfirmUI: lihtne tagasivõtmisvalikNt: meili arhiveerimine Suur mõju Tüüp: ReviewUI: teavitus + ülevaade TrailEx: mustandi saatmine kliendile Tüüp: Intent previewUI: Modal / Explicit PermissionEx: Serveri kustutamine
Tabel 1. Mõju- ja pöörduvusmaatriksit saab seejärel kasutada teie läbipaistvuse hetkede kaardistamiseks disainimustritega. Kvalitatiivne valideerimine: "Oota, miks?" Test Võimalikud sõlmed saate tahvlil tuvastada, kuid peate need kinnitama inimkäitumisega. Peate kontrollima, kas teie kaart vastab kasutaja vaimsele mudelile. Ma kasutan protokolli nimega "Oota, miks?" Test. Paluge kasutajal jälgida, kuidas agent ülesande sooritab. Paluge neil valjusti rääkida. Kui nad esitavad küsimuse: "Oota, miks ta seda tegi?" või "Kas see on kinni jäänud?" või "Kas see kuulis mind?" — märgite ajatempli. Need küsimused viitavad kasutajate segadusse. Kasutaja tunneb, et tema kontroll libiseb käest. Näiteks tervishoiu planeerimise assistendi uuringus jälgisid kasutajad, kuidas agent broneeris kohtumise. Ekraan jäi neli sekundit staatiliseks. Osalejad küsisid järjekindlalt: "Kas see kontrollib minu või arsti kalendrit?"
See küsimus näitas puuduvat läbipaistvushetke. Süsteem pidi selle neljasekundilise ootamise jagama kaheks erinevaks etapiks: „Saadavuse kontrollimine”, millele järgnes „Sünkroonimine teenusepakkuja ajakavaga”. See väike muudatus vähendas kasutajate väljendatud ärevust. Läbipaistvus ebaõnnestub, kui see kirjeldab ainult süsteemi toimingut. Liides peab ühendama tehnilise protsessi kasutaja konkreetse eesmärgiga. Ekraan, mis kuvab „Saadavuse kontrollimine”, kukub tühjaks, kuna sellel puudub kontekst. Kasutaja saab aru, et AI vaatab kalendrit, kuid ta ei tea, miks. Peame toimingu siduma tulemusega. Süsteem peab jagama selle neljasekundilise ootamise kaheks erinevaks etapiks. Esiteks kuvab liides „Kalendri kontrollimine lahtiste aegade leidmiseks”. Seejärel värskendatakse valikut „Teie kohtumise kindlustamiseks sünkroonimine teenusepakkuja ajakavaga”. See põhjendab tehnilist protsessi kasutaja tegelikus elus. Kaaluge tehisintellekti haldamist kohaliku kohviku jaoks. Süsteemis esineb tarnepuudus. Liides, mis loeb "müüjaga ühenduse võtmine" või "valikute ülevaatamine", tekitab ärevust. Juht mõtleb, kas süsteem tühistab tellimuse või ostab kalli alternatiivi. Parem lähenemine on kavandatud tulemuse selgitamine: "Alternatiivsete tarnijate hindamine reedese tarnegraafiku säilitamiseks." See ütleb kasutajale täpselt, mida AI püüab saavutada. Auditi teostamine Olete lõpetanud otsustussõlme auditi ja filtreerinud oma loendi mõju- ja riskimaatriksi kaudu. Nüüd on teil nimekiri läbipaistvuse jaoks olulistest hetkedest. Järgmiseks peate need kasutajaliideses looma. See samm nõuab meeskonnatööd erinevates osakondades. Läbipaistvust ei saa disainitööriista kasutades ise kujundada. Peate mõistma, kuidas süsteem kulisside taga töötab. Alustage loogikaülevaatest. Tutvuge oma juhtsüsteemi kujundajaga. Tooge oma otsustussõlmede kaart. Peate kinnitama, et süsteem saab neid olekuid tegelikult jagada. Tihti avastan, et tehniline süsteem ei näita täpset olekut, mida soovin näidata. Insener võib öelda, et süsteem tagastab üldise "töötava" oleku. Peate nõudma üksikasjalikku värskendust. Konkreetse teate saatmiseks vajate süsteemikui see lülitub teksti lugemiselt reeglite kontrollimisele. Ilma selle tehnilise ühenduseta on teie disaini võimatu ehitada. Järgmisena kaasake sisukujunduse meeskond. Teil on tehisintellekti tegevuse tehniline põhjus, kuid vajate selget ja inimsõbralikku selgitust. Insenerid pakuvad alusprotsessi, kuid sisukujundajad pakuvad viisi, kuidas seda edastatakse. Ärge kirjutage neid sõnumeid üksi. Arendaja võib kirjutada "Täitefunktsiooni 402", mis on tehniliselt õige, kuid kasutaja jaoks mõttetu. Disainer võib kirjutada "Mõtlemise", mis on sõbralik, kuid liiga ebamäärane. Sisustrateeg leiab õige kesktee. Need loovad konkreetsed fraasid, näiteks "Vastutusriskide otsimine", mis näitavad, et tehisintellekt töötab kasutajat segadusse ajamata. Lõpuks testige oma sõnumite läbipaistvust. Ärge oodake lõpptoote valmimist, et näha, kas tekst töötab. Ma viin läbi lihtsate prototüüpide võrdlusteste, kus ainuke asi, mis muutub, on olekuteade. Näiteks näitan ühele rühmale (A-rühm) sõnumit, mis ütleb "identiteedi kontrollimine" ja teisele rühmale (B-rühmale) sõnumit "Valitsusasutuste andmebaaside kontrollimine" (need on väljamõeldud näited, kuid te mõistate asja mõtet). Seejärel küsin neilt, milline tehisintellekt tunneb end turvalisemalt. Sageli avastate, et teatud sõnad tekitavad muret, teised aga usaldust. Peate käsitlema sõnastust kui midagi, mida peate testima ja tõhusust tõestama. Kuidas see disainiprotsessi muudab Nende auditite läbiviimine võib tugevdada meeskonna koostööd. Lõpetame poleeritud disainifailide kätteandmise. Hakkame kasutama segaseid prototüüpe ja jagatud arvutustabeleid. Põhitööriistaks saab läbipaistvusmaatriks. Insenerid ja sisukujundajad muudavad seda arvutustabelit koos. Need kaardistavad täpsed tehnilised koodid sõnadega, mida kasutaja loeb. Loogikaülevaatuse ajal kogevad meeskonnad hõõrdumist. Kujutage ette disainerit, kes küsib insenerilt, kuidas AI otsustab kuluaruandes esitatud tehingu tagasi lükata. Insener võib öelda, et taustaprogramm väljastab ainult üldise olekukoodi, näiteks "Viga: puuduvad andmed". Disainer väidab, et see ei ole ekraanil olev teave. Konkreetse tehnilise konksu loomiseks peab disainer inseneriga läbirääkimisi. Insener kirjutab uue reegli, nii et süsteem teatab täpselt, mis puudu on, näiteks puuduv kviitungi pilt. Sisu kujundajad tegutsevad selles etapis tõlkijatena. Arendaja võib kirjutada tehniliselt täpse stringi, näiteks „Usaldusläve arvutamine tarnija sobitamiseks”. Sisu kujundaja tõlgib selle stringi fraasiks, mis loob usaldust konkreetse tulemuse suhtes. Strateeg kirjutab selle ümber järgmiselt: "Kohalike müüjate hindade võrdlemine reedese kohaletoimetamise tagamiseks". Kasutaja saab aru tegevusest ja tulemusest. Kogu funktsionaalne meeskond osaleb kasutajate testimises. Nad jälgivad, kuidas reaalne inimene reageerib erinevatele olekusõnumitele. Kasutaja paanika nägemine, kuna ekraanil on kirjas "Tehing kaubandus", sunnib meeskonda oma lähenemisviisi ümber mõtlema. Insenerid ja disainerid järgivad paremat sõnastust. Nad muudavad enne aktsiate ostmist teksti tekstiks "Piisav vahendite kontrollimine". Koos testimine tagab, et lõplik liides teenib nii süsteemiloogikat kui ka kasutaja meelerahu. Nende lisategevuste meeskonna kalendrisse lisamine nõuab aega. Lõpptulemuseks peaks aga olema meeskond, kes suhtleb avatumalt, ja kasutajad, kes mõistavad paremini, mida nende tehisintellektil töötavad tööriistad nende nimel (ja miks) teevad. See integreeritud lähenemisviis on tõeliselt usaldusväärse AI-kogemuse kujundamise nurgakivi. Usaldus on disaini valik Näeme usaldust sageli hea kasutajakogemuse emotsionaalse kõrvalsaadusena. Usaldust on lihtsam vaadelda kui ennustatava suhtluse mehaanilist tulemust. Loome usaldust, näidates õiget teavet õigel ajal. Hävitame selle kasutaja ülekoormamisega või masina täieliku peitmisega. Alustage otsustussõlme auditist, eriti tehisintellekti agentide tööriistade ja toodete puhul. Leidke hetked, mil süsteem teeb otsuse. Kaardistage need hetked riskimaatriksiga. Kui panused on suured, avage kast. Näidake tööd. Järgmises artiklis vaatleme, kuidas neid hetki kujundada: kuidas kirjutada koopiat, struktureerida kasutajaliidest ja käsitleda vältimatuid vigu, kui agent eksib. Lisa: Otsustussõlme auditi kontroll-loend 1. etapp: seadistamine ja kaardistamine ✅ Pange meeskond kokku: tooge kaasa tooteomanikud, ärianalüütikud, disainerid,peamised otsustajad ja tehisintellekti ehitanud insenerid. Vihje: peate tegelikku taustaloogikat selgitama insenerid. Ärge proovige seda sammu üksinda. ✅ Joonistage kogu protsess: dokumenteerige tehisintellekti iga samm, alates kasutaja esimesest tegevusest kuni lõpptulemuseni. Vihje. Füüsilise tahvli seanss sobib sageli kõige paremini nende esialgsete sammude joonistamiseks. 2. etapp: peidetud loogika leidmine ✅ Leidke kohad, kus asjad on ebaselged: vaadake protsessikaardilt kohta, kus tehisintellekt võrdleb valikuid või sisendeid, millel pole täiuslikku vastet. ✅ Tehke kindlaks parimad arvamise sammud: kontrollige iga ebaselge koha puhul, kas süsteem kasutab usaldusskoori. Näiteks küsige, kas süsteem on 85 protsenti kindel. Need on punktid, kus tehisintellekt teeb lõpliku valiku. ✅ Kontrollige valikut: iga valikupunkti jaoks mõelge välja konkreetne sisemine matemaatika või võrdlus, mida tehakse. Näiteks on lepingu osa sobitamine poliisiga. Teine näide hõlmab katkise auto pildi võrdlemist kahjustatud auto fotode raamatukoguga. 3. etapp: kasutajakogemuse loomine ✅ Kirjutage selged selgitused: looge kasutajale sõnumeid, mis kirjeldavad selgelt konkreetset sisemist tegevust, mis toimub, kui AI teeb valiku. Vihje: jahvatage oma sõnumid konkreetseks reaalsuseks. Kui tehisintellekt broneerib kohalikus kohvikus kliendiga kohtumise, öelge kasutajale, et süsteem kontrollib kohviku broneerimissüsteemi. ✅ Värskendage ekraani: lisage need uued selged selgitused kasutajaliidesesse. Asendage ebamäärased sõnumid (nt lepingute ülevaatamine) oma konkreetsete selgitustega. ✅ Kontrollige usaldusväärsust: veenduge, et uued ekraaniteated annaksid kasutajatele ooteaja või tulemuse jaoks lihtsa põhjuse. See peaks panema nad tundma end enesekindlalt ja usaldavalt. Vihje: testige neid sõnumeid tegelike kasutajatega, et veenduda, et nad mõistavad konkreetset saavutatavat tulemust.
