Праектаванне для аўтаномных агентаў выклікае ўнікальнае расчараванне. Мы перадаем складанае заданне ІІ, ён знікае на 30 секунд (ці 30 хвілін), а потым вяртаецца з вынікам. Мы ўзіраемся ў экран. А атрымалася? Гэта былі галюцынацыі? Ён правяраў базу дадзеных адпаведнасці або прапусціў гэты крок? Звычайна мы рэагуем на гэтую трывогу адной з дзвюх крайнасцей. Мы альбо захоўваем сістэму як чорную скрыню, хаваючы ўсё, каб захаваць прастату, альбо панікуем і ствараем дамп даных, перадаючы кожны радок часопіса і выклік API карыстачу. Ні адзін з падыходаў непасрэдна не закранае нюансы, неабходныя для забеспячэння карыстальнікам ідэальнага ўзроўню празрыстасці. Чорная скрыня прымушае карыстальнікаў адчуваць сябе бяссільнымі. Дамп даных стварае слепату для апавяшчэнняў, знішчаючы эфектыўнасць, якую абяцаў забяспечыць агент. Карыстальнікі ігнаруюць пастаянны паток інфармацыі, пакуль нешта не зламаецца, і ў гэты момант ім не хапае кантэксту, каб гэта выправіць. Нам патрэбны арганізаваны спосаб знайсці баланс. У маім папярэднім артыкуле «Распрацоўка для Agentic AI» мы разглядалі элементы інтэрфейсу, якія ўмацоўваюць давер, напрыклад, загадзя паказваючы меркаванае дзеянне AI (Папярэдні прагляд намераў) і прадастаўляючы карыстальнікам кантроль над тым, колькі AI робіць сам па сабе (Autonomy Dials). Але ведаць, якія элементы выкарыстоўваць, - гэта толькі частка задачы. Больш складанае пытанне для дызайнераў - ведаць, калі іх выкарыстоўваць. Як даведацца, які канкрэтны момант у 30-секундным працоўным працэсе патрабуе папярэдняга прагляду намераў, а які можна апрацаваць простым запісам у журнале? Гэты артыкул дае спосаб адказаць на гэтае пытанне. Мы пройдземся па аўдыту вузла прыняцця рашэнняў. Гэты працэс прымушае дызайнераў і інжынераў знаходзіцца ў адным пакоі, каб адлюстраваць бэкэнд-логіку ў карыстальніцкім інтэрфейсе. Вы даведаецеся, як вызначыць дакладныя моманты, калі карыстальніку патрэбна інфармацыя аб тым, што робіць штучны інтэлект. Мы таксама разгледзім матрыцу ўздзеяння/рызыкі, якая дапаможа расставіць прыярытэты, якія вузлы прыняцця рашэння адлюстроўваць, і любы звязаны шаблон праектавання, які спалучаецца з гэтым рашэннем. Моманты празрыстасці: прыклад тэматычнага даследавання Разгледзім Meridian (не сапраўдная назва), страхавую кампанію, якая выкарыстоўвае агентскі штучны інтэлект для апрацоўкі першапачатковых патрабаванняў аб аварыях. Карыстальнік загружае фатаграфіі пашкоджанняў аўтамабіля і пратакол міліцыі. Затым агент знікае на хвіліну, перш чым вярнуцца з ацэнкай рызыкі і прапанаваным дыяпазонам выплат. Першапачаткова інтэрфейс Meridian проста паказваў Calculating Claim Status. Карыстальнікі расчароўваліся. Яны прадставілі некалькі падрабязных дакументаў і не ведалі, ці разглядаў AI нават міліцэйскі пратакол, які ўтрымліваў змякчальныя абставіны. Чорная скрыня выклікала недавер. Каб выправіць гэта, група дызайнераў правяла аўдыт вузла прыняцця рашэнняў. Яны выявілі, што штучны інтэлект выконвае тры розныя этапы, заснаваныя на верагоднасці, са шматлікімі ўбудаванымі меншымі крокамі:
Аналіз выявы Агент параўнаў фатаграфіі пашкоджанняў з базай дадзеных тыповых сцэнарыяў аўтамабільных аварый, каб ацаніць кошт рамонту. Гэта ўключала ацэнку даверу. Textual ReviewIt адсканаваў паліцэйскі пратакол на прадмет ключавых слоў, якія ўплываюць на адказнасць (напрыклад, віна, умовы надвор'я, цвярозасць). Гэта ўключала ацэнку верагоднасці юрыдычнага статусу. Перакрыжаваная спасылка на палітыку. Ён супастаўляе дэталі прэтэнзіі з канкрэтнымі ўмовамі палітыкі карыстальніка, шукаючы выключэнні або абмежаванні ахопу. Гэта таксама прадугледжвала імавернаснае супастаўленне.
Каманда ператварыла гэтыя крокі ў моманты празрыстасці. Паслядоўнасць інтэрфейсу была абноўлена да:
Ацэнка фатаграфій пашкоджанняў: параўнанне з 500 профілямі сутыкнення транспартных сродкаў. Разгляд паліцэйскай справаздачы: аналіз ключавых слоў аб адказнасці і прававога прэцэдэнту. Праверка ахопу палітыкі: праверка наяўнасці пэўных выключэнняў у вашым плане.
Сістэма па-ранейшаму займала столькі ж часу, але дакладная інфармацыя аб унутранай працы агента аднавіла давер карыстальнікаў. Карыстальнікі разумелі, што штучны інтэлект выконвае складаную задачу, для якой ён быў распрацаваны, і яны дакладна ведалі, на што засяродзіць сваю ўвагу, калі канчатковая ацэнка падасца недакладнай. Такі выбар дызайну ператварыў момант трывогі ў момант сувязі з карыстальнікам. Прымяненне матрыцы ўздзеяння/рызыкі: што мы вырашылі схаваць У большасці вопытаў штучнага інтэлекту няма недахопу ў падзеях і вузлах рашэнняў, якія патэнцыйна могуць адлюстроўвацца падчас апрацоўкі. Адным з найбольш крытычных вынікаў аўдыту было прыняцце рашэння аб тым, што пакінуць нябачным. У прыкладзе Meridian серверныя журналы стваралі 50+ падзей на прэтэнзію. Мы маглі б па змаўчанні адлюстроўваць кожную падзею, калі яна апрацоўвалася як частка карыстацкага інтэрфейсу. Замест гэтага мы ўжылі матрыцу рызыкі, каб скараціць іх:
Падзея ў журнале: пінг-серверЗахад-2 для праверкі празмернасці. Вердыкт фільтра: схаваць. (Нізкія стаўкі, высокая тэхнічнасць).
Журнал падзеі: Параўнанне ацэнкі рамонту з коштам BlueBook. Вердыкт фільтра: Паказаць. (Высокія стаўкі, уплываюць на выплату карыстальніка).
Выразаючы непатрэбныя дэталі, важная інфармацыя - напрыклад, праверка пакрыцця - была больш уплывовай. Мы стварылі адкрыты інтэрфейс і распрацавалі адкрыты вопыт. Гэты падыход выкарыстоўвае ідэю, што людзі адчуваюць сябе лепш аб паслузе, калі бачаць, як выконваецца праца. Паказваючы канкрэтныя крокі (ацэнка, агляд, праверка), мы змянілі 30-секунднае чаканне з часу турботы («Ён зламаўся?») на час адчування, што ствараецца нешта каштоўнае («Гэта думае»). Давайце зараз больш падрабязна разгледзім, як мы можам праглядзець працэс прыняцця рашэнняў у нашых прадуктах, каб вызначыць ключавыя моманты, якія патрабуюць дакладнай інфармацыі. Аўдыт вузла прыняцця рашэнняў Празрыстасць не працуе, калі мы разглядаем яе як выбар стылю, а не як функцыянальнае патрабаванне. У нас ёсць тэндэнцыя пытацца: «Як павінен выглядаць карыстацкі інтэрфейс?» перш чым мы спытаем: "Што насамрэч вырашае агент?" Аўдыт вузла прыняцця рашэнняў - гэта просты спосаб зрабіць сістэмы штучнага інтэлекту больш зразумелымі. Ён працуе шляхам стараннага адлюстравання ўнутраных працэсаў сістэмы. Асноўная мэта складаецца ў тым, каб знайсці і дакладна вызначыць моманты, калі сістэма перастае прытрымлівацца зададзеных правілаў і замест гэтага робіць выбар, заснаваны на выпадковасці або ацэнцы. Адлюстроўваючы гэтую структуру, стваральнікі могуць паказаць гэтыя моманты нявызначанасці непасрэдна людзям, якія выкарыстоўваюць сістэму. Гэта змяняе абнаўленні сістэмы з расплывістых заяваў на канкрэтныя, надзейныя справаздачы аб тым, як штучны інтэлект прыйшоў да высновы. У дадатак да страхавога выпадку, прыведзенага вышэй, я нядаўна працаваў з агентам па закупках, які стварае каманду. Сістэма правярала кантракты пастаўшчыкоў і адзначала рызыкі. Першапачаткова на экране была простая панэль прагрэсу: «Агляд кантрактаў». Карыстальнікі ненавідзелі гэта. Наша даследаванне паказала, што яны адчувалі трывогу з нагоды прававых наступстваў адсутнага пункта. Мы выправілі гэта, правёўшы аўдыт вузла прыняцця рашэнняў. Я ўключыў пакрокавы кантрольны спіс для правядзення гэтага аўдыту ў канцы гэтага артыкула. Мы правялі сесію з інжынерамі і апісалі, як працуе сістэма. Мы вызначылі «кропкі прыняцця рашэння» — моманты, калі ІІ павінен быў выбіраць паміж двума добрымі варыянтамі. У стандартных камп'ютэрных праграмах працэс зразумелы: калі адбываецца А, то Б заўсёды будзе адбывацца. У сістэмах штучнага інтэлекту працэс часта заснаваны на выпадковасці. ШІ лічыць, што А - гэта, верагодна, лепшы выбар, але ён можа быць упэўнены толькі на 65%. У кантрактнай сістэме мы знайшлі момант, калі штучны інтэлект правяраў умовы адказнасці на адпаведнасць правілам нашай кампаніі. Гэта рэдка было ідэальнае супадзенне. ШІ павінен быў вырашыць, ці дастаткова добрае супадзенне ў 90%. Гэта быў ключавы момант прыняцця рашэння.
Як толькі мы вызначылі гэты вузел, мы адкрылі яго для карыстальніка. Замест «Прагляду кантрактаў» інтэрфейс абноўлены, каб сказаць: «Палажэнне аб адказнасці адрозніваецца ад стандартнага шаблону. Аналіз узроўню рызыкі». Гэта канкрэтнае абнаўленне дало карыстальнікам упэўненасць. Яны ведалі, што агент праверыў пункт аб адказнасці. Яны зразумелі прычыну затрымкі і пераканаліся, што жаданае дзеянне адбываецца на задняй частцы. Яны таксама ведалі, дзе капаць глыбей, як толькі агент згенераваў кантракт. Каб праверыць, як штучны інтэлект прымае рашэнні, вам трэба цесна супрацоўнічаць са сваімі інжынерамі, менеджэрамі па прадуктах, бізнес-аналітыкамі і ключавымі людзьмі, якія робяць выбар (часта схаваны), які ўплывае на працу інструмента штучнага інтэлекту. Намалюйце крокі, якія робіць інструмент. Адзначце кожнае месца, дзе працэс змяняе кірунак, таму што існуе верагоднасць. Гэта месцы, дзе вы павінны засяродзіцца на большай празрыстасці. Як паказана на малюнку 2 ніжэй, аўдыт вузла прыняцця рашэнняў уключае ў сябе наступныя этапы:
Збярыце каманду: прыцягніце ўладальнікаў прадуктаў, бізнес-аналітыкаў, дызайнераў, ключавых асоб, якія прымаюць рашэнні, і інжынераў, якія стварылі штучны інтэлект. напрыклад, Падумайце аб камандзе прадукту, якая стварае інструмент штучнага інтэлекту, прызначаны для праверкі брудных юрыдычных кантрактаў. У каманду ўваходзяць UX-дызайнер, менеджэр па прадуктах, даследчык UX, практыкуючы юрыст, які выступае ў якасці эксперта па прадмету, і бэкэнд-інжынер, які напісаў код для аналізу тэксту.
Намалюйце ўвесь працэс: задакументуйце кожны крок, які робіць ІІ, ад першага дзеяння карыстальніка да канчатковага выніку. Каманда стаіць ля дошкі і накідвае ўсю паслядоўнасць ключавога працоўнага працэсу, які прадугледжвае пошук ІІ пункта аб адказнасці ў складаным кантракце. Адвакат загружаепяцідзесяцістаронкавы PDF → Сістэма пераўтворыць дакумент у чытэльны тэкст. → AI скануе старонкі на прадмет адказнасці. → Карыстальнік чакае. → Праз некалькі імгненняў ці хвілін інструмент вылучае знойдзеныя абзацы ў карыстальніцкім інтэрфейсе жоўтым колерам. Яны робяць гэта для многіх іншых працоўных працэсаў, якія інструмент таксама змяшчае.
Знайдзіце, дзе рэчы незразумелыя: паглядзіце на карту працэсу для любога месца, дзе штучны інтэлект параўноўвае параметры або ўводы, якія не маюць ідэальнага супадзення. Каманда глядзіць на дошку, каб заўважыць неадназначныя крокі. Пераўтварэнне выявы ў тэкст выконваецца па строгіх правілах. Пошук канкрэтнага пункта аб адказнасці прадугледжвае здагадкі. Кожная фірма піша гэтыя пункты па-рознаму, таму штучнаму інтэлекту трэба ўзважыць некалькі варыянтаў і зрабіць прагноз замест таго, каб знаходзіць дакладнае супадзенне слоў.
Вызначце этапы «найлепшага здагадкі»: для кожнага незразумелага месца праверце, ці выкарыстоўвае сістэма ацэнку даверу (напрыклад, ці ўпэўненая яна на 85%?). Гэта кропкі, дзе ІІ робіць канчатковы выбар. Сістэма павінна адгадаць (даць верагоднасць), які абзац(ы) вельмі нагадвае стандартны пункт аб адказнасці. Ён прысвойвае ацэнку даверу свайму лепшаму меркаванню. Гэтая здагадка з'яўляецца вузлом рашэння. Інтэрфейс павінен паведаміць юрысту, што ён падкрэслівае патэнцыйнае супадзенне, а не заяўляць, што знойдзены канчатковы пункт.
Праверце выбар: для кожнага пункта выбару высветліце канкрэтную ўнутраную матэматыку або параўнанне, якое праводзіцца (напрыклад, супастаўленне часткі кантракта з полісам або параўнанне выявы зламанай машыны з бібліятэкай фатаграфій пашкоджанай машыны). Інжынер тлумачыць, што сістэма параўноўвае розныя параграфы з базай дадзеных стандартных палажэнняў аб адказнасці з мінулых спраў фірмаў. Ён разлічвае ацэнку падабенства тэксту, каб прыняць рашэнне аб супадзенні на аснове верагоднасцей.
Напішыце зразумелыя тлумачэнні: стварайце паведамленні для карыстальніка, якія дакладна апісваюць канкрэтныя ўнутраныя дзеянні, якія адбываюцца, калі ІІ робіць выбар. Кантэнт-дызайнер піша канкрэтнае паведамленне менавіта для гэтага моманту. Тэкст абвяшчае: Параўнанне тэксту дакумента са стандартнымі палажэннямі фірмы для выяўлення магчымых рызык адказнасці.
Абнавіце экран: змясціце гэтыя новыя зразумелыя тлумачэнні ў карыстальніцкі інтэрфейс, замяніўшы расплывістыя паведамленні, такія як «Прагляд кантрактаў». Каманда дызайнераў выдаляе агульны круцёлак загрузкі Апрацоўкі PDF. Яны ўстаўляюць новае тлумачэнне ў радок стану, размешчаны прама над праглядальнікам дакументаў, пакуль штучны інтэлект думае.
Праверце давер: пераканайцеся, што новыя экранныя паведамленні даюць карыстальнікам простую прычыну для любога часу чакання або выніку, што павінна зрабіць іх больш упэўненымі і даверлівымі.
Матрыца ўздзеяння/рызыкі Пасля таго, як вы ўважліва паглядзіце на працэс штучнага інтэлекту, вы, верагодна, знойдзеце шмат момантаў, дзе ён робіць выбар. ШІ можа зрабіць дзясяткі дробных варыянтаў для адной складанай задачы. Паказ іх усіх стварае занадта шмат непатрэбнай інфармацыі. Вам трэба згрупаваць гэтыя выбары. Вы можаце выкарыстоўваць матрыцу ўздзеяння/рызыкі, каб сартаваць гэтыя варыянты на аснове тыпаў дзеянняў, якія выконвае ІІ. Вось прыклады матрыц уздзеяння/рызыкі: Па-першае, звярніце ўвагу на рашэнні з нізкімі стаўкамі і невялікім уздзеяннем. Нізкія стаўкі / нізкі ўплыў
Прыклад: арганізацыя файлавай структуры або перайменаванне дакумента. Патрэба ў празрыстасці: мінімальная. Дастаткова тонкага апавяшчэння або запісу ў журнале. Карыстальнікі могуць лёгка адмяніць гэтыя дзеянні.
Затым вызначце высокія стаўкі і важныя рашэнні. Высокія стаўкі / Высокі ўплыў
Прыклад: адхіленне заяўкі на пазыку або ажыццяўленне біржавога гандлю. Патрэба ў празрыстасці: высокая. Гэтыя дзеянні патрабуюць пацверджання працы. Сістэма павінна прадэманстраваць абгрунтаванне да або адразу, як яна дзейнічае.
Разгледзім фінансавага гандлёвага бота, які разглядае ўсе заказы на куплю/продаж аднолькава. Ён здзяйсняе здзелку ў 5 долараў з той жа непразрыстасцю, што і ў здзелцы ў 50 000 долараў. Карыстальнікі могуць задацца пытаннем, ці прызнае гэты інструмент магчымы ўплыў празрыстасці на гандаль вялікай сумай у доларах. Ім патрэбна, каб сістэма прыпыніла працу і паказала сваю працу для здзелак з высокімі стаўкамі. Рашэнне складаецца ў тым, каб увесці стан "Агляд логікі" для любой транзакцыі, якая перавышае пэўную суму ў доларах, што дазваляе карыстальніку бачыць фактары, якія абумоўліваюць рашэнне перад выкананнем. Супастаўленне вузлоў з шаблонамі: рубрыка выбару шаблонаў дызайну Пасля таго, як вы вызначылі ключавыя вузлы рашэння вашага вопыту, вы павінны вырашыць, які шаблон карыстацкага інтэрфейсу прымяняецца да кожнага з іх, якія вы будзеце паказваць. У Designing For Agentic AI мы ўвялі такія шаблоны, як Intent Preview (для кантролю з высокімі стаўкамі) і Action Audit (для рэтраспектыўнай бяспекі). Вырашальным фактарам пры выбары паміж імі з'яўляецца зваротнасць. Працэджваем кожнуювузел рашэння праз матрыцу ўздзеяння, каб прызначыць правільны шаблон: Высокія стаўкі і незваротнасць: гэтыя вузлы патрабуюць папярэдняга прагляду намераў. Паколькі карыстальнік не можа лёгка адмяніць дзеянне (напрыклад, незваротнае выдаленне базы дадзеных), момант празрыстасці павінен адбыцца перад выкананнем. Сістэма павінна зрабіць паўзу, растлумачыць свой намер і запытаць пацвярджэнне. Высокія стаўкі і зварачальныя: гэтыя вузлы могуць абапірацца на шаблон аўдыту дзеянняў і адмены. Калі агент па продажах на базе штучнага інтэлекту перамяшчае патэнцыйны кліент у іншы канвеер, ён можа рабіць гэта аўтаномна, пакуль ён апавяшчае карыстальніка і прапануе неадкладную кнопку "Адмяніць". Строга класіфікуючы вузлы такім чынам, мы пазбягаем «стомленасці абвесткі». Мы пакідаем Intent Preview з высокім узроўнем трэння толькі для сапраўды незваротных момантаў, а для ўсяго астатняга мы разлічваем на Action Audit для падтрымання хуткасці.
Зваротны Незваротны Нізкі ўдар Тып: Auto-ExecuteUI: Passive Toast / LogEx: Перайменаванне файла Тып: ConfirmUI: Простая опцыя адменыEx: Архіваванне электроннай пошты Высокі ўдар Тып: ReviewUI: Апавяшчэнне + Агляд TrailEx: Адпраўка чарнавіка кліенту Тып: Intent previewUI: Мадальны / Відавочны PermissionEx: Выдаленне сервера
Табліца 1: Матрыца ўздзеяння і зваротнасці можа быць выкарыстана для адлюстравання вашых момантаў празрыстасці ў шаблонах праектавання. Якасная праверка: «Чаму чакаць?» Тэст Вы можаце вызначыць патэнцыйныя вузлы на дошцы, але вы павінны пацвердзіць іх паводзінамі чалавека. Вам трэба праверыць, ці адпавядае ваша карта разумовай мадэлі карыстальніка. Я выкарыстоўваю пратакол пад назвай "Пачакайце, чаму?" Тэст. Папрасіце карыстальніка назіраць, як агент выконвае заданне. Даручыце ім гаварыць услых. Кожны раз, калі яны задаюць пытанне: "Пачакайце, чаму гэта зроблена?" або «Гэта затрымалася?» або «Ці пачуў ён мяне?» — вы пазначаеце пазнаку часу. Гэтыя пытанні сігналізуюць аб замяшанні карыстальнікаў. Карыстальнік адчувае, што іх кантроль выслізгвае. Напрыклад, у даследаванні для памочніка па планаванні медыцынскіх паслуг карыстальнікі назіралі, як агент запісваецца на прыём. Экран стаяў нерухома на працягу чатырох секунд. Удзельнікі паслядоўна пыталіся: "Гэта правярае мой каляндар ці доктара?"
Гэтае пытанне выявіла недахоп празрыстасці. Сістэме трэба было падзяліць гэтае чатырохсекунднае чаканне на два розныя этапы: «Праверка вашай даступнасці», а затым «Сінхранізацыя з раскладам пастаўшчыка». Гэта невялікае змяненне знізіла ўзровень трывожнасці карыстальнікаў. Празрыстасць не працуе, калі яна апісвае толькі дзеянне сістэмы. Інтэрфейс павінен падключаць тэхнічны працэс да канкрэтнай мэты карыстальніка. Экран з надпісам «Праверка даступнасці» не працуе, таму што на ім адсутнічае кантэкст. Карыстальнік разумее, што ІІ глядзіць на каляндар, але не ведае чаму. Мы павінны спалучаць дзеянне з вынікам. Сістэма павінна падзяліць гэтае чатырохсекунднае чаканне на два розныя крокі. Па-першае, інтэрфейс адлюстроўвае «Праверка вашага календара, каб знайсці час працы». Затым ён абнаўляецца да «Сінхранізацыя з раскладам пастаўшчыка, каб забяспечыць вашу сустрэчу». Гэта засноўвае тэхнічны працэс у рэальным жыцці карыстальніка. Разгледзім штучны інтэлект для кіравання інвентаром для мясцовага кафэ. Сістэма сутыкаецца з дэфіцытам запасаў. Інтэрфейс з надпісам «звязацца з пастаўшчыком» або «агляд варыянтаў» выклікае трывогу. Менеджэр цікавіцца, сістэма адмяняе заказ або купляе дарагую альтэрнатыву. Лепшы падыход - растлумачыць чаканы вынік: "Ацэнка альтэрнатыўных пастаўшчыкоў, каб захаваць графік дастаўкі ў пятніцу". Гэта паведамляе карыстальніку, чаго менавіта спрабуе дасягнуць ІІ. Аперацыяналізацыя аўдыту Вы завяршылі аўдыт вузла прыняцця рашэнняў і адфільтравалі свой спіс праз матрыцу ўздзеяння і рызыкі. Цяпер у вас ёсць спіс важных момантаў для празрыстасці. Далей вам трэба стварыць іх у карыстальніцкім інтэрфейсе. Гэты крок патрабуе сумеснай працы розных аддзелаў. Вы не можаце стварыць празрыстасць самастойна з дапамогай інструмента дызайну. Вы павінны разумець, як сістэма працуе за кулісамі. Пачніце з лагічнага агляду. Сустрэцца са сваім вядучым распрацоўшчыкам сістэмы. Вазьміце з сабой карту вузлоў рашэння. Вам трэба пацвердзіць, што сістэма сапраўды можа абагульваць гэтыя станы. Я часта лічу, што тэхнічная сістэма не паказвае той стан, які я хачу паказаць. Інжынер можа сказаць, што сістэма проста вяртае агульны «працоўны» статус. Вы павінны дамагацца дэталёвага абнаўлення. Вам патрэбна сістэма, каб адправіць канкрэтнае паведамленнекалі ён пераключаецца з чытання тэксту на праверку правіл. Без гэтай тэхнічнай сувязі немагчыма пабудаваць ваш дызайн. Далей прыцягніце каманду Content Design. У вас ёсць тэхнічная прычына дзеянняў штучнага інтэлекту, але вам патрэбна дакладнае, зручнае для чалавека тлумачэнне. Інжынеры забяспечваюць асноўны працэс, але дызайнеры кантэнту забяспечваюць спосаб яго перадачы. Не пішыце гэтыя паведамленні ў адзіночку. Распрацоўшчык можа напісаць «Выкананне функцыі 402», што тэхнічна правільна, але бессэнсоўна для карыстальніка. Дызайнер можа напісаць «Думаючы», што прыязна, але занадта расплывіста. Кантэнт-стратэг знаходзіць правільную залатую сярэдзіну. Яны ствараюць пэўныя фразы, такія як «Сканаванне рызык адказнасці», якія паказваюць, што штучны інтэлект працуе, не блытаючы карыстальніка. Нарэшце, праверце празрыстасць вашых паведамленняў. Не чакайце, пакуль будзе створаны канчатковы прадукт, каб убачыць, ці працуе тэкст. Я праводжу параўнальныя тэсты на простых прататыпах, дзе змяняецца толькі паведамленне аб стане. Напрыклад, я паказваю адной групе (групе A) паведамленне з надпісам «Праверка асобы», а іншай групе (групе B) паведамленне з надпісам «Праверка дзяржаўных баз даных» (гэта выдуманыя прыклады, але вы разумееце сутнасць). Затым я пытаюся ў іх, які штучны інтэлект адчувае сябе бяспечней. Вы часта выяўляеце, што некаторыя словы выклікаюць непакой, а іншыя ўмацоўваюць давер. Вы павінны разглядаць фармулёўкі як тое, што вам трэба праверыць і даказаць сваю эфектыўнасць. Як гэта змяняе працэс праектавання Правядзенне гэтых аўдытаў мае патэнцыял для ўмацавання сумеснай працы каманды. Мы спыняем перадачу адшліфаваных файлаў дызайну. Мы пачынаем выкарыстоўваць брудныя прататыпы і агульныя электронныя табліцы. Асноўным інструментам становіцца матрыца празрыстасці. Інжынеры і дызайнеры кантэнту разам рэдагуюць гэту табліцу. Яны супастаўляюць дакладныя тэхнічныя коды са словамі, якія прачытае карыстальнік. Падчас праверкі логікі каманды будуць сутыкацца. Уявіце, што дызайнер пытаецца ў інжынера, як ІІ вырашае адхіліць транзакцыю, прадстаўленую ў справаздачы аб выдатках. Інжынер можа сказаць, што бэкэнд выдае толькі агульны код стану, напрыклад «Памылка: адсутнічаюць дадзеныя». Дызайнер сцвярджае, што гэта не з'яўляецца інфармацыяй на экране. Дызайнер дамаўляецца з інжынерам аб стварэнні канкрэтнага тэхнічнага крука. Інжынер піша новае правіла, каб сістэма паведамляла, чаго менавіта не хапае, напрыклад, адсутнічае выява квітанцыі. Кантэнт-дызайнеры выконваюць ролю перакладчыкаў на гэтым этапе. Распрацоўшчык можа напісаць тэхнічна дакладны радок накшталт «Разлік парога даверу для супастаўлення пастаўшчыка». Дызайнер кантэнту перакладае гэты радок у фразу, якая стварае давер да пэўнага выніку. Стратэг перапісвае гэта як «Параўнанне коштаў мясцовых прадаўцоў, каб забяспечыць дастаўку ў пятніцу». Карыстальнік разумее дзеянне і вынік. Уся шматфункцыянальная каманда ўдзельнічае ў сеансах тэсціравання карыстальнікаў. Яны назіраюць, як рэальны чалавек рэагуе на розныя паведамленні аб статусе. Убачыўшы, што карыстальнік панікуе, таму што на экране напісана «Выкананне гандлю», каманда прымушае перагледзець свой падыход. Інжынеры і дызайнеры сышліся на лепшай фармулёўцы. Перад пакупкай акцый яны змяняюць тэкст на «Праверка дастатковай колькасці сродкаў». Сумеснае тэсціраванне гарантуе, што канчатковы інтэрфейс адпавядае як логіцы сістэмы, так і душэўнаму спакою карыстальніка. Гэта патрабуе часу, каб уключыць гэтыя дадатковыя мерапрыемствы ў каляндар каманды. Тым не менш, канчатковым вынікам павінна стаць каманда, якая будзе мець зносіны больш адкрыта, і карыстальнікі, якія лепш разумеюць, што іх інструменты на аснове штучнага інтэлекту робяць ад іх імя (і чаму). Гэты інтэграваны падыход з'яўляецца краевугольным каменем распрацоўкі сапраўды надзейнага вопыту штучнага інтэлекту. Давер - гэта выбар дызайну Мы часта разглядаем давер як эмацыйны пабочны прадукт добрага карыстацкага досведу. Лягчэй разглядаць давер як механічны вынік прадказальнай камунікацыі. Мы будуем давер, паказваючы патрэбную інфармацыю ў патрэбны час. Мы знішчаем яго, перагружаючы карыстальніка або цалкам хаваючы абсталяванне. Пачніце з аўдыту вузла прыняцця рашэнняў, асабліва для агентскіх інструментаў і прадуктаў штучнага інтэлекту. Знайдзіце моманты, калі сістэма прымае рашэнне. Адлюструйце гэтыя моманты да матрыцы рызык. Калі стаўкі высокія, адкрыйце скрыню. Паказаць работу. У наступным артыкуле мы разгледзім, як распрацаваць гэтыя моманты: як напісаць копію, структураваць карыстальніцкі інтэрфейс і апрацоўваць непазбежныя памылкі, калі агент памыляецца. Дадатак: кантрольны спіс аўдыту вузла прыняцця рашэнняў Этап 1: Наладка і адлюстраванне ✅ Збярыце каманду: прыцягніце ўладальнікаў прадуктаў, бізнес-аналітыкаў, дызайнераў,ключавыя асобы, якія прымаюць рашэнні, і інжынеры, якія стварылі штучны інтэлект. Падказка: вам патрэбны інжынеры, каб растлумачыць фактычную бэкэнд-логіку. Не рабіце гэты крок у адзіночку. ✅ Намалюйце ўвесь працэс: задакументуйце кожны крок, які робіць ІІ, ад першага дзеяння карыстальніка да канчатковага выніку. Падказка: занятак на фізічнай дошцы часта лепш за ўсё падыходзіць для распрацоўкі гэтых пачатковых крокаў. Фаза 2: Пошук схаванай логікі ✅ Знайдзіце незразумелыя месцы: паглядзіце на карту працэсу, каб знайсці любое месца, дзе штучны інтэлект параўноўвае варыянты або ўводы, якія не маюць ідэальнага супадзення. ✅ Вызначце лепшыя крокі здагадкі: для кожнага незразумелага месца праверце, ці выкарыстоўвае сістэма ацэнку даверу. Напрыклад, спытайце, ці ўпэўненая сістэма на 85 працэнтаў. Гэта кропкі, дзе ІІ робіць канчатковы выбар. ✅ Праверце выбар: для кожнага пункта выбару высветліце канкрэтную ўнутраную матэматыку або параўнанне. Прыкладам можа служыць супастаўленне часткі кантракта з полісам. Яшчэ адзін прыклад - параўнанне выявы разбітай машыны з бібліятэкай фатаграфій пашкоджанай машыны. Этап 3: Стварэнне карыстацкага досведу ✅ Пішыце зразумелыя тлумачэнні: стварайце паведамленні для карыстальніка, якія выразна апісваюць канкрэтныя ўнутраныя дзеянні, якія адбываюцца, калі ІІ робіць выбар. Падказка: грунтуйце свае паведамленні на канкрэтнай рэальнасці. Калі штучны інтэлект замаўляе сустрэчу з кліентам у мясцовым кафэ, скажыце карыстальніку, што сістэма правярае сістэму браніравання кафэ. ✅ Абнавіце экран: змясціце гэтыя новыя зразумелыя тлумачэнні ў карыстацкі інтэрфейс. Заменіце расплывістыя паведамленні, такія як Агляд кантрактаў, вашымі канкрэтнымі тлумачэннямі. ✅ Праверка даверу: пераканайцеся, што новыя экранныя паведамленні даюць карыстальнікам простую прычыну любога часу чакання або выніку. Гэта павінна прымусіць іх адчуваць сябе ўпэўнена і даверліва. Падказка: праверце гэтыя паведамленні з рэальнымі карыстальнікамі, каб пераканацца, што яны разумеюць канкрэтны вынік, які дасягаецца.
