اکثر آموزش‌های RAG به مرحله دمو ختم می‌شوند. شما متن را بر اساس تعداد توکن تکه‌بندی می‌کنید، همه چیز را در یک پایگاه داده برداری می‌ریزید و کار را تمام شده می‌پندارید. این روش زمانی جواب می‌دهد که کاربر در یک بخش FAQ تمیز بپرسد: «سیاست مرجوعی چیست؟». اما وقتی کسی نیمه یک قرارداد را کپی می‌کند و درباره بند سوم سوال می‌پرسد، یا زمانی که یک توسعه‌دهنده یک کد خطای مبهم را در جستجوی مستندات شما تایپ می‌کند، این سیستم از هم می‌پاشد.

پنجره‌های توکن ثابت، قراردادهای حقوقی را در میانه‌ی جمله قطع می‌کنند. تکه‌های بزرگ، مراجع API را زیر انبوهی از نویز دفن می‌کنند. بدتر از همه، بازیابی کند باعث می‌شود کاربران پیش از آنکه مدل حتی شروع به تولید پاسخ کند، پرس‌وجوی خود را رها کنند. ما این را به سختی یاد گرفتیم. وقتی لایه بازیابی خود را از «امیدواری» به «اندازه‌گیری» تغییر دادیم، تأخیر را ۴۰ درصد کاهش دادیم و نرخ فراخوانی (recall) را به ۹۵ درصد رساندیم. در اینجا دقیقاً توضیح می‌دهیم که چه چیزی تغییر کرد.

تکه‌بندی هوشمند

فکر کردن به اندازه تکه (chunk size) به عنوان یک عدد جادویی را متوقف کنید. یک پنجره ۵۱۲ توکنی برای یک سند حقوقی که در آن یک بند واحد چندین پاراگراف را در بر می‌گیرد، هیچ منطقی ندارد؛ و به همان اندازه برای مستندات API که در آن امضای یک تابع و توضیحات دو خطی آن باید در کنار هم بمانند، بی‌فایده است. ما به سمت تکه‌بندی آگاه از ساختار (structure-aware

اعداد به وضوح سخن می‌گویند. Recall@10 ما از ۷۸ درصد به ۹۵ درصد افزایش یافت. تأخیر p95 از ۸۵۰ میلی‌ثانیه به ۳۲۰ میلی‌ثانیه کاهش یافت. و از آنجا که مدل بالاخره به جای نویز، بافت (context) مرتبط دریافت می‌کرد، نرخ توهم (hallucination rate) از ۱۲ درصد به ۳ درصد رسید. بازیابی بهتر فقط پاسخ‌ها را سریع‌تر نمی‌کند، بلکه آن‌ها را درست و واقعی می‌کند.

گام‌های بعدی

اگر در حال بازسازی لایه بازیابی (retrieval layer) خود هستید، از اینجا شروع کنید:

  • قطعه‌بندی (Chunking) را بر اساس ساختار سند انجام دهید، نه تعداد توکن. استراتژی تقسیم‌بندی خود را با ساختار داده‌هایتان مطابقت دهید.
  • از بازیابی ترکیبی (hybrid retrieval) استفاده کنید. جستجوی برداری (vector search) و BM25 را با هم ترکیب کنید، آن‌ها را با Reciprocal Rank Fusion ادغام نمایید و پیش از تولید پاسخ، بازرتبه‌بندی (rerank) انجام دهید.
  • پرس‌وجوها (queries) را برای پوشش بهتر گسترش دهید. پیش از اجرای جستجو، آن‌ها را بازنویسی و تجزیه کنید.
  • یک مجموعه داده طلایی (golden dataset) برای آزمایش بسازید. چیزی را که اندازه‌گیری نمی‌کنید، نمی‌توانید بهینه کنید.
  • پارامترها را با ابزارهای خودکار بهینه کنید. جستجوی بیزی (Bayesian search) تنظیمات بهتری نسبت به حدس و گمان شما پیدا خواهد کرد.

بازیابی یک فایل پیکربندی نیست که یک بار تنظیم کنید و فراموشش کنید. بازیابی یک زیرساخت است، و زیرساخت شایسته همان دقت و سخت‌گیریِ کدِ عملیاتی (production code) است: تست‌ها، اندازه‌گیری‌ها و بهینه‌سازی مداوم. اگر این‌گونه با آن برخورد کنید، سیستم RAG شما از یک نسخه نمایشی (demo) فراتر رفته و به یک محصول تبدیل می‌شود.

جامعه یادگیری اختیاری: GyaanSetu AI