
multilingual-e5 یا BGE-M3 برای فارسی؛ ۱٫۰۶ امتیاز همهٔ انتخاب نیست

در جدول PTEB، میانگین multilingual-e5-large-instruct برابر ۷۶٫۱۳ و BGE-M3 برابر ۷۵٫۰۷ است؛ فاصلهٔ ۱٫۰۶ امتیازی برای انتخاب embedding در RAG فارسی کافی نیست. اگر بخشهای کوتاه را با جستوجوی برداری بازیابی میکنید، E5 نامزد مناسبی است؛ اگر سندهای بلند یا بازیابی ترکیبی در کار است، قابلیتهای BGE-M3 به آزمون جداگانه نیاز دارد.
انتخاب نهایی به این بستگی دارد که کدام پیکربندی بخش حاوی پاسخ را از میان اسناد خودتان پیدا میکند. طول ورودی مدل، قالب پرسش و استفاده از تطبیق واژه در کنار شباهت معنایی میتوانند ترتیب نتایج را تغییر دهند. بنابراین امتیاز عمومی، نامزدهای مقایسه را مشخص میکند و آزمون روی پرسشهای واقعی محصول، مبنای تصمیم است.
اختلاف میانگین چه چیزی را پنهان میکند؟
امتیاز کلی PTEB حاصل وظایف متفاوتی است و نباید آن را به اختلاف کیفیت بازیابی در یک مجموعهسند خاص تبدیل کرد. حتی در خود جدول، برتری یک مدل در همهٔ آزمونهای بازیابی تکرار نمیشود. در دادههای تفکیکی PTEB، BGE-M3 در MIRACLRetrievalHardNegatives امتیاز ۶۱٫۳۴ را در برابر ۵۹٫۲۳ برای E5 دارد؛ در WikipediaRetrievalMultilingual، امتیاز E5 برابر ۹۰٫۳۶ و امتیاز BGE-M3 برابر ۸۹٫۲۷ است. اینها نتایج دو وظیفهٔ مشخصاند، نه پیشبینی عملکرد روی اسناد یک سامانهٔ RAG.
دامنهٔ ارزیابی فارسی نیز از جستوجوی بخش پاسخ گستردهتر است. پژوهش FaMTEB از ۶۳ مجموعهداده در هفت وظیفه، از جمله retrieval و reranking، استفاده میکند. FaMTEB و PTEB مجموعه و شیوهٔ گزارش یکسانی ندارند؛ برای مسئلهٔ RAG باید پیش از توجه به رتبهٔ کلی دید کدام نتیجه به بازیابی متن و نوع پرسش محصول نزدیکتر است. پرسشی که پاسخ آن در یک بند کوتاه است با پرسشی که به عبارتی دقیق در میانهٔ سند بلند اشاره میکند، دشواری یکسانی برای نمایهٔ جستوجو ندارد.
طول متن چگونه انتخاب را عوض میکند؟
کارت multilingual-e5-large-instruct میگوید متنهای بلند حداکثر تا ۵۱۲ توکن پردازش میشوند و هر پرسش باید یک دستور یکجملهای دربارهٔ وظیفه داشته باشد؛ سندهای بازیابیشونده به این دستور نیاز ندارند. اگر یک بخش از سقف ورودی بگذرد، انتهای آن در نمایش برداری همان بخش حضور نخواهد داشت. برای اسنادی که پاسخ در بندهای پایانی آنهاست، این محدودیت میتواند مهمتر از فاصلهٔ امتیاز کلی باشد.
در مقابل، کارت BGE-M3 ظرفیت ورودی تا ۸۱۹۲ توکن و سه شیوهٔ dense، sparse و multi-vector را ثبت میکند. ظرفیت بیشتر امکان رمزگذاری بخش بلندتر را میدهد، اما بهخودیخود ثابت نمیکند که یک بردار برای کل سند بهتر از چند بردار برای بندهای کوتاه، محل پاسخ را پیدا خواهد کرد. در بخش بلند، متن مرتبط ممکن است سهم کوچکی از کل محتوا باشد؛ تقسیم سند به بندهای معنادار همچنان یک انتخاب مستقل در طراحی بازیابی است.
برای جدا کردن اثر مدل از اثر بخشبندی، ابتدا هر دو مدل را روی بخشهای یکسانی که در سقف ورودی E5 جا میشوند مقایسه کنید. سپس اگر اسناد واقعاً به زمینهٔ بلند نیاز دارند، بخشهای بلندتر BGE-M3 را بهعنوان پیکربندی دیگری بسنجید. در حالت دوم، نتیجه حاصل انتخاب همزمان مدل و اندازهٔ بخش است. عنوان، متن اصلی و هر عبارت دیگری که همراه بخش رمزگذاری میشود نیز باید در شمارش طول ورودی لحاظ شود.
قالب پرسش و روش بازیابی چه نقشی دارند؟
برای E5، پرسش باید با قالب مستند «Instruct:» و «Query:» ساخته شود. یک نمونهٔ مشروط برای جستوجوی پاسخ در دانشنامهٔ فارسی این است که دستور از مدل بخواهد بخش پاسخدهنده به پرسش کاربر را بازیابی کند و متن پرسش پس از «Query:» بیاید. متن دستور را در طول آزمون ثابت نگه دارید؛ تغییر آن همزمان با تغییر مدل، تفسیر نتیجه را دشوار میکند. برای BGE-M3 افزودن چنین دستوری به پرسش لازم نیست.
مقایسهٔ dense با dense به تفاوت دو مدل در بازیابی برداری نزدیکتر است. خروجی sparse در BGE-M3 به تطبیق واژگانی وزن میدهد و میتواند در کنار dense استفاده شود؛ multi-vector نیز متن را با چند بردار بازنمایی میکند. این حالتها را نباید با یک امتیاز واحد برای «BGE-M3» جمع کرد: ترکیب dense و sparse یک مسیر بازیابی متفاوت است و استفاده از multi-vector نیز محاسبه و نمایهٔ متفاوتی میخواهد. خروجی sparse معادل خودکار یک سامانهٔ BM25 با همان تنظیمات نیست.
نام محصول، شناسه، شمارهٔ ماده و صورتهای متفاوت نوشتن یک نام، نمونههاییاند که ارزش آزمودن تطبیق واژه را بالا میبرند. در فارسی، تفاوت «ی» و «ي»، «ک» و «ك» یا وجود نیمفاصله میتواند بر آنچه جستوجوی واژگانی میبیند اثر بگذارد. پاکسازی متن را برای همهٔ پیکربندیها یکسان ثبت کنید تا بهبود یا افت بازیابی را به مدل نسبت ندهید، در حالی که از تغییر پردازش متن آمده است.
آزمون محلی را چگونه قابل بازتولید کنید؟
مجموعهٔ ارزیابی را از پرسشهای واقعی محصول، یا نمونههای نمایندهٔ همان نوع پرسش، بسازید. پرسشهای معنایی، عبارتهای دقیق، نگارشهای متفاوت نامها و پرسشهایی را بگنجانید که پاسخشان در میانه یا انتهای سند قرار دارد. برای هر پرسش، شناسهٔ بخشهای مرتبط را پیش از اجرای مدل ثبت کنید. اگر پاسخ از چند بخش تشکیل میشود، روشن کنید کدام بخشها لازماند؛ تغییر این داوری پس از دیدن رتبهبندی، مقایسه را مخدوش میکند.
- نسخهٔ اسناد، قواعد پاکسازی، مرز بخشها، فهرست پرسشها و بخشهای مرتبط را ثابت نگه دارید. نسخهٔ مدل، قالب پرسش E5، طول ورودی و روش ساخت بردار را هم ثبت کنید تا اجرای بعدی همان شرایط را داشته باشد.
- ابتدا E5 و حالت dense در BGE-M3 را با نمایههای جدا و تعداد نتایج یکسان اجرا کنید. سپس ترکیب dense و sparse در BGE-M3 را بهعنوان آزمایش مستقلی اضافه کنید. اگر از بازچینی نتایج استفاده میکنید، جایگاه بخشهای مرتبط را پیش و پس از آن جداگانه گزارش کنید.
- برای هر پرسش، Recall@k را سهم بخشهای مرتبطی حساب کنید که در میان k نتیجهٔ نخست پیدا شدهاند و سپس میانگین پرسشها را بگیرید. وقتی فقط یک بخش مرتبط برای هر پرسش تعریف شده باشد، این معیار به سهم پرسشهایی تبدیل میشود که پاسخشان در نتایج نخست دیده شده است. مقدار k را با تعداد بخشهایی هماهنگ کنید که واقعاً به مرحلهٔ تولید پاسخ میرسند.
- در کنار کیفیت، زمان ساخت بردارها، زمان پاسخ جستوجو و اندازهٔ نمایه را در محیط یکسان اندازه بگیرید. مسیر ترکیبی ممکن است کیفیت بیشتری بدهد، اما انتخاب عملی به هزینهٔ همان پیکربندی در حجم اسناد و ترافیک محصول بستگی دارد.
نتایج را برای انواع پرسش جدا نگه دارید. میانگین خوب میتواند افت بازیابی نامهای دقیق یا بخشهای بلند را بپوشاند؛ در مقابل، برتری روی یک دستهٔ کمکاربرد شاید ارزش پیچیدگی بیشتر را نداشته باشد. Recall@k رسیدن شواهد به مرحلهٔ تولید را میسنجد و کیفیت پاسخ تولیدشده پرسش دیگری است؛ ارزیابی بازیابی در RAG به تفکیک این دو مرحله مربوط است.
اگر E5 با بخشهای کوتاه و قالب درست پرسش، بخشهای مرتبط را در بودجهٔ زمان و نمایهٔ محصول پیدا میکند، امتیاز نزدیک PTEB بهتنهایی دلیلی برای پیچیدهتر کردن مسیر نیست. اگر پاسخ به زمینهٔ بلند وابسته است یا تطبیق واژه در پرسشهای مهم محصول بخشهای بیشتری را برمیگرداند، پیکربندی مناسب BGE-M3 میتواند انتخاب بهتری باشد. داوری باید بر نتیجهٔ همان ترکیب مدل، بخشبندی و روش بازیابی انجام شود که قرار است در محصول اجرا شود.
بیشتر بخوانید:
مقالات مرتبط


Qdrant یا Weaviate؛ تأخیر کمتر همیشه بازیابی بهتر نیست

GraphRAG یا Vector RAG؛ گراف فقط در پرسشهای چندمرحلهای جلو میافتد

pgvector یا Pinecone؛ دیتابیس دوم فقط وقتی مقیاس آن را توجیه کند

RAG یا پنجرهٔ زمینهٔ بلند؛ اسناد بیشتر همیشه پاسخ بهتر نمیسازند

RAG را درست ارزیابی کنید؛ یک امتیاز خوب میتواند خطای بازیابی را پنهان کند
عضویت در خبرنامه
تازهترین اخبار Web3، هوش مصنوعی و رمزارز را مستقیم در صندوق ایمیل خود دریافت کنید.