در قسمت اول این مجموعه، تغییر اساسی از هوش مصنوعی مولد به عاملی را ایجاد کردیم. ما بررسی کردیم که چرا این جهش از پیشنهاد به بازیگری نیازمند ابزار روانشناختی و روششناسی جدیدی برای محققان UX، مدیران محصول و رهبران است. ما یک طبقهبندی از رفتارهای عامل، از پیشنهاد تا اقدام مستقل را تعریف کردیم، روشهای تحقیق ضروری را مشخص کردیم، خطرات لجن عامل را تعریف کردیم، و معیارهای پاسخگویی مورد نیاز برای حرکت در این قلمرو جدید را ایجاد کردیم. ما به چیستی و چرایی آن پرداختیم. اکنون، ما از پایه به عملکرد می رویم. این مقاله روشهایی را ارائه میدهد: الگوهای طراحی مشخص، چارچوبهای عملیاتی و شیوههای سازمانی ضروری برای ساختن سیستمهای عاملی که نه تنها قدرتمند، بلکه شفاف، قابل کنترل و شایسته اعتماد کاربر هستند. اگر تحقیق ما ابزار تشخیصی باشد، این الگوها طرح درمان هستند. آنها مکانیسمهای عملی هستند که از طریق آنها میتوانیم حس کنترل قابل لمسی را به کاربران بدهیم، حتی اگر به هوش مصنوعی استقلال بیسابقهای اعطا کنیم. هدف ایجاد تجربهای است که در آن استقلال به عنوان یک امتیاز اعطا شده توسط کاربر احساس میشود، نه حقی که توسط سیستم تصرف شده است. الگوهای اصلی UX برای سیستم های عامل طراحی برای هوش مصنوعی عامل طراحی برای یک رابطه است. این رابطه، مانند هر شراکت موفق، باید بر اساس ارتباطات روشن، درک متقابل، و مرزهای مشخص ساخته شود. برای مدیریت تغییر از پیشنهاد به عمل، از شش الگوی استفاده می کنیم که از چرخه حیات عملکردی یک تعامل عامل پیروی می کند:
Pre-Action (Establishing Intent) Intent Preview و Dial Autonomy اطمینان می دهد که کاربر قبل از هر اتفاقی طرح و مرزهای عامل را مشخص می کند. در عمل (ارائه زمینه) منطق قابل توضیح و سیگنال اعتماد در حین کار نماینده شفافیت را حفظ می کند و «چرا» و «چقدر قطعی» را نشان می دهد. پس از اقدام (ایمنی و بازیابی) Action Audit & Undo و Escalation Pathway یک شبکه ایمنی برای خطاها یا لحظات با ابهام بالا فراهم می کند.
در زیر، هر الگو را به طور مفصل پوشش خواهیم داد، از جمله توصیه هایی برای معیارهای موفقیت. این اهداف معیارهای معرف بر اساس استانداردهای صنعت هستند. آنها را بر اساس ریسک دامنه خاص خود تنظیم کنید. 1. پیشنمایش هدف: روشن کردن چیستی و چگونه این الگو معادل گفت و گوی گفتاری است: "اینجا کاری است که می خواهم انجام دهم. آیا شما با آن مشکلی ندارید؟" این لحظه اساسی کسب رضایت در رابطه کاربر-نماینده است. قبل از اینکه یک عامل اقدام مهمی انجام دهد، کاربر باید درک روشن و واضحی از آنچه در شرف وقوع است داشته باشد. پیشنمایش قصد، یا خلاصه طرح، رضایت آگاهانه را ایجاد میکند. این مکث مکالمه قبل از اقدام است که جعبه سیاهی از فرآیندهای مستقل را به یک طرح شفاف و قابل بررسی تبدیل می کند. پشتوانه روانشناختی ارائه یک طرح قبل از اقدام، بار شناختی را کاهش میدهد و تعجب را از بین میبرد و به کاربران فرصتی میدهد تا تأیید کنند که عامل واقعاً قصد آنها را درک کرده است. پیش نمایش آناتومی یک هدف مؤثر:
وضوح و مختصر پیش نمایش باید بلافاصله قابل هضم باشد. باید اقدامات و نتایج اولیه را به زبانی ساده خلاصه کند و از اصطلاحات فنی اجتناب شود. به عنوان مثال، به جای «اجرای تماس API برای cancel_booking(id: 4A7B)،» باید عبارت «لغو پرواز AA123 به سانفرانسیسکو» را بیان کند. مراحل متوالی برای عملیات چند مرحله ای، پیش نمایش باید مراحل کلیدی را مشخص کند. این منطق عامل را نشان می دهد و به کاربران اجازه می دهد تا مسائل بالقوه را در دنباله پیشنهادی تشخیص دهند. پاک کردن اقدامات کاربر پیش نمایش یک نقطه تصمیم است، نه فقط یک اعلان. باید با مجموعه ای واضح از انتخاب ها همراه باشد. این یک لحظه اصطکاک عمدی است، یک "سرعت دست انداز" در فرآیند طراحی شده برای اطمینان از انتخاب آگاهانه کاربر، به ویژه برای اقدامات غیرقابل برگشت یا با ریسک بالا.
بیایید سناریوی دستیار سفر خود را از قسمت اول این مجموعه دوباره مرور کنیم. ما از این دستیار فعال برای نشان دادن نحوه برخورد یک مامور با لغو پرواز استفاده می کنیم. این نماینده یک پرواز لغو شده را شناسایی کرده و یک برنامه بهبودی را تدوین کرده است. Intent Preview چیزی شبیه به این خواهد بود: طرح پیشنهادی برای اختلال در سفر شما متوجه شدم که پرواز ساعت 10:05 صبح شما لغو شده است. کاری که من قصد انجام آن را دارم این است: لغو پرواز UA456 بازپرداخت و تایید جزئیات لغو را انجام دهید. رزرو مجدد در پرواز DL789 یک صندلی تایید شده در پرواز بدون توقف ساعت 2:30 بعد از ظهر رزرو کنید، زیرا این پرواز بدون توقف بعدی در دسترس است باصندلی تایید شده. به روز رسانی رزرو هتل به ماریوت اطلاع دهید که دیر وارد خواهید شد. برنامه سفر ایمیل به روز شده جزئیات پرواز و هتل جدید را برای شما و دستیارتان جین دو ارسال کنید.
این پیشنمایش مؤثر است زیرا تصویری کامل از لغو تا ارتباط ارائه میکند و سه مسیر متمایز را به جلو ارائه میدهد: رضایت کامل (ادامه), تمایل به اصلاح (طرح ویرایش) یا لغو کامل (آن را خودم مدیریت کنم). این کنترل چند وجهی بستر اعتماد است.
زمانی که این الگو را اولویت بندی کنیم این الگو برای هر اقدامی که برگشت ناپذیر است (مانند حذف داده های کاربر)، شامل تراکنش مالی به هر مقدار، به اشتراک گذاری اطلاعات با افراد یا سیستم های دیگر، یا ایجاد یک تغییر قابل توجه که کاربر به راحتی نمی تواند آن را لغو کند، غیرقابل مذاکره است. خطر حذف بدون این، کاربران در کمین اقدامات عامل احساس می کنند و این ویژگی را برای به دست آوردن مجدد کنترل غیرفعال می کنند. معیارهای موفقیت:
طرحهای نسبت پذیرش بدون ویرایش پذیرفته شدند / کل طرحها نمایش داده شدند. هدف > 85 درصد نادیده گرفتن FrequencyTotal خودم آن را مدیریت کنم کلیکها / کل طرحهای نمایش داده شده. نرخ > 10 درصد باعث بررسی مدل می شود. دقت درصد از شرکتکنندگان در آزمون را به خاطر بیاورید که میتوانند 10 ثانیه پس از پنهان شدن پیشنمایش، مراحل طرح را به درستی فهرست کنند.
اعمال این در دامنه های با ریسک بالا در حالی که برنامههای سفر یک خط پایه قابل ربط هستند، این الگو در محیطهای پیچیده و پرمخاطره که در آن یک خطا بیش از یک ناراحتی برای یک فرد در حال سفر است، ضروری میشود. بسیاری از ما در محیطهایی کار میکنیم که تصمیمهای اشتباه ممکن است منجر به اختلال در سیستم، به خطر انداختن ایمنی بیمار، یا پیامدهای فاجعهبار متعدد دیگری شود که فناوری غیرقابل اعتماد ایجاد میکند. یک DevOps Release Agent را در نظر بگیرید که وظیفه مدیریت زیرساخت ابر را دارد. در این زمینه، Intent Preview به عنوان یک مانع ایمنی در برابر خرابی تصادفی عمل می کند.
در این رابط، اصطلاحات خاص (Drain Traffic، Rollback) جایگزین کلیات می شود و اقدامات باینری و تأثیرگذار هستند. کاربر به جای تایید یک پیشنهاد، یک تغییر عملیاتی عمده را بر اساس منطق عامل اجازه می دهد. 2. شماره گیری خودکار: کالیبره کردن اعتماد با مجوز پیشرو هر رابطه سالمی دارای حد و مرزهایی است. شماره گیری Autonomy نحوه برقراری آن توسط کاربر با نماینده خود است، و تعریف می کند که چه چیزی با کارکرد عامل به تنهایی راحت است. اعتماد یک سوئیچ باینری نیست. این یک طیف است یک کاربر ممکن است به یک نماینده اعتماد کند تا وظایف کم ریسک را به طور مستقل انجام دهد، اما برای تصمیمات با ریسک بالا، تأیید کامل را درخواست کند. شماره گیری خودکار، شکلی از مجوز پیشرونده، به کاربران اجازه می دهد تا سطح دلخواه خود را از استقلال نماینده تعیین کنند و آنها را در تعریف رابطه شرکت کنند. زیربنای روانی اجازه دادن به کاربران برای تنظیم استقلال عامل به آنها یک منبع کنترل می دهد و به آنها اجازه می دهد رفتار سیستم را با تحمل ریسک شخصی خود مطابقت دهند. پیاده سازی این می تواند به عنوان یک تنظیم ساده و واضح در برنامه کاربردی، به طور ایده آل بر اساس هر وظیفه، پیاده سازی شود. با استفاده از طبقه بندی مقاله اول ما، تنظیمات می تواند به صورت زیر باشد:
مشاهده و پیشنهاد میخواهم از فرصتها یا مسائل مطلع شوم، اما نماینده هرگز طرحی را پیشنهاد نمیکند. Plan & ProposeThe agent میتواند برنامههایی ایجاد کند، اما من باید قبل از انجام هر اقدامی، همه آنها را بررسی کنم. با Confirmation عمل کنید برای کارهای آشنا، نماینده می تواند اقدامات را آماده کند، و من یک تایید نهایی رفتن/ممنوع را ارائه می دهم. به طور مستقل عمل کنید برای کارهای از پیش تأیید شده (مانند بحث در مورد هزینه های کمتر از 50 دلار)، نماینده می تواند به طور مستقل عمل کند و پس از این واقعیت به من اطلاع دهد.
به عنوان مثال، یک دستیار ایمیل می تواند یک شماره گیری مستقل برای زمان بندی جلسات در مقابل ارسال ایمیل از طرف کاربر داشته باشد. این ریزه کاری کلیدی است، زیرا منعکس کننده واقعیت ظریف اعتماد کاربر است. چه زمانی باید این الگو را اولویت بندی کرد در سیستم هایی که وظایف از نظر ریسک و ترجیحات شخصی بسیار متفاوت است (مانند ابزارهای مدیریت مالی، پلت فرم های ارتباطی) این مورد را اولویت بندی کنید. برای ورود به سیستم ضروری است، به کاربران اجازه می دهد با استقلال کم شروع کنند و با افزایش اعتماد به نفس آن را افزایش دهند. خطر حذف بدون این، کاربرانی که تنها یک شکست را تجربه می کنند، به جای اینکه به سادگی مجوزهای آن را شماره گیری کنند، عامل را به طور کامل رها می کنند. معیارهای موفقیت:
Trust DensityPercentage تفکیک کاربران در هر تنظیم (مثلاً 20٪ پیشنهاد، 50٪ تأیید، 30٪ خودکار). تنظیم ChurnNumber تغییرات تنظیمات / مجموع کاربران فعال در ماه. ریزش زیاد نشان دهنده اعتماد استنوسانات
3. منطق قابل توضیح: پاسخ به چرا؟ پس از انجام یک اقدام، یک شریک خوب دلیل خود را توضیح می دهد. این الگو، ارتباط باز است که به دنبال یک عمل، پاسخ چرا؟ حتی قبل از اینکه پرسیده شود "من این کار را انجام دادم زیرا شما در گذشته به من گفتید که X را ترجیح می دهید." هنگامی که یک نماینده، به ویژه به صورت مستقل عمل می کند، اغلب این سوال در ذهن کاربر مطرح می شود که چرا این کار را انجام داد؟ الگوی منطقی قابل توضیح به طور فعال به این سوال پاسخ می دهد و توجیه مختصری برای تصمیمات عامل ارائه می دهد. این یک فایل گزارش فنی نیست. در اولین مقاله من از این مجموعه، ما در مورد ترجمه اصول اولیه سیستم به زبان کاربر برای جلوگیری از فریب صحبت کردیم. این الگو کاربرد عملی آن اصل است. این منطق خام را به توضیحی قابل خواندن برای انسان تبدیل می کند که بر اساس ترجیحات و ورودی های قبلی خود کاربر است. پشتوانه روانشناختی هنگامی که اعمال یک عامل قابل توضیح باشد، به جای تصادفی، منطقی به نظر می رسد و به کاربر کمک می کند تا یک مدل ذهنی دقیق از نحوه تفکر عامل ایجاد کند. دلایل موثر:
پایهگذاری شده در Precedent بهترین توضیحات به یک قانون، اولویت یا اقدام قبلی مرتبط است. منطق شرطی پیچیده ساده و DirectAvoid. از ساختار ساده «چون گفتی X، من Y انجام دادم» استفاده کنید.
با بازگشت به مثال سفر، پس از رزرو مجدد پرواز به طور مستقل، کاربر ممکن است این مورد را در فید اعلان خود ببیند: من پرواز لغو شده شما را دوباره رزرو کردم. پرواز جدید: دلتا 789، ساعت 2:30 بعد از ظهر حرکت میکند. چرا این اقدام را انجام دادم: پرواز اصلی شما توسط شرکت هواپیمایی لغو شد. شما رزرو مجدد خودکار برای پروازهای بدون توقف در همان روز را از قبل تأیید کردهاید.[ مشاهده برنامه سفر جدید ] [ واگرد این اقدام
این منطق روشن، قابل دفاع است و این ایده را تقویت می کند که عامل در محدوده هایی که کاربر تعیین کرده است عمل می کند. چه زمانی باید این الگو را اولویت بندی کرد، آن را برای هر اقدام مستقلی که استدلال بلافاصله از زمینه مشخص نیست، به ویژه برای اقداماتی که در پسزمینه اتفاق میافتند یا توسط یک رویداد خارجی تحریک میشوند، اولویت بندی کنید (مانند مثال لغو پرواز). خطر حذف بدون این، کاربران اقدامات مستقل معتبر را به عنوان رفتار تصادفی یا "اشکالات" تفسیر می کنند و از ایجاد یک مدل ذهنی صحیح جلوگیری می کنند. معیارهای موفقیت:
چرا؟ حجم بلیط تعداد بلیط های پشتیبانی با برچسب "رفتار عامل - نامشخص" به ازای هر 1000 کاربر فعال. اعتبار منطقی درصد کاربرانی که در بررسیهای خرد پس از تعامل، توضیح را «مفید» ارزیابی میکنند.
4. سیگنال اعتماد این الگو در مورد خودآگاهی عامل در رابطه است. با برقراری ارتباط با اعتماد به نفس خود، به کاربر کمک می کند تصمیم بگیرد چه زمانی به قضاوت خود اعتماد کند و چه زمانی بررسی دقیق تر را اعمال کند. برای کمک به کاربران برای کالیبره کردن اعتماد خود، نماینده باید اعتماد خود را در برنامه ها و اقدامات خود نشان دهد. این حالت داخلی عامل را خواناتر می کند و به کاربر کمک می کند تصمیم بگیرد که چه زمانی تصمیم را دقیق تر بررسی کند. پشتوانه روانی عدم قطعیت ظاهری به جلوگیری از سوگیری اتوماسیون کمک می کند، و کاربران را تشویق می کند تا برنامه های کم اعتماد را به جای پذیرش کورکورانه آنها بررسی کنند. پیاده سازی:
امتیاز اطمینان یک درصد ساده (به عنوان مثال، اطمینان: 95٪) می تواند یک شاخص سریع و قابل اسکن باشد. Scope Declaration بیانیه واضح حوزه تخصص نماینده (مثلاً محدوده: فقط رزرو سفر) به مدیریت انتظارات کاربر کمک می کند و از درخواست آنها از نماینده برای انجام وظایفی که برای آنها طراحی نشده است جلوگیری می کند. Visual CuesA تیک سبز رنگ می تواند نشان دهنده اطمینان بالا باشد، در حالی که یک علامت سوال زرد می تواند نشان دهنده عدم قطعیت باشد و کاربر را وادار می کند تا با دقت بیشتری بررسی کند.
چه زمانی باید این الگو را اولویت بندی کرد زمانی که عملکرد عامل می تواند به طور قابل توجهی بر اساس کیفیت داده های ورودی یا ابهام کار متفاوت باشد. به ویژه در سیستم های خبره (به عنوان مثال، کمک های پزشکی، دستیاران کد) که در آن انسان باید خروجی هوش مصنوعی را به طور انتقادی ارزیابی کند، ارزشمند است. خطر حذف بدون این، کاربران قربانی سوگیری اتوماسیون می شوند، کورکورانه توهمات کم اعتماد را می پذیرند، یا با نگرانی کار با اعتماد به نفس بالا را دوباره بررسی می کنند. معیارهای موفقیت:
امتیاز کالیبراسیون همبستگی پیرسون بین امتیاز اعتماد مدل و میزان پذیرش کاربر. هدف > 0.8. بررسی دقیق دلتا تفاوت بین میانگین زمان بررسی طرحهای کماعتماد و طرحهای با اعتماد بالا. انتظار می رود مثبت باشد (به عنوان مثال، +12 ثانیه).
5. حسابرسی اقدام و لغو: شبکه ایمنی نهایی اعتماد مستلزم دانستن این است که می توانید از یک اشتباه بازیابی کنید. لغوعملکرد شبکه ایمنی نهایی رابطه است و به کاربر اطمینان می دهد که حتی اگر عامل سوء تفاهم کند، عواقب آن فاجعه بار نیست. قدرتمندترین مکانیسم برای ایجاد اطمینان کاربر، توانایی معکوس کردن آسان عملکرد یک نماینده است. گزارش عملیات حسابرسی مداوم و آسان برای خواندن، با یک دکمه واگرد برجسته برای هر اقدام ممکن، شبکه ایمنی نهایی است. این به طور چشمگیری خطر درک شده اعطای خودمختاری را کاهش می دهد. پشتوانه روانشناختی دانستن اینکه یک اشتباه به راحتی قابل بازگرداندن است، امنیت روانی ایجاد می کند و کاربران را تشویق می کند تا وظایف را بدون ترس از عواقب غیرقابل برگشت محول کنند. بهترین روش های طراحی:
نمای جدول زمانی گزارش زمانی از همه اقدامات آغاز شده توسط عامل بصری ترین قالب است. Clear Status Indicators نشان می دهد که آیا یک اقدام موفقیت آمیز بوده، در حال انجام است یا واگرد شده است. Undos محدود به زمان برای اقداماتی که پس از یک نقطه معین غیرقابل برگشت می شوند (مثلاً رزرو غیرقابل استرداد)، رابط کاربری باید این پنجره زمانی را به وضوح اعلام کند (به عنوان مثال، لغو برای 15 دقیقه در دسترس است). این شفافیت در مورد محدودیتهای سیستم به همان اندازه مهم است که خود قابلیت لغو کردن. صادق بودن در مورد زمانی که یک عمل دائمی می شود باعث ایجاد اعتماد می شود.
چه زمانی این الگو را اولویت بندی کنیم این یک الگوی اساسی است که باید تقریباً در تمام سیستم های عاملی اجرا شود. در هنگام معرفی ویژگی های مستقل یا زمانی که هزینه یک خطا (مالی، اجتماعی، یا مربوط به داده ها) زیاد است، کاملاً غیرقابل مذاکره است. خطر حذف بدون این، یک خطا به طور دائم اعتماد را از بین می برد، زیرا کاربران متوجه می شوند که هیچ شبکه ایمنی ندارند. معیارهای موفقیت:
نرخ بازگشت اقدامات لغو شده / کل اقدامات انجام شده. اگر نرخ بازگشت برای یک کار خاص > 5٪ است، اتوماسیون را برای آن کار غیرفعال کنید. تبدیل شبکه ایمنی درصد کاربرانی که در عرض 7 روز پس از استفاده موفقیتآمیز از «واگرد»، بهصورت خودکار عمل کنند.
6. مسیر تشدید: مدیریت عدم قطعیت با ظرافت یک شریک باهوش می داند که چه زمانی به جای حدس زدن کمک بخواهد. این الگو به عامل اجازه میدهد تا ابهام را با ظرافت و با تشدید به کاربر مدیریت کند و فروتنی را نشان دهد که اعتماد را ایجاد میکند، نه از بین بردن. حتی پیشرفتهترین عامل نیز با موقعیتهایی مواجه میشود که در مورد هدف یا بهترین اقدام کاربر نامشخص است. اینکه چگونه این عدم قطعیت را مدیریت می کند یک لحظه تعیین کننده است. یک عامل خوب طراحی شده حدس نمی زند. تشدید می شود. پشتوانه روانی هنگامی که یک نماینده به جای حدس زدن، محدودیت های خود را تصدیق می کند، با احترام به اختیارات کاربر در موقعیت های مبهم اعتماد ایجاد می کند. الگوهای تشدید شامل:
درخواست توضیح "شما به "سه شنبه آینده" اشاره کردید. منظورتان 30 سپتامبر یا 7 اکتبر است؟" ارائه گزینهها "من سه پرواز پیدا کردم که با معیارهای شما مطابقت دارند. کدام یک به نظر شما بهتر است؟" درخواست مداخله انسانی برای وظایف پرمخاطره یا بسیار مبهم، نماینده باید مسیر روشنی برای حلقه زدن به متخصص انسانی یا عامل پشتیبانی داشته باشد. پیام ممکن است این باشد: "این تراکنش غیرعادی به نظر می رسد، و من در مورد چگونگی ادامه آن مطمئن نیستم. آیا می خواهید این را برای بازبینی یک نماینده انسانی علامت گذاری کنم؟"
چه زمانی باید این الگو را اولویت بندی کرد در دامنه هایی که هدف کاربر می تواند مبهم یا بسیار وابسته به زمینه باشد (به عنوان مثال، تعاملات زبان طبیعی، پرس و جوهای داده پیچیده). هر زمان که عامل با اطلاعات ناقص کار می کند یا چندین مسیر صحیح وجود دارد از این استفاده کنید. خطر حذف بدون این، عامل در نهایت یک حدس مطمئن و فاجعه بار انجام می دهد که کاربر را بیگانه می کند. معیارهای موفقیت:
تشدید فرکانس درخواست های عامل برای کمک / کل وظایف. محدوده سالم: 5-15٪. RateTasks موفقیت در بازیابی پس از تشدید تکمیل شد / افزایش کل. هدف > 90 درصد
الگو بهترین برای ریسک اولیه متریک کلیدی پیش نمایش قصد اقدامات غیرقابل برگشت یا مالی کاربر احساس کمین می کند > 85٪ نرخ پذیرش شماره گیری خودکار وظایف با سطوح ریسک متغیر رها شدن کامل ویژگی تنظیم Churn منطق قابل توضیح کارهای پس زمینه یا مستقل کاربر اشکالات را درک می کند "چرا؟" حجم بلیط سیگنال اعتماد سیستم های خبره یا با ریسک بالا تعصب اتوماسیون دلتای موشکافی حسابرسی اقدام و لغو کلیه سیستم های نمایندگی از دست دادن دائمی اعتماد <5%نرخ بازگشت مسیر تشدید نیت کاربر مبهم حدس های مطمئن و فاجعه آمیز > 90% موفقیت در بازیابی
جدول 1: خلاصه الگوهای Agentic AI UX. به یاد داشته باشید که معیارها را بر اساس ریسک دامنه و نیازهای خاص خود تنظیم کنید. طراحی برای تعمیر و ترمیم این یادگیری نحوه عذرخواهی موثر است. یک عذرخواهی خوب اشتباه را تصدیق می کند، آسیب را برطرف می کند و قول می دهد از آن درس بگیرد. خطاها یک احتمال نیستند. آنها یک امر اجتناب ناپذیر هستند. موفقیت بلندمدت یک سیستم عامل کمتر به توانایی آن برای کامل بودن بستگی دارد و بیشتر به توانایی آن برای بازیابی دلپذیر در صورت شکست بستگی دارد. یک چارچوب قوی برای تعمیر و اصلاح یک ویژگی اصلی است، نه یک فکر بعدی. عذرخواهی همدلانه و اصلاح روشن هنگامی که یک نماینده اشتباه می کند، پیام خطا عذرخواهی است. باید با دقت روانشناختی طراحی شود. این لحظه فرصتی حیاتی برای نشان دادن مسئولیت پذیری است. از منظر طراحی خدمات، اینجا جایی است که شرکتها میتوانند از پارادوکس بازیابی خدمات استفاده کنند: پدیدهای که در آن مشتری که با شکست خدمات مواجه میشود و به دنبال آن یک بازیابی موفق و همدلانه انجام میشود، در واقع میتواند وفادارتر از مشتری باشد که اصلاً شکستی را تجربه نکرده است. یک اشتباه خوب می تواند یک رویداد اعتمادسازی قدرتمندتر از یک سابقه طولانی اجرای بی عیب و نقص باشد. نکته کلیدی این است که خطا را به عنوان یک گسست رابطه تلقی کنیم که باید اصلاح شود. این شامل:
خطا را تصدیق کنید پیام باید به وضوح و به سادگی بیان کند که اشتباهی رخ داده است. مثال: من وجه را به اشتباه منتقل کردم. تصحیح فوری را بیان کنید فوراً اقدام اصلاحی را دنبال کنید. مثال: من این اقدام را معکوس کردم و وجوه به حساب شما برگردانده شد. مسیری برای کمک بیشتر فراهم کنید همیشه یک پیوند واضح به پشتیبانی انسانی ارائه دهید. این امر ناامیدی را کاهش می دهد و نشان می دهد که یک سیستم پاسخگویی فراتر از خود عامل وجود دارد.
یک رابط کاربری تعمیر که به خوبی طراحی شده باشد ممکن است به شکل زیر باشد: ما در انتقال اخیر شما اشتباه کردیم. من عذرخواهی می کنم. من 250 دلار را به حساب اشتباهی منتقل کردم.✔ اقدام اصلاحی: انتقال معکوس شد و 250 دلار شما بازپرداخت شد. [تماس با پشتیبانی]
ساخت موتور حاکمیتی برای نوآوری ایمن الگوهای طراحی که در بالا توضیح داده شد، کنترلهای رو به روی کاربر هستند، اما بدون ساختار پشتیبانی داخلی قوی نمیتوانند به طور موثر عمل کنند. این در مورد ایجاد موانع بوروکراتیک نیست. این در مورد ایجاد یک مزیت استراتژیک است. سازمانی با چارچوب حاکمیتی بالغ میتواند ویژگیهای عامل بلندپروازانهتری را با سرعت و اطمینان بیشتر عرضه کند، زیرا بداند که نردههای محافظ لازم برای کاهش ریسک برند وجود دارد. این موتور حاکمیت ایمنی را از یک چک لیست به یک دارایی رقابتی تبدیل می کند. این موتور باید به عنوان یک نهاد حاکمیتی رسمی، یک شورای اخلاق هوش مصنوعی کارگزار، متشکل از یک اتحاد متقابل عملکردی از UX، محصول، و مهندسی، با پشتیبانی حیاتی از سوی حقوقی، سازگاری، و پشتیبانی عمل کند. در سازمانهای کوچکتر، این نقشهای «شورایی» اغلب به یک سهگانه واحد از سرنخهای محصول، مهندسی و طراحی فرو میروند. چک لیستی برای حکمرانی
حقوقی/انطباق این تیم اولین خط دفاعی است که اطمینان می دهد اقدامات بالقوه نماینده در محدوده های قانونی و قانونی باقی می ماند. آنها به تعریف مناطق ممنوعه سخت برای اقدام خودمختار کمک می کنند. محصول مدیر محصول، مباشر هدف نماینده است. آنها مرزهای عملیاتی آن را از طریق یک خط مشی رسمی خودمختاری تعریف و نظارت می کنند که آنچه را که عامل مجاز به انجام و انجام آن نیست، مستند می کند. آنها مالک ثبت ریسک عامل هستند. UX Research این تیم صدای اعتماد و اضطراب کاربر است. آنها مسئول یک فرآیند تکرارشونده برای اجرای مطالعات کالیبراسیون اعتماد، آزمونهای رفتار نادرست شبیهسازی شده و مصاحبههای کیفی برای درک مدل ذهنی در حال تکامل کاربر از عامل هستند. مهندسی این تیم زیربنای فنی اعتماد را ایجاد می کند. آنها باید سیستم را برای گزارش گیری قوی، عملکرد خنثی کردن یک کلیک و قلاب های مورد نیاز برای ایجاد دلایل واضح و قابل توضیح طراحی کنند. پشتیبانی این تیم ها در خط مقدم شکست هستند. آنها باید برای رسیدگی به حوادث ناشی از خطاهای عامل آموزش دیده و مجهز شوند و باید یک حلقه بازخورد مستقیم به شورای اخلاق برای گزارش الگوهای شکست در دنیای واقعی داشته باشند.
این ساختار حاکمیتی باید الف را حفظ کندمجموعهای از اسناد زنده، از جمله ثبت ریسک عامل که به طور فعال حالتهای شکست احتمالی را شناسایی میکند، گزارشهای حسابرسی اقدام که مرتباً بررسی میشوند، و مستندات خطمشی استقلال رسمی. از کجا شروع کنیم: رویکرد مرحلهای برای رهبران محصول برای مدیران محصول و مدیران اجرایی، یکپارچهسازی هوش مصنوعی عاملی میتواند کاری بسیار مهم به نظر برسد. نکته کلیدی این است که آن را نه به عنوان یک راه اندازی واحد، بلکه به عنوان یک سفر مرحله ای برای ایجاد قابلیت های فنی و اعتماد کاربر به طور موازی مورد بررسی قرار دهیم. این نقشه راه به سازمان شما اجازه می دهد تا یاد بگیرد و سازگار شود و اطمینان حاصل شود که هر مرحله بر پایه ای محکم ساخته شده است. فاز 1: ایمنی پایه (پیشنهاد و پیشنهاد) هدف اولیه ایجاد بستر اعتماد بدون ریسکهای مستقل است. در این مرحله، قدرت عامل به تحلیل و پیشنهاد محدود می شود.
یک پیشنمایش هدف سنگ جامد را پیادهسازی کنید: این مدل تعامل اصلی شما است. در عین حال که کاربر را در کنترل کامل اجرا نگه میدارد، کاربران را با ایدهای که عامل برنامهریزی میکند، راحت کنید. زیرساخت Action Audit & Undo را بسازید: حتی اگر عامل هنوز به طور مستقل عمل نمی کند، داربست فنی را برای ثبت و برگشت بسازید. این سیستم شما را برای آینده آماده میکند و اعتماد کاربر را نسبت به وجود شبکه ایمنی ایجاد میکند.
فاز 2: خودمختاری کالیبره شده (با تایید عمل کنید) هنگامی که کاربران با پیشنهادات نماینده راحت شدند، می توانید شروع به معرفی خودمختاری کم خطر کنید. این مرحله در مورد آموزش به کاربران است که چگونه نماینده فکر می کند و به آنها اجازه می دهد سرعت خود را تنظیم کنند.
شماره گیری خودکار را با تنظیمات محدود معرفی کنید: با اجازه دادن به کاربران برای اعطای قدرت عمل با تأیید به نماینده شروع کنید. Deploy the Explainable Rationale: برای هر اقدامی که نماینده آماده می کند، توضیح واضحی ارائه دهید. این امر منطق عامل را ابهام می کند و این را تقویت می کند که بر اساس ترجیحات خود کاربر عمل می کند.
مرحله 3: تفویض اختیار فعال (عملیات مستقل) این مرحله نهایی است که تنها پس از دریافت داده های واضح از مراحل قبلی که نشان می دهد کاربران به سیستم اعتماد دارند، برداشته می شود.
فعال کردن Act Autonomously برای وظایف خاص و از پیش تأیید شده: از دادههای فاز 2 (مثلاً نرخهای بالا، نرخهای واگرد پایین) استفاده کنید تا اولین مجموعه از وظایف کمخطر را که میتوانند کاملاً خودکار شوند، شناسایی کنید. نظارت و تکرار: راهاندازی ویژگیهای مستقل پایان نیست، بلکه آغاز یک چرخه مداوم نظارت بر عملکرد، جمعآوری بازخورد کاربر، و اصلاح محدوده و رفتار عامل بر اساس دادههای دنیای واقعی است.
طراحی به عنوان اهرم ایمنی نهایی ظهور هوش مصنوعی عامل مرز جدیدی در تعامل انسان و کامپیوتر است. این نوید آینده ای را می دهد که در آن فناوری می تواند به طور فعال بارهای ما را کاهش دهد و زندگی ما را ساده کند. اما این قدرت با مسئولیت عمیق همراه است. استقلال خروجی یک سیستم فنی است، اما قابل اعتماد بودن خروجی یک فرآیند طراحی است. چالش ما این است که اطمینان حاصل کنیم که تجربه کاربر یک قربانی توانایی فنی نیست، بلکه ذینفع اصلی آن است. به عنوان متخصصان UX، مدیران محصول و رهبران، نقش ما این است که به عنوان مباشر این اعتماد عمل کنیم. با پیادهسازی الگوهای طراحی واضح برای کنترل و رضایت، طراحی مسیرهای متفکرانه برای تعمیر و ایجاد چارچوبهای حاکمیتی قوی، اهرمهای ایمنی ضروری را ایجاد میکنیم که هوش مصنوعی عامل را قابل دوام میکند. ما فقط رابط طراحی نمی کنیم. ما در حال معماری روابط هستیم. آینده کاربرد و پذیرش هوش مصنوعی به توانایی ما در طراحی این سیستم های پیچیده با خرد، آینده نگری و احترام عمیق به قدرت نهایی کاربر بستگی دارد.
