«خطای بازیابی»؛ دلیل اصلی فریب‌دهنده بودن نتایج ارزیابی RAG

داشبورد ارزیابی RAG شما احتمالاً دارد به شما دروغ می‌گوید. بسیاری از توسعه‌دهندگان نوسان امتیازها را به حساب ناپایداری مدل زبانی (LLM) می‌گذارند، اما مقصر اصلی اغلب لایه‌ی بازیابی است که در هر اجرا، داده‌های متفاوتی را به مدل تحویل می‌دهد. من سه بار خط لوله ارزیابی خود را بازسازی کردم تا بالاخره پذیرفتم مشکل هرگز از مدل نبود؛ بلکه بازیابی بود و ارزیابی‌ها به جای کیفیت مدل، نویز بازیابی را اندازه می‌گرفتند.

این مشکل سیستماتیک باعث می‌شود تیم‌ها هفته‌ها وقت خود را روی تنظیم دقیق (Fine-tuning) — که مثل دادن تخصص پوست به یک پزشک عمومی است تا روی یک حوزه دقیق شود — یا ارتقا به مدل‌های بزرگ‌تر تلف کنند. این موضوع با این واقعیت همسو است که بیشتر شکست‌های RAG در عمل ناشی از خطای بازیابی داده‌ها هستند و نه ضعف ذاتی مدل‌های زبانی. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم و بررسی کردیم که چگونه ابزارهایی مثل vLLM و LoRA می‌توانند هزینه‌های استقرار مدل‌هایی نظیر Llama 3.3 70B را به شدت کاهش دهند، تمرکز اکنون از هزینه استنتاج به بدهی فنی پنهان در قابلیت اطمینان ارزیابی‌ها تغییر کرده است. طبق گزارش یک توسعه‌دهنده ارشد، نویز بازیابی می‌تواند تست‌های رگرسیون را در یک کامیت کد یکسان، از سبز به قرمز تغییر دهد. تمام نتیجه‌گیری‌های «مدل در حال بدتر شدن است» طی شش هفته، در واقع نتیجه‌ی بازگشت تکه‌های متفاوت برای یک پرس‌وجوی یکسان در اجراهای مختلف بود.

کالبدشکافی ارزیابی‌های ناپایدار

به نقل از این گزارش، علامت اصلی این مشکل، واریانس در مجموعه‌های ارزیابی «طلایی» است. در یک مورد خاص، توسعه‌دهنده از مجموعه‌ای شامل ۲۰۰ جفت پرسش و پاسخ استفاده کرد که هر کدام به یک شناسه تکه (Chunk ID) درست در یک پیکره متنی مشخص متصل بود. با وجود استفاده از مدل یکسان، پرامپت یکسان، پیکره متنی یکسان و تنظیم دما (Temperature) روی صفر، اعداد در هر بار اجرا تغییر می‌کردند.

در سه اجرای کاملاً یکسان، معیارها به این شکل نوسان داشتند:

• اجرای اول: recall@5 = ۰.۷۸، faithfulness = ۰.۸۴
• اجرای دوم: recall@5 = ۰.۷۱، faithfulness = ۰.۸۱
• اجرای سوم: recall@5 = ۰.۷۴، faithfulness = ۰.۷۹

بررسی‌ها نشان داد مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — تمام تلاشش را می‌کرد تا با هر آنچه به او تحویل داده شده بود بهترین پاسخ را بسازد، اما «دستِ» بازیابی ناپایدار بود. برای پرس‌وجویی مثل «چگونه SSL offloading را در edge gateway پیکربندی کنم؟»، شناسه‌های تکه‌ها بین اجراها تغییر می‌کردند. اجرای اول تکه‌های [a17, b04, c91, d22, e55] را برگرداند؛ اما در اجرای دوم c91 به c92 و e55 به e58 تغییر یافت و در اجرای سوم b04 با b05 جابجا شد. در واقع ارزیابی داشت لایه‌ی بازیابی را می‌سنجید، نه هوش مدل را.

