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

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

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

اندازه و تغییر مجموعه چه اثری دارند؟

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

راهنمای Claude Projects می‌گوید وقتی دانش پروژه به سقف پنجرهٔ زمینه نزدیک می‌شود، حالت RAG به‌طور خودکار فعال می‌شود و ظرفیت دانش پروژه را تا ۱۰ برابر افزایش می‌دهد. این عدد به قابلیت همان محصول تعلق دارد، نه به همهٔ پیاده‌سازی‌های RAG. در این حالت، سامانه به‌جای بارگذاری هم‌زمان همهٔ محتوای پروژه، اطلاعات مرتبط را هنگام پاسخ بازیابی می‌کند.

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

چه زمانی متن کامل به پاسخ کمک می‌کند؟

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

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

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

RAG کجا صرفه دارد و کجا شاهد را از دست می‌دهد؟

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

نقطهٔ ضعف، پیدا نشدن شاهد یا جداشدن قطعه از زمینهٔ سند است. عبارتی مانند «این استثنا از ماه بعد اعمال می‌شود» بدون نام سند، موضوع و نسخه ممکن است هم برای جست‌وجو مبهم باشد و هم برای مدل. در آزمایش بازیابی زمینه‌مند Anthropic، ترکیب توضیح زمینهٔ قطعه با جست‌وجوی معنایی و BM25، نرخ ناکامی در یافتن شاهد میان ۲۰ قطعهٔ نخست را در پیکربندی گزارش‌شده از ۵٫۷ به ۲٫۹ درصد رساند. این سنجه دربارهٔ بازیابی شاهد است؛ درست بودن پاسخ نهایی را اندازه نمی‌گیرد.

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

چه وقت مسیر ترکیبی لازم می‌شود؟

وقتی بیشتر پرسش‌ها موضعی‌اند اما بخشی از آن‌ها به ارتباط میان اسناد نیاز دارند، یک مسیر ثابت یا بیش از حد پرهزینه می‌شود یا گاهی شاهد را جا می‌گذارد. در مطالعهٔ مقایسه‌ای روی چند مجموعه‌داده و سه مدل، زمینهٔ بلند با منابع کافی در میانگین عملکرد از RAG پیش افتاد و RAG هزینهٔ کمتری داشت؛ نویسندگان روش ترکیبی Self-Route را پیشنهاد کردند که با کاهش هزینه، عملکردی نزدیک به زمینهٔ بلند به دست آورد. این نتیجه به مدل‌ها، داده‌ها و روش بازیابی همان مطالعه مربوط است.

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

درخت تصمیم برای معماری و هزینه

انتخاب را می‌توان از متنِ موردنیاز هر پرسش آغاز کرد، سپس تغییرپذیری مجموعه و بودجه را وارد کرد. شاخه‌های زیر قاعدهٔ قطعی دربارهٔ تعداد اسناد نیستند؛ نقطهٔ شروعی برای طراحی سامانه با همان نوع پرسش‌اند:

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

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

بیشتر بخوانید:

• GPT-6 Sol یا Luna؛ کیفیت بیشتر ارزش هزینهٔ ۲۰ برابری را دارد؟