کدام استراتژی RAG برای مدیریت ۵۰ هزار سند کارآمدتر است؟

اگر امروز یک سامانه تولید بازیابی‌افزا (RAG) روی ۵۰ هزار سند پیاده کرده‌اید و پاسخ‌های اشتباه دریافت می‌کنید، مشکل احتمالاً از مدل زبانی نیست، بلکه سیستم بازیابی شما پاراگراف غلطی را به مدل تحویل می‌دهد. در ۶ اکتبر ۲۰۲۶، یک تحلیل فنی در وب‌سایت dev.to فاش کرد که در این مقیاس از داده، کیفیت بازیابی بسیار حیاتی‌تر از انتخاب نوع پایگاه‌داده برداری است.

بسیاری از توسعه‌دهندگان پیش از اندازه‌گیری نیازهای واقعی، زیرساخت خود را بیش از حد پیچیده می‌کنند. در مقیاس ۵۰ هزار سند — که با فرض ۱۰ تکه برای هر سند، به ۵۰۰ هزار تکه (Chunk) تبدیل می‌شود — شما می‌توانید از جست‌وجوهای دقیق استفاده کنید و کلاً از زیرساخت‌های پیچیده بگذرید. این عدد برای محاسبه حافظه و تأخیر (Latency) بسیار حیاتی است. هدف نهایی این است که تکه درست به پرامپت برسد؛ زیرا هیچ مدلی نمی‌تواند سیستمی را که داده‌های نامرتبط بازیابی می‌کند، نجات دهد. برای مدیریت بهینه این حجم از داده در محیط‌های سازمانی، استفاده از معماری داده‌های دانه‌ریز می‌تواند راهکاری موثر برای جلوگیری از نشت اطلاعات باشد.

کتابدار سخت‌گیر: BM25

الگوریتم BM25 مثل کتابداری است که هرگز کتاب‌ها را نمی‌خواند اما کارت‌های فهرست دقیقی از جایگاه هر کلمه دارد. این تابع رتبه‌بندی که از دهه ۹۰ میلادی می‌آید، بر اساس سه مکانیزم خاص عمل می‌کند:

• تکرار عبارت (Term Frequency): بررسی اینکه کلمات پرس‌وجو هر چند بار در یک تکه متن تکرار شده‌اند.
• معکوس فراوانی سند (Inverse Document Frequency): بررسی اینکه کلمات مورد نظر در کل مجموعه داده چقدر کمیاب هستند (کلمات کمیاب‌تر امتیاز بیشتری می‌گیرند).
• نرمال‌سازی طول (Length Normalization): جلوگیری از اولویت دادن به تکه‌های طولانی و پراکنده که صرفاً به دلیل تعداد کلمات بیشتر، امتیاز می‌گیرند.

برای درک بهتر، این استعاره را در نظر بگیرید: تصور کنید کتابداری دارید که هرگز محتوای کتاب‌ها را نمی‌خواند، اما فهرست‌های دقیقی دارد که کدام کلمه در کدام صفحه است. اگر از او بپرسید «ERR-4012 کجاست؟»، او در چند ثانیه صفحه دقیق را به شما می‌دهد. اما اگر بپرسید «چرا اپلیکیشن من هنگام اجرا کرش می‌کند؟»، او درمانده خواهد شد، مگر اینکه در صفحه دقیقاً کلمات «کرش» و «اجرا» به همین شکل نوشته شده باشند.

به نقل از این تحلیل، BM25 در یافتن عبارات دقیق مثل کدهای خطا (مثلاً ERR-4012)، شناسه‌های محصول، نام توابع، شماره بندهای قانونی و اصطلاحات تخصصی کمیاب بی‌نظیر است. اما وقتی تفاوت واژگانی (Vocabulary Mismatch) رخ دهد، شکست می‌خورد؛ مثلاً اگر کاربر «استرداد وجه» (Refund) را جست‌وجو کند اما در سند عبارت «بازپرداخت» (Reimbursement) آمده باشد، BM25 هیچ ارتباطی بین این دو نمی‌بیند چون معنا را نمی‌فهمد و فقط حضور کاراکترهای خاص را می‌شمارد.

جزئیات پیاده‌سازی BM25

در پیاده‌سازی BM25، توکن‌سازی (Tokenization) — یعنی خرد کردن متن به تکه‌های کوچک — نیمی از مسیر است. یک توکن‌ساز پیش‌فرض که روی علائم نگارشی متن را می‌بُرد، می‌تواند جست‌وجوهای دقیق را بی‌صدا نابود کند. برای مثال، استفاده از یک عبارت منظم (Regex) که نقاط، خط‌تیره‌ها و زیرخط‌ها (Underscores) را داخل توکن حفظ کند، باعث می‌شود «v2.4.1» یا «user_id» یک واحد جست‌وجویی واحد باقی بمانند و به تکه‌های بی‌معنی تبدیل نشوند.

