بازیابی ترکیبی در RAG؛ از بخش‌بندی تا رتبه‌بندی مجدد

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

منظور از بازیابی ترکیبی، جمع کردن چند جست‌وجوی بی‌هدف نیست. هر مسیر باید ضعف مشخصی از مسیر دیگر را پوشش دهد و سود آن با دادهٔ پروژه سنجیده شود. همچنین نتیجهٔ نهایی باید به منبع و مجوز قابل تشخیص بازگردد؛ افزایش تعداد نتایج، بدون حفظ این پیوند، کیفیت عملیاتی ایجاد نمی‌کند.

چرا جست‌وجوی معنایی به‌تنهایی کافی نیست؟

نمایش برداری، متن و پرسش را به فضایی می‌برد که شباهت معنایی در آن قابل مقایسه باشد. پژوهش Dense Passage Retrieval نمونه‌ای از استفاده از نمایش‌های متراکم برای یافتن متن مرتبط است. ۱ این مسیر برای عبارت‌های متفاوت با مفهوم نزدیک مفید است؛ اما از این ویژگی نباید نتیجه گرفت که هر شناسه یا عدد را نیز دقیق پیدا می‌کند.

در سناریوی طراحی یک دستیار محصول، سؤال «چگونه حساب را ببندم؟» ممکن است با سند «غیرفعال‌سازی کاربر» مرتبط باشد. اینجا شباهت معنایی کمک می‌کند. در مقابل، سؤال دربارهٔ خطای «E-407» یا مدل «AX-12» به حفظ دقیق شناسه وابسته است. یک سند از نظر موضوعی نزدیک، جای سند همان شناسه را نمی‌گیرد. بنابراین مجموعهٔ آزمون باید هر دو گروه را داشته باشد.

سهم جست‌وجوی واژگانی در معماری چیست؟

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

برای فارسی، همین بخش به بررسی جداگانه نیاز دارد: «ی» و «ک» عربی و فارسی، نیم‌فاصله، عدد فارسی و لاتین و شکل‌های مختلف یک اصطلاح ممکن است نتیجه را تغییر دهند. متن نرمال‌شده برای جست‌وجو مفید است، ولی متن اصلی باید برای نمایش و استناد حفظ شود. به‌ویژه در کد، نام خاص یا نقل دقیق، تغییر بی‌رویهٔ متن می‌تواند اطلاعات معنادار را از بین ببرد.

ترکیب نتایج: امتیازها را بی‌دلیل جمع نکنید

امتیاز دو موتور الزاماً مقیاس یکسان ندارد. عدد بالاتر در جست‌وجوی برداری و عدد بالاتر در جست‌وجوی واژگانی ممکن است معنای متفاوتی داشته باشند. به همین دلیل، ادغام باید روش مشخصی داشته باشد. ادغام مبتنی بر رتبه مانند Reciprocal Rank Fusion یکی از گزینه‌های قابل بررسی است؛ در آن، جایگاه نتیجه در فهرست‌ها اهمیت دارد، نه مقایسهٔ مستقیم امتیازهای خام. ۲

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

BM25 و RRF را در دو مرحلهٔ متفاوت ببینید

BM25 یک روش امتیازدهی واژگانی است: حضور واژهٔ پرسش، میزان تکرار آن و طول سند در امتیاز اثر دارند. پارامتر k1 بر اشباع اثر تکرار واژه و پارامتر b بر نرمال‌سازی طول سند اثر می‌گذارد. این پارامترها را نباید به‌جای تنظیمات مدل برداری به کار برد. همچنین هر قابلیت جست‌وجوی متنی در پایگاه داده، خودبه‌خود همان امتیازدهی BM25 را اجرا نمی‌کند؛ روش واقعی موتور باید مشخص باشد. ۶

RRF پس از تولید فهرست‌ها عمل می‌کند. در شکل ساده و با وزن برابر، سهم هر نتیجه از هر فهرست برابر معکوس جمع یک ثابت و رتبهٔ آن است؛ سند غایب از یک فهرست، از همان فهرست سهمی نمی‌گیرد. ۲

RRF(document) = sum(1 / (rank_constant + rank_in_list))

مثال صرفاً آموزشی: با ثابت ۶۰، سندی با رتبه‌های ۱ و ۱۰، امتیاز 1/61 + 1/70 می‌گیرد. سند دیگری با رتبهٔ ۲ در فقط یک فهرست، امتیاز 1/62 دارد. بنابراین توافق دو مسیر می‌تواند نتیجه را بالا بیاورد، حتی اگر در هیچ مسیر دیگری امتیاز خام قابل مقایسه‌ای نداشته باشد. اندازهٔ پنجرهٔ نامزدها، حذف تکرار بر اساس شناسهٔ قطعهٔ مادر و اعمال مجوز، همچنان باید جدا طراحی شوند؛ ادغام رتبه‌ها این کارها را جایگزین نمی‌کند.

مرز قطعه از تعداد توکن مهم‌تر است

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

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

