کاربر خطرناک‌ترین جواب را تشخیص نمی‌دهد؛ جوابِ غلطِ بااعتمادبه‌نفس را نمی‌بیند. مدل با همان لحن مطمئن همیشه، نام مقاله‌ای را می‌سازد که وجود ندارد، بندی از قرارداد را به‌اشتباه نقل می‌کند یا عددی می‌دهد که هیچ منبعی ندارد. به این پدیده توهم‌زایی می‌گویند و اگر بخواهیم یک مانع اصلی جلوی استفاده‌ی جدی از LLM در کارهای حساس بنامیم، همین است. خبر خوب این است که توهم یک خجالت اخلاقی مدل نیست؛ یک ویژگی شناخته‌شده با دلایل مهندسی‌شده و راه‌های مهندسی‌شده برای کنترل است.
توهم از کجا می‌آید؟
مدل زبانی در اصل ماشین پیش‌بینی توکن بعدی است؛ مأموریتش «ادامه‌ی روان و محتمل متن» است، نه «صادق بودن». چند عامل مشخص توهم می‌سازند: شکاف دانش — مدل چیزی را ندیده یا قدیمی است؛ پیش‌زمینه را در محدودیت‌های دانش مدل خوانده‌اید. فشار قالب پاسخ — آموزش مدل‌ها عمدتاً برای «جواب دادن» است و مدل تمایل دارد حتی در نبود اطلاعات، یک فرم کامل و قابل‌قبول پر کند. زمینه‌ی گمراه‌کننده — اگر در پرامپت جواب را تلویح بدهید، مدل آن را تأیید می‌کند. و ترکیب به‌جای بازیابی — مدل به‌جای یادآوری دقیق، چیزی «به سبک» آموخته‌شده‌ها می‌سازد؛ اسم ساخته‌شده با الگوی اسم‌های واقعی، محتمل است اما درست نیست.
سه لایه‌ی دفاع
لایه‌ی قبل از تولید — زمین دادن به مدل: مهم‌ترین قاعده: پاسخی که باید به واقعیت وابسته باشد را از دانش پارامتری مدل نسازید؛ از اسناد بازیابی‌شده بسازید. این دقیقاً کار RAG است: سند مرتبط را جلوی مدل بگذارید و بخواهید فقط بر اساس آن جواب دهد. کیفیت این لایه به کیفیت بازیابی بسته است — پوششِ خط لوله‌ی RAG پیشرفته را ببینید.
لایه‌ی هنگام تولید — اجازه‌ی «نمی‌دانم»: اگر قرارداد پرامپت «همیشه جواب بده» باشد، مدل هرگز سکوت نمی‌کند. صریح بنویسید: اگر در اسناد پاسخ نیست، بگو پاسخ یافت نشد. خروجی را ساختاریافته بگیرید و فیلد «منبع» و «اطمینان» را در همان قرارداد بگذارید؛ جوابی بدون منبع قابل‌پذیرش نیست.
لایه‌ی بعد از تولید — راستی‌آزمایی: قبل از نمایش به کاربر، پاسخ را چک کنید. سه ابزار رایج: تطبیق با منبع — هر ادعا باید در سند بازیابی‌شده پشتوانه داشته باشد؛ ادعای بدون پشتوانه حذف یا علامت می‌خورد. خودسازگاری — همان پرسش را چند بار با دما بالا بپرسید؛ جواب‌های پراکنده نشانه‌ی عدم قطعیت مدل است. و داور — یک مدل دیگر (یا همان مدل با دستور داوری) جواب و منبع را کنار هم می‌سنجد؛ ارزان‌ترین بازرسی در دسترس است.
اعتماد به خروجی مدل را مثل پرداخت مالی مدیریت کنید: امضا و رسید بخواهید، نه حس خوب.
معیارها: بدون سنجش، بهبود ندارید
دو معیار متفاوت را نباید قاطی کرد. صحت واقعی (Factuality): آیا ادعای پاسخ با واقعیت بیرونی می‌خواند؟ وفاداری به منبع (Faithfulness): آیا پاسخ با همان اسنادی که خودتان به مدل داده‌اید سازگار است؟ سیستم RAG خوب باید در وفاداری تقریباً بی‌نقص باشد؛ اگر وابسته به دانش پارامتری باشد، فقط صحت واقعی مهم می‌شود که سنجشش سخت‌تر است. سنجش عملی یعنی ساخت مجموعه‌ی پرسش‌های دامنه‌ای با جواب شناخته‌شده — شامل پرسش‌های طِبَق‌اصل بدون جواب — و گذاشتن سیستم از روی آن؛ چارچوب کاملش را در ارزیابی سیستم‌های RAG خوانده‌اید.
چالش‌های باز
صادق باشیم: توهم به‌طور کامل «حل» نشده است. مدل هنوز نمی‌فهمد کجا واقعاً نمی‌داند — سنجش اطمینان درونی مدل هنوز مسئله‌ی باز است. تعادل خلاقیت و دقت هم همیشه به نفع دقت نیست: برای تولید محتوا، سخت‌گیری کامل خلاقیت را می‌کشد؛ خط‌کشی وظیفه‌ای لازم است. و راستی‌آزمایی خودش هزینه دارد: داورِ دقیق یعنی درخواست اضافه و تأخیر بیشتر؛ باید بودجه‌ی بازرسی را با بحران‌پذیری وظیفه تنظیم کنید.
جمع‌بندی
توهم‌زایی حذف نمی‌شود؛ مهار می‌شود. نسخه‌ی عملی برای هر محصول: پاسخ‌های حساس را از RAG بگیرید نه از حافظه‌ی مدل، حق «نمی‌دانم» را در قرارداد بگذارید، خروجی ساختاریافته با فیلد منبع بگیرید، و یک لایه‌ی راستی‌آزمایی جلوی کاربر بگذارید. بعد، ماهی یک بار مجموعه‌ی ارزیابی‌تان را رشد دهید و عددها را نگاه کنید. چیدمان درست زمینه و دستورها را در مهندسی زمینه ببینید و برای تست روی پرسش‌های واقعی خودتان، یک حساب بسازید.