Hybrid Search چیست؟ ترکیب BM25 و Vector Search برای افزایش دقت RAG

یکی از اولین وسوسه‌ها هنگام ساخت RAG این است که تمام جستجو را به embedding بسپاریم. متن‌ها به بردار تبدیل می‌شوند، سؤال کاربر هم embedding می‌شود و نزدیک‌ترین بردارها پاسخ را می‌دهند.

این روش روی سؤال‌های مفهومی عملکرد بسیار خوبی دارد، اما در داده واقعی به سرعت با Queryهایی روبه‌رو می‌شویم که Vector Search برای آن‌ها ابزار ایده‌آلی نیست.

در پروژه ما نقطه عطف زمانی بود که queryهایی شبیه این وارد شدند:

ERR_DB-7312
RFC-1048
invoice_id
PaymentGatewayTimeout

برای چنین queryهایی کاربر «چیزی شبیه این» را نمی‌خواهد؛ همان عبارت دقیق را می‌خواهد.

اینجا Hybrid Search وارد می‌شود.

Hybrid Search چه چیزی را ترکیب می‌کند؟

در ساده‌ترین تعریف، Hybrid Search ترکیب retrieval معنایی و lexical است.

معماری ما در نهایت چند کانال candidate داشت:

• Dense Vector Search
• BM25F Lexical Search
• Exact Identifier Search
• Optional Sparse/SPLADE
• Optional Graph/Visual retrieval

بعد نتایج این کانال‌ها با fusion ترکیب می‌شوند.

Dense Search کجا عالی است؟

Dense Search زمانی قوی است که واژگان سؤال و سند متفاوت باشند ولی مفهوم یکسان باشد.

مثلاً سند:

تعداد اتصال‌های هم‌زمان دیتابیس به سقف pool رسیده است.

Query:

چرا درخواست‌ها وقتی ترافیک بالا می‌رود منتظر دیتابیس می‌مانند؟

Lexical overlap ممکن است کم باشد، اما embedding می‌تواند ارتباط مفهومی را تشخیص دهد.

Dense Search کجا ضعیف‌تر است؟

شناسه‌های دقیق

ERR-7312 معنای زبانی خاصی ندارد. embedding ممکن است آن را representation ضعیفی بدهد.

نام کد و symbol

get_user_by_id یا PaymentProcessorV2 بیشتر lexical entity هستند تا جمله معنایی.

واژگان نادر

نام محصول، شماره قرارداد یا acronym خاص شرکت ممکن است در embedding space به‌خوبی مدل نشده باشد.

Query بسیار کوتاه

Query تک‌کلمه‌ای می‌تواند ambiguity زیادی داشته باشد.

BM25 چرا هنوز مهم است؟

BM25 یک الگوریتم lexical ranking بسیار قدیمی‌تر از embeddingهاست، اما هنوز برای search فوق‌العاده مفید است.

BM25 به شکل ساده به این عوامل توجه می‌کند:

• term frequency
• document frequency
• طول document

واژه‌ای که در corpus نادر است وزن بیشتری می‌گیرد. این دقیقاً برای error code، نام فنی و اصطلاحات خاص مفید است.

چرا BM25F به جای BM25 ساده؟

در سیستم ما در v4 lexical path به BM25F ارتقا پیدا کرد.

BM25F اجازه می‌دهد فیلدها وزن متفاوت داشته باشند.

فرض کنید document این فیلدها را دارد:

title
raw_text
keywords
references

وجود عبارت PostgreSQL Replication در title احتمالاً مهم‌تر از یک occurrence گذرا در body است.

BM25F می‌تواند این تفاوت را مدل کند.

Exact Search؛ مسیری که نباید فراموش شود

برای identifierها حتی BM25 هم گاهی بیش از حد عمومی است.

اگر query دقیقاً ERR_DB-7312 باشد و سندی همین identifier را داشته باشد، Exact Index می‌تواند evidence بسیار قوی تولید کند.

در معماری ما references representation و exact identifier path دقیقاً برای چنین queryهایی وجود دارد.

مشکل Fusion چیست؟

فرض کنید سه موتور این scoreها را تولید کنند:

Dense: 0.82
BM25: 14.7
Exact: 1.0

نمی‌توان این اعداد را مستقیم جمع کرد. scale آن‌ها متفاوت است.

یک روش، calibration scoreهاست. روش دیگری که ساده و مقاوم است Reciprocal Rank Fusion یا RRF است.

RRF چگونه کار می‌کند؟

RRF به score خام اهمیت کمتری می‌دهد و از رتبه استفاده می‌کند.

فرمول کلاسیک به شکل زیر است:

RRF(d) = Σ 1 / (k + rank_i(d))

اگر document در چند retrieval channel رتبه خوبی داشته باشد، score نهایی آن بالا می‌رود.

