Reranking و Hybrid Search؛ وقتی جست‌وجوی برداری کافی نیست

خیلی از تیم‌هایی که برای اولین‌بار یک خط لولهٔ RAG می‌سازند، بعد از چند هفته با یک الگوی آزاردهنده مواجه می‌شوند: بات برای سؤال‌های کلی و مفهومی خوب جواب می‌دهد، اما وقتی کاربر شمارهٔ مدل دقیق یک محصول یا نام یک فیلد فنی را می‌پرسد، جواب اشتباه یا ناقص می‌دهد. این نشانهٔ کلاسیک محدودیت جست‌وجوی برداری تنها است، و راه‌حلش ترکیب آن با جست‌وجوی کلیدواژه‌ای (keyword search) و یک لایهٔ rerank است. اگر ساختار کلی خط لوله برایتان روشن نیست، اول نقشهٔ راه ساخت چت‌بات تخصصی را ببینید؛ این مقاله دقیقاً روی همان لایهٔ بازیابی زوم می‌کند.

چرا جست‌وجوی برداری به‌تنهایی کافی نیست

embedding برای گرفتن «معنا» طراحی شده، نه برای تطبیق دقیق رشته‌ها. این یعنی جست‌وجوی برداری در سه دستهٔ سؤال ضعیف عمل می‌کند:

• کلمهٔ دقیق: اگر کاربر عین یک اصطلاح فنی یا کد خطا را بپرسد، مدل embedding ممکن است آن را به مفهومی نزدیک اما نادرست تعمیم دهد، چون در فضای برداری، رشته‌های نزدیک از نظر معنا خوشه می‌شوند نه از نظر تطابق حرف‌به‌حرف.
• نام محصول: نام‌های تجاری اغلب کلمات نامتعارف یا ترکیبی هستند که embedding آن‌ها را به‌خوبی کلمات رایج زبان نمایندگی نمی‌کند؛ دو محصول با نام مشابه ممکن است در فضای برداری خیلی نزدیک شوند و جابه‌جا بازیابی شوند.
• شمارهٔ مدل: اعداد و کدهای الفبا-عددی (مثل X200-Pro در برابر X200) معنای معناشناختی ندارند؛ برای embedding تقریباً یکسان به نظر می‌رسند، درحالی‌که برای کاربر تفاوتشان حیاتی است.

در هر سه مورد، مشکل این نیست که مدل embedding «بد» است؛ مشکل این است که این‌ها اساساً کارهایی هستند که جست‌وجوی کلیدواژه‌ای (مثل BM25) در آن‌ها بهتر از جست‌وجوی معنایی عمل می‌کند.

Hybrid Search؛ ترکیب دو دنیا

Hybrid Search یعنی هر سؤال هم‌زمان با دو روش جست‌وجو می‌شود: جست‌وجوی برداری برای گرفتن مفهوم کلی سؤال، و جست‌وجوی کلیدواژه‌ای برای گرفتن تطابق دقیق رشته‌ها. نتیجهٔ دو جست‌وجو با یک فرمول امتیازدهی ترکیبی (مثلاً میانگین وزن‌دار یا Reciprocal Rank Fusion) با هم ادغام می‌شود. این ترکیب حل می‌کند که نه سؤال مفهومی («چطور اشتراکم را لغو کنم») قربانی جست‌وجوی کلیدواژه‌ای شود، و نه سؤال دقیق («خطای ERR-4471 یعنی چه») قربانی تعمیم بیش‌ازحد جست‌وجوی معنایی.

Reranking؛ لایهٔ دوم دقت

حتی با Hybrid Search، فهرست اولیهٔ بازیابی‌شده معمولاً بیست تا پنجاه تکه است که ترتیبشان بر اساس امتیاز تقریبی است. مرحلهٔ rerank یک مدل جداگانه (معمولاً یک cross-encoder) است که هر جفت «سؤال – تکهٔ متن» را با دقت بیشتری می‌سنجد و فهرست را دوباره مرتب می‌کند تا فقط بهترین چند مورد (مثلاً سه تا پنج تکه) به مدل زبانی برسد. تفاوت کلیدی این است که جست‌وجوی اولیه سریع اما تقریبی است (چون باید در میان هزاران تکه بگردد)، درحالی‌که rerank کند اما دقیق است (چون فقط روی چند ده کاندید نهایی اجرا می‌شود). این دو لایه مکمل هم‌اند، نه جایگزین هم.

