اگر امروز یک سیستم RAG را با تنظیمات پیش‌فرض اجرا می‌کنید، احتمالاً با تأخیری رو به افزایش و نرخ توهم بالا دست‌وپنجه نرم می‌کنید. واقعیت این است که فرمول‌های استاندارد برای محیط‌های آزمایشگاهی عالی هستند، اما در مقیاس تولید، به‌سرعت شکست می‌خورند.
طبق گزارش فنی دقیقی که در ۱۹ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک تیم مهندسی توانست تأخیر (Latency) در سطح p95 را از ۸۵۰ میلی‌ثانیه به ۳۲۰ میلی‌ثانیه کاهش دهد. آن‌ها این موفقیت را با جایگزین کردن استراتژی «جست‌وجوی معنایی و امید به نتیجه» با بهینه‌سازی بیزی (Bayesian Optimization) به دست آوردند و نرخ بازیابی (Recall) را در ۱۰ نتیجه برتر (recall@10) در میان انواع مختلف اسناد به ۹۵٪ رساندند. آن‌ها این نتیجه را با بازسازی لایه بازیابی از اصول اولیه (First Principles) به دست آوردند.
واقعیت‌های تلخ RAG
بسیاری از توسعه‌دهندگان تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را با یک فرمول استاندارد پیاده می‌کنند: تکه‌های ۵۱۲ توکنی، جاسازی (Embedding) با مدل text-embedding-3-small و بازیابی ۵ مورد برتر (top-k=5). اما این رویکرد در محیط واقعی به دلیل حالت‌های شکست (Failure Modes) خاص، شکست می‌خورد:
- قراردادهای حقوقی: تکه‌بندی‌های ۵۱۲ توکنی اغلب باعث می‌شوند بندهای قانونی درست در میانه یک جمله قطع شوند.
- مستندات API: تکه‌های ۱۰۰۰ توکنی اغلب باعث می‌شوند سیگنال‌های اصلی در میان نویز و اطلاعات اضافی غرق شوند.
- تیکت‌های پشتیبانی: بافت گفتگو در تیکت‌ها به جای پنجره‌های ثابت، نیازمند هم‌پوشانی (Overlap) است.
- تجمع تأخیر: یک پشته ساده شامل ۵۰۰ میلی‌ثانیه برای جاسازی، ۲۰۰ میلی‌ثانیه جست‌وجوی برداری و ۳۰۰ میلی‌ثانیه برای LLM، منجر به تأخیری بیش از ۱ ثانیه برای هر پرس‌وجو می‌شود.
تصور کنید سعی دارید سوزنی خاص را در یک انبار کاه پیدا کنید، اما این سوزن به تکه‌های تصادفی خرد شده است.
استراتژی‌های تکه‌بندی: یک اندازه برای همه مناسب نیست
برای حل این مشکل، تیم یک معماری تکه‌بندی منعطف را از طریق یک کلاس پایه انتزاعی به نام ChunkingStrategy پیاده کرد. آن‌ها از پنجره‌های ثابت فاصله گرفتند و استراتژی‌هایی را تعریف کردند که بر اساس نوع سند شخصی‌سازی شده بود:
- قراردادهای حقوقی: استفاده از تکه‌بندی بازگشتی (آگاه از بندها یا Clause-aware) با ۱۰۲۴ توکن و ۱۰۰ توکن هم‌پوشانی برای رسیدن به بازیابی ۹۴٪ در ۱۰ نتیجه برتر.
- مراجع API: به‌کارگیری تکه‌بندی بازگشتی (آگاه از توابع یا Function-aware) با ۷۶۸ توکن و ۵۰ توکن هم‌پوشانی برای دستیابی به بازیابی ۹۶٪ در ۱۰ نتیجه برتر.
- تیکت‌های پشتیبانی: استفاده از تکه‌بندی معنایی (Semantic Chunking) بر اساس شباهت جاسازی با آستانه ۰.۷، ترکیب شده با نوبت‌های گفتگو، با ۵۱۲ توکن و ۷۵ مورد هم‌پوشانی که به بازیابی ۹۱٪ در ۱۰ نتیجه برتر رسید.
- ویکی‌های داخلی: بهره‌گیری از مدل gpt-4o-mini برای تکه‌بندی عامل‌محور (Agentic Chunking) که در آن LLM مرزها را تعیین می‌کند و از ۱۵۰۰ توکن با ۲۰۰ توکن هم‌پوشانی برای رسیدن به بازیابی ۹۷٪ در ۱۰ نتیجه برتر استفاده می‌کند.
بازیابی ترکیبی و قیف بازرتبه‌بندی
بازیابی در این سیستم به یک مدل ترکیبی ارتقا یافت. جست‌وجوی برداری خالص اغلب تطبیق‌های دقیق مانند کدهای خطا یا نام توابع را گم می‌کند، در حالی که BM25 خالص قصد معنایی کاربر را نمی‌فهمد. خط لوله‌ی جدید از یک HybridRetriever با وزن‌های مشخص (در ابتدا ۰.۴ برداری، ۰.۳ BM25 و ۰.۳ بازرتبه‌بندی) استفاده می‌کند.
این سازوکار در سه مرحله عمل می‌کند:
۱. بازیابی موازی: پرس‌وجو هم‌زمان از ذخیره‌ساز برداری و شاخص BM25 برای استخراج k نتیجه برتر (مثلاً k=20).
۲. تلفیق رتبه متقابل (RRF): ترکیب نتایج با استفاده از فرمول 1 / (k + rank + 1) که در آن k=50 است و نیاز به کالیبراسیون امتیازها را حذف می‌کند.
۳. بازرتبه‌بندی با کراس-انکودر: یک قیف نهایی که ۵۰ کاندیدای برتر را به ۵ مورد نهایی کاهش می‌دهد.
چرا از کراس-انکودر استفاده کنیم؟ شباهت در بای-انکودرها (Bi-encoders) تنها حدود ۰.۷۵ هم‌بستگی با مرتبط بودن دارد، در حالی که کراس-انکودرها به ۰.۹۲ می‌رسند. این مرحله ۵۰ میلی‌ثانیه تأخیر اضافه می‌کند اما بازیابی را ۱۵٪ افزایش می‌دهد.
تبدیل پرس‌وجو (Query Transformation)
به نقل از گزارش مذکور، برای مدیریت پرس‌وجوهای مبهم یا بد بیان‌شده، سیستمی به نام QueryTransformer با قدرت gpt-4o-mini طراحی شد. به جای جست‌وجوی رشته خام، سیستم دو اقدام کلیدی انجام می‌دهد:
- گسترش (Expansion): تبدیل یک سؤال کاربر به یک مجموعه پرس‌وجو (
QuerySet) شامل ۳ تا ۵ پرس‌وجوی متنوع (شامل مترادف‌ها، اصطلاحات گسترده‌تر/محدودتر و پاسخ‌های فرضی). این کار بازیابی در ۱۰ نتیجه برتر را از ۷۸٪ (تک پرس‌وجو) به ۹۴٪ (۳ پرس‌وجو) و ۹۶٪ (۵ پرس‌وجو) رساند. در واقع، بهینه‌سازی نحوه پردازش ورودی‌ها می‌تواند تأثیر مستقیمی بر بهره‌وری داشته باشد، مشابه آنچه در روش‌های تشخیص قصد کاربر برای کاهش هزینه توکن‌ها مشاهده شده است. - تجزیه (Decomposition): شکستن سؤالات چند-مرحله‌ای (Multi-hop) به زیر‌سؤال‌های کوچک‌تر که هر کدام نیاز به سنتز جداگانه دارند.
اگرچه این کار تعداد فراخوانی‌های جاسازی را ۳ تا ۵ برابر افزایش می‌دهد، اما این درخواست‌ها برای حفظ سرعت به صورت موازی اجرا می‌شوند.
بهینه‌سازی بیزی از طریق Optuna
مهم‌ترین چرخش راهبردی، تبدیل ابرپارامترها (Hyperparameters) — مانند اندازه تکه (chunk_size)، هم‌پوشانی (overlap)، تعداد نتایج برتر (top_k) و وزن‌ها — به یک مسئله بهینه‌سازی جعبه-سیاه بود. تیم با استفاده از کتابخانه Optuna، یک جست‌وجوی بیزی روی یک «مجموعه داده طلایی» شامل ۲۰۰ پرس‌وجو انجام داد.
آن‌ها از یک TPESampler برای بهینه‌سازی دو هدف هم‌زمان استفاده کردند: حداکثر کردن بازیابی و حداقل کردن تأخیر. این فرآیند بهینه‌سازی یک‌ساعته، یک «جبهه پارتو» (Pareto frontier) ایجاد کرد که اجازه داد بسته به مورد استفاده، یکی از سه پیکربندی زیر را انتخاب کنند:
- محافظه‌کار: بازیابی ۹۱٪ با تأخیر ۱۸۰ میلی‌ثانیه (مناسب برای APIهای با ترافیک بالا).
- متعادل (تولید): بازیابی ۹۵٪ با تأخیر ۳۲۰ میلی‌ثانیه (تنظیم پیش‌فرض).
- تهاجمی: بازیابی ۹۷٪ با تأخیر ۵۸۰ میلی‌ثانیه (برای موارد حساس حقوقی یا پزشکی).
معیارهای تولید و نتایج نهایی
برای حفظ این دستاوردها، تیم یک InstrumentedRetriever با استفاده از Prometheus پیاده کرد تا معیارهای rag_retrieval_latency_seconds و rag_recall_at_k را ردیابی کند. آن‌ها به‌طور خاص ۱٪ از ترافیک را در برابر مجموعه داده طلایی نمونه‌برداری می‌کنند تا بازیابی واقعی را در لحظه نظارت کنند.
نتایج شش ماهه ارتقای این زیرساخت صریح است:
- بازیابی (Recall@10): افزایش از ۷۸٪ به ۹۵٪ (۱۷+ درصد واحد)
- تأخیر p95: کاهش از ۸۵۰ میلی‌ثانیه به ۳۲۰ میلی‌ثانیه (۶۲٪-)
- نرخ توهم: کاهش از ۱۲٪ به ۳٪ (۷۵٪-)
- هزینه هر پرس‌وجو: کاهش از ۰.۰۰۸ دلار به ۰.۰۰۵ دلار (۳۸٪-)
این رویکرد سیستماتیک، لایه بازیابی را به یک زیرساخت نسخه‌بندی شده تبدیل کرد. این گذار ثابت می‌کند که بازیابی یک امر ثانویه نیست، بلکه بخش اصلی زیرساختی است که نیاز به ارزیابی خودکار و مستمر دارد. گام بعدی شما این است که یک «مجموعه داده طلایی» از حیاتی‌ترین پرس‌وجوهای خود بسازید و یک پیمایش بیزی برای یافتن جبهه پارتو خاص خود اجرا کنید.
گام بعدی شما
- یک «مجموعه داده طلایی» (Golden Dataset) شامل حیاتی‌ترین پرس‌وجوهای کاربران خود بسازید.
- از کتابخانه Optuna برای یافتن نقطه تعادل بین تأخیر و دقت در سیستم خود استفاده کنید.
- تکه‌بندی‌های ثابت را کنار گذاشته و برای هر نوع سند، یک استراتژی تکه‌بندی مجزا تعریف کنید.
اما این بهینه‌سازی‌های نرم‌افزاری تنها بخشی از داستان است؛ بررسی اثر سخت‌افزارهای جدید بر هزینه استنتاج در گزارش بعدی ما را دنبال کنید.
گفتگو