Late Chunking ترتیب معمولِ «بخش‌بندی و سپس ساخت بردار» را بازنگری می‌کند: متن ابتدا در زمینهٔ بلندتر پردازش می‌شود و نمایش قطعه از آن به دست می‌آید. این ایده به توانایی مدل embedding و محدودیت طول ورودی وابسته است؛ یک گزینهٔ مستقل از مدل برای همهٔ سامانه‌ها نیست. ۳

الگوی چهار نمایه چگونه کار می‌کند؟

در الگوی پیشنهادی RAGHUB، برای یک قطعهٔ اصلی چهار نمای قابل جست‌وجو در نظر می‌گیریم. این یک تصمیم طراحی در معماری ماست و باید به‌صورت آزمایشی با خط مبنا مقایسه شود؛ آن را نباید قانون ثابت برای همهٔ محصولات دانست. نکتهٔ اصلی، بازگشت همهٔ نماها به یک شناسهٔ مادر و یک سیاست دسترسی است.

نمای پرسش می‌تواند فاصلهٔ زبان کاربر و سند را کم کند. برای مثال، یک بند رسمی دربارهٔ «فسخ عضویت» ممکن است پاسخ سؤال روزمرهٔ «چطور اشتراکم را تمام کنم؟» باشد. اما پرسش مصنوعی ممکن است بیش از محتوای سند ادعا کند. بنابراین متن تولیدشده نباید خودش مرجع پاسخ شود؛ فقط راهی برای پیدا کردن شاهد اصلی است.

زیرقطعه نیز نباید دسترسی تازه‌ای بسازد. اگر سند مادر محرمانه است، خلاصه و سؤال مصنوعی آن هم می‌توانند اطلاعات حساس داشته باشند. مجوز باید روی همهٔ نماها حمل شود و پیش از برگشت نتیجه اعمال گردد. حذف یک سند هم باید همهٔ نماهای مربوط را از دسترس خارج کند، نه فقط متن اصلی را.

رتبه‌بندی مجدد کجا ارزش دارد؟

بازیابی اولیه معمولاً می‌کوشد نامزدهای مرتبط را با هزینهٔ قابل کنترل پیدا کند. رتبه‌بندی مجدد، مرحلهٔ محدودتری است که ارتباط سؤال و هر نامزد را دقیق‌تر بررسی می‌کند. در این نقطه می‌توان نتیجه‌ای را که از نظر موضوعی نزدیک است ولی پاسخ سؤال را ندارد، پایین‌تر برد. با این حال، این مرحله نیز هزینه و زمان دارد.

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

افزودن زمینه به قطعه، چه مشکلی را هدف می‌گیرد؟

گاهی یک قطعه دربارهٔ «این محصول» یا «سه‌ماههٔ دوم» حرف می‌زند، اما نام محصول و سال در قسمت دیگری از سند است. Contextual Retrieval در معرفی Anthropic، افزودن زمینهٔ توضیحیِ کوتاه به قطعه پیش از ساخت نمایهٔ برداری و واژگانی را بررسی می‌کند. نتیجه‌های گزارش‌شده به آزمایش همان منبع مربوط‌اند و نباید به‌صورت تضمین عملکرد یک پروژه نقل شوند. ۴

در طراحی محصول، می‌توان ابتدا روش ساده‌تری را هم سنجید: آیا نگه داشتن عنوان، مسیر بخش و نسخهٔ سند کنار قطعه مشکل را حل می‌کند؟ اگر پاسخ مثبت است، تولید زمینهٔ اضافی شاید ضروری نباشد. اگر متن توضیحی با مدل ساخته می‌شود، باید از نظر صحت، هزینه و به‌روزرسانی کنترل شود تا توضیح نادرست وارد نمایه نشود.

بازنویسی سؤال و HyDE چه زمانی مطرح می‌شوند؟

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

HyDE از یک متن فرضیِ تولیدشده برای ساخت نمایش بازیابی استفاده می‌کند تا به سندهای واقعی برسد. متن فرضی ممکن است جزئیات نادرست داشته باشد و خودش شاهد پاسخ محسوب نمی‌شود. ۵ در آزمون، بررسی کنید آیا این مسیر نسبت به خود سؤال، شواهد معتبرتری پیدا می‌کند یا فقط خطای پیش‌فرض را به جست‌وجو منتقل می‌کند.

یک برنامهٔ آزمایش کم‌ابهام

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

برای هر خطا، نمونهٔ سؤال، نامزدهای برگشتی، رتبهٔ شاهد درست و متن زمینهٔ نهایی را نگه دارید. اگر عدد کلی بهتر شد ولی سؤال‌های حساس به نسخه بدتر شدند، این یک بهبود بی‌قیدوشرط نیست. تصمیم انتشار باید به حساسیت گروه‌ها وابسته باشد. میانگین خوب نباید خطای پرخطر را مخفی کند.

در پایان، معماری را با هزینهٔ نگهداری بسنجید. هر نما، اتصال یا مدل تازه به به‌روزرسانی، حذف، مجوز و مشاهده‌پذیری نیاز دارد. بهترین ترکیب، معمولاً همان ترکیبی است که بهبود قابل اندازه‌گیری دارد و تیم می‌تواند آن را در طول زمان درست نگه دارد؛ نه ترکیبی که بیشترین نام فناوری را در نمودار معماری دارد.