چه زمانی این پیچیدگی ارزشش را دارد

اگر پایگاه دانش شما پر از اصطلاحات فنی، شماره‌مدل، کد خطا یا نام محصول است — که در اغلب باتهای پشتیبانی محصول همین‌طور است — Hybrid Search تقریباً ضروری می‌شود. اگر پایگاه دانش عمومی‌تر است (مثل مقالات آموزشی یا سؤالات متداول مفهومی)، شاید جست‌وجوی برداری تنها برای شروع کافی باشد و بتوانید rerank را بعداً اضافه کنید. نکته این است که این تصمیم را از ابتدا آگاهانه بگیرید، نه اینکه بعد از شکایت کاربران دربارهٔ «باتی که اسم محصول را قاطی می‌کند» متوجه علتش شوید.

مسئلهٔ خاص محتوای دوزبانه

در بسیاری از پایگاه‌های دانش فارسی، متن اصلی فارسی است اما نام محصول، شمارهٔ مدل، یا اصطلاح فنی به لاتین نوشته می‌شود؛ همین ترکیب دوزبانه یکی از رایج‌ترین منابع خطای جست‌وجوی برداری تنها است. مدل‌های embedding چندزبانه معمولاً برای متن پیوستهٔ یک زبان تنظیم شده‌اند، و وقتی یک کلمهٔ لاتین وسط جملهٔ فارسی می‌آید، بردار نهایی گاهی نه به فضای فارسی نزدیک است و نه به فضای انگلیسی، بلکه جایی نامشخص بین این دو قرار می‌گیرد. جست‌وجوی کلیدواژه‌ای در این حالت خیلی قابل‌اعتمادتر عمل می‌کند، چون به‌جای تلاش برای فهمیدن معنا، مستقیم دنبال همان رشتهٔ لاتین می‌گردد. اگر پایگاه دانش شما این ترکیب را دارد — که برای اکثر شرکت‌های ایرانی با محصولات فنی همین‌طور است — فعال بودن جست‌وجوی کلیدواژه‌ای از روز اول، نه یک بهینه‌سازی بعدی، بلکه یک نیاز پایه است.

ارزیابی و پایش کیفیت بازیابی

افزودن Hybrid Search و rerank بدون سنجش، حدس‌وگمان است. راه عملی این است که یک مجموعهٔ کوچک از سؤال‌های واقعی به‌همراه جواب درست یا سند مرجع درست‌شان تهیه کنید (حتی بیست تا سی نمونه کافی است برای شروع)، و بعد از هر تغییر در لایهٔ بازیابی — تغییر مدل embedding، اضافه کردن rerank، تنظیم وزن ترکیب — همان مجموعه را دوباره اجرا کنید تا ببینید نسبت سؤال‌هایی که سند درست را در نتایج بالا آوردند بهتر شده یا بدتر. بدون این حلقهٔ بازخورد، هر تغییری در لایهٔ بازیابی صرفاً یک حدس دیگر است، نه یک بهبود قابل‌اندازه‌گیری.

جست‌وجوی برداری «چه چیزی مرتبط است» را خوب می‌فهمد؛ جست‌وجوی کلیدواژه‌ای «کدام کلمهٔ دقیق» را خوب می‌فهمد. بات پشتیبانی جدی به هر دو نیاز دارد.

جمع‌بندی

• جست‌وجوی برداری برای معنا خوب است، نه برای تطابق دقیق کلمه، نام محصول یا شمارهٔ مدل.
• Hybrid Search نتیجهٔ جست‌وجوی معنایی و کلیدواژه‌ای را ترکیب می‌کند تا هر دو نوع سؤال پوشش داده شود.
• Reranking با یک مدل دقیق‌تر، فهرست اولیه را دوباره مرتب می‌کند تا فقط بهترین تکه‌ها به مدل زبانی برسند.
• این دو لایه مکمل‌اند: بازیابی سریع و تقریبی، سپس رتبه‌بندی کند و دقیق.
• تصمیم دربارهٔ نیاز به Hybrid Search را بر اساس ماهیت پایگاه دانش بگیرید، نه بعد از شکایت کاربر.