Multi-Vector Retrieval چیست و چرا یک Embedding برای کل سند کافی نیست؟
آشنایی با Multi-Vector Retrieval و Multi-Representation Search؛ چرا raw text، title، summary و references باید جداگانه دیده شوند؟
- multi vector retrieval
- multi representation RAG
- semantic search architecture

مقدمه
بسیاری از سیستمهای Semantic Search با یک فرض ساده شروع میشوند: هر document را به یک embedding تبدیل کن و همان را برای retrieval استفاده کن. این مدل برای شروع بد نیست، اما خیلی زود محدودیتش معلوم میشود. یک سند واقعی فقط «متن خام» نیست؛ title دارد، summary دارد، keywords دارد، references دارد و حتی metadata معنایی دارد.
Multi-Vector Retrieval تلاش میکند این واقعیت را وارد معماری retrieval کند.
مشکل single-vector چیست؟
وقتی کل document در یک embedding خلاصه میشود، چند اتفاق رخ میدهد:
- signalهای مختلف سند در یک representation مخلوط میشوند.
- title و body وزن مستقل ندارند.
- queryهای identifier یا reference-heavy خوب پشتیبانی نمیشوند.
- summary یا semantic abstraction از بین میرود.
در نتیجه بعضی queryها، مخصوصاً queryهای دقیق، ساختاری یا metadata-aware، بهخوبی پاسخ نمیگیرند.
ایده Multi-Vector چیست؟
بهجای یک representation، چند representation میسازیم؛ مثلاً:
raw_textsummarykeywordstitlesreferences
هر کدام از اینها embedding یا signal خاص خود را دارد. سپس برای retrieval میتوان از یکی یا چند تای آنها candidate گرفت و در نهایت fusion انجام داد.
تجربه ما در ماژول
در نسخههای اولیه، ظاهر multi-vector داشتیم ولی در عمل اگر بعضی فیلدها خالی بودند، همان raw text چند بار تکرار میشد. این معماری از نظر ظاهری پیشرفته بود، اما در کیفیت واقعی retrieval تفاوتی ایجاد نمیکرد.
در نسخههای بعدی، این مشکل را اصلاح کردیم و multi-representation candidate generation واقعی ساختیم. این تغییر باعث شد اسنادی که فقط از طریق title یا summary قابل کشف بودند، وارد candidate set شوند.
مزایا
Multi-Vector Retrieval چند مزیت مهم دارد:
- Recall بهتر برای queryهای متنوع
- انعطاف بیشتر در fusion
- توانایی بهتر برای matching title-level یا summary-level
- طراحی بهتر برای اسناد غنی و ساختاریافته
هزینهها
اما هزینه هم دارد:
- storage بیشتر
- embedding بیشتر
- index پیچیدهتر
- tuning دشوارتر
- latency بالاتر اگر کنترل نشود
به همین دلیل همیشه باید ارزیابی کنید که کدام representation واقعاً ارزش دارد.
بهترین use caseها
- knowledge base سازمانی
- اسناد policy و governance
- documentation فنی
- reportها و paperها
- سیستمهایی که metadata غنی دارند
طراحی خوب
برای طراحی خوب Multi-Vector Retrieval این نکات مهماند:
- representationها باید واقعاً متفاوت باشند.
- candidate generation باید چند representation را پوشش دهد، نه فقط ranking نهایی.
- fieldها باید versioned و explainable باشند.
- fusion باید با benchmark تنظیم شود.
جمعبندی
یک embedding برای کل سند در بسیاری از موارد کافی نیست. Multi-Vector Retrieval راهی است برای اینکه retrieval به جهان واقعی نزدیکتر شود؛ جایی که معنا فقط در body نیست و title، summary، keywords و references هر کدام بخشی از حقیقت سند را حمل میکنند. اگر به دنبال retrieval قویتر و دقیقتر هستید، این معماری یکی از مسیرهای جدی رشد سیستم شماست.
بهروزرسانی:
همهٔ نوشتهها