سیستم RAG را می‌سازید، چند سؤال امتحانی می‌پرسید، جواب‌ها خوب می‌آیند — و عرضه. چند هفته بعد، کاربرها می‌گویند «جواب نمی‌دهد» و شما هیچ عددی ندارید که بدانید مشکل از کجاست: بازیابی سند غلط را می‌آورد؟ سند درست هست ولی مدل سوءتفاهم می‌کند؟ یا پرسش‌ها خارج از محتوای منابع‌اند؟ بدون ارزیابی منظم، پاسخ به این سؤال‌ها حدس است. در این مطلب روش عملی ارزیابی را می‌بینیم: دو سطح جدا، مجموعه‌ی آزمون درست، معیارهای خواندنی و مسیر بهبود بر اساس نتیجه.

ارزیابی دو سطحی: بازیابی جدا از پاسخ

بنیادی‌ترین اصل ارزیابی RAG این است که دو خطا را قاطی نکنید. سطح بازیابی: آیا تکه‌های درست پیدا شده‌اند؟ این مرحله کاملاً مستقل از مدل است — فقط جست‌وجو را می‌سنجد. سطح پاسخ: با تکه‌های درست، آیا مدل پاسخ درست و مستند داده؟ جدا کردن این دو، عیب‌یابی را از حدس به مهندسی تبدیل می‌کند: اگر بازیابی خوب است و پاسخ بد، مشکل پرامپت یا مدل است؛ اگر بازیابی بد است، هیچ پرامپتی نجات نمی‌دهد — اول جست‌وجو را درست کنید.

«جواب غلط» دو بیماری متفاوت دارد: یا سند درست نیامده (بازیابی) یا آمده اما مدل بدخوانده (تولید). دارو یکی نیست.

ساخت مجموعه‌ی آزمون: مهم‌ترین سرمایه‌ی ارزیابی

برای ارزیابی به «سؤال‌های نمونه با جواب‌های مرجع» نیاز دارید — ۵۰ تا ۲۰۰ مورد برای شروع کافی است اگر متنوع باشند. روش ساخت کارا: از خود اسناد شروع کنید؛ برای هر سندِ مهم، یک یا دو سؤال بنویسید که پاسخ‌شان مشخصاً در همان سند است (جواب مرجع + آدرس تکه‌ی مبنایش را ثبت کنید). سه نوع سؤال را پوشش دهید: مستقیم (واقعیت صریح در سند)، ترکیبی (جواب از دو سند جمع می‌شود) و خارج از دامنه (سؤالی که جوابش در منابع نیست — جواب درست سیستم: «پیدا نکردم»). این نوع سوم را حتماً داشته باشید؛ بیشترِ سیستم‌های RAG دقیقاً همین‌جا شکست می‌خورند: جواب ناموجود را با اطمینان می‌سازند.

نکته‌ی عملی: ساخت این مجموعه خودش با AI سریع می‌شود — از هر سند بخواهید سه سؤال با پاسخ و آدرس بسازد، بعد انسانی بازبینی کند. هوش مصنوعی تولید می‌کند، انسان صاحب کیفیت است.

معیارهای سطح بازیابی

  • Hit Rate / Recall@k: در چند درصد سؤال‌ها، تکه‌ی مبنا میان k نتیجه‌ی اول آمده؟ ساده‌ترین و مهم‌ترین عدد؛ با k=۵ گزارش بگیرید.
  • MRR: میانگین جایگاه نخستین نتیجه‌ی درست — می‌گوید نه فقط «آمده» بلکه «چقدر بالا آمده»؛ چون تکه‌های بالاتر، تأثیر بیشتری بر مدل دارند.
  • نویز: میان k نتیجه، چند تکه‌ی بی‌ربط آمده؟ نویز زیاد، مدل را گیج می‌کند حتی وقتی تکه‌ی درست هم هست.
  • رفتار خارج‌ازدامنه: برای سؤال‌های بی‌جواب، سیستم باید امتیازها را «بد» ببیند و رد کند؛ نرخ تشخیص درست را جدا بسنجید.

ارزیابی سطح پاسخ: مدل داور

چک انسانی صد پاسخ در هر تغییر، عملی نیست؛ راهکار استاندارد، «مدل داور» است: یک مدل قوی، پاسخ سیستم را با سؤال و جواب مرجع مقایسه می‌کند و امتیاز می‌دهد. سه معیار را جدا امتیازدهی کنید: وفاداری — آیا هر ادعای پاسخ در تکه‌های ارائه‌شده هست؟ (سنجش توهم)؛ درستی — آیا با جواب مرجع سازگار است؟؛ مستندسازی — آیا ارجاع‌ها به منبع درست اشاره دارند؟ مدل داور جواب‌های کوتاه ساختاریافته (درست/نادرست + دلیل) می‌دهد و شما فقط نمونه‌های مردود را انسانی بازبینی می‌کنید. چرخه‌ی کامل: هر تغییر در سیستم — تکه‌بندی جدید، مدل جدید، پارامتر بازیابی — یک بار این ارزیابی خودکار را اجرا کنید و اعداد قبل/بعد را مقایسه کنید.

از عدد به اقدام: تفسیر نتیجه

اعداد وقتی ارزش دارند که به اقدام ترجمه شوند. Recall پایین + سؤال‌های مترادفِ ناموفق ← مشکل واژگان؛ بازیابی ترکیبی (کلمه‌ای + برداری) را فعال کنید. Recall پایین روی اسناد طولانی ← تکه‌بندی را بازبینی کنید؛ احتمالاً تکه‌ها معنا را می‌شکنند. Recall خوب اما وفاداری پایین ← پرامپت تولید را سخت‌گیرانه کنید («فقط از متن‌ها؛ خارج از آن حدس نزن») یا مدل قوی‌تر بگذارید. خارج‌ازدامنه‌ها بد جواب می‌دهند ← آستانه‌ی فاصله به بازیابی اضافه کنید و در پرامپت اجازه‌ی صریح «نمی‌دانم» بدهید. هر عدد، یک پیام دارد — ارزیابی بی‌اقدام، فقط گزارش‌سازی است.

جمع‌بندی

ارزیابی RAG یعنی: مجموعه‌ی آزمون متنوع با جواب مرجع، سنجش جداگانه‌ی بازیابی (Recall@k و MRR) و پاسخ (وفاداری و درستی با مدل داور)، و پوشش حتماً سؤال‌های خارج از دامنه. همین چرخه‌ی ساده، سیستم شما را از «به نظر خوب می‌آید» به «عدد دارد» می‌رساند — و عدد، همان چیزی است که گسترش، بودجه و اعتماد سازمان را می‌سازد. اگر سیستم RAG ندارید هنوز، از آموزش ساخت RAG شروع کنید و مجموعه‌ی آزمون را هم‌زمان با کد بسازید — دیر شدنش گران است.