Cross-Encoder چیست و چه تفاوتی با Embedding Search دارد؟
مقایسه Cross-Encoder و Bi-Encoder در Semantic Search و RAG؛ از کیفیت رتبهبندی تا latency و هزینه عملیاتی در پروژههای واقعی.
- cross encoder vs bi encoder
- embedding search
- reranker
- semantic search
مقدمه
در سیستمهای بازیابی اطلاعات مدرن، دو معماری بسیار مهم وجود دارد: Bi-Encoder و Cross-Encoder. بیشتر تیمها Embedding Search را با Bi-Encoder میشناسند؛ یعنی query و document جداگانه به بردار تبدیل میشوند و سپس با cosine similarity مقایسه میشوند. در مقابل، Cross-Encoder query و document را با هم وارد مدل میکند و relevance را مستقیم پیشبینی میکند.
در ظاهر، هر دو برای «جستجوی معنایی» استفاده میشوند، اما در عمل کاربردهایشان متفاوت است. تجربه ما در ساخت موتور retrieval این بود که هر کدام جای مخصوص خود را دارند و جایگزین کامل هم نیستند.
Bi-Encoder چگونه کار میکند؟
در Bi-Encoder، این فرایند انجام میشود:
- query با مدل embedding به یک بردار تبدیل میشود.
- هر document هم قبلاً به بردار تبدیل شده است.
- شباهت query و document با معیارهایی مثل cosine similarity محاسبه میشود.
مزیت اصلی این روش سرعت و مقیاسپذیری است. چون document embeddingها از قبل ساخته شدهاند، در زمان query فقط کافی است nearest neighbors پیدا شوند.
Cross-Encoder چگونه کار میکند؟
در Cross-Encoder، query و document با هم به مدل داده میشوند. مدل نهتنها هر دو متن را میبیند، بلکه interaction بین کلمات و ساختار دو متن را هم بررسی میکند. خروجی مدل یک score relevance است.
مزیت اصلی Cross-Encoder دقت بالاتر در رتبهبندی است، چون متنها را مشترکاً میفهمد؛ اما قیمت این دقت، latency و هزینه بیشتر است.
تفاوت عملیاتی اصلی
در عمل میتوان تفاوتها را اینطور خلاصه کرد:
Bi-Encoder
- سریع
- مناسب ANN و corpus بزرگ
- عالی برای candidate generation
- ارزانتر در زمان query
- دقت کمتر در ranking نهایی
Cross-Encoder
- کندتر
- نامناسب برای scan کل corpus
- عالی برای reranking
- دقت بیشتر در top results
- نیازمند compute بیشتر
چرا نمیتوان فقط Cross-Encoder داشت؟
اگر corpus کوچک باشد، شاید بتوان برای همه اسناد از Cross-Encoder استفاده کرد؛ اما در اکثر سناریوهای واقعی این کار عملی نیست. تصور کنید 500 هزار chunk دارید. اجرای Cross-Encoder روی همه آنها برای هر query هزینهبر و کند خواهد بود.
به همین دلیل در معماریهای حرفهای، Bi-Encoder یا Hybrid Retrieval مرحله اول را انجام میدهد و Cross-Encoder روی top-k محدود اجرا میشود.
تجربه ما در ماژول
در این ماژول، Embedding Search مرحله candidate generation را بر عهده دارد و Cross-Encoder برای reranking اختیاری استفاده میشود. در hardening ماژول یک نکته مهم روشن شد: adapter مربوط به Cross-Encoder نباید activation را حدس بزند یا score را دوباره اشتباه تبدیل کند. همچنین score Cross-Encoder نباید قواعد سیاستی مثل ACL و source trust را overwrite کند.
این تجربه به ما نشان داد که Cross-Encoder اگرچه از نظر مفهومی ساده بهنظر میرسد، ولی در production جزئیات زیادی دارد.
چه زمانی Bi-Encoder کافی است؟
در این شرایط، Bi-Encoder بهتنهایی میتواند کافی باشد:
- corpus کوچک یا متوسط است.
- latency خیلی حساس است.
- top results خیلی به هم نزدیک نیستند.
- use case بیشتر اکتشافی است تا precision-critical.
چه زمانی Cross-Encoder لازم است؟
Cross-Encoder معمولاً وقتی ارزش واقعی خود را نشان میدهد که:
- top-20 نتایج خیلی نزدیک به هم باشند.
- query کوتاه و مبهم باشد.
- precision در top-3 اهمیت حیاتی داشته باشد.
- دادهها ساختار پیچیده یا اصطلاحات فنی خاص داشته باشند.
- RAG نیاز دارد بهترین context ممکن را برای LLM بسازد.
الگوی پیشنهادی برای معماری
بهترین الگو برای اکثر تیمها این است:
- Bi-Encoder / Hybrid Search برای candidate generation
- Cross-Encoder برای reranking top-k
- MMR یا dedup برای جلوگیری از تکرار
- Context assembly برای ساخت ورودی LLM
جمعبندی
Bi-Encoder و Cross-Encoder رقیب نیستند؛ مکملاند. Embedding Search با Bi-Encoder پایه مقیاسپذیری را میسازد و Cross-Encoder کیفیت ranking را بالا میبرد. اگر این دو را در جای درست خود استفاده کنید، هم سرعت مناسبی خواهید داشت و هم کیفیت بهتر. این دقیقاً همان الگویی است که در بیشتر موتورهای retrieval مدرن دیده میشود.
بهروزرسانی:
همهٔ نوشتهها