Agentic RAG یا RAG عامل محور، بازیابی اطلاعات را از یک مرحله ثابت به یک فرایند تصمیم گیر تبدیل می کند. در RAG معمولی، پرسش وارد می شود، چند سند نزدیک پیدا می شوند و مدل پاسخ می سازد. در Agentic RAG، ایجنت تصمیم می گیرد چه چیزی را جستجو کند، پرسش را چگونه بشکند، از کدام منبع کمک بگیرد و آیا شواهد برای پاسخ کافی هستند یا نه.
این معماری برای پرسش های چندبخشی، دانش پراکنده و تصمیم هایی مفید است که یک جستجوی ساده پاسخ کامل نمی دهد. البته پیچیدگی و هزینه بیشتری دارد و برای هر پروژه لازم نیست.
تفاوت RAG معمولی و Agentic RAG چیست؟
RAG معمولی برای پرسش روشن و یک مخزن دانش منظم عالی است. مثلا «مدت ضمانت محصول الف چقدر است؟» با یک بازیابی و یک پاسخ حل می شود. اما پرسش «کدام قراردادهای فعال با سیاست تازه تمدید ناسازگارند و چه اقدامی لازم است؟» به چند جستجو، مقایسه، کنترل تاریخ و شاید فراخوانی ابزار نیاز دارد.
| ویژگی | RAG معمولی | Agentic RAG |
|---|---|---|
| مسیر بازیابی | ثابت و یک مرحله ای | پویا و چندمرحله ای |
| نوع پرسش | روشن و مستقیم | ترکیبی و چند منبعی |
| انتخاب منبع | از پیش تعیین شده | بر اساس پرسش و شواهد |
| کنترل کفایت | معمولا محدود | بازبینی و جستجوی دوباره |
| هزینه و تاخیر | کمتر | بیشتر و متغیر |
برای شناخت پایه بازیابی و حافظه، مقاله حافظه ایجنت هوش مصنوعی مکمل خوبی است.
چرخه Agentic RAG چگونه کار می کند؟
- درک هدف: پرسش، محدودیت زمانی و قالب خروجی روشن می شود.
- تقسیم پرسش: مساله به چند زیرپرسش قابل جستجو شکسته می شود.
- انتخاب منبع: پایگاه برداری، جستجوی متنی، پایگاه داده یا API انتخاب می شود.
- بازیابی و بازچینی: گزینه های بیشتر پیدا و بر اساس ارتباط دوباره مرتب می شوند.
- سنجش کفایت: ایجنت بررسی می کند آیا شواهد برای نتیجه کافی و تازه هستند.
- پاسخ مستند: نتیجه فقط بر پایه محتوای بازیابی شده ساخته می شود.
این چرخه نمونه روشن الگوی مشاهده، برنامه، اقدام و بازبینی است که در مقاله ایجنت هوش مصنوعی چگونه کار می کند توضیح داده شده است.
معماری عملی Agentic RAG
لایه ورود و سیاست
هویت کاربر، دامنه پرسش و مجوز داده پیش از بازیابی بررسی می شود. جستجوی خوب نباید مرز دسترسی را دور بزند.
هماهنگ کننده
زیرپرسش ها، ترتیب ابزارها، سقف تلاش و شرط توقف را مدیریت می کند. برای کار ساده، همین بخش باید مسیر کوتاه را انتخاب کند.
ابزارهای بازیابی
هر منبع قرارداد مشخص دارد: ورودی مجاز، فیلتر دسترسی، تعداد نتیجه، زمان انتظار و شکل خروجی. راهنمای ابزار و API ایجنت برای این طراحی کاربردی است.
لایه شواهد
متن سند، شناسه، تاریخ، نسخه و امتیاز ارتباط کنار هم نگهداری می شوند تا پاسخ قابل بازبینی باشد.
ارزیاب پاسخ
پوشش شواهد، ناسازگاری منابع، تازگی داده و ادعاهای بدون پشتوانه را کنترل می کند. در تصمیم حساس، نتیجه برای انسان فرستاده می شود.
چه زمانی Agentic RAG انتخاب بدی است؟
اگر همه پرسش ها ساده اند، یک منبع دارید یا پاسخ باید در چند صد میلی ثانیه آماده شود، معماری چندمرحله ای احتمالا ارزش اضافه ندارد. ابتدا RAG ساده را بهینه کنید؛ کیفیت بخش بندی سند، فراداده، فیلتر دسترسی و بازچینی گاهی بیشتر از افزودن ایجنت اثر دارد.
Agentic RAG را چگونه ارزیابی کنیم؟
- درصد پاسخ هایی که شواهد کافی و مرتبط دارند
- نرخ ادعای بدون پشتوانه یا ناسازگار با سند
- دقت انتخاب منبع و فیلتر دسترسی
- تعداد دور بازیابی تا رسیدن به پاسخ
- زمان و هزینه هر پاسخ موفق
- نرخ ارجاع درست به انسان
برای ثبت رد بازیابی و یافتن گلوگاه ها، مشاهده پذیری ایجنت را در معماری بگنجانید. امنیت داده و تزریق دستور در اسناد نیز باید با اصول امنیت و ارزیابی ایجنت سنجیده شود.
سوالات متداول
آیا Agentic RAG جای RAG معمولی را می گیرد؟
نه. برای پرسش های مستقیم، RAG معمولی ساده تر و سریع تر است. معماری عامل محور برای مساله های چندمرحله ای ارزش دارد.
آیا Agentic RAG به پایگاه برداری نیاز دارد؟
الزامی نیست. ایجنت می تواند از جستجوی متنی، پایگاه داده، گراف دانش و API نیز استفاده کند.
چگونه از پاسخ ساختگی جلوگیری کنیم؟
پاسخ باید به شواهد بازیابی شده محدود شود، کفایت مدرک سنجیده شود و ادعای حساس بدون سند اجازه انتشار نگیرد.
مهم ترین هزینه این معماری چیست؟
تعداد بیشتر فراخوانی مدل و ابزار، تاخیر متغیر و نیاز به پایش دقیق از هزینه های اصلی هستند.