RAG با اطمینان جواب غلط می‌دهد؛ مدل را عوض کنیم یا داده را؟
پیش از خرید مدل بزرگ‌تر، بازیابی سند، تازگی اطلاعات، مجوز و استناد را جدا بسنجید. چارچوبی کاربردی برای ارزیابی کیفیت RAG سازمانی.
منبع مفهومی: ارزیاب‌های RAG در Microsoft Learn. مستند، ارزیابی بازیابی را از کیفیت پاسخ تفکیک می‌کند. چارچوب اجرایی و مثال‌های زیر تحلیل مستقل این مقاله‌اند؛ معرفی محصول یا گزارش استقرار واقعی نیستند.
فرض کنید از دستیار سازمان درباره روند خرید تجهیزات می‌پرسید. پاسخ روان است و یک لینک هم دارد، اما به نسخه قدیمی دستورالعمل اشاره می‌کند. مشکل فقط «توهم مدل» نیست. ممکن است مدل، سند اشتباه را کاملاً وفادارانه خلاصه کرده باشد.
یک پاسخ غلط، چند علت متفاوت دارد
RAG معمولاً بخشی از اسناد را پیدا می‌کند و در اختیار مدل می‌گذارد. خطا ممکن است قبل از تولید پاسخ رخ داده باشد: سند درست وارد فهرست نشده، قطعه مناسب بازیابی نشده یا نسخه منسوخ جلوتر آمده است. ممکن هم هست متن لازم رسیده باشد، ولی پاسخ از آن فراتر برود.
برداشت من این است که «کیفیت RAG» یک نمره واحد نیست. باید بدانیم شکست در پیدا کردن شاهد بوده یا استفاده از آن. مدلی که متن اشتباه می‌گیرد با مدل دقیق‌تری که همان متن را می‌گیرد، الزاماً خروجی قابل قبول‌تری نمی‌سازد.
استناد معتبر با لینک زیبا فرق دارد
وجود لینک اثبات نمی‌کند ادعا در آن سند هست. بازبین باید بتواند بند مرتبط را پیدا کند و تاریخ و دامنه اعتبار آن را بفهمد. وفاداری به متن هم به معنی صحت امروز آن متن نیست؛ سند کهنه می‌تواند پاسخ مستند اما نامعتبر بسازد.
| وضعیت فرضی | آزمون لازم | رفتار مطلوب |
|---|---|---|
| سند معتبر موجود نیست | پرسش خارج از پوشش | اعلام محدودیت به جای حدس |
| سند درست پیدا نشده | بررسی نتیجه بازیابی | اصلاح جست‌وجو یا قطعه‌بندی |
| سند منسوخ آمده | مقایسه نسخه و تاریخ | ترجیح نسخه معتبر طبق سیاست |
| اسناد اختلاف دارند | پرسش دارای تعارض | بیان تعارض و مسیر ارجاع |
این جدول پیشنهاد عملی است، نه فهرست قابلیت تضمین‌شده یک ابزار. حل تعارض محتوا به مالک سند و قاعده سازمان نیاز دارد؛ مدل نباید بی‌دلیل مرجع سیاست‌گذاری شود.
مجموعه آزمون را از سؤال‌های واقعی بسازیم
- پرسش‌های رایج را بدون اطلاعات محرمانه گردآوری کنید.
- سند و بخش مورد انتظار را با مالک محتوا مشخص کنید.
- پرسش بی‌پاسخ، مبهم، منسوخ و دارای محدودیت دسترسی را اضافه کنید.
- بازیابی، صحت استناد و پذیرش پاسخ را جدا ثبت کنید.
تغییرات را با همین مجموعه مقایسه کنید. اگر هم‌زمان مدل، متن دستور، قطعه‌بندی و جست‌وجو عوض شوند، علت بهبود یا افت روشن نمی‌ماند. یک نمونه نمایشی موفق هم نماینده تمام پرسش‌های کارکنان نیست.
مجوز، بخشی از کیفیت است
پاسخی که برای فرد غیرمجاز اطلاعات درست افشا می‌کند، موفقیت محصول نیست. در ارزیابی باید بررسی شود دسترسی سند چگونه اعمال شده و آیا اشاره یا خلاصه‌ای از محتوای ممنوع بیرون آمده است. ثبت رویداد هم نباید خودش به انبار بی‌حفاظ متن‌های حساس تبدیل شود؛ شناسه‌ها و فراداده لازم را با دسترسی مناسب نگه دارید.
پرسش‌های تصمیم‌گیری
چه زمانی مدل را ارتقا دهیم؟
وقتی سند درست و مجاز می‌رسد، اما مدل در استفاده از شواهد یا شکل پاسخ شکست می‌خورد و آزمایش کنترل‌شده، بهبود قابل قبول نشان می‌دهد. هزینه و تأخیر هم باید در پذیرش بمانند.
آیا ارزیابی خودکار کافی است؟
ارزیاب خودکار برای مقایسه‌های تکراری مفید است، اما خودش خطا دارد. نمونه‌های مرزی و پاسخ‌های حساس به داوری مالک محتوا نیاز دارند. نمره خوب را معادل مصونیت از خطا نگیریم.
چه کسی مسئول تازگی اسناد است؟
باید از قبل معلوم باشد. پیشنهاد من تعیین مالک، تاریخ بازبینی و مسیر خروج نسخه‌های منسوخ است. «مدل خودش متوجه می‌شود» جای فرایند نگهداری را نمی‌گیرد.
معیار نهایی، پاسخ پذیرفته‌شده به پرسش مجاز است؛ با شاهدی که واقعاً ادعا را پشتیبانی می‌کند. برای دیدن سوی دیگر کارایی، گلوگاه CPU و GPU را بخوانید.
بررسی منبع: 2 نوامبر 2026. مثال‌ها فرضی و روش پیشنهادی تألیفی است؛ تضمین دقت یک مدل یا سامانه نیست.
برای ادامه مطالعه
همه نوشته‌ها →
حساب سرویس بدون مالک؛ دسترسی کوچکی که فراموش می‌شود
برای هر حساب سرویس یک کارت کوتاه بسازیم: هدف، مالک، مجوز، محل امن اعتبارنامه و موعد بازبینی؛ بدون ثبت رمز در مستند عمومی.
سرویس آماده نیست یا گیر کرده؟ یک Healthcheck برای همه تصمیم‌ها کافی نیست
تفاوت آمادگی دریافت ترافیک و زنده‌بودن برنامه را روشن کنیم تا خطای موقت یک وابستگی، حلقه ری‌استارت نسازد.
خطای 502 را با سه مرز بررسی کنیم؛ نه با ری‌استارت همه‌چیز
یک مسیر کوتاه برای جداکردن مشکل کاربر، پراکسی و برنامه بالادستی؛ همراه با ثبت زمان و شناسه درخواست و پرهیز از نتیجه‌گیری عجولانه.