Az autonóm ügynökök számára történő tervezés egyedülálló frusztrációt jelent. Egy összetett feladatot átadunk egy MI-nek, az 30 másodpercre (vagy 30 percre) eltűnik, majd eredménnyel tér vissza. A képernyőt bámuljuk. Sikerült? Hallucinált? Ellenőrizte a megfelelőségi adatbázist, vagy kihagyta ezt a lépést? Erre a szorongásra jellemzően két véglet valamelyikével reagálunk. Vagy fekete dobozként tartjuk a rendszert, mindent elrejtve az egyszerűség megőrzése érdekében, vagy pánikba esünk, és adatkiíratást biztosítunk, amely minden naplósort és API-hívást streamel a felhasználónak. Egyik megközelítés sem foglalkozik közvetlenül azzal az árnyalattal, amely a felhasználók számára az átláthatóság ideális szintjének biztosításához szükséges. A Black Box miatt a felhasználók tehetetlennek érzik magukat. A Data Dump értesítési vakságot hoz létre, tönkretéve az ügynök által ígért hatékonyságot. A felhasználók figyelmen kívül hagyják az állandó információáramot, amíg valami el nem törik, ekkor hiányzik a kontextus a javításhoz. Szervezett módszerre van szükségünk az egyensúly megtalálásához. Korábbi, „Designing For Agentic AI” című cikkemben olyan interfész-elemeket vizsgáltunk, amelyek bizalmat építenek, mint például az AI tervezett műveletének előzetes bemutatása (Intent Previews), és lehetővé teszik a felhasználók számára, hogy szabályozzák, mennyit csinál az AI önmagában (Autonomy Dials). De tudni, hogy mely elemeket kell használni, csak egy része a kihívásnak. A tervezők számára nehezebb kérdés, hogy tudják, mikor használják őket. Honnan tudhatja, hogy egy 30 másodperces munkafolyamat melyik pillanatában van szükség Intent Preview-ra, és melyik kezelhető egy egyszerű naplóbejegyzéssel? Ez a cikk egy módszert kínál erre a kérdésre. Végigjárjuk a döntési csomópont auditját. Ez a folyamat a tervezőket és a mérnököket ugyanabban a helyiségben hozza létre, hogy leképezzék a háttér logikáját a felhasználói felületre. Megtanulhatja, hogyan határozhatja meg pontosan azokat a pillanatokat, amikor a felhasználónak frissítésre van szüksége az AI tevékenységéről. Kitérünk egy hatás/kockázat mátrixra is, amely segít prioritást adni, hogy mely döntési csomópontok jelenjenek meg, és minden kapcsolódó tervezési minta párosuljon a döntéssel. Átláthatósági pillanatok: példa egy esettanulmányra Vegyük fontolóra a Meridian (nem valódi név), egy biztosítótársaságot, amely egy ügynöki mesterséges intelligencia segítségével dolgozza fel a kezdeti baleseti kárigényeket. A felhasználó fotókat tölt fel a jármű sérüléseiről és a rendőrségi jelentésről. Az ügynök ezután egy percre eltűnik, mielőtt visszatérne egy kockázatértékeléssel és egy javasolt kifizetési tartománysal. Kezdetben a Meridian felülete egyszerűen a Claim Status kiszámítása feliratot mutatta. A felhasználók frusztráltak lettek. Számos részletes dokumentumot nyújtottak be, és bizonytalannak érezték, hogy az AI egyáltalán átnézte-e az enyhítő körülményeket tartalmazó rendőrségi jelentést. A Fekete Doboz bizalmatlanságot keltett. Ennek kijavításához a tervezőcsapat döntési csomópont-ellenőrzést végzett. Azt találták, hogy az AI három különálló, valószínűség-alapú lépést hajtott végre, számos kisebb lépéssel:
Képelemzés Az ügynök összehasonlította a kárfotókat a tipikus autóbaleset-forgatókönyvek adatbázisával, hogy megbecsülje a javítási költséget. Ez magabiztossági pontszámmal járt. Textual ReviewIt megvizsgálta a rendőrségi jelentést a felelősséget befolyásoló kulcsszavak után (pl. hiba, időjárás, józanság). Ez magában foglalta a jogképesség valószínűségének felmérését. A Policy Cross ReferenceIt összevetette a követelés részleteit a felhasználó konkrét irányelvi feltételeivel, kivételeket vagy lefedettségi korlátokat keresve. Ez a valószínűségi egyeztetést is magában foglalta.
A csapat ezeket a lépéseket átláthatósági pillanatokká változtatta. Az interfész sorrendje a következőre módosult:
A sérülésekről készült fényképek értékelése: Összehasonlítás 500 jármű ütközési profiljával. Rendőrségi jelentés áttekintése: A felelősségre vonatkozó kulcsszavak és a jogi precedens elemzése. Szabályzati lefedettség ellenőrzése: bizonyos kizárások ellenőrzése a tervben.
A rendszer ugyanannyi időt vett igénybe, de az ügynök belső működéséről szóló kifejezett kommunikáció helyreállította a felhasználók bizalmát. A felhasználók megértették, hogy a mesterséges intelligencia azt az összetett feladatot hajtja végre, amelyre tervezték, és pontosan tudták, hová kell összpontosítaniuk figyelmüket, ha a végső értékelés pontatlannak tűnt. Ez a tervezési választás a szorongás pillanatát a felhasználóval való kapcsolat pillanatává változtatta. A hatás/kockázat mátrix alkalmazása: amit elrejteni választottunk A legtöbb AI-élményben nincs hiány eseményekből és döntési csomópontokból, amelyek potenciálisan megjelenhetnek a feldolgozás során. Az ellenőrzés egyik legkritikusabb eredménye annak eldöntése volt, hogy mi maradjon láthatatlan. A Meridian példában a háttérnaplók jogcímenként több mint 50 eseményt generáltak. Alapértelmezés szerint úgy jeleníthettük meg az egyes eseményeket, ahogy azokat a felhasználói felület részeként dolgozták fel. Ehelyett a kockázati mátrixot alkalmaztuk a metszéshez:
Eseménynaplózás: Pinging szerverNyugat-2 a redundancia ellenőrzéséhez. Szűrő ítélet: Elrejtés. (Alacsony tét, magas technikai).
Eseménynaplózás: A javítási becslés összehasonlítása a BlueBook értékével. Szűrő ítélet: Mutasd. (Magas tét, hatással van a felhasználó kifizetésére).
A szükségtelen részletek kiiktatásával a fontos információk – például a lefedettség ellenőrzése – hatásosabbak voltak. Nyílt felületet hoztunk létre, és nyitott élményt terveztünk. Ez a megközelítés azt az elképzelést használja, hogy az emberek jobban érzik magukat egy szolgáltatással kapcsolatban, ha látják a munka elvégzését. A konkrét lépések (értékelés, áttekintés, ellenőrzés) bemutatásával megváltoztattuk a 30 másodperces várakozást az aggodalomról („Elromlott?”) egy olyan érzésre, amikor valami értékes dolog születik („Gondolkodás”). Most nézzük meg közelebbről, hogyan tekinthetjük át termékeinkben a döntéshozatali folyamatot, hogy azonosítsuk azokat a kulcsfontosságú pillanatokat, amelyek egyértelmű tájékoztatást igényelnek. A határozati csomópont auditja Az átláthatóság kudarcot vall, ha stílusválasztásként kezeljük, nem pedig funkcionális követelményként. Hajlamosak vagyunk feltenni a kérdést: „Hogy nézzen ki a felhasználói felület?” mielőtt megkérdeznénk: „Tulajdonképpen mit dönt az ügynök?” A Decision Node Audit egy egyszerű módszer az AI-rendszerek könnyebb megértésére. Úgy működik, hogy gondosan feltérképezi a rendszer belső folyamatait. A fő cél az, hogy megtaláljuk és egyértelműen meghatározzuk azokat a pillanatokat, amikor a rendszer abbahagyja a meghatározott szabályok betartását, és ehelyett véletlen vagy becslés alapján választ. Ennek a szerkezetnek a feltérképezésével az alkotók közvetlenül megmutathatják ezeket a bizonytalansági pontokat a rendszert használó embereknek. Ez a rendszerfrissítéseket homályos kijelentésekről konkrét, megbízható jelentésekre változtatja, amelyek arról szólnak, hogy az AI hogyan jutott a következtetésre. A fenti biztosítási esettanulmányon kívül nemrégiben egy beszerzési ügynököt építő csapattal dolgoztam. A rendszer felülvizsgálta a szállítói szerződéseket és megjelölte a kockázatokat. Eredetileg a képernyő egy egyszerű folyamatjelző sávot jelenített meg: „Szerződések áttekintése”. A felhasználók utálták. Kutatásunk azt mutatta, hogy aggódnak a hiányzó záradék jogi következményei miatt. Ezt döntési csomópont-audit végrehajtásával javítottuk. Ennek a cikknek a végén egy lépésenkénti ellenőrzőlistát mellékeltem az ellenőrzés elvégzéséhez. Megbeszélést folytattunk a mérnökökkel, és felvázoltuk a rendszer működését. Meghatároztuk a „döntési pontokat” – azokat a pillanatokat, amikor az AI-nak két jó lehetőség közül kellett választania. A szabványos számítógépes programokban a folyamat egyértelmű: ha A megtörténik, akkor B mindig megtörténik. Az AI-rendszerekben a folyamat gyakran a véletlenen alapul. Az AI szerint az A valószínűleg a legjobb választás, de lehet, hogy csak 65%-ban biztos. A szerződéses rendszerben találtunk egy pillanatot, amikor az AI ellenőrizte a felelősségi feltételeket cégünk szabályai szerint. Ritkán volt tökéletes egyezés. Az AI-nak kellett eldöntenie, hogy a 90%-os egyezés elég jó-e. Ez volt a kulcsfontosságú döntési pont.
Miután azonosítottuk ezt a csomópontot, közzétettük a felhasználó számára. A „Szerződések áttekintése” helyett a kezelőfelület a következőképpen módosult: „A felelősségi záradék eltér a szabványos sablontól. A kockázati szint elemzése.” Ez a konkrét frissítés önbizalmat adott a felhasználóknak. Tudták, hogy az ügynök ellenőrizte a felelősségi záradékot. Megértették a késés okát, és bizalmat nyertek abban, hogy a kívánt művelet a hátsó oldalon történik. Azt is tudták, hol kell mélyebbre ásni, miután az ügynök megalkotta a szerződést. Annak ellenőrzéséhez, hogy az MI hogyan hoz döntéseket, szorosan együtt kell működnie mérnökeivel, termékmenedzsereivel, üzleti elemzőivel és kulcsfontosságú személyeivel, akik meghozzák azokat a (gyakran rejtett) döntéseket, amelyek befolyásolják az AI-eszköz működését. Rajzolja le a szerszám lépéseit. Jelöljön meg minden olyan helyet, ahol a folyamat irányt változtat, mert a valószínűség teljesül. Ezek azok a helyek, ahol az átláthatóságra kell összpontosítania. Amint az alábbi 2. ábrán látható, a döntési csomópont ellenőrzése a következő lépéseket tartalmazza:
Állítsa össze a csapatot: hozza be a terméktulajdonosokat, az üzleti elemzőket, a tervezőket, a kulcsfontosságú döntéshozókat és az AI-t építő mérnököket. Például Gondoljon egy olyan termékcsapatra, amely egy mesterséges intelligencia-eszközt hoz létre, hogy felülvizsgálja a rendetlen jogi szerződéseket. A csapat tagja a UX tervező, a termékmenedzser, a UX-kutató, egy gyakorló jogász, aki a téma szakértőjeként működik, és a háttérmérnök, aki a szövegelemző kódot írta.
Rajzolja le a teljes folyamatot: dokumentálja az AI minden lépését, a felhasználó első lépésétől a végeredményig. A csapat a táblánál áll, és felvázolja a teljes szekvenciát egy kulcsfontosságú munkafolyamathoz, amely magában foglalja az MI-t, hogy felelősségi záradékot keressen egy összetett szerződésben. Az ügyvéd feltöltiegy ötven oldalas PDF → A rendszer a dokumentumot olvasható szöveggé alakítja. → Az AI átvizsgálja az oldalakat a felelősségi záradékokért. → A felhasználó vár. → Pillanatokkal vagy percekkel később az eszköz sárgával kiemeli a talált bekezdéseket a felhasználói felületen. Ezt számos más munkafolyamathoz is megteszik, amelyekhez az eszköz is képes.
Keresse meg azokat a helyeket, ahol a dolgok nem egyértelműek: Nézze meg a folyamattérképen azokat a helyeket, ahol a mesterséges intelligencia összehasonlítja azokat a lehetőségeket vagy bemeneteket, amelyeknek nincs tökéletes egyezése. A csapat a táblára néz, hogy észrevegye a kétértelmű lépéseket. A kép szöveggé alakítása szigorú szabályok szerint történik. Egy konkrét felelősségi záradék megtalálása találgatásokkal jár. Minden cég máshogy írja ezeket a záradékokat, ezért az AI-nak több lehetőséget kell mérlegelnie, és jóslatot kell készítenie ahelyett, hogy pontos szóegyezést találna.
Határozza meg a „legjobb tippelés” lépéseit: Minden tisztázatlan helyen ellenőrizze, hogy a rendszer használ-e megbízhatósági pontszámot (például 85%-ban biztos?). Ezek azok a pontok, ahol az MI meghozza a végső döntést. A rendszernek ki kell tippelnie (valószínűséget kell megadnia), mely bekezdés(ek) hasonlít(nak) szorosan egy szabványos felelősségi záradékra. A legjobb tipphez megbízhatósági pontszámot rendel. Ez a tipp egy döntési csomópont. A felületnek közölnie kell az ügyvéddel, hogy potenciális egyezést emel ki, ahelyett, hogy azt közölné, hogy megtalálta a végleges záradékot.
Vizsgálja meg a választást: Minden választási pontnál találja ki az elvégzendő konkrét belső matematikát vagy összehasonlítást (például egy szerződés egy részének összeegyeztetése kötvényekkel vagy egy törött autó képének összehasonlítása sérült autós fotókat tartalmazó könyvtárral). A mérnök elmagyarázza, hogy a rendszer összehasonlítja a különböző bekezdéseket a korábbi, határozott esetekből származó szabványos felelősségi záradékok adatbázisával. Kiszámítja a szöveghasonlósági pontszámot, hogy a valószínűségek alapján döntsön az egyezésről.
Írjon egyértelmű magyarázatokat: Hozzon létre üzeneteket a felhasználó számára, amelyek egyértelműen leírják a konkrét belső műveletet, amely akkor történik, amikor az MI választ. A tartalomtervező konkrét üzenetet ír erre a pillanatra. A szöveg a következő: Dokumentumszöveg összehasonlítása szabványos kikötésekkel a lehetséges felelősségi kockázatok azonosítása érdekében.
Frissítse a képernyőt: Helyezze be ezeket az új, világos magyarázatokat a felhasználói felületbe, és váltsa fel az olyan homályos üzeneteket, mint a „Szerződések áttekintése”. A tervezőcsapat eltávolítja az általános PDF-feldolgozó betöltő spinnert. Beillesztik az új magyarázatot egy állapotsorba, amely közvetlenül a dokumentumnézegető felett található, miközben az AI gondolkodik.
Megbízhatóság ellenőrzése: Győződjön meg arról, hogy az új képernyőn megjelenő üzenetek egyszerű okot adnak a felhasználóknak a várakozási időre vagy az eredményre, ami magabiztosabbá és bizalmasabbá teszi őket.
A hatás/kockázat mátrix Ha alaposan megvizsgálja a mesterséges intelligencia folyamatát, valószínűleg sok olyan pontot fog találni, ahol az AI döntést hoz. Egy mesterséges intelligencia több tucat apró döntést hozhat egyetlen összetett feladathoz. Ha mindegyiket megmutatja, túl sok felesleges információ keletkezik. Csoportosítania kell ezeket a lehetőségeket. Hatás/kockázati mátrix segítségével rendezheti ezeket a választásokat az MI által végrehajtott művelet(ek) alapján. Íme néhány példa a hatás/kockázat mátrixokra: Először is keressen alacsony tétű és csekély hatású döntéseket. Alacsony tét / alacsony hatás
Példa: Fájlstruktúra rendezése vagy dokumentum átnevezése. Átlátszóságigény: Minimális. Elég egy finom pohárköszöntő vagy egy naplóbejegyzés. A felhasználók könnyen visszavonhatják ezeket a műveleteket.
Ezután azonosítsa a nagy téttel bíró és nagy hatású döntéseket. High Stakes / High Impact
Példa: Hitelkérelem elutasítása vagy tőzsdei kereskedés végrehajtása. Átlátszóságigény: magas. Ezekhez a tevékenységekhez munkaigazolás szükséges. A rendszernek bemutatnia kell az indoklást a működése előtt vagy azonnal.
Tekintsünk egy pénzügyi kereskedési botot, amely minden vételi/eladási megbízást ugyanúgy kezel. 5 dolláros kereskedést hajt végre, ugyanolyan átlátszatlansággal, mint egy 50 000 dolláros kereskedést. A felhasználók megkérdőjelezik, hogy az eszköz felismeri-e az átláthatóság potenciális hatását a nagy dollárösszeg kereskedésére. Szükségük van a rendszerre, hogy szüneteltesse, és megmutassa a munkáját a nagy tétű ügyleteknél. A megoldás az, hogy minden, egy dolláros összeget meghaladó tranzakcióhoz be kell vezetni a Review Logic állapotot, amely lehetővé teszi a felhasználó számára, hogy a végrehajtás előtt lássa a döntést befolyásoló tényezőket. Csomópontok leképezése mintákhoz: Tervezési minta kiválasztási rubrika Miután azonosította az élmény kulcsfontosságú döntési csomópontjait, el kell döntenie, hogy melyik felhasználói felületi minta vonatkozik mindegyik megjelenítendőre. A Designing For Agentic AI-ben olyan mintákat vezettünk be, mint az Intent Preview (nagy téttel rendelkező vezérléshez) és az Action Audit (a visszamenőleges biztonság érdekében). A köztük való választásnál a reverzibilitás a döntő tényező. Mindent szűrünkdöntési csomópontot az impakt mátrixon keresztül a helyes minta hozzárendeléséhez: Magas tét és visszafordíthatatlan: Ezekhez a csomópontokhoz Intent Preview szükséges. Mivel a felhasználó nem tudja könnyen visszavonni a műveletet (például egy adatbázis végleges törlését), az átlátszósági pillanatnak a végrehajtás előtt meg kell történnie. A rendszernek szünetet kell tartania, meg kell magyaráznia a szándékát, és megerősítést kell kérnie. Magas tét és visszafordítható: Ezek a csomópontok az Action Audit & Undo mintára támaszkodhatnak. Ha a mesterséges intelligencia által működtetett értékesítési ügynök áthelyez egy leadet egy másik folyamatba, ezt önállóan is megteheti, amennyiben értesíti a felhasználót, és felajánlja az azonnali Visszavonás gombot. A csomópontok ilyen szigorú kategorizálásával elkerüljük az „éber fáradtságot”. A nagy súrlódású Intent Preview-t csak a valóban visszafordíthatatlan pillanatokra tartjuk fenn, miközben az Action Audit-ra hagyatkozunk, hogy minden másnál fenntartsa a sebességet.
Megfordítható Visszafordíthatatlan Alacsony hatás Típus: Auto-ExecuteUI: Passzív Toast / LogEx: Fájl átnevezése Típus: ConfirmUI: Egyszerű visszavonási lehetőségPl.: E-mail archiválása Nagy hatás Típus: ReviewUI: Értesítés + áttekintés TrailEx: Piszkozat küldése egy ügyfélnek Típus: Intent previewUI: Modális / Explicit PermissionEx: Szerver törlése
1. táblázat: A hatás- és megfordíthatósági mátrix ezután felhasználható az átláthatóság pillanatainak leképezésére a tervezési mintákra. Minőségi érvényesítés: "A várakozás, miért?" Teszt A lehetséges csomópontokat azonosíthatja a táblán, de érvényesítenie kell őket az emberi viselkedés alapján. Ellenőriznie kell, hogy a térkép megfelel-e a felhasználó mentális modelljének. A „Várj, miért?” nevű protokollt használom. Teszt. Kérje meg a felhasználót, hogy nézze meg, ahogy az ügynök végrehajt egy feladatot. Utasítsa őket, hogy beszéljenek hangosan. Valahányszor kérdést tesznek fel: „Várj, miért tette ezt?” vagy "Beragadt?" vagy „Hallott engem?” - megjelölsz egy időbélyeget. Ezek a kérdések a felhasználó zavarát jelzik. A felhasználó úgy érzi, az irányítása kicsúszik. Például egy egészségügyi ütemezési asszisztensnek készült tanulmányban a felhasználók figyelték, ahogy az ügynök foglal időpontot. A képernyő négy másodpercig mozdulatlan maradt. A résztvevők következetesen azt kérdezték: „Az én naptáram vagy az orvosé?”
Ez a kérdés feltárt egy hiányzó Átláthatósági pillanatot. A rendszernek ezt a négy másodperces várakozást két különálló lépésre kellett felosztania: „Elérhetőség ellenőrzése”, majd „Szinkronizálás a szolgáltató ütemezésével”. Ez a kis változás csökkentette a felhasználók kifejezett szorongását. Az átlátszóság meghiúsul, ha csak egy rendszerműveletet ír le. A felületnek össze kell kapcsolnia a technikai folyamatot a felhasználó konkrét céljával. Az „Elérhetőség ellenőrzése” feliratú képernyő elromlik, mert nincs kontextusa. A felhasználó megérti, hogy az AI egy naptárt néz, de nem tudja, miért. Párosítanunk kell a cselekvést az eredménnyel. A rendszernek ezt a négy másodperces várakozást két különálló lépésre kell felosztania. Először a felületen megjelenik a „Nyitott időpontok ellenőrzése a naptárban” üzenet. Ezután a „Szinkronizálás a szolgáltató ütemtervével a találkozó biztosítása érdekében” szövegre frissül. Ez megalapozza a technikai folyamatot a felhasználó tényleges életében. Fontolja meg a mesterséges intelligencia készletét egy helyi kávézó számára. A rendszer ellátási hiányba ütközik. A „kapcsolatfelvétel a szállítóval” vagy „opciók áttekintése” feliratú felület szorongást kelt. A menedzser kíváncsi, hogy a rendszer törli-e a rendelést, vagy drága alternatívát vásárol. Jobb megközelítés a tervezett eredmény magyarázata: „Alternatív beszállítók értékelése a pénteki szállítási ütemterv megtartása érdekében.” Ez pontosan megmondja a felhasználónak, hogy az AI mit próbál elérni. Az audit operacionalizálása Befejezte a döntési csomópont ellenőrzését, és a listát a hatás- és kockázati mátrixon keresztül szűrte. Most megvan az átláthatósághoz elengedhetetlen pillanatok listája. Ezután létre kell hoznia őket a felhasználói felületen. Ez a lépés csapatmunkát igényel a különböző részlegek között. Egyedül nem tervezhetsz átláthatóságot tervezőeszközzel. Meg kell értened, hogyan működik a rendszer a színfalak mögött. Kezdje egy logikai áttekintéssel. Találkozzon vezető rendszertervezőjével. Hozd el a döntési csomópontok térképét. Meg kell erősítenie, hogy a rendszer valóban meg tudja-e osztani ezeket az állapotokat. Gyakran tapasztalom, hogy a műszaki rendszer nem fedi fel pontosan azt az állapotot, amelyet meg akarok mutatni. A mérnök azt mondhatja, hogy a rendszer csak általános „működő” állapotot ad vissza. A részletes frissítésért nyomni kell. Konkrét értesítés küldéséhez szüksége van a rendszerreamikor a szövegolvasásról a szabályok ellenőrzésére vált át. E műszaki kapcsolat nélkül a tervet lehetetlen megépíteni. Ezután vonja be a tartalomtervező csapatot. Megvan a technikai oka az AI fellépésének, de világos, emberbarát magyarázatra van szüksége. A mérnökök biztosítják a mögöttes folyamatot, de a tartalomtervezők biztosítják a kommunikáció módját. Ne írja ezeket az üzeneteket egyedül. A fejlesztő írhat „402-es függvény végrehajtása”, ami technikailag helyes, de a felhasználó számára értelmetlen. Egy tervező írhat „Thinking”-et, ami barátságos, de túl homályos. A tartalomstratégia megtalálja a megfelelő középutat. Konkrét kifejezéseket hoznak létre, mint például a „Felelősségi kockázatok keresése”, amelyek megmutatják, hogy az AI működik anélkül, hogy megzavarná a felhasználót. Végül tesztelje üzenetei átláthatóságát. Ne várja meg a végtermék elkészítését, hogy megnézze, működik-e a szöveg. Összehasonlító teszteket végzek egyszerű prototípusokon, ahol csak az állapotüzenet változik. Például az egyik csoportnak (A csoport) megjelenítek egy üzenetet, amely azt mondja, hogy „Identitás ellenőrzése”, egy másik csoportnak (B csoport) pedig „Kormányzati adatbázisok ellenőrzése” (ezek kitalált példák, de érti a lényeget). Aztán megkérdezem őket, hogy melyik MI érzi magát biztonságosabbnak. Gyakran rájössz, hogy bizonyos szavak aggodalomra adnak okot, míg mások bizalmat építenek. A megfogalmazást úgy kell kezelnie, mint valami olyasmit, amelyet tesztelnie kell, és hatékonynak kell lennie. Hogyan változtatja meg ez a tervezési folyamatot Ezen auditok lefolytatása megerősítheti a csapat együttműködését. Leállítjuk a csiszolt tervfájlok átadását. Elkezdjük használni a rendetlen prototípusokat és a megosztott táblázatokat. Az alapvető eszköz egy átlátszósági mátrix lesz. A mérnökök és a tartalomtervezők együtt szerkesztik ezt a táblázatot. A pontos műszaki kódokat hozzárendelik azokhoz a szavakhoz, amelyeket a felhasználó olvasni fog. A csapatok súrlódást tapasztalnak a logikai áttekintés során. Képzeljünk el egy tervezőt, aki megkérdezi a mérnököt, hogy az MI hogyan dönt úgy, hogy elutasítja a költségjelentésen benyújtott tranzakciót. A mérnök azt mondhatja, hogy a háttérprogram csak egy általános állapotkódot ad ki, például „Hiba: hiányzó adatok”. A tervező kijelenti, hogy ez nem használható információ a képernyőn. A tervező tárgyal a mérnökkel egy konkrét műszaki horog létrehozásáról. A mérnök új szabályt ír, így a rendszer pontosan jelzi, mi hiányzik, például egy hiányzó nyugtakép. A tartalomtervezők fordítóként működnek ebben a fázisban. A fejlesztő technikailag pontos karakterláncot írhat, például „A megbízhatósági küszöb kiszámítása szállítóegyeztetéshez”. A tartalomtervező ezt a karakterláncot olyan kifejezéssé fordítja le, amely bizalmat épít egy adott eredményhez. A stratéga ezt így írja át: „A helyi gyártói árak összehasonlítása a pénteki kézbesítés biztosítása érdekében”. A felhasználó megérti a műveletet és az eredményt. A teljes, többfunkciós csapat részt vesz a felhasználói tesztelési munkameneteken. Figyelik, amint egy valós személy reagál a különböző állapotüzenetekre. Ha a felhasználó pánikba esik, mert a képernyőn az „Executing trade” felirat jelenik meg, a csapat arra kényszeríti, hogy újragondolja megközelítését. A mérnökök és a tervezők a jobb megfogalmazáshoz igazodnak. Részvényvásárlás előtt módosítják a szöveget: „Elégséges forrás ellenőrzése”. A közös tesztelés garantálja, hogy a végső interfész a rendszer logikáját és a felhasználó nyugalmát egyaránt szolgálja. Időre van szükség ahhoz, hogy ezeket a kiegészítő tevékenységeket beépítsék a csapat naptárába. A végeredménynek azonban egy nyíltabban kommunikáló csapatnak kell lennie, és a felhasználóknak, akik jobban megértik, mit tesznek az AI-alapú eszközeik a nevükben (és miért). Ez az integrált megközelítés az igazán megbízható AI-élmények kialakításának sarokköve. A bizalom tervezési választás Gyakran úgy tekintünk a bizalomra, mint a jó felhasználói élmény érzelmi melléktermékére. Könnyebb a bizalmat a kiszámítható kommunikáció mechanikus eredményének tekinteni. Úgy építjük ki a bizalmat, hogy a megfelelő információkat a megfelelő időben mutatjuk meg. Megsemmisítjük úgy, hogy túlterheljük a felhasználót, vagy teljesen elrejtjük a gépezetet. Kezdje a Decision Node Audittal, különösen az ügynöki AI-eszközök és -termékek esetében. Keresse meg azokat a pillanatokat, amikor a rendszer ítéletet mond. Térképezze fel ezeket a pillanatokat a kockázati mátrixban. Ha nagy a tét, nyissa ki a dobozt. Mutasd meg a munkát. A következő cikkben megvizsgáljuk, hogyan tervezzük meg ezeket a pillanatokat: hogyan írjuk meg a másolatot, hogyan strukturáljuk fel a felhasználói felületet, és hogyan kezeljük az elkerülhetetlen hibákat, ha az ügynök hibázik. Függelék: A határozati csomópont ellenőrzési ellenőrző listája 1. fázis: Beállítás és leképezés ✅ Hozd össze a csapatot: hozd be a terméktulajdonosokat, üzleti elemzőket, tervezőket,kulcsfontosságú döntéshozók és az AI-t építő mérnökök. Tipp: Szüksége van a mérnökökre, hogy elmagyarázzák a tényleges háttér logikát. Ne próbálkozzon egyedül ezzel a lépéssel. ✅ Rajzolja le a teljes folyamatot: dokumentálja az AI minden lépését, a felhasználó első lépésétől a végeredményig. Tipp: A kezdeti lépések megrajzolásához gyakran a fizikai tábla-munkamenet a legmegfelelőbb. 2. fázis: A rejtett logika megkeresése ✅ Keresse meg azokat a helyeket, ahol a dolgok nem egyértelműek: Nézze meg a folyamattérképen azokat a helyeket, ahol a mesterséges intelligencia összehasonlítja azokat az opciókat vagy bemeneteket, amelyeknek nincs tökéletes egyezése. ✅ Határozza meg a legjobb tippelési lépéseket: Minden tisztázatlan helyen ellenőrizze, hogy a rendszer használ-e megbízhatósági pontszámot. Például kérdezze meg, hogy a rendszer 85 százalékban biztos-e. Ezek azok a pontok, ahol az MI meghozza a végső döntést. ✅ Vizsgálja meg a választást: Minden választási ponthoz találja ki az adott belső matematikát vagy összehasonlítást. Példa erre a szerződés egy részének egy kötvényhez való illesztése. Egy másik példa egy törött autó képének összehasonlítása egy sérült autós fotókat tartalmazó könyvtárral. 3. fázis: A felhasználói élmény megteremtése ✅ Írjon egyértelmű magyarázatokat: Hozzon létre üzeneteket a felhasználó számára, amelyek egyértelműen leírják a konkrét belső műveletet, amely akkor történik, amikor az MI választ. Tipp: Alapozza meg üzeneteit a konkrét valóságban. Ha egy mesterséges intelligencia találkozót foglal le egy ügyféllel egy helyi kávézóban, közölje a felhasználóval, hogy a rendszer ellenőrzi a kávézó-foglalási rendszert. ✅ Frissítse a képernyőt: helyezze el ezeket az új, világos magyarázatokat a felhasználói felületen. Cserélje ki a homályos üzeneteket, mint például a Szerződések áttekintése a konkrét magyarázatokkal. ✅ Megbízhatóság ellenőrzése: Győződjön meg arról, hogy az új képernyőn megjelenő üzenetek egyszerű okot adnak a felhasználóknak a várakozási időre vagy az eredményre. Ettől magabiztosnak és bizalommal kell érezniük magukat. Tipp: Tesztelje ezeket az üzeneteket tényleges felhasználókkal, hogy megbizonyosodjon arról, hogy megértik az elérendő konkrét eredményt.
