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

سیستم RAG چیست؟

مدل‌های زبانی بزرگ یا LLMها در سال‌های اخیر به یکی از مهم‌ترین فناوری‌های حوزه هوش مصنوعی تبدیل شده‌اند. مدل‌هایی مانند GPT می‌توانند متن تولید کنند، به پرسش‌ها پاسخ دهند، اطلاعات را خلاصه کنند و در بسیاری از وظایف زبانی عملکرد بسیار خوبی داشته باشند. با این حال، یک محدودیت مهم وجود دارد: یک مدل زبانی لزوماً به اطلاعات اختصاصی، جدید یا لحظه‌ای مورد نیاز کاربر دسترسی ندارد.
برای مثال فرض کنید یک شرکت هزاران سند داخلی، قرارداد، آیین‌نامه، مستندات فنی و اطلاعات محصول دارد و می‌خواهد یک چت‌بات هوشمند ایجاد کند که بتواند بر اساس همین اطلاعات به سؤالات کارکنان یا مشتریان پاسخ دهد. صرفاً استفاده از یک LLM عمومی نمی‌تواند تضمین کند که پاسخ‌ها بر اساس اسناد داخلی شرکت باشند.
اینجاست که RAG وارد می‌شود.
RAG مخفف Retrieval-Augmented Generation است و می‌توان آن را «تولید تقویت‌شده با بازیابی اطلاعات» ترجمه کرد. در یک سیستم RAG، قبل از اینکه مدل زبانی پاسخ نهایی را تولید کند، سیستم اطلاعات مرتبط را از یک یا چند منبع خارجی پیدا می‌کند و این اطلاعات را به عنوان Context در اختیار مدل قرار می‌دهد.
بنابراین، به زبان ساده می‌توان گفت:
RAG به LLM اجازه می‌دهد قبل از پاسخ دادن، اطلاعات مرتبط را از یک منبع خارجی پیدا کند و سپس پاسخ خود را بر اساس آن اطلاعات تولید کند.
این رویکرد باعث می‌شود بتوان از مدل‌های زبانی در سناریوهایی استفاده کرد که اطلاعات اختصاصی، سازمانی، تخصصی یا به‌روز اهمیت زیادی دارند.

چرا به سیستم RAG نیاز داریم؟

برای درک بهتر RAG، ابتدا باید محدودیت‌های مدل‌های زبانی را بشناسیم.
یک LLM بر اساس داده‌هایی که در فرآیند آموزش یا Fine-Tuning در اختیارش قرار گرفته‌اند، الگوهای زبانی و دانشی مختلفی را یاد می‌گیرد. اما این موضوع به این معنی نیست که مدل همیشه به جدیدترین اطلاعات یا تمام اطلاعات مورد نیاز یک کسب‌وکار دسترسی دارد.
فرض کنید یک فروشگاه آنلاین، اطلاعات هزاران محصول خود را در یک سیستم مدیریت محصولات نگهداری می‌کند. اگر کاربر از مدل بپرسد:
«آیا لپ‌تاپ مدل X در انبار موجود است و چه مشخصاتی دارد؟»
مدل زبانی عمومی احتمالاً چنین اطلاعاتی را نمی‌داند. حتی اگر مدل قبلاً درباره آن محصول اطلاعاتی داشته باشد، نمی‌توان تضمین کرد که اطلاعات آن با وضعیت فعلی فروشگاه یکسان باشد.
در RAG، مدل مجبور نیست این اطلاعات را از حافظه پارامتریک خود حدس بزند. سیستم ابتدا اطلاعات مرتبط را از منبع داده بازیابی می‌کند و سپس آن را در اختیار LLM قرار می‌دهد.
یکی دیگر از مشکلات LLMها Hallucination یا تولید اطلاعات نادرست و غیرواقعی است. RAG می‌تواند با فراهم کردن Context مرتبط و قابل استناد، احتمال چنین خطاهایی را در بسیاری از سناریوها کاهش دهد؛ البته RAG به‌تنهایی تضمین نمی‌کند که تمام پاسخ‌های مدل صحیح باشند.
بنابراین RAG را می‌توان راهکاری برای اتصال یک مدل زبانی به یک Knowledge Base خارجی در نظر گرفت.

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

