RAG چیست؟ راهنمای کامل هوش مصنوعی، نحوه کار، کاربردها و مزایا و معایب RAG

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

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

RAG چیست؟

برای درک این موضوع که Retrieval Augmented Generation چیست، کافی است به شیوۀ کار یک متخصص فکر کنیم. وقتی او برای پاسخ‌دادن به جزئیات دقیق، عدد یا سند نیاز دارد، فقط به حافظۀ خود تکیه نمی‌کند و سراغ منبع معتبر می‌رود. RAG همین الگو را برای مدل‌های زبانی پیاده می‌کند: ابتدا اطلاعات مرتبط را پیدا می‌کند و سپس مدل با استفاده از همان اطلاعات پاسخ را می‌سازد. از نظر فنی، RAG یک الگوی معماری نرم‌افزار (Software Architecture Pattern) است، نه یک الگوریتم مستقل یادگیری ماشین.

این ایده در سال ۲۰۲۰ با مقاله پاتریک لوئیس و همکارانش مطرح شد و بعدتر به یکی از رویکردهای مهم در توسعۀ سیستم‌های مبتنی بر مدل‌های زبانی تبدیل شد. در فارسی، Retrieval Augmented Generation را معمولاً «تولید افزوده‌شده با بازیابی» یا «تولید تقویت‌شده با بازیابی» ترجمه می‌کنند. در عمل، این معماری به سیستم‌های هوش مصنوعی مولد (Generative AI) امکان می‌دهد پیش از تولید پاسخ، اسناد یا پایگاه دانش مشخصی را بررسی کنند. بنابراین پاسخ مدل می‌تواند علاوه بر دانش آموزشی خود، به اطلاعاتی متکی باشد که از منبعی مشخص بازیابی شده‌اند.

دلیل پیدایش معماری RAG

پیدایش RAG را می‌توان نتیجۀ دو محدودیت مهم مدل‌های زبانی دانست. محدودیت اول، احتمال تولید اطلاعات نادرست یا ساختگی است؛ پدیده‌ای که با عنوان توهم هوش مصنوعی (AI Hallucination) شناخته می‌شود. وقتی مدل اطلاعات کافی برای پاسخ‌دادن ندارد، ممکن است متنی تولید کند که از نظر زبانی قانع‌کننده است، اما با واقعیت هم‌خوانی ندارد. RAG با افزودن مرحلۀ بازیابی، اطلاعات مرتبط را پیش از تولید پاسخ در اختیار مدل می‌گذارد و از این راه احتمال چنین خطاهایی را کاهش می‌دهد.

محدودیت دوم به به‌روزبودن اطلاعات مربوط است. آموزش دوبارۀ مدل‌های پایه با هر تغییر جدید، زمان‌بر و پرهزینه است و مدل‌ها نیز معمولاً تاریخ قطع دانش (Knowledge Cutoff) دارند. در RAG لازم نیست برای هر تغییر، خود مدل دوباره آموزش ببیند؛ کافی است منبع دادۀ به‌روزرسانی شود تا اطلاعات تازه در زمان پاسخ‌گویی در دسترس سیستم قرار بگیرند.

سیستم RAG چگونه کار می‌کند؟

فرایند RAG دو بخش به‌هم‌پیوسته دارد: اول بازیابی اطلاعات و دوم تولید پاسخ. ابتدا سیستم در میان داده‌های موجود جست‌وجو می‌کند تا بخش‌هایی را پیدا کند که بیشترین ارتباط را با سؤال کاربر دارند. سپس همان بخش‌ها، همراه با سؤال، به مدل زبانی داده می‌شوند تا پاسخ نهایی شکل بگیرد.

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

مرحلۀ بازیابی اطلاعات از پایگاه داده

پیش از آنکه سیستم بتواند در اسناد جست‌وجو کند، باید داده‌ها برای بازیابی آماده شوند. معمولاً متن‌های طولانی در مرحلۀ Chunking به بخش‌های کوچک‌تر و معنادار تقسیم می‌شوند؛ سپس یک مدل Embedding هر بخش را به برداری عددی تبدیل می‌کند و این بردارها در پایگاه دادۀ برداری (Vector Database) ذخیره می‌شوند. چنین ساختاری به سیستم اجازه می‌دهد علاوه بر تطابق واژه‌ها، شباهت معنایی میان سؤال کاربر و بخش‌های مختلف اسناد را نیز پیدا کند.

