یک دستیار جدید RAG (تولید تقویت‌شده با بازیابی) مبتنی بر واتس‌اپ، با الزام به اینکه هر پاسخ توسط یک ارجاع با فرمت JSON پشتیبانی شود، از توهم‌زدگی (hallucinating) دست کشید. زمانی که مدل نمی‌توانست به تکه (chunk) مشخصی اشاره کند، پاسخ «اطلاعات کافی برای پاسخ به این سوال ندارم» را برمی‌گرداند و بدین ترتیب یک دروغگوی با اعتمادبه‌نفس را به یک سیستم قابل اعتماد با پاسخ «نمی‌دانم» تبدیل کرد.

چرا اعتماد در RAG اهمیت دارد

بیشتر آموزش‌های مربوط به RAG بر روی بازیابی (retrieval) تمرکز بیش از حد دارند؛ از انتخاب embeddingها گرفته تا تکه‌تکه کردن اسناد به chunkها و رتبه‌بندی مجدد نتایج. آن‌ها از آنچه پس از یافتن متن مرتبط اتفاق می‌افتد، غافل می‌شوند. وقتی دستیار پاسخی قطعی ارائه می‌دهد که متن بازیابی‌شده در واقع از آن پشتیبانی نمی‌کند، کاربران اعتماد خود را از دست می‌دهند.

شکاف اعتمادبه‌نفس

در یک نمونه اولیه که با PostgreSQL و افزونه pgvector ساخته شده بود، خط لوله بازیابی (retrieval pipeline) ساده بود. چالش واقعی در مرحله تولید (production) ظاهر شد: مدل زبانی حتی زمانی که قطعه بازیابی‌شده فاقد اطلاعات مورد نیاز بود، با اطمینان صحبت می‌کرد. یک نسخه نمایشی (demo) می‌توانست مشکل را پنهان کند، اما کاربران واقعی شکاف بین «با اعتمادبه‌نفس به نظر رسیدن» و «درست بودن» را آشکار کردند.

اعمال اجباری ارجاعات با JSON

نویسنده به جای ترغیب مدل با پرامپت‌هایی مانند «فقط اگر متن مرتبط داری پاسخ بده»، فرمت خروجی را تغییر داد. اکنون سیستم به یک شیء JSON نیاز دارد که در آن هر ادعا شامل ارجاعی به تکه (chunk) دقیقی باشد که از آن پشتیبانی می‌کند. اگر مدل نتواند ارجاعی را پیوست کند، پاسخ رد شده و کاربر پیام واضح «نمی‌دانم» را مشاهده می‌کند.

اعمال این قانون از دستورالعمل‌های زبان طبیعی به اعتبارسنجی طرحواره (schema validation) منتقل شد. مدل همچنان متن تولید می‌کند، اما کدهای اطراف بررسی می‌کنند که JSON قبل از رسیدن به کاربر، با ساختار مورد نیاز مطابقت داشته باشد.

چه چیزی تغییر کرد

  • تکه‌تکه کردن (Chunking) محافظه‌کارانه شد. تکه‌های مبهم یا بیش از حد گسترده اکنون ادعاهایی بدون ارجاع تولید می‌کنند که باعث فعال شدن حالت جایگزین (fallback) «نمی‌دانم» می‌شود.
  • پرامپت سیستم کوچک‌تر شد. پرامپت‌های سنگین و سخت‌گیرانه‌ای که سعی در کنترل رفتار مدل داشتند، با مجموعه‌ای از دستورالعمل‌های کوتاه جایگزین شدند و اجازه دادند که طرحواره (schema) کار اصلی را انجام دهد.
  • شکست‌ها قابل مشاهده هستند. وقتی بازیابی مطالب نامرتبط را برمی‌گرداند، دستیار دیگر خطا را با یک پاسخ با اعتمادبه‌نفس اما اشتباه پنهان نمی‌کند؛ بلکه آشکارا به عدم قطعیت خود اعتراف می‌کند.

نتیجه‌گیری: برای دستیارهای RAG، تضمین اینکه هر ادعا به یک منبع بازیابی‌شده قابل ردیابی باشد، اعتماد کاربر را بسیار قابل‌اعتمادتر از صرفاً بهبود مرحله بازیابی ایجاد می‌کند. توسعه‌دهندگان با تبدیل ارجاعات مفقود شده به یک «نمی‌دانمِ» قابل مشاهده، اجازه می‌دهند سیستم به جای ساختن پاسخ‌های ساختگی، به محدودیت‌های خود اعتراف کند.