فرآیند کلی یک سیستم RAG را می‌توان در دو بخش اصلی خلاصه کرد:
Retrieval و Generation
در مرحله Retrieval، سیستم اطلاعات مرتبط با سؤال کاربر را پیدا می‌کند.
در مرحله Generation، اطلاعات بازیابی‌شده به همراه سؤال کاربر در اختیار LLM قرار می‌گیرد تا پاسخ نهایی تولید شود.
یک جریان ساده را می‌توان این‌گونه نمایش داد:
User Query → Retrieval → Relevant Context → LLM → Generated Answer
اما در یک سیستم واقعی، پشت این فرآیند چندین مرحله مختلف وجود دارد.

مرحله اول: جمع‌آوری داده‌ها

اولین مرحله در ساخت سیستم RAG، مشخص کردن منابعی است که قرار است مدل از آن‌ها اطلاعات دریافت کند.
این منابع می‌توانند بسیار متنوع باشند. برای مثال:
اسناد PDF، فایل‌های Word، صفحات وب، مقالات، مستندات فنی، پایگاه‌های داده، فایل‌های متنی، سیستم‌های مدیریت دانش، تیکت‌های پشتیبانی، قراردادها و حتی APIهای مختلف می‌توانند به عنوان منبع داده استفاده شوند.
در یک سازمان ممکن است داده‌ها در چندین سیستم مختلف قرار داشته باشند. بنابراین طراحی لایه Data Ingestion یکی از بخش‌های مهم معماری RAG محسوب می‌شود.

مرحله دوم: پردازش و آماده‌سازی داده‌ها

داده خام معمولاً نمی‌تواند مستقیماً وارد سیستم Retrieval شود.
ابتدا باید اطلاعات استخراج، پاک‌سازی و استانداردسازی شوند. برای مثال ممکن است یک PDF شامل Header، Footer، شماره صفحه، جدول و متن‌های غیرضروری باشد.
اگر این اطلاعات بدون پردازش وارد سیستم شوند، کیفیت Retrieval کاهش پیدا می‌کند.
بنابراین معمولاً یک Pipeline پردازش داده ایجاد می‌شود که می‌تواند شامل استخراج متن، حذف اطلاعات غیرضروری، نرمال‌سازی، ساخت Metadata و تقسیم متن باشد.

مرحله سوم: Chunking چیست؟

یکی از مهم‌ترین مراحل در سیستم RAG، Chunking است.
فرض کنید یک فایل PDF شامل ۱۰۰ صفحه اطلاعات است. منطقی نیست که کل فایل را به عنوان یک واحد در اختیار سیستم Retrieval قرار دهیم.
بنابراین سند به قطعات کوچک‌تری تقسیم می‌شود که به آن‌ها Chunk گفته می‌شود.
برای مثال یک سند ممکن است به بخش‌هایی با اندازه مشخص تقسیم شود و هر بخش به صورت مستقل در سیستم ذخیره شود.
هدف از Chunking این است که وقتی کاربر سؤالی می‌پرسد، سیستم بتواند به جای برگرداندن یک سند بسیار بزرگ، دقیقاً بخش‌هایی را پیدا کند که بیشترین ارتباط را با سؤال دارند.
اندازه Chunk اهمیت زیادی دارد.
اگر Chunk بیش از حد بزرگ باشد، ممکن است اطلاعات نامرتبط زیادی همراه نتیجه Retrieval وارد Context مدل شود. اگر Chunk بیش از حد کوچک باشد، ممکن است ارتباط معنایی بین بخش‌های مختلف از بین برود.
در بسیاری از سیستم‌ها از Chunk Overlap نیز استفاده می‌شود. یعنی بخشی از متن بین دو Chunk مشترک باقی می‌ماند تا اطلاعاتی که در مرز بین دو قطعه قرار گرفته‌اند از بین نروند.
بنابراین Chunking را نباید صرفاً یک عملیات ساده برای تقسیم متن دانست؛ کیفیت این مرحله مستقیماً روی عملکرد Retrieval تأثیر می‌گذارد.