در حالی که کتابخانه‌هایی مثل rank_bm25 برای ساخت نمونه‌های اولیه (Prototype) مناسب هستند، اما آن‌ها هر سند را برای هر پرس‌وجو دوباره امتیازدهی می‌کنند. برای محیط‌های عملیاتی و تولیدی، توصیه می‌شود از سیستم‌هایی با ایندکس معکوس (Inverted Index) استفاده کنید، مانند:

• Elasticsearch
• OpenSearch
• Tantivy
• جست‌وجوی تمام‌متن در Postgres

دوست بصیر: بازیابی متراکم

بازیابی متراکم از مدل‌های عصبی مثل BAAI/bge-small-en-v1.5 استفاده می‌کند تا متن را به بردار معنایی (Embedding) تبدیل کند. در این روش، تکه‌هایی با معنای مشابه در فضای برداری نزدیک به هم قرار می‌گیرند و جست‌وجو از طریق یافتن نزدیک‌ترین همسایگان به بردار پرس‌وجو انجام می‌شود.

این روش شبیه داشتن دوستی است که کتاب‌ها را خوانده و مفاهیم را می‌فهمد. شما یک ایده مبهم را توصیف می‌کنید («آن مشکلی که سرور مدام تلاش می‌کند و اوضاع بدتر می‌شود») و او سریعاً شما را به سند «طوفان‌های تلاش مجدد» (Retry Storms) ارجاع می‌دهد. او معنا را می‌فهمد، اما ممکن است شماره سریال دقیقی را که می‌خواهید، فراموش کند.

در حالی که بازیابی متراکم به راحتی از پس بازنویسی‌ها (Paraphrases)، پرسش‌های زبان طبیعی، تطبیق واژگان متفاوت و پرس‌وجوهای چندزبانه برمی‌آید، نقاط ضعف مشخصی دارد. این روش اغلب در مواجهه با شناسه‌های دقیق، توکن‌های کمیاب و هرگونه واژگان تخصصی دامنه (Domain-specific) که مدل Embedding هرگز ندیده است، دچار مشکل می‌شود.

حافظه و مقیاس بازیابی متراکم

در مقیاس ۵۰ هزار سند (حدود ۵۰۰ هزار تکه)، شما احتمالاً نیازی به ایندکس «نزدیک‌ترین همسایه تقریبی» (ANN) ندارید. ایندکس‌های ANN مانند HNSW، بخشی از دقت (Recall) را فدای سرعت می‌کنند، اما در این مقیاس، شما ممکن است این هزینه را بدون دلیل پرداخت کنید.

میزان اشغال حافظه را در نظر بگیرید: ۵۰ هزار تکه با بردارهای float32 و ۳۸۴ بُعد، حدود ۷۷ مگابایت فضا می‌گیرند. حتی ۵۰۰ هزار تکه تنها به حدود ۷۷۰ مگابایت رم نیاز دارند. یک ضرب ماتریسی ساده (Sequential Scan) روی چند صد هزار بردار، هنوز در یک ماشین معمولی بسیار سریع است.

اگر در نهایت به pgvector مهاجرت کردید و به HNSW نیاز داشتید، پیکربندی استاندارد شامل موارد زیر است:

• ایجاد ایندکس: CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);
• تنظیمات: قرار دادن hnsw.ef_search = 100 برای ایجاد تعادل بین دقت و سرعت (مقدار بالاتر ef_search به معنای دقت بیشتر اما سرعت کمتر است).

یافته‌های پژوهشی و بنچمارک‌ها

بنچمارک BEIR (۲۰۲۱) که بازیابی Zero-shot را در محیط‌های مختلف بررسی می‌کند، یک بینش کلیدی ارائه می‌دهد. مدل‌های متراکم در مجموعه داده MS MARCO (که روی آن آموزش دیده‌اند) با اختلاف زیاد بر BM25 پیروز می‌شوند، اما BM25 در تقریباً هر جای دیگری یک خط پایه (Baseline) استوار باقی می‌ماند. در همین راستا، پژوهش‌های جدیدتری مانند مدل SPARSEUP تلاش کرده‌اند تا هزینه‌های استنتاج را در بازیابی معنایی کاهش دهند در حالی که همچنان بر روی بنچمارک BEIR به نتایج قابل توجهی دست می‌یابند.

