هیبرید RAG عملکرد بهتری از جستجوی برداری خالص دارد — دادهها چه میگویند
جستجوی برداری خالص انتخاب پیشفرض اکثر پیادهسازیهای RAG است — و همین یک مشکل بزرگ است. Retrieval مبتنی بر Embedding یک شکاف دقتسنجی کاملاً مستند دارد: در تشخیص شباهت معنایی عالی عمل میکند، اما در پیدا کردن تطابق دقیق، اصطلاحات نادر و اسامی خاص مدام خطا میدهد. طبق بنچمارکهای استاندارد، ترکیب دو روش retrieval یعنی BM25 و Embeddingهای متراکم، در مقایسه با جستجوی برداری خالص، بین ۱۵ تا ۴۰ درصد عملکرد بهتری دارد — البته این رقم بستگی به دیتاست و نوع query دارد. بیشتر تیمها اصلاً این فاصله را اندازه نمیگیرند چون هیچوقت گزینههای جایگزین را بنچمارک نمیکنند. این پست قرار است مکانیزمها، اعداد و نحوه پیادهسازی را توضیح بدهد.
تله جستجوی برداری
Embeddingهای متراکم با نگاشت متن به یک فضای برداری با ابعاد بالا کار میکنند؛ جایی که محتوای مشابه از نظر معنایی در کنار هم خوشهبندی میشوند. این ویژگی برای retrieval در سطح مفهوم عالی است — مثلاً جستجوی "استقرار مدل Machine Learning" میتواند اسناد مربوط به MLOps را به درستی برگرداند، حتی اگر آن اسناد دقیقاً از عبارت "استقرار مدل Machine Learning" استفاده نکرده باشند. اما همین ویژگی برای queryهای حساس به دقت تبدیل به یک نقطه ضعف میشود.
تصور کنید در یک پایگاه دانش فنی به دنبال "GPT-4o" میگردید. یک مدل Embedding این token را بر اساس توزیع آموزش خودش بازنمایی میکند — و ممکن است اسنادی درباره "GPT-4"، "GPT-4 Turbo" یا مقایسه کلی مدلهای OpenAI را بالاتر از سندی رتبهبندی کند که دقیقاً رشته "GPT-4o" را دارد اما موضوع متفاوتی را بحث میکند. امتیاز شباهت Embedding هیچ درکی از مرز رشتهای بین "GPT-4" و "GPT-4o" ندارد. همین الگوی شکست برای SKUهای محصول (مثلاً جستجوی "WD-40" به جای محصول دقیق، محتوای مرتبط با روانکننده را بالا میآورد)، شماره نسخهها ("Python 3.12" در مقابل "Python 3.1")، استنادهای حقوقی و کدهای دارویی هم تکرار میشود.
ریشه مشکل: Embeddingهای متراکم بر اساس الگوهای همظهوری آموزش میبینند، نه هویت در سطح کاراکتر. یک اصطلاح که در مجموعه آموزشی به ندرت دیده شده — مثلاً اسم یک مدل جدید، یک متد API ناآشنا یا اسم یک شخص — یک Embedding نویزی یا عمومی میگیرد که دقت retrieval را از بین میبرد. این یک باگ در مدل Embedding نیست؛ یک محدودیت معماری در این روش است.
چطور BM25 این شکاف را پر میکند
BM25 (Best Match 25) یک تابع امتیازدهی احتمالاتی بر اساس فراوانی کلمه است که بیش از ۳۰ سال ستون فقرات موتورهای جستجو بوده. این تابع بر اساس دو عامل به اسناد امتیاز میدهد: Term Frequency (TF) — تعداد دفعاتی که کلمه query در سند تکرار شده — و Inverse Document Frequency (IDF) — اینکه آن کلمه در کل مجموعه چقدر نادر است. اسنادی که شامل کلمات نادر query هستند، امتیاز بالایی میگیرند؛ کلمات رایج مثل "the" یا "is" تقریباً هیچ تأثیری ندارند.
برای "GPT-4o"، BM25 به سندی که دقیقاً شامل "GPT-4o" است تقریباً امتیاز کامل میدهد — به شرطی که آن کلمه در مجموعه نادر باشد (که در اکثر پایگاههای دانش سازمانی همینطور است). BM25 به شباهت معنایی اهمیت نمیدهد؛ به هویت کلمه اهمیت میدهد. این باعث میشود BM25 برای سناریوهای تطابق دقیق تقریباً بیرقیب باشد: شناسههای محصول، تکهکدهای برنامهنویسی، پیامهای خطا، بندهای حقوقی، فرمولهای شیمیایی و هر حوزهای که دقت مهمتر از پوشش (recall) است.
BM25 همچنین queryهای چندکلمهای را با وزندهی IDF خوب مدیریت میکند. در یک query مثل "Python asyncio event loop timeout"، BM25 به "asyncio" و "timeout" (کلمات نادر) وزن بالا و به "Python" (کلمه رایج) وزن پایین میدهد. در مقابل، جستجوی برداری همه کلمات را در یک Embedding ترکیب میکند و ممکن است سیگنال کلمات نادر اما حیاتی را از دست بدهد.
امتیازدهی ترکیبی در عمل
روش استاندارد برای ترکیب نتایج BM25 و برداری، Reciprocal Rank Fusion (RRF) است. RRF لیستهای رتبهبندی شده از هر دو retriever را میگیرد و با فرمول RRF_score = Σ 1 / (k + rank_i) یک امتیاز تلفیقی برای هر سند محاسبه میکند؛ k معمولاً ۶۰ است و rank_i جایگاه سند در هر لیست است. اسنادی که در هر دو لیست رتبه بالایی دارند، بالاترین امتیاز تلفیقی را میگیرند؛ اسنادی که فقط در یکی از retrieverها قوی هستند باز هم امتیاز میگیرند اما جریمه میشوند.
RRF به درونیابی خطی امتیاز ترجیح داده میشود چون مشکلات نرمالسازی امتیاز را ندارد — BM25 و cosine similarity در مقیاسهای متفاوتی کار میکنند و نرمالسازی آنها به پیچیدگی تنظیم hyperparameter منجر میشود. RRF پارامتر کم میخواهد و در انواع queryها پایدار است.
در اینجا یک راهاندازی minimal برای hybrid retriever با استفاده از EnsembleRetriever کتابخانه LangChain میبینید:
from langchain.retrievers import BM25Retriever, EnsembleRetriever
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings
# ساخت BM25 retriever از لیست اسناد
bm25_retriever = BM25Retriever.from_documents(docs)
bm25_retriever.k = 10
# ساخت vector retriever
vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings())
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 10})
# ترکیب با وزنهای مساوی (RRF در پشت صحنه)
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.5, 0.5]
)
results = ensemble_retriever.invoke("GPT-4o multimodal capabilities")
LlamaIndex هم قابلیت مشابهی از طریق QueryFusionRetriever با حالت mode="reciprocal_rerank" ارائه میدهد. هر دو ابزار، عملیات RRF را در داخل انجام میدهند، بنابراین هزینه پیادهسازی بعد از داشتن یک pipeline وکتور RAG کاری، بسیار پایین است.
اعداد عملکرد در دنیای واقعی
در بنچمارک MS-MARCO passage ranking — که معروفترین دیتاست retrieval با ۸٫۸ میلیون passage است — retrieval ترکیبی BM25 + dense مدام NDCG@10 را ۱۰ تا ۲۰ درصد بالاتر از pure dense retrieval میبرد. در بنچمارک BEIR 2023 که ۱۸ دیتاست ناهمگن را پوشش میدهد، مشخص شد هیچ روش retrieval به تنهایی برتر نیست: مدلهای dense در دیتاستهای غنی از نظر معنایی مثل FEVER و HotpotQA برنده میشوند، در حالی که BM25 در دیتاستهای سنگین روی تطابق دقیق مثل DBPedia و Robust04 برنده یا مساوی است. اما روشهای hybrid در تمام ۱۸ دیتاست به طور مداوم در رتبه بالایی قرار میگیرند — تنها رویکردی است که در هیچکدام از انواع دیتاست شکست فاجعهباری ندارد.
مطالعه بنچمارک RAG شرکت Elastic در سال ۲۰۲۵ که کیفیت retrieval را روی دیتاستهای تیکتهای پشتیبانی سازمانی ارزیابی کرد، نشان داد که جستجوی hybrid تعداد خطاهای retrieval (queryهایی که هیچ سند مرتبطی در top-5 برنمیگردانند) را ۳۴ درصد نسبت به جستجوی صرفاً semantic کاهش میدهد. این بهبود به ویژه برای queryهای کوتاه و کلیدواژهای که در موارد استفاده پشتیبانی و عملیات رایج هستند، چشمگیر بود.
ارزیابی جستجوی hybrid توسط Pinecone (با استفاده از ایندکس sparse-dense که بردارهای SPLADE sparse را با Embeddingهای متراکم ترکیب میکند) بهبود MRR@10 را بین ۱۸ تا ۲۷ درصد روی دیتاستهای کاتالوگ محصول و اسناد حقوقی نسبت به dense-only گزارش داد. نتیجهگیری آنها: بیشترین سود از hybrid search وقتی حاصل میشود که مجموعه شامل ترکیبی از شناسههای ساختاریافته و متن آزاد باشد — توصیفی که برای اکثر پایگاههای دانش سازمانی صدق میکند.
کی از هر کدام استفاده کنیم
استراتژی مناسب retrieval به نوع query و ویژگیهای مجموعه بستگی دارد. در اینجا یک چارچوب تصمیمگیری عملی داریم:
- جستجوی برداری خالص: بهترین حالت برای queryهای معنایی در سطح مفهوم، retrieval بین زبانی و مجموعههایی که paraphrase زیاد دارند. موارد استفاده: جستجوی مقالات تحقیقاتی، تحلیل بازخورد مشتریان، Q&A عمومی روی اسناد روایی.
- BM25 خالص: بهترین برای queryهای تطابق دقیق روی محتوای ساختاریافته یا فنی. موارد استفاده: جستجوی کاتالوگ محصول با SKU، جستجوی کد بر اساس نام تابع، retrieval متون حقوقی با شماره قانون، retrieval سوابق پزشکی با کد تشخیص.
- Hybrid (BM25 + vector): پیشفرض درست برای اکثر استقرارهای RAG سازمانی. موارد استفاده: پشتیبانی مشتری (ترکیب queryهای کلیدواژهای مثل کد خطا با queryهای معنایی مثل "چطور اشتراکم را لغو کنم؟")، پایگاههای دانش داخلی، مستندات فنی، جستجوی محصولات فروشگاهی، retrieval سیاستهای منابع انسانی.
یک قاعده سرانگشتی عملی: اگر بیش از ۲۰ درصد queryهای کاربران شما شامل شناسهها، نام مدلها، شماره نسخهها یا دیگر عبارات تطابق دقیق است، hybrid search از pure vector بهتر عمل میکند. ۵۰ query واقعی را از هر دو روش عبور دهید و precision@5 را اندازه بگیرید — تفاوت تقریباً همیشه ظرف یک ساعت تست قابل مشاهده است.
چکلیست پیادهسازی
- اول سیستم فعلی را خط پایه (baseline) کنید. ۵۰–۱۰۰ query نمادین را از RAG برداری موجود عبور دهید و دقت top-5 را به صورت دستی امتیازدهی کنید. این baseline باعث میشود بهبود حاصل از hybrid retrieval قابل اندازهگیری باشد، نه صرفاً فرضی.
- از یک sparse index متناسب با پشته فنی خود استفاده کنید. Elasticsearch و OpenSearch به صورت بومی BM25 دارند؛ Pinecone از sparse-dense پشتیبانی میکند؛ Weaviate از BM25F؛ Qdrant از sparse vector. گزینهای را انتخاب کنید که نیاز به اضافه کردن یک سرویس جستجوی جداگانه نداشته باشد.
- پارامتر k را در RRF روی یک مجموعه query کنارگذاشته تنظیم کنید. مقدار پیشفرض k=60 خوب است اما همیشه بهینه نیست. یک جستجوی شبکهای روی k=20, 40, 60, 80 با ۵۰ query برچسبخورده معمولاً کمتر از یک ساعت طول میکشد.
- ایندکسهای BM25 و برداری را همزمان نگه دارید. هر دو ایندکس باید با افزودن/حذف/بهروزرسانی اسناد بهروز شوند. عدم بهروزرسانی یکی از ایندکسها به صورت خاموش کیفیت fusion را کاهش میدهد. از یک pipeline یکپارچه واردسازی استفاده کنید که به هر دو ایندکس بنویسد.
- برای BM25 از query expansion استفاده کنید. با استفاده از LLM دو تا سه واریانت از query تولید کنید (الگوی HyDE) قبل از اجرای BM25. این کار recall را برای queryهای مکالمهای که کاربران به صورت سؤال مطرح میکنند به جای کلیدواژه، بهبود میدهد.
- کیفیت retrieval را در تولید (production) در سطح هر query رصد کنید. ثبت کنید که کدام retriever (BM25 یا vector) به اسناد نهایی top-ranked کمک کرده. اگر یک ranker برای الگوهای خاصی از query به طور مداوم غالب است، وزنها را تنظیم کنید یا queryها را به retrieverهای تخصصی مسیریابی کنید.
نتیجهگیری
اکثر تیمهایی که سیستم RAG میسازند، به طور پیشفرض به سراغ pure vector retrieval میروند بدون اینکه حتی یک بنچمارک کنترلشده اجرا کنند. اضافه کردن BM25 به یک pipeline RAG برداری موجود — با استفاده از EnsembleRetriever لنگچین یا QueryFusionRetriever لاماایندکس — یک کار یکروزه است. بهبود عملکرد روی اکثر دیتاستهای سازمانی حاشیهای نیست: ۱۵ تا ۴۰ درصد بهبود در دقت retrieval مستقیماً به کاهش خطاهای توهم (hallucination)، کاهش fallbackهای LLM به "نمیدانم" و افزایش نمرات رضایت کاربر نهایی منجر میشود. دادهها در MS-MARCO، BEIR و بنچمارکهای صنعتی یکسان است: hybrid retrieval یک بهینهسازی نیست — بلکه خط پایهای است که pure vector RAG باید در برابر آن سنجیده شود.