Embedding چیست؟

پس از آماده‌سازی و Chunk کردن داده‌ها، نوبت به تبدیل متن به یک نمایش عددی می‌رسد.
این کار توسط Embedding Model انجام می‌شود.
Embedding را می‌توان روشی برای تبدیل متن، جمله یا سند به یک بردار عددی دانست که ویژگی‌های معنایی آن متن را در فضای چندبعدی نمایش می‌دهد.
برای مثال دو جمله:
«چطور می‌توان سرور را ریستارت کرد؟»
و:
«روش راه‌اندازی مجدد سرور چیست؟»
از نظر لغات دقیقاً یکسان نیستند، اما از نظر معنا بسیار نزدیک‌اند.
مدل Embedding می‌تواند این شباهت معنایی را در فضای برداری نمایش دهد.
به این ترتیب سیستم RAG می‌تواند به جای اینکه فقط به دنبال تطابق دقیق کلمات باشد، به دنبال اطلاعاتی بگردد که از نظر معنایی با سؤال کاربر ارتباط دارند.

Vector Database چیست؟

پس از تولید Embedding برای Chunkها، این بردارها باید در محلی ذخیره شوند که امکان جست‌وجوی سریع و مؤثر بین آن‌ها وجود داشته باشد.
اینجاست که Vector Database یا پایگاه داده برداری وارد معماری RAG می‌شود.
Vector Database برای ذخیره و بازیابی داده‌های برداری طراحی شده است.
هر Chunk معمولاً همراه با Embedding و Metadata مربوط به خودش ذخیره می‌شود.
Metadata می‌تواند شامل اطلاعاتی مانند نام فایل، تاریخ ایجاد سند، دسته‌بندی، نویسنده، شناسه محصول یا واحد سازمانی باشد.
در زمان جست‌وجو، Embedding مربوط به سؤال کاربر با Embeddingهای ذخیره‌شده مقایسه می‌شود و نزدیک‌ترین موارد انتخاب می‌شوند.
از نمونه‌های شناخته‌شده Vector Database می‌توان به Qdrant، Pinecone، Weaviate، Milvus و Chroma اشاره کرد. همچنین PostgreSQL با افزونه pgvector نیز می‌تواند برای برخی معماری‌های RAG مورد استفاده قرار گیرد.

Retrieval در RAG چگونه انجام می‌شود؟

وقتی کاربر سؤال خود را وارد می‌کند، سیستم ابتدا Query را پردازش می‌کند.
برای مثال کاربر می‌پرسد:
«شرایط لغو سفارش چیست؟»
این Query به یک Embedding تبدیل می‌شود.
سپس سیستم این بردار را با بردارهای موجود در Vector Database مقایسه می‌کند.
در نتیجه، تعدادی از Chunkهایی که بیشترین شباهت معنایی را با سؤال دارند انتخاب می‌شوند.
این فرآیند را Retrieval می‌نامیم.
معمولاً سیستم فقط چند نتیجه برتر را انتخاب می‌کند. این مفهوم را می‌توان با پارامتر Top-K کنترل کرد.
اگر K برابر ۵ باشد، سیستم مثلاً پنج Chunk مرتبط‌تر را به عنوان Context انتخاب می‌کند.

Similarity Search چیست؟

برای پیدا کردن نزدیک‌ترین بردارها، سیستم باید میزان شباهت بین Query و داده‌های موجود را محاسبه کند.
یکی از معیارهای متداول، Cosine Similarity است.
این روش میزان شباهت جهت دو بردار را در فضای چندبعدی اندازه‌گیری می‌کند.
هرچه دو بردار از نظر معنایی نزدیک‌تر باشند، امتیاز شباهت آن‌ها بیشتر خواهد بود.
البته در سیستم‌های مدرن RAG روش Retrieval فقط به یک معیار شباهت ساده محدود نمی‌شود و می‌توان از روش‌های مختلف جست‌وجوی معنایی، Keyword Search، Hybrid Search و Reranking استفاده کرد.