مدل‌های متراکم زمانی خوب عمل می‌کنند که داده‌های آموزشی و داده‌های هدف هم‌پوشانی زیادی داشته باشند، اما در مجموعه‌های داده‌ای با «تغییر دامنه» (Domain Shift) زیاد شکست می‌خورند. داده‌های داخلی شرکت شما — پر از مخفف‌های منحصر‌به‌فرد و نام محصولات خاص — احتمالاً برای یک مدل عمومی «خارج از دامنه» است. اینجاست که BM25 نقش شبکه ایمنی را ایفا می‌کند.

با این حال، BEIR به یک توازن هزینه نیز اشاره کرد: BM25 در میلی‌ثانیه روی CPU پاسخ می‌دهد، در حالی که بازرتبه‌بندهای Cross-encoder برای هر پرس‌وجو چندین برابر کندتر هستند. این نشان می‌دهد که اگرچه بازرتبه‌بندی کمک می‌کند، اما رایگان نیست.

راهکار ترکیبی و متد RRF

جست‌وجوی ترکیبی (Hybrid)، BM25 و بازیابی متراکم را به‌صورت موازی اجرا می‌کند. تصور کنید دو شاهد برای یک جرم دارید؛ یکی پلاک دقیق ماشین را به یاد می‌آورد (BM25) و دیگری برداشت کلی از یک سدان تیره دارد که نامنظم رانندگی می‌کرد (Dense). ترکیب این دو، شما را به ماشین درست می‌رساند.

از آنجا که امتیازات BM25 و شباهت کسینوسی در مقیاس‌های کاملاً متفاوتی هستند، نمی‌توان آن‌ها را ساده جمع کرد. استاندارد صنعت برای ادغام این لیست‌ها، تلفیق رتبه متقابل (Reciprocal Rank Fusion یا RRF) است که بر اساس مقاله سال ۲۰۰۹ در SIGIR توسط کورمک، کلارک و بوتچر معرفی شد.

• فرمول RRF: RRF(d) = Σ 1 / (k + rank(d))، که در آن k = 60 مقدار پیش‌فرض استاندارد است.
• مزیت: RRF مستقل از امتیاز است. این روش فقط از جایگاه رتبه‌ها استفاده می‌کند، به این معنی که یک بازیاب با بازه امتیازدهی عجیب نمی‌تواند بر نتیجه غالب شود. داوستانی که در هر دو لیست رتبه ۲ را دارد، بر کسی که در یک لیست اول و در دیگری چهلم است، پیروز می‌شود. اجماع بر یک نظر بلند، برتر است.

شرکت Anthropic اخیراً در گزارش «بازیابی زمینه‌ای» (Contextual Retrieval) خود اعلام کرد که ترکیب بردارهای زمینه‌ای با BM25 زمینه‌ای، نرخ شکست بازیابی در ۲۰ تکه برتر را ۴۹٪ کاهش داده و از ۵.۷٪ به ۲.۹٪ رسانده است. اگرچه برخی منتقدان اشاره می‌کنند که بهترین نتیجه آن‌ها (کاهش ۶۷٪) نیازمند ترکیب چندین تکنیک از جمله بازرتبه‌بندی بود، اما درس اصلی این است: روش ترکیبی از هر دو روش به تنهایی بهتر است.

استراتژی پیاده‌سازی برای ۵۰ هزار سند

برای مجموعه‌ای با این اندازه، گردش کار پیشنهادی از بهینه‌سازی زودهنگام اجتناب کرده و بر اندازه‌گیری تمرکز می‌کند:

۱. شروع با BM25: یک خط پایه سریع و قابل اعتماد بسازید. اگر به هدف Recall شما رسید، ممکن است کار تمام شده باشد.
۲. افزودن جست‌وجوی متراکم ساده: از اسکن متوالی (Sequential Scan) با یک مدل Embedding باز استفاده کنید. تا زمانی که بردارها در رم جا می‌شوند، از پایگاه‌داده‌های برداری مدیریت‌شده دوری کنید.
۳. تلفیق با RRF: پیش از تلفیق، یک استخر کاندیدای سخاوتمندانه (حدود ۵۰ مورد) از هر بازیاب استخراج کنید. اینجاست که Recall معمولاً در مجموعه‌های داده با واژگان مختلط جهش می‌کند.
۴. بهینه‌سازی تکه‌بندی: تکه‌هایی را که زمینه را از دست داده‌اند اصلاح کنید (مثلاً پاراگرافی که می‌گوید «آن ۱۲٪ افزایش یافت» بدون اینکه تعریف کند «آن» چیست). این همان مشکلی است که رویکرد زمینه‌ای Anthropic هدف قرار داده است.
۵. بازرتبه‌بندی در مرحله آخر: تنها زمانی از یک بازرتبه‌بند Cross-encoder استفاده کنید که Recall@50 در حالت ترکیبی خوب باشد اما Precision@5 ضعیف باشد. این نشان می‌دهد تکه درست در استخر موجود است اما رتبه‌اش بیش از حد پایین است.

