چطور یک جریان اتوماسیون گفتگو طراحی کنیم؟
ربات مفید از انتخاب پلتفرم شروع نمیشود؛ از کاری شروع میشود که کاربر میخواهد انجام دهد. این راهنما یک روش اجرایی برای تعریف مسیر، اتصال سرویسها، مدیریت خطا و آزمون پیش از انتشار ارائه میکند.
۱. یک کار مشخص و مخاطب واقعی انتخاب کنید
عبارتهایی مانند «پشتیبانی را هوشمند کنیم» برای طراحی کافی نیستند. یک کار تکرارشونده را انتخاب کنید: مثلاً پیدا کردن وضعیت یک درخواست یا دریافت اطلاعات اولیه. بنویسید چه کسی گفتگو را آغاز میکند، چه اطلاعاتی لازم است و در پایان چه رخدادی باید اتفاق بیفتد. اگر کاربر نتواند به نتیجهٔ مشخصی برسد، تعداد شاخههای ربات بیشتر هم آن را مفید نمیکند.
۲. مسیر موفق و مسیرهای خروج را روی کاغذ بیاورید
مسیر اصلی را به گامهای کوتاه تقسیم کنید و برای هر پرسش مشخص کنید پاسخ نامعتبر، ناقص یا نامفهوم چه مسیری دارد. امکان شروع دوباره، بازگشت به مرحلهٔ قبل، لغو درخواست و ارتباط با اپراتور را از ابتدا در نظر بگیرید. متنها باید به کاربر بگویند چه چیزی لازم است و بعد از ثبت پاسخ چه میشود.
۳. اتصال API را مثل یک جزء مستقل طراحی کنید
برای هر درخواست بیرونی، مالک داده، مجوز دسترسی، قالب ورودی و خروجی و شرایط خطا را مشخص کنید. پاسخ دیرهنگام یا ناموفق API نباید کاربر را در صفحهای بیپاسخ نگه دارد. زمان انتظار محدود، پیام قابل فهم و مسیر تلاش دوباره یا ارجاع را تعریف کنید. کلیدها و رمزهای دسترسی را در متن پیام، مرورگر یا لاگ عمومی قرار ندهید.
اگر جریان درخواست را دوباره اجرا کند، بررسی کنید عملیات مقصد تکراری نمیشود؛ برای نمونه، ارسال مجدد فرم نباید چند سفارش یا درخواست یکسان ثبت کند. دسترسی و رفتار هر اتصال را با مستندات سرویس مقصد و پیکربندی محیط واقعی بسنجید.
۴. مرز قابلیت هوش مصنوعی را محدود کنید
اگر در یک مرحله از مدل زبانی استفاده میکنید، مشخص کنید مدل به کدام متن مرجع دسترسی دارد و کدام تصمیم را نباید بگیرد. پاسخ نامطمئن یا خارج از موضوع باید به پیام روشن، پرسش تکمیلی یا اپراتور منتهی شود. پاسخهای واقعی و دشوار را نمونهبرداری و بررسی کنید؛ نمایش پاسخ روان به معنی درست بودن آن نیست.
برای دادهٔ حساس، پیش از ارسال به سرویس بیرونی محل پردازش، مجوز، نگهداری و حذف را بررسی کنید. برای توصیه یا تصمیم حساس، کنترل انسانی و مسئولیت نهایی را مبهم نگذارید. اگر استفاده از مدل ارزش قابلاندازهگیری ندارد، قواعد ثابت یا فرم ساده ممکن است مناسبتر باشند.
۵. سناریوهای آزمون را از رفتار واقعی بسازید
فقط مسیر بینقص را آزمایش نکنید. حالتهای زیر را هم پوشش دهید:
- کاربر پاسخ خالی، طولانی یا خارج از قالب میفرستد.
- کاربر گفتگو را نیمهکاره رها میکند یا بعداً برمیگردد.
- سرویس مقصد کند است، خطا میدهد یا پاسخ ناقص برمیگرداند.
- یک رویداد یا فرم دوبار ارسال میشود.
- کاربر درخواست اپراتور دارد یا مسئلهای خارج از دامنه مطرح میکند.
- پاسخ هوش مصنوعی نامطمئن، بیمنبع یا خارج از سیاست است.
۶. پایلوت را محدود و قابل سنجش نگه دارید
ابتدا یک کانال، یک گروه کاربری و یک فرایند را انتخاب کنید. پیش از انتشار، خط پایهٔ فعلی را ثبت کنید؛ سپس تکمیل موفق فرایند، نرخ خروج، تعداد خطاهای اتصال، دفعات ارجاع و بازخورد کاربر را در کنار هزینه و زمان پاسخ مرور کنید. برای هر شاخص تعریف یکسان داشته باشید تا مقایسهٔ قبل و بعد معنیدار باشد. نتیجهٔ پایلوت را به سایر سناریوها تعمیم ندهید مگر اینکه آنها را هم جداگانه بسنجید.
چکلیست پیش از انتشار
- هدف و کاربر اصلی هر مسیر نوشته شده است.
- برای ورودی ناقص، خطای API، خروج و ارجاع مسیر وجود دارد.
- سطح دسترسی و اطلاعاتی که جابهجا میشوند بازبینی شدهاند.
- پاسخهای مدل با نمونههای واقعی آزمایش و موارد نامطمئن محدود شدهاند.
- لاگها برای عیبیابی کافیاند و دادهٔ حساس را بیجهت نگه نمیدارند.
- مالک نگهداری و روش توقف یا بازگردانی تغییر مشخص است.
برای سنجش پروژههای مبتنی بر مدل، چکلیست آمادگی پروژهٔ هوش مصنوعی را هم بخوانید. برای دیدن سایر مطالب به مرکز راهنماهای پرتو هوش مهرآسا برگردید.