Context چیست و چه نقشی در RAG دارد؟

بعد از Retrieval، سیستم تعدادی Chunk مرتبط پیدا کرده است.
این اطلاعات به عنوان Context در اختیار مدل زبانی قرار می‌گیرند.
در واقع مدل به جای اینکه صرفاً سؤال کاربر را دریافت کند، چیزی شبیه این ساختار را دریافت می‌کند:
System Instructions + Retrieved Context + User Query
مدل سپس بر اساس این اطلاعات پاسخ تولید می‌کند.
به همین دلیل کیفیت Context اهمیت بسیار زیادی دارد.
اگر Retrieval اطلاعات اشتباهی پیدا کند، حتی یک LLM قدرتمند هم ممکن است پاسخ نامناسبی تولید کند.
به همین دلیل یکی از اصول مهم در طراحی RAG این است:
کیفیت پاسخ نهایی تا حد زیادی به کیفیت Retrieval وابسته است.

معماری کامل سیستم RAG

یک معماری معمول RAG را می‌توان به دو مسیر اصلی تقسیم کرد.
در مسیر اول، داده‌ها وارد سیستم می‌شوند:
Data Sources → Document Processing → Chunking → Embedding → Vector Database
در مسیر دوم، سؤال کاربر پردازش می‌شود:
User Query → Query Embedding → Retrieval → Relevant Context → LLM → Final Answer
این دو مسیر در کنار یکدیگر سیستم RAG را تشکیل می‌دهند.
نکته مهم این است که مرحله آماده‌سازی داده معمولاً یک فرآیند Offline یا نیمه‌آنلاین است، در حالی که Retrieval و Generation هنگام ارسال سؤال توسط کاربر اتفاق می‌افتند.

اجزای اصلی سیستم RAG

یک سیستم RAG کامل معمولاً از چند جزء اصلی تشکیل می‌شود.

Data Source

محلی که اطلاعات اصلی از آن دریافت می‌شوند.

Document Loader

وظیفه خواندن و استخراج اطلاعات از فرمت‌های مختلف را بر عهده دارد.

Text Splitter

اسناد را به Chunkهای قابل مدیریت تقسیم می‌کند.

Embedding Model

متن را به بردارهای عددی تبدیل می‌کند.

Vector Database

Embeddingها و اطلاعات مرتبط با آن‌ها را ذخیره و امکان جست‌وجوی برداری را فراهم می‌کند.

Retriever

وظیفه پیدا کردن اطلاعات مرتبط با Query را بر عهده دارد.

Reranker

در معماری‌های پیشرفته، نتایج Retrieval را مجدداً بررسی و بر اساس میزان ارتباط مرتب می‌کند.

LLM

مدل زبانی که Context و Query را دریافت کرده و پاسخ نهایی را تولید می‌کند.

Prompt Template

نحوه تعامل LLM با Context و قوانین پاسخ‌گویی را مشخص می‌کند.

Reranker چیست و چرا در RAG استفاده می‌شود؟

Retrieval اولیه همیشه نمی‌تواند بهترین نتایج را با بالاترین ترتیب ممکن پیدا کند.
برای همین در سیستم‌های پیشرفته‌تر، پس از Retrieval اولیه از Reranker استفاده می‌شود.
در این معماری ابتدا تعداد بیشتری نتیجه بازیابی می‌شود. سپس Reranker آن‌ها را بررسی کرده و نتایج را بر اساس ارتباط واقعی با Query مرتب می‌کند.
برای مثال سیستم ممکن است ابتدا ۲۰ Chunk را پیدا کند، اما پس از Reranking فقط ۵ Chunk واقعاً مرتبط برای ارسال به LLM انتخاب شوند.
این روش می‌تواند کیفیت Context را افزایش دهد، هرچند هزینه پردازشی و Latency بیشتری ایجاد می‌کند.

