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