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

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

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

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

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