انواع روش‌های Retrieval در RAG

Retrieval فقط یک روش مشخص ندارد.

Semantic Search

در Semantic Search، سیستم به دنبال شباهت معنایی بین Query و اسناد می‌گردد.
این روش برای سؤالاتی که کاربر از کلمات متفاوت اما با معنای مشابه استفاده می‌کند، بسیار مفید است.

Keyword Search

در Keyword Search، تطابق کلمات اهمیت بیشتری دارد.
این روش برای مواردی که نام محصول، کد خطا، شماره قرارداد یا اصطلاح خاصی اهمیت دارد می‌تواند بسیار کاربردی باشد.

Hybrid Search

Hybrid Search ترکیبی از Semantic Search و Keyword Search است.
در بسیاری از سیستم‌های واقعی، این رویکرد می‌تواند نسبت به استفاده از یکی از این دو روش به تنهایی عملکرد بهتری داشته باشد.

Metadata Filtering

در این روش علاوه بر شباهت معنایی، Metadata نیز برای محدود کردن نتایج استفاده می‌شود.
برای مثال اگر کاربر درباره محصولات سال ۲۰۲۶ سؤال کند، می‌توان Retrieval را فقط به اسناد مربوط به سال ۲۰۲۶ محدود کرد.

یک مثال واقعی از سیستم RAG

فرض کنید یک شرکت دارای یک Knowledge Base شامل هزاران سند داخلی است.
یکی از کارکنان سؤال می‌کند:
«برای درخواست مرخصی استعلاجی چه مراحلی باید انجام شود؟»
در یک سیستم معمولی، LLM ممکن است پاسخ عمومی ارائه کند؛ اما نمی‌داند قوانین دقیق این شرکت چیست.
در سیستم RAG، ابتدا سؤال کاربر به Embedding تبدیل می‌شود.
سیستم سپس در Vector Database جست‌وجو می‌کند و بخش‌هایی از آیین‌نامه منابع انسانی را پیدا می‌کند.
این بخش‌ها به عنوان Context در اختیار LLM قرار می‌گیرند.
مدل سپس پاسخ خود را بر اساس همان اطلاعات تولید می‌کند.
بنابراین RAG در اینجا نقش یک پل میان داده‌های اختصاصی شرکت و مدل زبانی را ایفا می‌کند.

RAG چه مشکلاتی را حل می‌کند؟

یکی از مهم‌ترین مزایای RAG این است که برای استفاده از اطلاعات جدید الزاماً نیازی به آموزش مجدد مدل وجود ندارد.
فرض کنید شرکت یک آیین‌نامه جدید منتشر کرده است. در معماری RAG می‌توان سند جدید را پردازش کرد، Chunkهای آن را ایجاد کرد و Embeddingهای مربوط به آن را در Vector Database قرار داد.
بعد از آن سیستم می‌تواند از اطلاعات جدید هنگام Retrieval استفاده کند.
این موضوع در مقایسه با آموزش مجدد یک مدل زبانی، فرآیندی سریع‌تر و انعطاف‌پذیرتر در بسیاری از کاربردها ایجاد می‌کند.
RAG همچنین برای استفاده از داده‌های اختصاصی سازمان‌ها مناسب است، زیرا اطلاعات مورد نیاز می‌توانند در زیرساخت و پایگاه داده‌ای که سازمان کنترل می‌کند نگهداری شوند.

تفاوت RAG و Fine-Tuning چیست؟

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

انواع معماری RAG

RAG نیز مانند بسیاری از فناوری‌های هوش مصنوعی از معماری‌های ساده تا پیچیده تشکیل می‌شود.

Naive RAG

ساده‌ترین معماری معمولاً شامل این مراحل است:
Chunking → Embedding → Vector Search → Context → LLM
این روش برای پروژه‌های ساده و Proof of Concept مناسب است.

Advanced RAG