سه منبع نویز در بازیابی

عدم قطعیت در خط لوله تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — از سه مسیر اصلی وارد می‌شود:

• شکستن گره‌های ANN (Tie-Breaking): اکثر شاخص‌های نزدیک‌ترین همسایه تقریبی (ANN) مانند HNSW، IVF و ScaNN، وقتی دو بردار تقریباً در فاصله یکسانی از پرس‌وجو باشند، ترتیب‌های متفاوتی برمی‌گردانند. در حالی که امتیازها تا چهار رقم اعشار یکسان به نظر می‌رسند، ترتیب آن‌ها جابجا می‌شود. اگر top-k=5 شما دقیقاً روی مرز این تساوی باشد، این جابجایی به مدل منتقل می‌شود.
• تلفیق جست‌وجوی ترکیبی (Hybrid Search Fusion): ترکیب BM25 و بازیابی متراکم شامل دو فراخوانی موازی و یک مرحله تلفیق است. این رویکرد ترکیبی معمولاً در مواجهه با داده‌های پیچیده‌ی صنعتی، عملکرد بسیار بهتری نسبت به جست‌وجوی برداری خالص دارد. بسته به اینکه کدام فراخوانی زودتر تمام شود، ترتیب دسته‌بندی (batching order) چگونه باشد یا تغییرات همزمان در شاخص‌ها رخ دهد، وزن‌های تلفیق ممکن است به صورت کسری تغییر کنند. این مقدار ناچیز اغلب برای جابجایی نتایج چهارم و پنجم کافی است.
• تغییر تکه‌بندی (Chunking Drift): این رایج‌ترین منبع نادیده گرفته شده است. اگر خط لوله ورود داده از تصادفی‌سازی استفاده کند — مانند پنجره‌های هم‌پوشان (overlap windows)، چسباندن به مرز جملات (sentence-boundary snapping) یا تکه‌بندهای موازی — هر بار بازخوانی داده‌ها، چشم‌انداز را تغییر می‌دهد. اگر توسعه‌دهنده اندازه تکه (chunk_size) را از ۵۱۲ به ۴۸۰ توکن تغییر دهد، تمام شناسه‌های تکه در مجموعه ارزیابی نامعتبر می‌شوند. در این حالت، ارزیابی عملاً دارد پاسخی را نمره می‌دهد که با تکه‌ای مقایسه می‌کند که دیگر وجود ندارد.

راهکار قطعی برای تثبیت

برای حل این مشکل، گزارش پیشنهاد می‌کند بازیابیِ ارزیابی را از بازیابیِ عملیاتی جدا کنید. در محیط عملیاتی، مقدار کمی تصادفی بودن پذیرفته است چون مدل می‌تواند آن را جبران کند، اما ارزیابی‌ها به محیطی قفل‌شده نیاز دارند. این کار از طریق پیکربندی ثابت شامل یک بذر (Seed)، پارامترهای جست‌وجوی مشخص و نسخه‌بندی انجام می‌شود.

یک تکنیک حیاتی، استفاده از ضریب بیش‌نمونه‌برداری (oversample_factor) است. به جای بازیابی تنها ۵ کاندید، سیستم ۲۰ کاندید (۴ برابر) را بازیابی کرده و سپس از یک بازرتبه‌بندی (Reranker) مدل زبانی با دما=۰ برای انتخاب ۵ مورد نهایی استفاده می‌کند. استخراج ۵ مورد از یک استخر ۲۰ تایی بسیار پایدارتر از نتایج خام ANN است، زیرا بازرتبه‌بند مدل زبانی در دمای صفر تا حد زیادی قطعی (Deterministic) عمل می‌کند.

پیاده‌سازی حفاظ‌ها