وقتی کاربر سؤالش را مطرح می‌کند، همان سؤال نیز به بردار تبدیل می‌شود و سیستم بخش‌هایی از اسناد را که از نظر معنایی نزدیک‌ترند بازیابی می‌کند. در پیاده‌سازی‌های پیشرفته‌تر، مرحلۀ دیگری به نام رتبه‌بندی مجدد (Re-ranker / Ranker) به این فرایند اضافه می‌شود. ری‌رنکر نتایج اولیه را دوباره بررسی و مرتب می‌کند تا مرتبط‌ترین بخش‌ها به پنجرۀ زمینۀ (Context Window) مدل زبانی برسند. این مرحله در واقع پلی است میان جست‌وجوی اولیه و تولید پاسخ.

مرحلۀ تولید متن توسط مدل زبانی

پس از انتخاب اطلاعات مرتبط، خروجی مرحلۀ بازیابی به ورودی مدل زبانی تبدیل می‌شود. در اینجا مهندسی پرامپت (Prompt Engineering) اهمیت پیدا می‌کند؛ چون سیستم باید سؤال کاربر و متن‌های بازیابی‌شده را به شکلی روشن و ساختاریافته کنار هم قرار دهد و مشخص کند پاسخ بر چه اساسی ساخته شود.

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

چرا به فناوری RAG نیاز داریم؟

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

کاربرد مهم دیگر RAG، ساخت پاسخ‌هایی است که بتوان مبنای آن‌ها را بررسی کرد. برای مثال، هنگام تحلیل قراردادهای حقوقی، مدل می‌تواند پاسخ را با تکیه بر بندهای مشخصی از سند تولید کند تا کاربر امکان راستی‌آزمایی داشته باشد. به‌طور خلاصه، مهم‌ترین دلایل استفاده از معماری RAG عبارت‌اند از:
● کاهش نیاز به آموزش مجدد و مداوم مدل‌های زبانی (Pre-training).
● شخصی‌سازی پاسخ‌ها بر اساس داده‌ها و لحن اختصاصی سازمان.
● امکان ارجاع به منابع و بررسی مبنای پاسخ‌های هوش مصنوعی.
● کاهش هزینۀ پردازشی در مقایسه با آموزش دوبارۀ مدل پایه.

انواع کاربرد RAG در کسب‌وکارها کدامند؟

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

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

مزایای استفاده از RAG

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

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

معایب و چالش‌های پیاده‌سازی RAG

همین چندمرحله‌ای بودن RAG، در کنار مزایای آن، پیچیدگی و هزینۀ پردازشی بیشتری هم ایجاد می‌کند. یکی از پیامدهای این موضوع تأخیر (Latency) در پاسخ‌گویی است؛ زیرا سؤال باید به بردار تبدیل شود، پایگاه داده جست‌وجو شود، نتایج مناسب انتخاب یا رتبه‌بندی شوند و سپس اطلاعات به مدل زبانی برسند. در نتیجه، پاسخ‌گویی ممکن است نسبت به یک چت‌بات ساده زمان بیشتری ببرد.

چالش مهم دیگر، کیفیت داده‌های منبع است. اصل «Garbage In, Garbage Out» در RAG کاملاً صدق می‌کند: اگر اسناد اولیه متناقض، پرخطا یا آکنده از اطلاعات نامرتبط باشند، مرحلۀ بازیابی نیز همان ضعف‌ها را با خود به مرحله تولید پاسخ می‌برد. بنابراین پاکیزگی و کیفیت اسناد، بخشی از کیفیت خود سیستم است.

تفاوت فاین‌تیونینگ با RAG چیست؟

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

به همین دلیل، این دو روش الزاماً جایگزین یکدیگر نیستند. در یک پروژه می‌توان بسته به نیاز، RAG را در کنار فاین‌تیونینگ، مهندسی پرامپت (Prompt Engineering) یا روش‌های دیگر به کار گرفت. انتخاب میان آن‌ها به این بستگی دارد که مسئلۀ اصلی پروژۀ «دانش» مدل است یا «رفتار» آن.

ابزارهای مورد نیاز برای ساخت RAG کدامند؟