در معماری‌های پیشرفته، مراحل بیشتری به سیستم اضافه می‌شوند؛ مانند:
Query Rewriting، Hybrid Search، Metadata Filtering، Reranking و Context Optimization.
هدف این معماری‌ها افزایش کیفیت Retrieval و کاهش اطلاعات نامرتبطی است که به LLM ارسال می‌شوند.

Modular RAG

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

چالش‌های سیستم RAG چیست؟

با وجود مزایای زیاد، RAG یک راهکار جادویی نیست.
یکی از مهم‌ترین چالش‌ها Retrieval اشتباه است. اگر سیستم نتواند اطلاعات مرتبط را پیدا کند، LLM نیز Context مناسبی برای تولید پاسخ نخواهد داشت.
چالش دیگر Chunking نامناسب است. اگر اسناد به شکل نامناسب تقسیم شوند، ممکن است اطلاعات مرتبط از یکدیگر جدا شوند یا Context بیش از حد بزرگ شود.
کیفیت Embedding نیز اهمیت زیادی دارد. یک مدل Embedding ضعیف می‌تواند باعث شود اسناد مرتبط در جست‌وجوی معنایی پیدا نشوند.
از طرف دیگر، اگر تعداد زیادی Chunk به LLM ارسال شود، Context ممکن است بیش از حد بزرگ یا پر از اطلاعات نامرتبط شود.
Latency و هزینه نیز در سیستم‌های بزرگ اهمیت دارند. هر مرحله اضافی مانند Reranking می‌تواند کیفیت را افزایش دهد، اما در مقابل زمان و منابع پردازشی بیشتری مصرف می‌کند.
بنابراین طراحی RAG همیشه یک مسئله تعادلی بین Accuracy، Latency و Cost است.

چگونه دقت سیستم RAG را افزایش دهیم؟

افزایش دقت RAG فقط با انتخاب یک LLM قدرتمند انجام نمی‌شود.
یکی از اولین مواردی که باید بهینه شود، Chunking است. اندازه Chunk، میزان Overlap و روش تقسیم اسناد باید بر اساس نوع داده انتخاب شوند.
انتخاب Embedding Model مناسب نیز اهمیت زیادی دارد. اگر داده‌ها فارسی باشند، باید عملکرد مدل Embedding روی زبان فارسی و داده‌های واقعی پروژه بررسی شود.
استفاده از Hybrid Search می‌تواند در پروژه‌هایی که هم اطلاعات معنایی و هم اصطلاحات دقیق اهمیت دارند، مفید باشد.
Reranking نیز می‌تواند کیفیت نتایج Retrieval را افزایش دهد.
Metadata Filtering یکی دیگر از روش‌های مؤثر است. برای مثال می‌توان Retrieval را بر اساس تاریخ، نوع سند، محصول یا واحد سازمانی محدود کرد.
همچنین Query Rewriting می‌تواند سؤالات مبهم یا کوتاه کاربر را قبل از Retrieval به Query مناسب‌تری تبدیل کند.
در نهایت، سیستم باید با داده واقعی ارزیابی شود. بدون Evaluation نمی‌توان مطمئن شد که تغییرات معماری واقعاً باعث افزایش کیفیت شده‌اند.

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

ارزیابی RAG فقط به این سؤال محدود نمی‌شود که:
«آیا پاسخ مدل خوب بود؟»
در واقع باید حداقل دو بخش را جداگانه بررسی کرد.
بخش اول Retrieval است.
باید بررسی شود که آیا سیستم توانسته اطلاعات مرتبط را پیدا کند یا خیر.
معیارهایی مانند Precision، Recall و Hit Rate می‌توانند برای ارزیابی Retrieval استفاده شوند.
بخش دوم Generation است.
در این مرحله باید بررسی شود که آیا پاسخ تولیدشده با Context موجود سازگار است و آیا واقعاً به سؤال کاربر پاسخ می‌دهد.
معیارهایی مانند Faithfulness، Answer Relevance و Context Relevance می‌توانند برای این منظور استفاده شوند.
این تفکیک اهمیت زیادی دارد؛ زیرا ممکن است LLM بسیار خوب عمل کند اما Retrieval ضعیف باشد، یا برعکس.

