انتخاب مدل Embedding و تلهٔ ناسازگاری ابعاد

یکی از رایج‌ترین اشتباه‌هایی که تیم‌ها هنگام ساخت یک سیستم RAG مرتکب می‌شوند، چیزی نیست که در کد دیده شود؛ در تصمیمی نامرئی اتفاق می‌افتد که هفته‌ها بعد خودش را به‌شکل نتایج جست‌وجوی بی‌معنا نشان می‌دهد: تغییر مدل embedding بعد از این‌که ایندکس با مدل قبلی ساخته شده. این مقاله همان تله را دقیق باز می‌کند و توضیح می‌دهد چرا انتخاب مدل embedding یک تصمیم یک‌باره نیست که بعداً بدون هزینه بشود عوضش کرد.

تلهٔ ناسازگاری ابعاد چیست؟

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

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

یک اصل ساده: بردارهایی که با دو مدل embedding متفاوت ساخته شده‌اند، حتی اگر ابعاد یکسانی داشته باشند، در یک فضای مشترک قابل مقایسه نیستند. مقایسهٔ آن‌ها با شباهت کسینوسی، عددی تولید می‌کند که هیچ معنای معناشناختی ندارد.

چطور از این تله دور بمانیم؟

راه‌حل اصلی این است که ابعاد و مدل embedding را به‌عنوان بخشی از قرارداد ایندکس در نظر بگیرید، نه یک جزئیات پیاده‌سازی فراموش‌شدنی. چند اقدام عملی:

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

معیارهایی که هنگام انتخاب مدل embedding باید در نظر بگیرید

انتخاب مدل embedding فقط دربارهٔ کیفیت جست‌وجو نیست؛ چند بُعد دیگر هم دخیل‌اند که معمولاً بعد از استقرار در تولید خودشان را نشان می‌دهند.

نسخهٔ مدل هم بخشی از هویت آن است

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

ابعاد ثابت، تصمیمی که باید از اول قفل شود

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

جمع‌بندی

• بردارهای ساخته‌شده با دو مدل embedding متفاوت، حتی با ابعاد یکسان، در یک فضای معنایی مشترک نیستند و مقایسه‌شان بی‌معناست.
• تغییر مدل embedding بدون بازسازی کامل ایندکس، باعث افت تدریجی و بی‌سروصدای کیفیت جست‌وجو می‌شود، نه خطای صریح.
• نام، نسخه و ابعاد مدل embedding را در متادیتای ایندکس ذخیره کنید تا هر ناسازگاری قابل ردیابی باشد.
• پیش از تغییر مدل، ایندکس را کامل از نو بسازید؛ ترکیب بردارهای دو مدل مختلف در یک کالکشن مجاز نیست.
• زبان فارسی، هزینهٔ ساخت embedding، و سازگاری با وکتور دیتابیس را همان ابتدای انتخاب مدل بسنجید، نه بعد از استقرار.