تصور کنید یک دستیار هوشمند با اطمینان کامل، پاسخی را به شما می‌دهد که هرگز نباید داده می‌شد؛ این وضعیت بسیار خطرناک‌تر از یک اشتباه ساده است. در سامانه‌های تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — هدف اصلی این نیست که مدل «بتواند» پاسخی تولید کند، بلکه این است که برنامه شواهد کافی برای اجازه دادن به این پاسخ را داشته باشد.
تلهٔ انگیزشی
بسیاری از تیم‌های توسعه برای اینکه دموهای خود را موفق جلوه دهند، نرخ پاسخ‌دهی را بهینه می‌کنند. آن‌ها اولویت را بر کاهش پاسخ‌های خالی، کم کردن سؤالات شفاف‌ساز و بالا بردن نرخ حل مسئله قرار می‌دهند. این رویکرد یک انگیزه خطرناک ایجاد می‌کند: جایی که کمبود شواهد، به‌طور نامحسوس به زبانی با اعتمادبه‌نفس بالا تبدیل می‌شود.
به نقل از گزارش‌های صنعتی در ۱۷ اوت ۲۰۲۶، گرایشی جدید شکل گرفته تا عبارت «نمی‌دانم» نه به عنوان شکست مدل، بلکه به عنوان قابل‌اعتمادترین رفتار محصول برای پرس‌وجوهای حساس تلقی شود. این موضوع به‌ویژه زمانی حیاتی است که کاربران درباره تصمیمات پزشکی، استثنائات امنیتی یا تغییرات در محیط عملیاتی (Production) سؤال می‌پرسند.
فراتر از اطمینان در بازیابی
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به خروجی مدل بدون لایه‌های کنترلی ریسک بالایی دارد. طبق گزارش dev.to، امتیاز بالای بازیابی تنها ثابت می‌کند که یک سند از نظر ظاهری به پرس‌وجو شبیه است، اما ثابت نمی‌کند که پاسخ ایمن است. مدل به‌طور ذاتی نمی‌داند که آیا یک سند به‌روز، معتبر یا کامل است، مگر اینکه برنامه این بررسی‌ها را صریح کند.
برای جلوگیری از توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یک برنامه کاربردی باید پنج معیار را ارزیابی کند. در همین راستا، برخی شرکت‌ها با پیاده‌سازی چارچوب‌های سخت‌گیرانه توانسته‌اند این خطاها را به حداقل برسانند؛ برای مثال RevoplyAI با اعمال محدودیت‌های شدید در لایه RAG توانست توهمات چت‌بات‌های خود را حذف کند.
- اعتبار منبع: بررسی اینکه آیا سند یک سیاست تأییدشده است یا صرفاً یک یادداشت قدیمی.
- تازگی منبع: اطمینان از اینکه اطلاعات برای نسخه فعلی محصول، قرارداد یا قیمت‌ها معتبر است.
- پوشش ادعا: بررسی اینکه آیا متن بازیابی‌شده کل پاسخ را پشتیبانی می‌کند یا فقط یک جمله از آن را.
- توافق منابع: شناسایی اینکه آیا اسناد موجود با هم هم‌سو هستند یا تضاد دارند.
- ریسک اقدام: تشخیص اینکه آیا پاسخ صرفاً اطلاع‌رسانی است یا می‌تواند منجر به اقدامات حساس مثل استرداد وجه یا تغییر دسترسی‌ها شود.
مهندسی «عدم پاسخ»
پیاده‌سازی یک «عدم پاسخِ ایمن» نیازمند یک گردش‌کار ساختاریافته است، نه یک عذرخواهی مبهم. یک سیستم قدرتمند باید از منطقی برای ارزیابی منابع استفاده کند و پیش از تولید متن، به‌روز بودن و اعتبار آن‌ها را بسنجد.
به عنوان مثال، سیستم باید بتواند هنگام امتناع از پاسخ، کدهای دلیل (Reason Codes) مشخصی را فعال کند:
no_relevant_source(عدم وجود منبع مرتبط)outdated_source(منبع قدیمی)conflicting_sources(منابع متضاد)insufficient_evidence(شواهد ناکافی)tool_failure(شکست ابزار)approval_required(نیاز به تأیید)
بدون این کدها، تیم‌ها نمی‌توانند تشخیص دهند که آیا کاربران سؤالات بدی می‌پرسند، بازیابی ضعیف است یا مستندات قدیمی شده‌اند.
معیارهای جدید محصول
این رویکرد نحوه اندازه‌گیری موفقیت را تغییر می‌دهد. توسعه‌دهندگان به‌جای تمرکز صرف بر تأخیر (Latency)، مصرف توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک که مدل می‌خورد — و تکمیل وظیفه، باید این موارد را ردیابی کنند:
- پاسخ‌های بدون پشتیبانی و پاسخ‌های فاقد ارجاعات معتبر.
- نرخ ارجاع به انسان و نرخ امتناع در هر گردش‌کار.
- نرخ تضاد در منابع.
- تعداد اصلاحات انسانی پس از پاسخ هوش مصنوعی.
- هزینه واقعی رفع یک پاسخ نادرست.
نرخ پایین امتناع ممکن است در واقع نشانه‌ای از سیستمی باشد که بیش از حد تمایل دارد وقتی باید سکوت کند، حدس بزند.
چالش مدل‌های چندگانه
محیط‌های چندمدلی این موضوع را پیچیده‌تر می‌کنند. مدل‌هایی مثل GPT، Claude، Gemini، DeepSeek، Qwen، Kimi و GLM عدم قطعیت را متفاوت مدیریت می‌کنند؛ برخی به‌طور طبیعی محتاط هستند و برخی دیگر جزئیاتی را که در منبع نیست استنتاج می‌کنند یا برای حفظ روانی متن، عدم قطعیت را حذف می‌کنند.
تیم‌ها باید تست کنند که آیا هر مدل:
- دستورات «فقط بر اساس منبع» را رعایت می‌کند؟
- عدم قطعیت را حفظ کرده و از ادعاهای بدون پشتیبانی امتناع می‌کند؟
- شواهد درست را ارجاع می‌دهد؟
- سؤالات تکمیلی مفیدی می‌پرسد؟
- پس از جایگزینی مدل یا بازگشت به حالت پشتیبان (Fallback)، ایمن رفتار می‌کند؟
در نهایت، بهترین پاسخ اغلب پاسخی است که از ابداع بخش‌های گم‌شده امتناع می‌کند. یک انتقال کنترل‌شده — ارجاع به انسان، درخواست تأیید یا پرسیدن سؤال شفاف‌ساز — بسیار ارزشمندتر از یک پاسخ روان اما ساختگی است.
برای پیاده‌سازی این بررسی‌ها، توسعه‌دهندگان می‌توانند از پلتفرم‌هایی مثل VectorNode برای تست رفتار مدل در گردش‌کارهای واقعی RAG و عامل‌ها با استفاده از مدل‌های پیشرو جهانی و چینی استفاده کنند.
گام بعدی شما
- نرخ «امتناع از پاسخ» (Abstention Rate) را به عنوان یک KPI مثبت در داشبورد مانیتورینگ خود تعریف کنید.
- برای هر مورد عدم پاسخ، یک کد دلیل (Reason Code) اختصاص دهید تا نقاط ضعف مستندات خود را شناس کنید.
- مدل‌های مختلف را با تست‌های «تضاد منبع» به چالش بکشید تا ببینید کدام‌یک در مواجهه با داده‌های متناقض صادقانه‌تر است.
اما مدیریت این عدم قطعیت در لایه سخت‌افزاری و بهینه‌سازی هزینه استنتاج، چالش دیگری است — به تحلیل ما درباره کاهش هزینه‌های GPU مراجعه کنید.
گفتگو