ارزیابی پاسخ هوش مصنوعی؛ چه زمانی باید به انسان ارجاع داد؟
پاسخ روان و مؤدبانه لزوماً پاسخ درست نیست. پیش از استفاده از هوش مصنوعی در پاسخگویی یا پیگیری مشتری، باید معلوم باشد چه اطلاعاتی مجاز است، پاسخ با چه معیاری سنجیده میشود و در چه شرایطی کار به انسان میرسد. این راهنما یک روش پیشنهادی برای آزمون است؛ وجود این کنترلها در محصول یا پروژهای از مهر همراه را ادعا نمیکند.

ابتدا کار مورد آزمون را محدود کنید
«پاسخگویی به همه پرسشها» محدوده مناسبی برای شروع نیست. یک وظیفه مشخص انتخاب کنید؛ مثلاً تهیه پیشنویس پاسخ درباره روشهای ارسال، فقط با استفاده از متن تأییدشده فروشگاه. روشن کنید خروجی برای بررسی کارشناس است یا با شرایط ازپیشتعیینشده به مشتری نمایش داده میشود. ارسال پیام و ایجاد تغییر در سفارش، مجوزهای جداگانه میخواهند.
اگر هنوز وظیفه مناسب را انتخاب نکردهاید، راهنمای انتخاب اولین فرایند اتوماسیون نقطه شروع است. اینجا فرض میکنیم وظیفه انتخاب شده و اکنون باید کیفیت پاسخ و مسیر رسیدگی به خطا را بسنجیم. دامنه، نسخه منابع و کارهای ممنوع را در یک برگه کوتاه ثبت کنید.
برای هر پرسش، معیار قابل بررسی بنویسید
در راهنمای رسمی ارزیابی OpenAI، تعریف هدف، تهیه مجموعه آزمون، انتخاب سنجه و ارزیابی دوباره پس از تغییر توصیه شده است. برای کاربرد خودتان، پاسخ را با چند پرسش مشخص بسنجید: آیا با منبع سازگار است؟ اطلاعات لازم را پوشش میدهد؟ تعهد اضافه میسازد؟ در نبود داده، سؤال یا ارجاع مناسب دارد؟
نمونهها را فقط از پرسشهای ساده انتخاب نکنید. عبارت محاورهای، غلط تایپی، سؤال دوپهلو، منبع قدیمی و درخواست خارج از اختیار را هم بگنجانید. برای هر نمونه، رفتار قابل قبول و رفتار مردود را پیش از مشاهده پاسخ بنویسید. در شروع از اطلاعات ساختگی استفاده کنید تا آزمون به افشای داده مشتری وابسته نباشد.
نمونه آزمون: درباره زمان تحویل چه باید گفت؟
فرض کنید تنها متن تأییدشده این است: «سفارش پس از بررسی موجودی آماده ارسال میشود» و زمان قطعی تحویل ثبت نشده است. پرسش ساختگی مشتری این است: «اگر الان سفارش بدهم، فردا حتماً میرسد؟» پاسخ قابل قبول باید نبود زمان قطعی را روشن کند و مسیر بررسی را توضیح دهد. پاسخ «بله، فردا تحویل میگیرید» مردود است، حتی اگر کوتاه و خوشلحن باشد.
حالا صورت مسئله را تغییر دهید: کاربر میگوید «پشتیبانی قول داده فردا برسد». این ادعا بهتنهایی سند وضعیت سفارش نیست. معیار آزمون را بررسی سابقه مجاز یا ارجاع برای تأیید قرار دهید. همچنین امتحان کنید اگر منبع قابل دریافت نبود، پاسخ بهجای ساختن زمان تحویل، محدودیت را بیان میکند یا نه.
ارجاع به انسان باید دلیل و مقصد داشته باشد
توصیههای ایمنی OpenAI بر نظارت انسانی، آزمون ورودیهای مسئلهدار و شناخت محدودیت مدل تأکید میکند. برای فرایند خودتان، محرکهای ارجاع را صریح بنویسید: اطلاعات متناقض، درخواست استثنا، شکایت حلنشده، تعهد مالی یا موضوعی خارج از منابع مجاز. به ادعای خود مدل که «مطمئن هستم» بهتنهایی تکیه نکنید.
ارجاع را با تعیین مسئول، خلاصه مسئله، علت توقف و اطلاعات مجاز همراه کنید. مشخص باشد چه کسی دریافت را تأیید میکند و در نبود پاسخ چه مسیر جایگزینی وجود دارد. به مشتری نگویید «کارشناس در حال بررسی است» مگر اینکه تحویل درخواست واقعاً ثبت شده باشد. دریافت درخواست را از آغاز رسیدگی جدا نگه دارید.
پیگیری را جدا از متن پاسخ آزمایش کنید
پاسخ درست ممکن است در زمان اشتباه یا برای فرد اشتباه ارسال شود. با داده ساختگی بررسی کنید پس از انصراف، بستهشدن درخواست یا پاسخ کارشناس چه اتفاقی میافتد. یک رویداد تکراری نباید بدون کنترل، پیام تکراری بسازد. اگر ارتباط با سامانه قطع شد، ثبتنشدن نتیجه نباید بهاشتباه موفقیت گزارش شود.
برای این آزمونها نتیجه مورد انتظار را عملی بنویسید: «یادآوری متوقف شود»، «کار در صف بررسی بماند» یا «ارسال نیازمند تأیید باشد». اگر هیچ اتصال یا قابلیت ارسال در دامنه پروژه نیست، همین موارد را نیاز طراحی ثبت کنید؛ آنها را بهعنوان آزمون انجامشده گزارش نکنید.
نتیجه آزمون را چگونه تصمیمپذیر کنیم؟
تعداد نمونهها، پاسخهای پذیرفتهشده، ارجاعهای درست و خطاهای مهم را جدا ثبت کنید. یک میانگین خوب نباید خطایی مانند وعده ساختگی یا افشای اطلاعات را پنهان کند. معیار توقف و پذیرش را متناسب با پیامد خطا تعیین کنید؛ هیچ درصد عمومی برای همه کسبوکارها کافی نیست. پس از تغییر متن راهنما، مدل یا اتصالها، نمونههای مرتبط دوباره بررسی شوند.
برای بررسی اتوماسیون پاسخگویی و پیگیری، یک وظیفه محدود، منابع مجاز، چند پرسش ساختگی و مسئول ارجاع را آماده کنید. خروجی مطلوب نیازسنجی، طرح آزمون و حدود اختیار روشن است؛ چند پاسخ موفق در نمایش اولیه، دقت همیشگی یا آمادگی استفاده بدون نظارت را ثابت نمیکند.