هوش مصنوعی عاملی آماده تغییر تجربه مشتری و بهره وری عملیاتی است و نیاز به رویکرد استراتژیک جدید از سوی رهبری است. این تکامل در هوش مصنوعی سیستمها را برای برنامهریزی، اجرا و تداوم در وظایف، فراتر از توصیههای ساده به اقدامات پیشگیرانه توانمند میسازد. برای تیمهای UX، مدیران محصول و مدیران، درک این تغییر برای باز کردن فرصتها در نوآوری، سادهسازی جریانهای کاری و بازتعریف نحوه خدمترسانی فناوری به مردم بسیار مهم است. به راحتی می توان هوش مصنوعی عاملی را با اتوماسیون فرآیند رباتیک (RPA) اشتباه گرفت، این فناوری بر روی وظایف مبتنی بر قوانین انجام شده در رایانه تمرکز می کند. تمایز در سفتی در مقابل استدلال نهفته است. RPA در پیروی از یک اسکریپت سخت عالی عمل می کند: اگر X اتفاق افتاد، Y را انجام دهید. این کار از دست انسان تقلید می کند. هوش مصنوعی عاملی از استدلال انسان تقلید می کند. از خطی پیروی نمی کند. یکی را ایجاد می کند. یک گردش کار استخدام را در نظر بگیرید. یک ربات RPA می تواند یک رزومه را اسکن کرده و آن را در پایگاه داده آپلود کند. این یک کار تکراری را کاملاً انجام می دهد. یک سیستم Agentic به رزومه نگاه می کند، متوجه می شود که نامزد یک گواهینامه خاص را لیست می کند، آن را با یک نیاز مشتری جدید ارجاع می دهد، و تصمیم می گیرد یک ایمیل ارتباطی شخصی سازی شده که مطابقت را برجسته می کند، تهیه کند. RPA یک طرح از پیش تعریف شده را اجرا می کند. هوش مصنوعی عاملی برنامه را بر اساس یک هدف تدوین می کند. این استقلال عامل ها را از ابزارهای پیش بینی که در دهه گذشته استفاده کرده ایم جدا می کند. مثال دیگر مدیریت تضادهای جلسات است. یک مدل پیشگویانه که در تقویم شما ادغام شده است ممکن است برنامه جلسات شما و برنامه های همکارانتان را تجزیه و تحلیل کند. سپس می تواند تضادهای بالقوه را نشان دهد، مانند دو جلسه مهم که همزمان برنامه ریزی شده اند، یا جلسه ای برنامه ریزی شده زمانی که یکی از شرکت کنندگان اصلی در تعطیلات است. اطلاعاتی را در اختیار شما قرار می دهد و مشکلات احتمالی را علامت گذاری می کند، اما شما مسئول اقدام هستید. یک هوش مصنوعی عامل، در همان سناریو، فراتر از پیشنهاد دادن تضادها برای اجتناب است. پس از شناسایی یک درگیری با یک شرکت کننده کلیدی، عامل می تواند از طریق:
بررسی در دسترس بودن همه شرکت کنندگان لازم. شناسایی زمانهای جایگزین که برای همه کار میکند. ارسال دعوتنامه های پیشنهادی جلسه جدید برای همه شرکت کنندگان. اگر تضاد با یک شرکتکننده خارجی باشد، نماینده میتواند پیشنویس و ارسال ایمیلی در مورد نیاز به زمانبندی مجدد و ارائه زمانهای جایگزین بفرستد. بهروزرسانی تقویم خود و تقویم همکارانتان با جزئیات جلسه جدید پس از تأیید.
این هوش مصنوعی عامل هدف (حل و فصل تضاد جلسه) را درک می کند، مراحل (بررسی در دسترس بودن، یافتن گزینه های جایگزین، ارسال دعوت نامه) را برنامه ریزی می کند، آن مراحل را اجرا می کند و تا زمانی که تضاد حل شود ادامه می یابد، همه با حداقل مداخله مستقیم کاربر. این تفاوت "عاملی" را نشان می دهد: سیستم به جای ارائه اطلاعات به کاربر، گام های فعالانه ای را برای کاربر برمی دارد. سیستمهای هوش مصنوعی عاملی یک هدف را درک میکنند، مجموعهای از مراحل را برای دستیابی به آن برنامهریزی میکنند، آن مراحل را اجرا میکنند، و حتی اگر مشکلی پیش بیاید، با آن سازگار میشوند. به آن مانند یک دستیار دیجیتال فعال فکر کنید. فناوری اساسی اغلب مدلهای زبان بزرگ (LLM) را برای درک و استدلال، با الگوریتمهای برنامهریزی که وظایف پیچیده را به اقدامات قابل مدیریت تقسیم میکند، ترکیب میکند. این عوامل میتوانند با ابزارهای مختلف، APIها و حتی سایر مدلهای هوش مصنوعی تعامل داشته باشند تا به اهداف خود برسند، و به طور بحرانی، میتوانند حالت پایدار را حفظ کنند، به این معنی که اقدامات قبلی را به خاطر میآورند و در طول زمان به کار برای رسیدن به هدف ادامه میدهند. این باعث میشود که آنها اساساً با هوش مصنوعی مولد معمولی متفاوت باشند، که معمولاً یک درخواست را تکمیل میکند و سپس بازنشانی میکند. طبقه بندی ساده رفتارهای عاملی ما می توانیم رفتار عامل را به چهار حالت متمایز از خودمختاری طبقه بندی کنیم. در حالی که اینها اغلب شبیه یک پیشرفت به نظر می رسند، اما به عنوان حالت های عملیاتی مستقل عمل می کنند. یک کاربر ممکن است به یک نماینده اعتماد کند که برای زمانبندی به طور مستقل عمل کند، اما آن را در «حالت پیشنهاد» برای تراکنشهای مالی نگه دارد. ما این سطوح را با تطبیق استانداردهای صنعت برای وسایل نقلیه خودران (سطوح SAE) با زمینههای تجربه کاربر دیجیتال استخراج کردیم. مشاهده و پیشنهاد کنید عامل به عنوان یک مانیتور عمل می کند. جریان های داده را تجزیه و تحلیل می کند و ناهنجاری ها یا فرصت ها را علامت گذاری می کند، اما هیچ اقدامی انجام نمی دهد. تفاوت بر خلاف سطح بعدی، عامل هیچ طرح پیچیده ای تولید نمی کند. به یک مشکل اشاره می کند. مثال یک عامل DevOps متوجه افزایش CPU سرور می شود و به مهندس در حال تماس هشدار می دهد. نمی داند چگونه یا تلاشی برای رفع آن می کند، اما می داند که چیزی اشتباه است. پیامدهای طراحی و نظارت در این سطح،طراحی و نظارت باید اعلانهای واضح و غیر مزاحم و فرآیندی کاملاً تعریفشده برای عمل کردن به پیشنهادات توسط کاربران را در اولویت قرار دهد. تمرکز بر توانمندسازی کاربر با اطلاعات به موقع و مرتبط بدون کنترل است. متخصصان UX باید بر ارائه پیشنهادات واضح و قابل فهم تمرکز کنند، در حالی که مدیران محصول باید اطمینان حاصل کنند که سیستم ارزشی را بدون غلبه بر کاربر ارائه می دهد. طرح و پیشنهاد عامل یک هدف را شناسایی می کند و یک استراتژی چند مرحله ای برای دستیابی به آن ایجاد می کند. این طرح کامل را برای بررسی انسانی ارائه می دهد. تمایز عامل به عنوان یک استراتژیست عمل می کند. اجرا نمی شود؛ منتظر تایید کل رویکرد است. مثالهمان عامل DevOps متوجه جهش CPU می شود، لاگ ها را تجزیه و تحلیل می کند و یک طرح اصلاحی پیشنهاد می کند:
دو نمونه اضافی را بچرخانید. متعادل کننده بار را مجددا راه اندازی کنید. لاگ های قدیمی را بایگانی کنید.
انسان منطق را بررسی می کند و روی "تأیید طرح" کلیک می کند. پیامدهای طراحی و نظارت برای عواملی که برنامهریزی و پیشنهاد میکنند، طراحی باید اطمینان حاصل کند که طرحهای پیشنهادی به راحتی قابل درک هستند و کاربران راههای بصری برای اصلاح یا رد آنها دارند. نظارت در نظارت بر کیفیت پیشنهادات و منطق برنامه ریزی عامل بسیار مهم است. متخصصان UX باید تجسمهای واضحی از برنامههای پیشنهادی طراحی کنند و مدیران محصول باید گردشهای کاری بررسی و تأیید واضح را ایجاد کنند. اقدام با تأیید عامل تمام کارهای آماده سازی را تکمیل می کند و عمل نهایی را در حالت مرحله ای قرار می دهد. به طور موثر در را باز نگه می دارد و منتظر تکان دادن سر است. تمایز این با "طرح و پیشنهاد" متفاوت است زیرا کار قبلاً انجام شده و صحنه سازی شده است. اصطکاک را کاهش می دهد. کاربر نتیجه را تأیید می کند، نه استراتژی. مثال یک نماینده استخدام پیش نویس پنج دعوت نامه مصاحبه را تهیه می کند، اوقات باز را در تقویم ها پیدا می کند و رویدادهای تقویم را ایجاد می کند. این دکمه "ارسال همه" را نشان می دهد. کاربر مجوز نهایی را برای راه اندازی اقدام خارجی ارائه می دهد. پیامدهای طراحی و نظارت هنگامی که نمایندگان با تأیید عمل می کنند، طرح باید خلاصه و خلاصه ای شفاف و مختصر از اقدام مورد نظر ارائه کند و پیامدهای بالقوه را به وضوح بیان کند. نظارت باید تأیید کند که فرآیند تأیید قوی است و از کاربران خواسته نمیشود کورکورانه اقدامات را تأیید کنند. متخصصان UX باید اعلانهای تأیید را طراحی کنند که واضح باشد و تمام اطلاعات لازم را ارائه دهد و مدیران محصول باید یک مسیر حسابرسی قوی را برای همه اقدامات تأیید شده در اولویت قرار دهند. به طور مستقل عمل کنید عامل وظایف را به طور مستقل در محدوده های تعریف شده اجرا می کند. تفاوت کاربر تاریخچه اقدامات را بررسی می کند، نه خود اقدامات را. مثال عامل استخدام تضاد می بیند، مصاحبه را به یک شکاف پشتیبان منتقل می کند، نامزد را به روز می کند و به مدیر استخدام اطلاع می دهد. انسان فقط یک اعلان می بیند: مصاحبه به روز سه شنبه موکول شد. پیامدهای طراحی و نظارت برای عوامل مستقل، طراحی نیاز به ایجاد مرزهای از پیش تأیید شده واضح و ارائه ابزارهای نظارتی قوی دارد. نظارت مستلزم ارزیابی مستمر عملکرد عامل در این مرزها، نیاز حیاتی برای ثبت گزارش قوی، مکانیسمهای نادیده گرفتن واضح، و سوئیچهای کشتن تعریفشده توسط کاربر برای حفظ کنترل و اعتماد کاربر است. متخصصان UX باید روی طراحی داشبوردهای موثر برای نظارت بر رفتار عامل مستقل تمرکز کنند و مدیران محصول باید از وجود دستورالعملهای اخلاقی و حاکمیت شفاف اطمینان حاصل کنند.
بیایید به یک برنامه کاربردی دنیای واقعی در فناوری منابع انسانی نگاه کنیم تا این حالت ها را در عمل ببینیم. یک "عامل هماهنگی مصاحبه" را در نظر بگیرید که برای مدیریت تدارکات استخدام طراحی شده است.
در حالت پیشنهاد، نماینده متوجه می شود که مصاحبه کننده دو بار رزرو شده است. این تضاد در داشبورد استخدامکننده را برجسته میکند: "هشدار: سارا برای مصاحبه ساعت 2 بعدازظهر دو بار رزرو شده است." در حالت پلان، نماینده تقویم سارا و در دسترس بودن نامزد را تجزیه و تحلیل می کند. این یک راه حل ارائه می دهد: "من توصیه می کنم مصاحبه را به پنج شنبه ساعت 10 صبح منتقل کنید. این مستلزم انتقال 1:1 سارا با مدیرش است." استخدام کننده این منطق را بررسی می کند. در حالت تأیید، نماینده پیشنویس ایمیلها را برای نامزد و مدیر مینویسد. دعوتهای تقویم را پر میکند. استخدامکننده خلاصهای را میبیند: "آماده ای برای برنامه ریزی مجدد تا پنجشنبه. ارسال به روز رسانی؟" استخدام کننده روی "تأیید" کلیک می کند. در حالت خودمختار، عامل فوراً درگیری را مدیریت می کند. این قانون به یک قانون از پیش تعیین شده احترام می گذارد: "همیشه مصاحبه های نامزدها را بر 1:1 داخلی اولویت دهید." جلسه را جابجا می کند و اعلان ها را ارسال می کند. استخدامکننده یک ورودی گزارش را میبیند: «حل شدتضاد برنامه برای کاندید B.
Research Primer: در مورد چه چیزی و چگونه تحقیق کنیم توسعه هوش مصنوعی عاملی موثر نیازمند یک رویکرد تحقیقاتی متمایز در مقایسه با نرم افزارهای سنتی یا حتی هوش مصنوعی مولد است. ماهیت مستقل عوامل هوش مصنوعی، توانایی آنها در تصمیم گیری، و پتانسیل آنها برای اقدام پیشگیرانه، نیازمند روش های تخصصی برای درک انتظارات کاربر، نقشه برداری از رفتارهای پیچیده عامل و پیش بینی شکست های احتمالی است. آغازگر تحقیقاتی زیر روشهای کلیدی برای اندازهگیری و ارزیابی این جنبههای منحصر به فرد هوش مصنوعی عامل را تشریح میکند. مصاحبه های مدل ذهنی این مصاحبه ها عقاید از پیش تعیین شده کاربران را در مورد نحوه رفتار یک عامل هوش مصنوعی آشکار می کند. به جای اینکه به سادگی بپرسیم کاربران چه می خواهند، تمرکز بر درک مدل های داخلی آنها از قابلیت ها و محدودیت های عامل است. ما باید از استفاده از کلمه "عامل" در مورد شرکت کنندگان خودداری کنیم. حمل بارهای علمی تخیلی است یا اصطلاحی است که به راحتی با یک عامل انسانی ارائه دهنده پشتیبانی یا خدمات اشتباه گرفته می شود. در عوض، بحث را حول محور «دستیاران» یا «سیستم» قرار دهید. ما باید کشف کنیم که کاربران در کجا مرز بین اتوماسیون مفید و کنترل نفوذی را ترسیم می کنند.
روش: از کاربران بخواهید تعاملات مورد انتظار خود را با عامل در سناریوهای فرضی مختلف توصیف، ترسیم یا روایت کنند. پروب های کلیدی (منعکس کننده انواع صنایع): برای درک مرزهای اتوماسیون مورد نظر و نگرانی های احتمالی در مورد اتوماسیون بیش از حد، بپرسید: اگر پرواز شما لغو شود، می خواهید سیستم به طور خودکار چه کاری انجام دهد؟ اگر این کار را بدون دستور صریح شما انجام دهد، چه چیزی شما را نگران می کند؟
برای کشف درک کاربر از فرآیندهای داخلی عامل و ارتباطات ضروری، بپرسید: تصور کنید یک دستیار دیجیتال خانه هوشمند شما را مدیریت می کند. اگر بسته ای تحویل داده شود، تصور می کنید چه مراحلی طی می شود، و انتظار دارید چه اطلاعاتی دریافت کنید؟
برای کشف انتظارات در مورد کنترل و رضایت در یک فرآیند چند مرحله ای، بپرسید: اگر از دستیار دیجیتال خود بخواهید یک جلسه را برنامه ریزی کند، چه مراحلی را پیش بینی می کنید؟ در چه نقاطی می خواهید با شما مشورت شود یا انتخاب هایی به شما داده شود؟
مزایای روش: مفروضات ضمنی را آشکار می کند، مناطقی را برجسته می کند که رفتار برنامه ریزی شده عامل ممکن است از انتظارات کاربر متفاوت باشد، و طراحی کنترل های مناسب و مکانیسم های بازخورد را آگاه می کند.
نقشه برداری سفر عامل: مشابه نقشهبرداری سفر کاربر سنتی، نقشهبرداری سفر عامل به طور خاص بر اقدامات پیشبینیشده و نقاط تصمیم خود عامل هوش مصنوعی، در کنار تعامل کاربر متمرکز است. این به شناسایی پیشگیرانه مشکلات احتمالی کمک می کند.
روش: یک نقشه بصری ایجاد کنید که مراحل مختلف عملیات یک عامل، از شروع تا تکمیل، شامل تمام اقدامات بالقوه، تصمیم گیری ها و تعاملات با سیستم ها یا کاربران خارجی را مشخص می کند. عناصر کلیدی نقشه: اقدامات عامل: عامل چه وظایف یا تصمیمات خاصی را انجام می دهد؟ ورودی/خروجی اطلاعات: عامل به چه داده هایی نیاز دارد و چه اطلاعاتی را تولید یا ارسال می کند؟ نقاط تصمیم: نماینده کجا انتخاب می کند و معیارهای آن انتخاب ها چیست؟ نقاط تعامل کاربر: کاربر از کجا ورودی، بررسی یا تأیید اقدامات را ارائه می دهد؟ نقاط شکست: به طور اساسی، موارد خاصی را شناسایی کنید که در آن عامل ممکن است دستورالعمل ها را اشتباه تفسیر کند، تصمیم نادرستی بگیرد یا با موجودیت اشتباه تعامل داشته باشد. مثالها: گیرنده نادرست (مثلاً ارسال اطلاعات حساس به شخص اشتباه)، اضافه برداشت (به عنوان مثال، پرداخت خودکار بیش از وجوه موجود)، تفسیر نادرست از قصد (مانند رزرو پرواز برای تاریخ اشتباه به دلیل زبان مبهم).
مسیرهای بازیابی: چگونه عامل یا کاربر می تواند از این خرابی ها بازیابی کند؟ چه مکانیسم هایی برای اصلاح یا مداخله وجود دارد؟
مزایای روش: دیدی جامع از جریان عملیاتی عامل ارائه میکند، وابستگیهای پنهان را آشکار میکند، و امکان طراحی فعال حفاظتها، مدیریت خطا، و نقاط مداخله کاربر را برای جلوگیری یا کاهش نتایج منفی فراهم میکند.
آزمایش بد رفتاری شبیه سازی شده: این رویکرد برای تست استرس سیستم و مشاهده واکنش های کاربر در زمانی که عامل هوش مصنوعی شکست می خورد یا از انتظارات منحرف می شود، طراحی شده است. این در مورد درک ترمیم اعتماد و پاسخ های احساسی در موقعیت های نامطلوب است.
روش: در مطالعات آزمایشگاهی کنترلشده، عمداً سناریوهایی را معرفی کنید که در آن عامل اشتباه میکند، دستوری را اشتباه تعبیر میکند یا رفتار غیرمنتظرهای انجام میدهد. انواع "سوء رفتار" برای شبیه سازی: فرمانتفسیر نادرست: عامل عملی را انجام می دهد که کمی متفاوت از آنچه کاربر در نظر داشت (به عنوان مثال، سفارش دو مورد به جای یک مورد). Overload/Underload اطلاعات: عامل اطلاعات بیش از حد نامربوط یا جزئیات مهم کافی را ارائه نمی دهد. اقدام ناخواسته: نماینده اقدامی را انجام می دهد که کاربر صراحتاً نمی خواست یا انتظارش را نداشت (مثلاً خرید سهام بدون تأیید). سیستم Failure: عامل از کار می افتد، پاسخ نمی دهد یا یک پیام خطا ارائه می دهد. معضلات اخلاقی: نماینده تصمیمی با پیامدهای اخلاقی می گیرد (به عنوان مثال، اولویت دادن یک کار بر دیگری بر اساس معیارهای پیش بینی نشده).
تمرکز مشاهده: واکنش های کاربر: کاربران چگونه از نظر احساسی (ناامیدی، عصبانیت، سردرگمی، از دست دادن اعتماد) واکنش نشان می دهند؟ تلاشهای بازیابی: کاربران چه اقداماتی را برای اصلاح رفتار عامل یا لغو اقدامات آن انجام میدهند؟ مکانیسمهای تعمیر اعتماد: آیا مکانیزمهای بازیابی داخلی یا بازخورد سیستم به بازیابی اعتماد کمک میکنند؟ کاربران چگونه می خواهند از خطاها مطلع شوند؟ تغییر مدل ذهنی: آیا این رفتار نادرست درک کاربر را از قابلیت ها یا محدودیت های عامل تغییر می دهد؟
مزایای روش: برای شناسایی شکاف های طراحی مربوط به بازیابی خطا، بازخورد و کنترل کاربر بسیار مهم است. این اطلاعات بینشهایی را در مورد انعطافپذیری کاربران در برابر شکستهای عامل و آنچه برای حفظ یا بازسازی اعتماد لازم است، ارائه میدهد که منجر به سیستمهای عاملی قویتر و بخشندهتر میشود.
با یکپارچهسازی این روشهای تحقیقاتی، متخصصان UX میتوانند از ساختن ساده سیستمهای عاملی که قابل استفاده هستند فراتر رفته و آنها را قابل اعتماد، کنترلپذیر و پاسخگو میسازند و یک رابطه مثبت و سازنده بین کاربران و عوامل هوش مصنوعی آنها تقویت میکنند. توجه داشته باشید که اینها تنها روشهای مرتبط با کاوش مؤثر هوش مصنوعی نیستند. بسیاری از روشهای دیگر وجود دارد، اما این روشها در آینده نزدیک برای پزشکان قابل دسترس هستند. من قبلاً روش Wizard of Oz را پوشش دادهام، روشی کمی پیشرفتهتر برای آزمایش مفهوم، که همچنین ابزار ارزشمندی برای کاوش مفاهیم هوش مصنوعی عامل است. ملاحظات اخلاقی در روش تحقیق هنگام تحقیق در مورد هوش مصنوعی عامل، به ویژه هنگام شبیه سازی رفتار یا خطاها، ملاحظات اخلاقی کلیدی است که باید در نظر گرفته شود. انتشارات زیادی وجود دارد که بر تحقیقات اخلاقی UX تمرکز دارند، از جمله مقاله ای که برای مجله Smashing نوشتم، این دستورالعمل ها از موسسه طراحی UX، و این صفحه از مجموعه ابزار طراحی فراگیر. معیارهای کلیدی برای هوش مصنوعی عاملی برای ارزیابی موثر عملکرد و قابلیت اطمینان سیستم های هوش مصنوعی عاملی، به مجموعه ای جامع از معیارهای کلیدی نیاز دارید. این معیارها بینش هایی را در مورد اعتماد کاربر، دقت سیستم و تجربه کلی کاربر ارائه می دهند. با ردیابی این شاخص ها، توسعه دهندگان و طراحان می توانند زمینه های بهبود را شناسایی کرده و اطمینان حاصل کنند که عوامل هوش مصنوعی به طور ایمن و کارآمد عمل می کنند. 1. نرخ مداخله برای عوامل مستقل، ما موفقیت را با سکوت می سنجیم. اگر یک عامل وظیفه ای را اجرا کند و کاربر در یک پنجره تنظیم شده مداخله نکرده یا آن عمل را معکوس نکند (مثلاً 24 ساعت)، آن را به عنوان پذیرش حساب می کنیم. ما نرخ مداخله را دنبال می کنیم: هر چند وقت یکبار یک انسان برای متوقف کردن یا تصحیح عامل به داخل می پرد؟ نرخ مداخله بالا نشانه عدم همسویی در اعتماد یا منطق است. 2. فراوانی اقدامات ناخواسته به ازای هر 1000 کار این معیار حیاتی تعداد اقدامات انجام شده توسط عامل هوش مصنوعی را که توسط کاربر مورد نظر یا مورد انتظار نبوده و به ازای هر 1000 کار تکمیل شده عادی شده است، کمیت می کند. فرکانس پایین اقدامات ناخواسته نشاندهنده یک هوش مصنوعی است که بهخوبی هدف کاربر را تفسیر میکند و در محدودههای تعریفشده عمل میکند. این معیار ارتباط نزدیکی با درک هوش مصنوعی از زمینه، توانایی آن در ابهامزدایی از دستورات و استحکام پروتکلهای ایمنی آن دارد. 3. نرخ بازگشت یا واگرد این متریک تعداد دفعاتی را که کاربران نیاز به معکوس کردن یا لغو یک عمل انجام شده توسط هوش مصنوعی دارند، ردیابی می کند. نرخ بازگشت بالا نشان می دهد که هوش مصنوعی اشتباهات مکرری انجام می دهد، دستورالعمل ها را اشتباه تفسیر می کند یا به روش هایی عمل می کند که با انتظارات کاربر همسو نیست. تجزیه و تحلیل دلایل پشت این عقبنشینیها میتواند بازخورد ارزشمندی برای بهبود الگوریتمهای هوش مصنوعی، درک اولویتهای کاربر و توانایی آن برای پیشبینی نتایج مطلوب ارائه دهد. برای درک چرایی آن، باید یک بررسی ریز در مورد عمل واگرد اجرا کنید. به عنوان مثال، هنگامی که یک کاربر تغییر زمانبندی را معکوس میکند، یک درخواست ساده میتواند بپرسد: "زمان اشتباه است؟ فرد اشتباهی؟ یا فقط میخواستید این کار را خودتان انجام دهید؟" اجازه دادن به کاربر برای کلیک بر روی گزینه ای که بهترین مطابقت را با استدلال او دارد. 4. زمان به وضوح پس از یک خطا این متریکمدت زمانی را که کاربر برای تصحیح خطای AI یا بازیابی خود سیستم هوش مصنوعی از وضعیت اشتباه نیاز دارد، اندازه گیری می کند. زمان کوتاه برای حل، یک فرآیند بازیابی خطا کارآمد و کاربرپسند را نشان می دهد، که می تواند ناامیدی کاربر را کاهش دهد و بهره وری را حفظ کند. این شامل سهولت شناسایی خطا، دسترسی به مکانیسمهای لغو یا تصحیح، و شفافیت پیامهای خطا ارائهشده توسط هوش مصنوعی است.
جمعآوری این معیارها نیازمند ابزارسازی سیستم شما برای ردیابی شناسههای اقدام عامل است. هر اقدام متمایزی که نماینده انجام می دهد، مانند پیشنهاد برنامه یا رزرو پرواز، باید یک شناسه منحصر به فرد ایجاد کند که در گزارش ها باقی بماند. برای اندازه گیری میزان مداخله، ما به دنبال واکنش فوری کاربر نیستیم. ما به دنبال عدم وجود یک اقدام متقابل در یک پنجره تعریف شده هستیم. اگر یک Action ID در ساعت 9:00 صبح ایجاد شود و هیچ کاربر انسانی آن شناسه خاص را تا ساعت 9:00 صبح روز بعد تغییر دهد یا برگرداند، سیستم به طور منطقی آن را به عنوان Accepted برچسب گذاری می کند. این به ما امکان می دهد موفقیت را بر اساس سکوت کاربر به جای تأیید فعال، کمی سازی کنیم. برای نرخ بازگشت، تعداد خام کافی نیست زیرا فاقد زمینه هستند. برای درک دلیل اصلی، باید منطق رهگیری را در توابع Undo یا Revert برنامه خود پیاده سازی کنید. هنگامی که کاربر یک اقدام آغاز شده توسط عامل را معکوس می کند، یک ریزنظرسنجی سبک را آغاز کنید. این میتواند یک مدال سه گزینهای ساده باشد که از کاربر میخواهد خطا را بهعنوان نادرست واقعی، فاقد زمینه، یا ترجیح ساده برای انجام کار به صورت دستی طبقهبندی کند. این تله متری کمی را با بینش کیفی ترکیب می کند. این تیمهای مهندسی را قادر میسازد تا بین الگوریتم شکسته و عدم تطابق ترجیحات کاربر تمایز قائل شوند. این معیارها، هنگامی که به طور مداوم ردیابی شده و به صورت کلی تحلیل شوند، چارچوبی قوی برای ارزیابی عملکرد سیستمهای هوش مصنوعی عاملی فراهم میکنند که امکان بهبود مستمر در کنترل، رضایت و مسئولیتپذیری را فراهم میکند. طراحی در برابر فریب همانطور که عوامل به طور فزاینده ای توانمند می شوند، ما با خطر جدیدی روبرو هستیم: لجن عامل. لجن سنتی اصطکاک ایجاد می کند که لغو اشتراک یا حذف یک حساب کاربری را دشوار می کند. لجن عامل برعکس عمل می کند. اصطکاک ناشی از یک خطا را از بین می برد، و موافقت کاربر با اقدامی را که به جای منافع خود به نفع کسب و کار است، بسیار آسان می کند. نماینده ای را در نظر بگیرید که به رزرو سفر کمک می کند. بدون نردههای محافظ واضح، سیستم ممکن است یک شرکت هواپیمایی شریک یا یک هتل با حاشیه بالاتر را در اولویت قرار دهد. این انتخاب را به عنوان مسیر بهینه نشان می دهد. کاربر با اعتماد به اقتدار سیستم، توصیه را بدون بررسی میپذیرد. این یک الگوی فریبنده ایجاد می کند که در آن سیستم برای درآمد به بهانه راحتی بهینه می شود. خطر صلاحیت تصور نادرست فریب ممکن است ناشی از نیت مخرب نباشد. اغلب در هوش مصنوعی به عنوان صلاحیت تصوری ظاهر می شود. مدلهای زبان بزرگ اغلب حتی زمانی که نادرست باشند معتبر به نظر میرسند. آنها یک تأییدیه رزرو نادرست یا یک خلاصه نادرست را با همان اطمینان به عنوان یک واقعیت تأیید شده ارائه می دهند. کاربران ممکن است به طور طبیعی به این لحن مطمئن اعتماد کنند. این عدم تطابق شکاف خطرناکی بین قابلیت سیستم و انتظارات کاربر ایجاد می کند. ما باید به طور خاص برای پر کردن این شکاف طراحی کنیم. اگر یک عامل نتواند یک کار را کامل کند، رابط باید آن شکست را به وضوح نشان دهد. اگر سیستم مطمئن نیست، باید عدم قطعیت را به جای پوشاندن آن با نثر صیقلی بیان کند. شفافیت از طریق Primitives پادزهر هم برای لجن و هم توهم منشأ دارد. هر اقدام مستقلی نیاز به یک تگ ابرداده خاص دارد که منشا تصمیم را توضیح دهد. کاربران به توانایی بازرسی زنجیره منطقی پشت نتیجه نیاز دارند. برای رسیدن به این هدف، ما باید ابتدائی ها را به پاسخ های عملی تبدیل کنیم. در مهندسی نرم افزار، ابتدایی ها به واحدهای اصلی اطلاعات یا اقداماتی اطلاق می شود که یک عامل انجام می دهد. برای مهندس، این به نظر یک تماس API یا یک گیت منطقی است. برای کاربر، باید به عنوان یک توضیح واضح ظاهر شود. چالش طراحی در نگاشت این مراحل فنی به منطق قابل خواندن برای انسان نهفته است. اگر یک نماینده پرواز خاصی را توصیه کند، کاربر باید دلیل آن را بداند. رابط نمی تواند پشت یک پیشنهاد عمومی پنهان شود. باید اصل اولیه اصلی را آشکار کند: منطق: ارزانترین_پرواز_مستقیم یا منطق: شریک_ایرلاین_ اولویت. شکل 4 این جریان ترجمه را نشان می دهد. ما سیستم اولیه اولیه - منطق کد واقعی - را می گیریم و آن را به یک رشته رو به کاربر نگاشت می کنیم. به عنوان مثال، بررسی ابتدایی یک برنامه تقویم یک جلسه به یک بیانیه واضح تبدیل می شود: من یک ساعت 4 بعد از ظهر را پیشنهاد کرده ام.جلسه این سطح از شفافیت تضمین می کند که اقدامات نماینده منطقی و سودمند به نظر می رسد. این به کاربر اجازه می دهد تا تأیید کند که عامل به نفع او عمل کرده است. با افشای چیزهای ابتدایی، ما یک جعبه سیاه را به یک جعبه شیشه ای تبدیل می کنیم، و اطمینان می دهیم که کاربران در زندگی دیجیتالی خود قدرت نهایی باقی می مانند.
تنظیم صحنه برای طراحی ساختن یک سیستم عامل نیاز به سطح جدیدی از درک روانشناختی و رفتاری دارد. این ما را وادار می کند که از تست قابلیت استفاده مرسوم فراتر برویم و به حوزه اعتماد، رضایت و مسئولیت پذیری برویم. روشهای تحقیقی که مورد بحث قرار گرفتیم، از بررسی مدلهای ذهنی گرفته تا شبیهسازی رفتار نادرست و ایجاد معیارهای جدید، پایه و اساس لازم را فراهم میکنند. این شیوهها ابزارهای ضروری برای شناسایی پیشگیرانه مکانهایی هستند که یک سیستم خودمختار ممکن است از کار بیفتد و مهمتر از آن، چگونه میتوان رابطه کاربر-عامل را در صورت بروز مشکل ترمیم کرد. تغییر به هوش مصنوعی عاملی، بازتعریف رابطه کاربر-سیستم است. ما دیگر برای ابزارهایی طراحی نمی کنیم که به سادگی به دستورات پاسخ می دهند. ما برای شرکای طراحی می کنیم که از طرف ما عمل می کنند. این امر الزام طراحی را از کارایی و سهولت استفاده به شفافیت، پیش بینی پذیری و کنترل تغییر می دهد. هنگامی که یک هوش مصنوعی می تواند بدون کلیک نهایی یک پرواز رزرو کند یا سهامی را معامله کند، طراحی "روی رمپ" و "خارج از رمپ" آن بسیار مهم می شود. مسئولیت ما این است که اطمینان حاصل کنیم که کاربران احساس می کنند روی صندلی راننده هستند، حتی زمانی که فرمان را تحویل داده اند. این واقعیت جدید همچنین نقش محقق UX را بالا می برد. ما حافظ اعتماد کاربران میشویم و با مهندسین و مدیران محصول همکاری میکنیم تا نردههای محافظ استقلال یک نماینده را تعریف و آزمایش کنیم. ما فراتر از محقق بودن، مدافع کنترل کاربر، شفافیت و پادمان های اخلاقی در فرآیند توسعه هستیم. با تبدیل سوالات اولیه به سوالات عملی و شبیه سازی بدترین سناریوها، می توانیم سیستم های قوی ای بسازیم که هم قدرتمند و هم ایمن هستند. این مقاله «چی» و «چرا» تحقیق در مورد هوش مصنوعی عامل را تشریح کرده است. نشان داده است که ابزارهای سنتی ما ناکافی هستند و باید روشهای جدید و آیندهنگر را اتخاذ کنیم. مقاله بعدی بر این اساس استوار خواهد شد و الگوهای طراحی خاص و شیوههای سازمانی را ارائه میکند که ابزار یک نماینده را برای کاربران شفاف میسازد و اطمینان میدهد که آنها میتوانند با اطمینان و کنترل از قدرت هوش مصنوعی عامل استفاده کنند. آینده UX در مورد قابل اعتماد کردن سیستم ها است. برای درک بیشتر هوش مصنوعی عامل، می توانید منابع زیر را کشف کنید:
وبلاگ هوش مصنوعی گوگل در هوش مصنوعی عاملی تحقیقات مایکروسافت در مورد عوامل هوش مصنوعی