وقتی اجزای فرایند RAG را کنار هم می‌گذاریم، مشخص می‌شود که برای پیاده‌سازی آن به چند ابزار نیاز داریم: یک مدل زبانی برای تولید پاسخ، یک مدل Embedding برای تبدیل متن به بردار و یک سیستم برداری برای ذخیره و بازیابی داده‌ها. فریم‌ورک‌هایی مانند LangChain ،LlamaIndex و Haystack نیز برای متصل‌کردن این اجزا و مدیریت جریان داده به کار می‌روند. انتخاب هر ابزار به حجم داده، نوع کاربرد و زیرساختی بستگی دارد که سیستم قرار است روی آن اجرا شود.

کاربرد پایگاه دادۀ برداری

پایگاه دادۀ برداری جایی است که بردارهای تولیدشده از اسناد ذخیره و جست‌وجو می‌شوند. ابزارهایی مانند Pinecone ،Milvus و Qdrant برای کار با مجموعه‌های بزرگ برداری طراحی شده‌اند. در زمان جست‌وجو، این پایگاه داده کمک می‌کند بخش‌هایی از اسناد پیدا شوند که از نظر معنایی بیشترین شباهت را با درخواست کاربر دارند. نتیجه این مرحله همان اطلاعاتی است که بعدتر به مدل زبانی داده می‌شود.

نقش مدل‌های تعبیه متن

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

سرور GPU چه تأثیری در پردازش سیستم‌های RAG دارد؟

پس از انتخاب نرم‌افزارها، مسئلۀ زیرساخت مطرح می‌شود. اینکه یک پروژۀ RAG به GPU نیاز دارد یا نه، به شیوۀ اجرای آن بستگی دارد. اگر مدل‌های زبانی متن‌باز (Local LLMs) روی سرورهای خود سازمان اجرا شوند یا حجم زیادی از اسناد به‌طور مداوم برای Embedding و پردازش آماده شوند، GPU می‌تواند سرعت محاسبات موازی و عملیات ماتریسی را به‌طور محسوسی افزایش دهد.

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

کاربرد RAG برای متن فارسی و کاربر ایرانی

در پروژه‌های فارسی، علاوه بر اجزای اصلی RAG باید به کیفیت پردازش زبان هم توجه کرد. ساختار زبان فارسی، کیفیت مدل‌های چندزبانه و محدودیت دسترسی به بعضی APIهای خارجی می‌توانند بر انتخاب ابزار و معماری اثر بگذارند. به همین دلیل، برخی کسب‌وکارها برای کاهش وابستگی به سرویس‌های خارجی یا داشتن کنترل بیشتر بر داده‌ها، از مدل‌های متن‌باز و اجرای محلی استفاده می‌کنند.
پیش‌پردازش متن در اینجا اهمیت ویژه‌ای دارد. یکدست‌کردن فاصله و نیم‌فاصله، شکل نویسه‌ها و سایر جزئیات نوشتاری پیش از Chunking می‌تواند بازیابی را دقیق‌تر کند. در کنار آن، مدل Embedding باید درک مناسبی از فارسی داشته باشد؛ در غیر این صورت، حتی اگر بقیۀ اجزای سیستم درست طراحی شده باشند، جست‌وجوی معنایی نتیجۀ مطلوبی نخواهد داد.

آیندۀ تکنولوژی RAG در توسعۀ هوش مصنوعی چگونه است؟

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

• Self-RAG: پاسخ و فرایند بازیابی را ارزیابی می‌کند و در صورت نیاز آن‌ها را اصلاح می‌کند.
• Corrective RAG یا CRAG: کیفیت اطلاعات بازیابی‌شده را می‌سنجد و اگر داده‌ها کافی نباشند، مسیر بازیابی را تغییر می‌دهد یا جست‌وجوی دیگری انجام می‌دهد.
• HyDE: ابتدا یک پاسخ یا سند فرضی تولید می‌کند و بعد از آن برای یافتن اسناد مشابه در پایگاه داده کمک می‌گیرد.

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

کلام آخر

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

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

سوالات متداول

آیا RAG مشکل توهم مدل‌های زبانی را به‌طور کامل حل می‌کند؟

آیا پیاده‌سازی RAG هزینۀ بالایی دارد؟

آیا اجرای RAG بدون کارت گرافیک (GPU) امکان‌پذیر است؟

آیا سیستم RAG از متون و زبان فارسی به‌خوبی پشتیبانی می‌کند؟

در معماری RAG بهترین مدل زبانی کدام است؟