آموزش جامع RAG از صفر تا پروداکشن – فصل ۲: RAG چیست؟ به زبان ساده

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

حالا سوال اینه که راه‌حلش دقیقاً چیه. اسمش RAG‌ هست. بذار ببینیم این اسم عجیب از کجا اومده و چرا دقیقاً همون گره‌ای رو باز می‌کنه که توی اون پروژه گیرش کرده بودیم.

Retrieval-Augmented Generation از سه کلمه ساخته شده، و خبر خوب اینه که هر سه‌تاش دقیقاً همون کاری رو می‌کنن که اسم‌شون می‌گه. هیچ استعاره‌ی پیچیده‌ای پشتش نیست:

• Retrieval، یعنی بازیابی. قبل از اینکه مدل حتی شروع کنه به جواب دادن، سیستم می‌ره توی پایگاه دانش شما و مرتبط‌ترین تکه‌های اطلاعات رو پیدا می‌کنه. نه همه‌ی مستندات، فقط اون چند پاراگرافی که واقعاً به سوال کاربر ربط دارن. همون جایی که سیاست مرجوعی واقعی توش نوشته شده.
• Augmented، یعنی تزریق‌شده. اون تکه‌های پیدا شده رو می‌چسبونی به پرامپتی که قراره به مدل بدی. انگار داری قبل از سوال، یه برگه تقلب قانونی می‌ذاری جلوی چشمش.
• Generation، یعنی تولید. حالا مدل، با سند واقعی جلوی چشمش، جواب نهایی رو می‌نویسه. دیگه از حفظ و از الگوهای عمومی جواب نمی‌ده؛ از چیزی جواب می‌ده که خودت بهش دادی.

همین. کل RAG همینه. بقیه‌ی چیزایی که توی این مقاله می‌خونیم، بهینه‌سازی و سخت‌کاری همین سه مرحله‌ست، نه یه مفهوم جدید که بخواد مغزت رو از نو سیم‌کشی کنه.

حلقه‌ای که برای هر سوال از نو می‌چرخه

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

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

سه رویکرد رقیب: کدوم رو کی انتخاب کنیم؟

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

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

دانش‌آموز دوم، همون Fine-Tuningه. چند ماه می‌فرستیش کلاس تقویتی فشرده تا خودِ دانشش از درون عوض بشه. اثرش عمیقه و موندگار، ولی وقت‌گیره، پرهزینه‌ست، و اگه هفته‌ی بعد منبع امتحان عوض بشه، باید دوباره بفرستیش کلاس.

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

(اگه دیاگرام فنی این مقایسه رو می‌خوای، همون تصویر پایانی فصل ۱ رو دوباره نگاه کن؛ همون سه ستون Prompt Engineering، Fine-Tuning و RAG که RAG با کادر سبز مشخص شده بود. اینجا تکرارش نمی‌کنم که صفحه شلوغ نشه.)

یه چیز مهم که خیلیا اشتباه می‌فهمندش: این سه تا دشمن همدیگه نیستن. توی پروژه‌های واقعی، مخصوصاً پروژه‌های جدی، Fine-Tuning و RAG اغلب کنار هم می‌شینن. یکی لحن و رفتار و سبک جواب دادن مدل رو می‌سازه، اون یکی دانش لحظه‌ای و خصوصی رو موقع پرسش تزریق می‌کنه. جدول زیر تفاوت عملی‌شون رو، بدون تعارف، نشون می‌ده:

RAG در برابر کانتکست میلیون‌توکنی: پس چرا اصلاً زحمت بکشیم؟

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

سوال منطقیه. ولی جوابش، حداقل تا سال ۲۰۲۶، روشنه. چند تحلیل مستقل عدد دقیق‌شون با هم فرق می‌کنه، ولی همه روی یه جهت مشترک توافق دارن:

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

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

از نظر دقت، قضیه حتی جالب‌تره. تست‌های استاندارد نشون می‌دن مدل‌ها معمولاً فقط حدود ۶۰ تا ۰ درصد ظرفیت مؤثر کانتکست‌شون رو واقعاً درست به‌کار می‌گیرن. هرچی پرامپت طولانی‌تر بشه، احتمال اینکه یه واقعیت مهم وسطش گم بشه و مدل ازش رد بشه، بیشتر می‌شه. به این پدیده میگن «گم شدن در وسط»، و دقیقاً همون چیزیه که RAG با کوتاه کردن کانتکست به تکه‌های مرتبط، دورش می‌زنه.

نتیجه‌ی عملی؟ استفاده از RAG بین ۲۰۲۴ تا ۲۰۲۶ نه‌تنها کم نشده، بلکه به‌طور چشمگیری بیشتر هم شده، چون اقتصادش توی مقیاس بزرگ کلاً به نفع بازیابیه. و الگوی غالب پروداکشن در ۲۰۲۶ نه RAG خالصه و نه کانتکست خالص، بلکه ترکیبی از هر دو: اول با بازیابی زیرمجموعه‌ی مرتبط رو پیدا می‌کنی، بعد همون زیرمجموعه‌ی کوچیک رو با یه مدل کانتکست‌بلند عمیق‌تر تحلیل می‌کنی.

پس چیزی که داری یاد می‌گیری نه یه مهارت منسوخ‌شدنیه، نه یه انتخاب همه‌ یا‌ هیچ. پایه‌ی همون ترکیبیه که الان توی پروداکشن داره برنده می‌شه، و همون چیزیه که اگر اون روز توی پروژه‌ی چت‌بات بلد بودم، اون تیکت بحران اصلاً ساخته نمی‌شد.

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