کاربردهای سیستم RAG

RAG در بسیاری از حوزه‌ها کاربرد دارد.

چت‌بات سازمانی

یک شرکت می‌تواند مستندات داخلی، قوانین، دستورالعمل‌ها و Knowledge Base خود را در اختیار یک سیستم RAG قرار دهد تا کارکنان بتوانند به صورت طبیعی با اطلاعات سازمان تعامل داشته باشند.

پشتیبانی مشتریان

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

مستندات فنی

تیم‌های فنی می‌توانند از RAG برای جست‌وجو در مستندات پیچیده نرم‌افزاری و زیرساختی استفاده کنند.

حوزه حقوقی

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

منابع انسانی

آیین‌نامه‌ها و دستورالعمل‌های داخلی سازمان می‌توانند به یک Knowledge Base متصل شوند تا کارکنان سریع‌تر پاسخ سؤالات خود را پیدا کنند.

فروش و بازاریابی

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

RAG برای داده‌های فارسی چه چالش‌هایی دارد؟

ساخت RAG برای زبان فارسی می‌تواند چالش‌های خاص خودش را داشته باشد.
یکی از این چالش‌ها تفاوت در شکل نوشتاری کلمات است. نیم‌فاصله، شکل‌های مختلف حروف، ترکیب فارسی و انگلیسی و کیفیت استخراج متن از PDFهای فارسی می‌توانند روی Retrieval تأثیر بگذارند.
برای مثال یک عبارت ممکن است در یک سند با نیم‌فاصله نوشته شده باشد و در سند دیگری بدون نیم‌فاصله.
همچنین کیفیت OCR در اسناد فارسی اهمیت زیادی دارد. اگر متن PDF به شکل اشتباه استخراج شود، حتی یک Embedding Model قدرتمند نیز نمی‌تواند مشکل داده خام را به‌طور کامل برطرف کند.
به همین دلیل در RAG فارسی باید کل Pipeline، از Data Processing تا Embedding و Retrieval، روی داده واقعی پروژه ارزیابی شود.

برای پیاده‌سازی RAG از چه ابزارهایی استفاده می‌شود؟

برای ساخت یک سیستم RAG می‌توان از ترکیبی از ابزارها و سرویس‌های مختلف استفاده کرد.
در لایه برنامه‌نویسی، Python یکی از گزینه‌های رایج است.
Frameworkهایی مانند LangChain و LlamaIndex نیز ابزارهایی برای ساخت Pipelineهای RAG ارائه می‌کنند.
برای Vector Database می‌توان از ابزارهایی مانند Qdrant، Pinecone، Weaviate، Milvus یا Chroma استفاده کرد.
در برخی معماری‌ها نیز PostgreSQL به همراه pgvector می‌تواند گزینه مناسبی باشد.
انتخاب ابزار مناسب به عواملی مانند حجم داده، تعداد کاربران، پیچیدگی Retrieval، نیازهای امنیتی، زیرساخت و بودجه پروژه بستگی دارد.

آیا برای RAG به GPU نیاز داریم؟

یکی از تصورات اشتباه این است که هر سیستم RAG الزاماً به یک GPU قدرتمند نیاز دارد.
در واقع پاسخ به این سؤال به معماری سیستم بستگی دارد.
اگر LLM از طریق API یک سرویس ابری اجرا شود، ممکن است بخش اصلی پردازش مدل روی زیرساخت ارائه‌دهنده سرویس انجام شود و سرور شما الزاماً به GPU قدرتمند نیاز نداشته باشد.
اما اگر قرار باشد LLM را به صورت Local اجرا کنید، GPU و میزان VRAM اهمیت بسیار بیشتری پیدا می‌کند.
همچنین در پروژه‌هایی که حجم زیادی داده باید Embedding شود یا تعداد زیادی Query به صورت همزمان پردازش می‌شوند، GPU می‌تواند سرعت پردازش را افزایش دهد.
Reranking، اجرای مدل‌های Embedding در مقیاس بالا و اجرای مدل‌های زبانی بزرگ نیز از دیگر سناریوهایی هستند که استفاده از GPU می‌تواند مزیت قابل توجهی داشته باشد.
بنابراین هنگام طراحی زیرساخت RAG باید بر اساس مدل مورد استفاده، حجم داده، تعداد کاربران و نوع Workload تصمیم گرفت که چه میزان CPU، RAM، Storage و GPU مورد نیاز است.
برای پروژه‌هایی که نیاز به اجرای مدل‌های هوش مصنوعی به صورت اختصاصی یا Local دارند، اجاره سرور GPU می‌تواند یکی از گزینه‌های زیرساختی باشد.