برای جلوگیری از شکست خاموش در اثر تغییر تکه‌بندی، نویسنده یک مکانیسم نسخه‌بندی سخت‌گیرانه را توصیه می‌کند. این کار شامل هش کردن پیکربندی تکه‌بندی و محتوای پیکره متنی با استفاده از الگوریتم SHA-256 است:

• هش پیکربندی (Config Hash): ترکیب پارامترهایی مثل seed ،ef_search ،nprobe و oversample_factor در یک رشته منحصربه‌فرد.
• هش پیکره (Corpus Hash): ایجاد یک هش محتواه از فایل‌های منبع پیکره متنی.
• دروازه کنترل (The Gate): اگر هش فعلی با هش ذخیره‌شده در مجموعه ارزیابی مطابقت نداشته باشد، سیستم باید از اجرا خودداری کرده و خطای EvalStaleError صادر کند. این کار کاربر را مجبور می‌کند که یا مجموعه ارزیابی را دوباره برچسب‌گذاری (Re-annotate) کند یا تغییرات تکه‌بند را به حالت قبل برگرداند.

این رویکرد مانع از سناریویی می‌شود که در آن یک درخواست پذیرش کد (PR) برای تغییر پیکربندی تکه‌بند، منجر به یک هفته تلاش بیهوده برای ردیابی یک «رگرسیون ارزیابی» جعلی شود.

نتایج تثبیت‌سازی

پس از اجرای این حفاظ‌ها — یعنی تثبیت ef_search ،بازرتبه‌بندی با بیش‌نمونه‌برداری و دروازه نسخه‌بندی — نتایج ارزیابی در چندین اجرا تا آخرین رقم اعشار یکسان شدند. هر سه اجرا دقیقاً نتایج زیر را برگرداندند: recall@5 = ۰.۷۸ و faithfulness = ۰.۸۴.

این پایداری باعث شد توانایی توسعه‌دهنده برای تکرار و بهبود (Iteration) متحول شود. سه تغییری که قبلاً به عنوان «نویز» رد شده بودند، به عنوان بهبودهای واقعی شناسایی شدند:
۱. تعویض مدل بازرتبه‌بند
۲. تغییر جزئی در اندازه تکه‌ها
۳. تنظیم وزن‌های جست‌وجوی ترکیبی

این اصلاحات در نهایت منجر به ۵ تا ۱۰ درصد بهبود واقعی شدند که پیش از این زیر لایه‌ی نویز بازیابی دفن شده بودند. این تغییر در دیدگاه به این معناست که «مدل» بی‌گناه است تا زمانی که گناه بازیابی ثابت شود. در پشته‌ی RAG، بازیابی اولین لایه‌ای است که شکست می‌خورد اما آخرین لایه‌ای است که متهم می‌شود. مجموعه ارزیابی منبع حقیقت است و اگر این حقیقت بازتولیدپذیر نباشد، هر «بهبودی» که عرضه می‌شود صرفاً شبیه به پرتاب سکه است.

برای کسانی که RAG را در محیط عملیاتی مدیریت می‌کنند، گام فوری بعدی بازرسی خط لوله بازیابی است. این سؤالات مشخص را بپرسید:

• آیا یک پرس‌وجوی یکسان را دو بار اجرا کردم و چک کردم که شناسه‌های تکه (Chunk ID) دقیقاً مطابقت داشته باشند؟
• آیا پارامتر ef_search (یا معادل آن) در هر بار اجرا یکسان است؟
• آیا پیکربندی تکه‌بند از زمان ساخت ارزیابی بدون تغییر مانده است؟
• آیا قبل از بازرتبه‌بندی، بیش‌نمونه‌برداری (Oversampling) می‌کنم یا مدل زبانی مستقیماً نتایج خام top-k از ANN را می‌بیند؟

اگر پاسخ هر یک از این‌ها «نه» یا «نمی‌دانم» است، پس ارزیابی شما کیفیت مدل را اندازه نمی‌گیرد. راه حل این مشکل صد خط پیکربندی است، نه هزار خط تنظیم دقیق (Fine-tuning).

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.