پرش به محتوای اصلی

تولید تقویت‌شده با بازیابی برای وظایف NLP دانش‌محور

· زمان مطالعه 7 دقیقه
Mike Thrift
Mike Thrift
Marketing Manager

مقاله «تولید تقویت‌شده با بازیابی برای وظایف NLP دانش‌محور» نوشته لوئیس و همکاران (NeurIPS 2020) احتمالاً تأثیرگذارترین مقاله در نحوه معماری سیستم‌های هوش مصنوعی عملیاتی امروزی است. پنج سال پس از انتشار، این مقاله همچنان معیاری است که تقریباً هر سیستم زبانی مبتنی بر سند با آن سنجیده می‌شود. من اکنون آن را می‌خوانم زیرا هر چیزی در بک‌لاگ Bean Labs من — از پرسش و پاسخ دفتر کل گرفته تا توضیح ناهنجاری‌ها — در نهایت به مسئله بازیابی ختم می‌شود و می‌خواهم قبل از حرکت به سمت جانشینان آن، تصمیمات طراحی اولیه را به وضوح درک کنم.

مقاله

2026-05-17-rag-retrieval-augmented-generation-knowledge-intensive-nlp

مشکل اصلی که RAG به آن می‌پردازد این است که مدل‌های زبانی از پیش آموزش‌دیده، دانش را در زمان آموزش در وزن‌های خود حک می‌کنند و این باعث می‌شود که دانش ایستا، مبهم و بدون آموزش مجدد غیرقابل به‌روزرسانی باشد. لوئیس و همکاران یک معماری ترکیبی را پیشنهاد می‌کنند: یک حافظه پارامتریک (BART-large به عنوان تولیدکننده) جفت شده با یک حافظه غیرپارامتریک (یک شاخص متراکم FAISS بر روی ۲۱ میلیون قطعه ویکی‌پدیا) که توسط یک بازیاب آموزش‌دیده بر اساس «بازیابی متراکم قطعات» (DPR، کارپوخین و همکاران ۲۰۲۰) به هم متصل شده‌اند. در زمان استنتاج، مدل برترین قطعات مرتبط (K عدد) را بازیابی کرده و سپس برای تولید خروجی نهایی، روی آن‌ها حاشیه‌سازی (marginalize) می‌کند.

این مقاله دو نوع را معرفی می‌کند. RAG-Sequence یک بار بازیابی انجام می‌دهد و از همان مجموعه اسناد برای کل توالی تولید شده استفاده می‌کند — که منسجم‌تر اما کمتر تطبیق‌پذیر است. RAG-Token به مدل اجازه می‌دهد در هر مرحله تولید به سند بازیابی شده متفاوتی توجه کند و آن را قادر می‌سازد تا اطلاعات را از چندین منبع در میان جمله ترکیب کند. هر دو نوع، بازیاب و تولیدکننده را به طور مشترک در طول تنظیم دقیق (fine-tuning) آموزش می‌دهند، اگرچه کدگذار سند منجمد می‌شود تا از هزینه بازسازی شاخص FAISS در طول آموزش جلوگیری شود.

ایده‌های کلیدی

  • RAG-Sequence به امتیاز ۴۴.۵ در پاسخگویی دقیق (Exact Match) در Natural Questions، امتیاز ۵۶.۸ در TriviaQA و ۶۸.۰ در WebQuestions دست یافت که در زمان انتشار، پیشرفته‌ترین (SOTA) بود.
  • در پرسش و پاسخ انتزاعی MS-MARCO، مدل RAG-Sequence امتیاز ۴۰.۸ ROUGE-L را در مقابل ۳۸.۲ برای خط پایه فقط-BART کسب کرد — پیشرفتی اندک اما ثابت.
  • تولید سوالات Jeopardy: ارزیابان انسانی خروجی‌های RAG را در ۴۲.۷٪ موارد واقعی‌تر از BART دانستند (BART در ۷.۱٪ موارد واقعی‌تر بود).
  • در تایید واقعیت FEVER، مدل RAG بدون هیچ مهندسی خاصِ وظیفه به دقت سه‌طرفه ۷۲.۵٪ رسید (۴.۳ واحد کمتر از مدل تخصصی پیشرو).
  • منجمد کردن کدگذار سند در طول آموزش تنها حدود ۳ واحد امتیاز EM در NQ هزینه دارد (۴۴.۰ به ۴۱.۲)، که این رویکرد را به قیمت قدیمی شدن دانش شاخص، از نظر محاسباتی امکان‌پذیر می‌کند.
  • بازیابی متراکم (Dense retrieval) در تمام وظایف به جز FEVER از BM25 بهتر عمل می‌کند؛ در FEVER پرس‌وجوهای موجودیت‌محور به نفع همپوشانی کلمات هستند — سیگنالی ملموس که بازیابی پراکنده (sparse) همیشه ضعیف‌تر نیست.

چه چیزی پابرجا مانده است — و چه چیزی نه

بینش اساسی — جداسازی مخزن دانش از موتور استدلال — به خوبی در گذر زمان حفظ شده است. این کار به شما دانش قابل به‌روزرسانی (فقط شاخص‌گذاری مجدد کنید)، ارجاع به منبع (قطعات بازیابی شده قابل بازرسی هستند) را می‌دهد و در پرسش و پاسخ دامنه-باز، تولید و تایید واقعیت بدون معماری‌های خاصِ وظیفه تعمیم می‌یابد. این ویژگی‌ها در عمل هنوز بیش از اعداد خاص پاسخگویی دقیق (Exact Match) اهمیت دارند.