اهمیت ارزیابی و تله‌های رایج

بسیاری از تیم‌ها به «حس کلی» (Vibes) حاصل از چند پرس‌وجوی دست‌چین شده برای دمو اعتماد می‌کنند که این یک اشتباه حیاتی است. تنها راه تصمیم‌گیری درباره استراتژی، ساخت یک مجموعه ارزیابی کوچک شامل ۵۰ تا ۱۰۰ پرس‌وجوی واقعی با شناسه‌های تکه‌های درست است. این‌ها را از لاگ‌های واقعی کاربران استخراج کنید و پرس‌وجوهای «زشت» شامل غلط‌های املایی، کدهای خطا و سوالات مبهم را نیز بگنجانید.

با اندازه‌گیری Recall@k — یعنی کسری از دفعاتی که تکه درست در k نتیجه اول ظاهر می‌شود — توسعه‌دهندگان می‌توانند ثابت کنند که آیا بازیابی ترکیبی واقعاً توجیه‌پذیر است یا خیر.

اگر متوجه شدید که خطاهای BM25 عمدتاً مربوط به بازنویسی‌ها (Paraphrase) و خطاهای Dense مربوط به شناسه‌های دقیق (ID) است، ثابت کرده‌اید که بازیابی ترکیبی تنها انتخاب منطقی برای داده‌های خاص شماست، فارغ از اینکه بنچمارک‌های عمومی چه می‌گویند.

اجتناب از تله‌های رایج

بیش‌مهندسی (Over-engineering) رایج‌ترین خطا است. تیم‌ها اغلب پایگاه‌داده‌های برداری مدیریت‌شده و سه سرویس مجزا را برای مجموعه‌ای مستقر می‌کنند که بردارهای آن در کمتر از یک گیگابایت رم جا می‌شود. سایر اشتباهات رایج عبارتند از:

• توکن‌سازی بی‌دقت: خرد کردن متن بر اساس علائم نگارشی که جست‌وجوی دقیق برای کدهایی مثل «v2.4.1» را نابود می‌کند.
• جمع زدن امتیازات: نرمال‌سازی و جمع کردن مستقیم شباهت کسینوسی با امتیازات BM25 به‌جای استفاده از تلفیق رتبه (Rank Fusion).
• مقصر دانستن LLM: نسبت دادن پاسخ غلط به مدل، در حالی که سیستم بازیابی در ارائه زمینه (Context) درست شکست خورده است.
• نادیده گرفتن فیلترهای متادیتا: اگر کاربران معمولاً درباره یک محصول خاص یا بازه زمانی خاص می‌پرسند، فیلتر کردن بر اساس متادیتا پیش از جست‌وجو، اغلب از هر الگوریتم رتبه‌بندی هوشمندی بهتر عمل می‌کند.

برای کسانی که از pgvector استفاده می‌کنند، به یاد داشته باشید که جست‌وجوی دقیق‌ترین همسایه (Exact Nearest Neighbor) حالت پیش‌فرض است. همیشه نتایج ANN را با نتایج دقیق روی پرس‌وجوهای خودتان مقایسه کنید پیش از آنکه به ایندکس اعتماد کنید.

این تغییر در رویکرد، تمرکز را از «کدام پایگاه‌داده را بخریم» به «چگونه Recall بازیابی را اندازه بگیریم» منتقل می‌کند. در خط لوله RAG، لایه بازیابی تنها نقطه شکست است که سقف عملکرد LLM را تعیین می‌کند. تلاش خود را روی یک مجموعه ارزیابی خوب و تکه‌بندی درست متمرکز کنید؛ این دو مورد کیفیت پاسخ‌های شما را بیش از هر تعویض مدلی ارتقا می‌دهند.

گام بعدی شما

• یک مجموعه ارزیابی (Eval Set) با ۱۰۰ پرس‌وجوی واقعی از لاگ‌های کاربران بسازید.
• نرخ Recall@10 را برای BM25 به‌تنهایی و سپس برای حالت ترکیبی (Hybrid) اندازه بگیرید.
• اگر نرخ خطا در شناسه‌های دقیق بالاست، توکن‌ساز خود را برای حفظ کاراکترهای خاص بازبینی کنید.

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