Weighted RRF اجازه می‌دهد بعضی channelها وزن بیشتری داشته باشند.

مثلاً برای identifier query می‌توان Exact Search را مهم‌تر کرد.

Query Routing می‌تواند Hybrid Search را هوشمندتر کند

لازم نیست همه queryها دقیقاً با یک وزن پردازش شوند.

Router می‌تواند query را تشخیص دهد:

• semantic question
• exact identifier
• navigational query
• multi-hop query

مثلاً query ERR_DB-7312 احتمالاً exact-heavy است، در حالی که «علت کند شدن replication چیست؟» semantic-heavy است.

در سیستم ما heuristic routing و امکان classifier-based routing در نظر گرفته شد.

Sparse Retrieval کجای معماری قرار می‌گیرد؟

مدل‌هایی مثل SPLADE تلاش می‌کنند مزایای lexical و neural را ترکیب کنند. خروجی آن‌ها sparse vector است که term expansion معنایی دارد.

این مسیر optional است، زیرا dependency و هزینه بیشتری دارد.

برای بسیاری از deploymentهای کوچک، Dense + BM25F + Exact Search نقطه شروع بسیار خوبی است.

Reranking بعد از Hybrid Candidate Generation

Fusion پایان کار نیست.

Hybrid Retrieval candidateها را جمع می‌کند. سپس می‌توان top-N را با Cross Encoder یا Late Interaction rerank کرد.

این معماری trade-off خوبی می‌دهد:

Fast retrieval -> 100 candidates
Fusion -> 40 candidates
Cross Encoder -> Top 10

مدل گران فقط روی مجموعه کوچک اجرا می‌شود.

Diversity و مشکل نتایج تکراری

اگر سند به چند Chunk نزدیک تقسیم شده باشد، ممکن است top results همگی از یک بخش باشند.

MMR یا source caps می‌تواند diversity را افزایش دهد.

هدف همیشه «بالاترین similarity» نیست؛ گاهی مجموعه‌ای از شواهد متنوع برای پاسخ بهتر است.

ACL در Hybrid Search

نکته امنیتی بسیار مهم: candidate generation باید policy-aware باشد.

اگر Dense path فیلتر tenant را رعایت کند ولی BM25 path نکند، نشت اطلاعات رخ می‌دهد.

تمام retrieval channelها باید یک boundary دسترسی یکسان داشته باشند.

در v4 این موضوع به‌عنوان یکی از hardening points جدی گرفته شد و ACL/tenant filtering در candidate retrieval اعمال می‌شود.

یک معماری پیشنهادی ساده

برای یک knowledge base سازمانی:

Query
  ├── Dense Search
  ├── BM25F
  └── Exact Search
    ↓
   Weighted RRF
    ↓
   Cross Encoder
    ↓
   ACL / Trust
    ↓
   MMR / Source Cap
    ↓
   Context Builder

این معماری بدون Graph Retrieval یا LTR پیشرفته هم می‌تواند کیفیت بسیار خوبی ارائه دهد.

چگونه Hybrid Search را ارزیابی کنیم؟

باید Dense-only را با Hybrid مقایسه کنیم.

Dataset را به چند نوع query تقسیم کنید:

• semantic questions
• exact IDs
• short keyword queries
• acronym queries
• multi-concept queries

سپس metricهایی مثل Recall@K، MRR و NDCG را جداگانه اندازه بگیرید.

ممکن است Dense-only روی semantic queries عالی باشد اما exact queries را از دست بدهد. میانگین کلی این تفاوت را پنهان می‌کند.

یکی از درس‌های مهم پروژه

ما ابتدا تصور می‌کردیم Vector Search هسته اصلی سیستم است و lexical search یک fallback است. بعد از تست روی Queryهای واقعی، دیدگاه تغییر کرد.

در یک موتور جستجوی خوب، Dense و Lexical دو شهروند درجه‌یک هستند. هرکدام نوع خاصی از evidence را ارائه می‌دهند.

Hybrid Search زمانی بهترین نتیجه را می‌دهد که به جای رقابت این روش‌ها، آن‌ها را مکمل هم طراحی کنیم.

جمع‌بندی

Vector Search معنای Query را می‌فهمد؛ BM25 واژه‌ها را جدی می‌گیرد؛ Exact Search شناسه‌ها را بدون ابهام پیدا می‌کند.

Hybrid Search یعنی استفاده از هرکدام در جایی که قوی هستند و ترکیب evidence آن‌ها به شکلی قابل کنترل.

برای ما این تغییر معماری یکی از مهم‌ترین قدم‌ها در فاصله گرفتن از یک RAG prototype و نزدیک شدن به یک Retrieval Engine واقعی بود.

به‌روزرسانی: ۲۷ شهریور ۱۴۰۵

←همهٔ نوشته‌ها