داوران NeurIPS درست می‌گفتند که نوآوری فنی محدود است. DPR و BART از قبل وجود داشتند؛ RAG یک یکپارچه‌سازی دقیق است، نه یک پیشرفت الگوریتمی بنیادی. تصمیم منجمد کردن کدگذار سند نیز مشکل ظریفی ایجاد می‌کند که مقاله تا حدودی از آن عبور می‌کند: شاخص یک بار ساخته می‌شود و به یک تصویر لحظه‌ای (snapshot) تبدیل می‌شود. هر واقعیتی که بعد از ساخت شاخص تغییر کند برای مدل نامرئی است. برای مجموعه‌های ایستا مانند پرونده‌های SEC، این قابل قبول است. برای سیستم‌های زنده — قیمت‌های لحظه‌ای، فیدهای تراکنش روزانه — این یک محدودیت معماری واقعی است، نه یک جزئیات جزئی.

یافته «فروپاشی بازیابی» (retrieval collapse) بیش از آنچه به آن توجه می‌شود، شایسته بررسی است. در وظایف تولید داستان، مدل یاد گرفت که اسناد بازیابی شده را کاملاً نادیده بگیرد و از حافظه پارامتریک تولید کند. مقاله اشاره می‌کند که این اتفاق زمانی می‌افتد که وظیفه «به دانش خاصی نیاز ندارد» اما مکانیسم آن را توضیح نمی‌دهد یا راهی اصولی برای تشخیص آن به متخصصان نمی‌دهد. عاملی که در حین عملکرد ظاهراً عادی، بی‌صدا بازیابی را متوقف می‌کند، دقیقاً همان حالت شکستی است که من را در سیستم‌های مالی عملیاتی نگران می‌کند.

ردپای حافظه نیز قابل توجه است: شاخص ویکی‌پدیا به تنهایی به حدود ۱۰۰ گیگابایت رم CPU نیاز دارد. مقاله این را به عنوان یک ویژگی مطرح می‌کند (حافظه غیرپارامتریک «به‌سرعت به‌روز می‌شود») اما این یک هزینه عملیاتی واقعی است که نحوه تکامل این تکنیک را در سال‌های بعد — به سمت شاخص‌های فشرده و بازیابی تقریبی — شکل داد.

چرا این برای هوش مصنوعی مالی اهمیت دارد

معماری بازیابی به طور طبیعی با ساختار مسئله Beancount مطابقت دارد. یک دفتر کل Beancount مجموعه‌ای بزرگ از اسناد است که فقط قابلیت افزودن (append-only) دارد و ورودی‌های فردی در آن به صورت معنایی به هم مرتبط هستند: یک هزینه قابل کسر مالیات به یک دسته اشاره می‌کند، یک دسته به یک قانون، و یک قانون به یک سال مالی. هیچ مدل پارامتریکی که روی داده‌های عمومی آموزش دیده باشد، نمودار حساب‌های خاص یک کاربر را نمی‌شناسد. جداسازی استدلال از دانش در RAG، آن را به پاسخ ساختاری درست تبدیل می‌کند: تولیدکننده را روی قالب‌های وظایف حسابداری تنظیم دقیق کنید، اما جستجوهای واقعیت را در شاخص واقعی دفتر کل کاربر مستقر کنید.

نگرانی عملی همان چیزی است که مقاله شناسایی کرده اما دست‌کم گرفته است: شاخص‌های قدیمی. اگر یک عامل Beancount از شاخصی که دیروز ساخته شده بازیابی انجام دهد، ممکن است تراکنش‌های امروز را از دست بدهد. شاخص‌گذاری تدریجی (Incremental indexing) و شاخص‌گذاری مجددِ تحریک‌شده هنگام نوشتن در دفتر کل باید از ابتدا بخشی از طراحی سیستم باشد، نه اینکه بعداً اضافه شود. نگرانی دیگر، دقت بازیابی روی داده‌های ساختاریافته است. RAG برای متن‌های ویکی‌پدیا طراحی شده بود. یک دفتر کل Beancount دارای بازه‌های زمانی، سلسله‌مراتب حساب‌ها و واحدهای پولی است که بازیاب‌های بهینه‌شده برای متن به طور بومی با آن‌ها برخورد نمی‌کنند. سوال «آیا LLMها می‌توانند روی داده‌های جدولی استدلال کنند» که قبلاً بررسی کردم، مستقیماً آنچه را که RAG می‌تواند به طور مفید بازیابی کند محدود می‌کند.

چه چیزی را در ادامه بخوانیم

  • Fusion-in-Decoder (FiD)، ایزاکارد و گریو ۲۰۲۰ (arXiv:2007.01282) — هر قطعه بازیابی شده را به طور مستقل پردازش کرده و در رمزگشا ترکیب می‌کند، و به امتیازات NQ بالاتری نسبت به RAG دست می‌یابد در حالی که از نظر معماری ساده‌تر است؛ ارزش درک کردن قبل از بکارگیری رویکرد خواندن مشترک RAG-Token را دارد.
  • FLARE: تولید تقویت‌شده با بازیابی فعال، جیانگ و همکاران ۲۰۲۳ (arXiv:2305.06983) — با پیش‌بینی زمانی که مدل در آستانه توهم است، در حین تولید به صورت در لحظه (on-demand) بازیابی می‌کند؛ طبیعی‌ترین گسترش ایده‌های RAG به سمت عوامل تطبیق‌پذیرتر.
  • «تنظیم دقیق یا بازیابی؟» اووادیا و همکاران ۲۰۲۳ (arXiv:2312.05934) — مقایسه سیستماتیک روش‌های تزریق دانش در وظایف مختلف؛ شواهد تجربی که قبل از تصمیم‌گیری در مورد اینکه آیا یک تولیدکننده خاصِ دفتر کل را تنظیم دقیق کنید یا فقط بازیابی را بهبود بخشید، به آن نیاز دارید.