هزینه راه‌اندازی سیستم RAG چقدر است؟

هزینه یک سیستم RAG عدد ثابتی ندارد و به معماری آن بستگی دارد.
حجم داده یکی از عوامل مهم است. هرچه تعداد اسناد و Chunkها بیشتر باشد، فضای ذخیره‌سازی و منابع مورد نیاز برای پردازش افزایش پیدا می‌کند.
تعداد Query نیز اهمیت دارد. یک سیستم داخلی با چند ده کاربر با یک سرویس عمومی که هزاران کاربر همزمان دارد، نیازهای زیرساختی یکسانی ندارد.
مدل LLM، مدل Embedding، Vector Database، هزینه API، منابع CPU و RAM، GPU، Storage و ترافیک همگی می‌توانند در هزینه نهایی تأثیرگذار باشند.
در برخی پروژه‌ها می‌توان با استفاده از APIهای ابری و زیرساخت سبک شروع کرد و با افزایش مقیاس، بخش‌های مختلف را به زیرساخت اختصاصی منتقل کرد.
در پروژه‌هایی که تعداد درخواست‌ها زیاد است یا نیاز به اجرای مدل‌های Local وجود دارد، هزینه زیرساخت GPU نیز باید در طراحی معماری لحاظ شود.

چه زمانی RAG انتخاب مناسبی نیست؟

RAG برای همه مسائل هوش مصنوعی بهترین گزینه نیست.
اگر مشکل شما صرفاً تغییر سبک پاسخ‌گویی مدل باشد، ممکن است Fine-Tuning راهکار مناسب‌تری باشد.
اگر داده مورد نیاز بسیار کم باشد و بتوان آن را مستقیماً در Prompt قرار داد، ایجاد یک معماری کامل RAG ممکن است پیچیدگی غیرضروری ایجاد کند.
همچنین اگر داده‌های شما ساختار بسیار مشخصی دارند، در برخی موارد استفاده مستقیم از یک Database Query یا API می‌تواند بهتر از Retrieval متنی باشد.
بنابراین قبل از ساخت RAG باید مشخص شود که آیا مسئله واقعاً به یک لایه Retrieval نیاز دارد یا خیر.

آینده سیستم‌های RAG

RAG همچنان در حال توسعه است و معماری‌های جدیدتری در حال شکل‌گیری هستند.
یکی از این رویکردها Graph RAG است که به جای اتکا صرف بر Retrieval برداری، از ساختارهای گرافی و ارتباط بین موجودیت‌ها و مفاهیم نیز استفاده می‌کند.
در Agentic RAG، سیستم می‌تواند از Agentها برای تصمیم‌گیری درباره نحوه جست‌وجو و منابع مورد استفاده بهره بگیرد.
Multimodal RAG نیز امکان کار با انواع داده مانند متن، تصویر، نمودار و سایر محتواهای غیرمتنی را فراهم می‌کند.
رویکردهایی مانند Self-RAG و Corrective RAG نیز با هدف بهبود فرآیند Retrieval و ارزیابی یا اصلاح نتایج توسعه یافته‌اند.
در آینده، احتمالاً RAG از یک Pipeline ساده Retrieval → Generation به بخشی از معماری‌های پیچیده‌تر AI Agentها و سیستم‌های هوشمند تبدیل خواهد شد.