اگر امروز در حال ساخت یک سیستم هوش مصنوعی هستید، تبدیل آن از یک کتابدار ساده به یک مدیر پروژه شخصی، پروژه شما را به یک مسئله‌ی پیچیده در مهندسی سیستم‌های توزیع‌شده تبدیل می‌کند. طبق گزارشی که در ۱۹ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، جهش به سمت RAG عامل‌محور (Agentic RAG) کمتر به نوشتن پرامپت‌های بهتر مربوط است و بیشتر به مدیریت یک «ماشین وضعیت» (State Machine) پیچیده برمی‌گردد.
بسیاری از توسعه‌دهندگان جذب تیترهایی می‌شوند که ادعا می‌کنند RAG عامل‌محور «موج بعدی» است یا وعده‌ی سیستم‌هایی را می‌دهند که «خودشان فکر می‌کنند». اما واقعیت اغلب یک تله است. آنچه به عنوان یک نمونه‌ی اولیه ساده با «چند گام اضافه» — مثل رزرو پرواز یا پیش‌نویس یک پست — شروع می‌شود، به‌سرعت به توده‌ای درهم‌تنیده از حلقه‌های تکراری و توهم (Hallucination) — مثل زمانی که مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — تبدیل می‌شود؛ مثلاً سیستمی که صورت‌حساب مشتری را به‌کل اشتباه پردازش می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هر لایه جدید در معماری، سطح جدیدی از ریسک را اضافه می‌کند. RAG استاندارد به مدل «حافظه» می‌دهد، اما عامل‌ها به آن «دست» می‌دهند. در حالی که یک خط‌لوله ساده فقط اسناد را بازیابی می‌کند، یک سیستم عامل‌محور در یک حلقه‌ی «مشاهده-تفکر-عمل» فعالیت می‌کند. این سیستم باید تصمیم بگیرد از کدام منبع داده استفاده کند، جستجو را اجرا کند و تا زمان تکمیل تکلیف، این روند را تکرار کند.
تصور کنید توسعه‌دهنده‌ای می‌خواهد پرس‌وجوی صورت‌حساب‌ها را برای یک سؤال مبهم مثل «وضعیت صورت‌حساب inv_8891 چیست؟» خودکار کند. به‌جای یک پاسخ تک‌مرحله‌ای، سیستم یک حلقه‌ی چند-مرحله‌ای را طی می‌کند:
- مشاهده: سیستم پرس‌وجوی کاربر را دریافت می‌کند.
- تفکر: مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — پرس‌وجو و ابزارهای موجود را تحلیل کرده و توابع
get_customerوget_invoiceرا شناسایی می‌کند. - عمل: سیستم اولین فراخوانی ابزار را برای بازیابی شناسه مشتری اجرا می‌کند.
- مشاهده: ابزار، داده‌های مشتری و شناسه‌های صورت‌حساب مرتبط را برمی‌گرداند.
- تفکر: مدل تشخیص می‌دهد که شناسه درست را دارد و ابزار
get_invoiceرا فراخوانی می‌کند. - عمل: صورت‌حساب بازیابی می‌شود.
- تفکر: مدل یک پایگاه دانش را برای بررسی سیاست‌های بازپرداخت چک می‌کند.
- عمل: پاسخ نهایی را تنظیم و ارسال می‌کند.
این فرآیند چند-مرحله‌ای که اغلب توسط گراف‌ها در چارچوب‌هایی مثل LangChain مدیریت می‌شود، سه مانع فنی اصلی ایجاد می‌کند:
- مسیریابی ابزار (Tool Routing): مدل باید در لحظه تصمیم بگیرد کدام یک از ۱۰ پایگاه داده یا API مختلف را اول بخواند؛ این یعنی ایجاد یک لایه پیچیده از «مسیریابی هوشمند».
- حلقه بی‌نهایت (Infinite Loop): بدون تعیین مرز سخت برای «گام‌های تفکر»، عامل‌ها ممکن است در چرخه‌ای از پرس‌وجوی ابزارها گیر کنند بدون اینکه هرگز پاسخی به کاربر بدهند.
- تأخیر (Latency): هر حلقه نیاز به یک رفت‌وبرگشت کامل به مدل دارد. پرس‌وجویی که در RAG استاندارد ۲ ثانیه زمان می‌برد، در ساختار عامل‌محور می‌تواند به ۱۵ تا ۲۰ ثانیه برسد و تجربه کاربر را تخریب کند.
بر اساس بررسی منابع متعدد، این گلوگاه‌ها یک تقابل شدید در عملکرد ایجاد می‌کنند. داده‌ها نشان می‌دهند که برای کارهای پایه، یک معماری ساده‌تر با یک مدل قدرتمندتر، اغلب بهتر از یک سیستم عامل‌محور پیچیده عمل می‌کند.
برای توسعه‌دهنده، این یعنی تغییر نقش. شما دیگر فقط دستور نمی‌نویسید؛ شما در حال ساخت یک ارکستراتور برای هوش مصنوعی هستید که عملاً ذهن خودش را دارد. شما تبدیل به یک مهندس سیستم شده‌اید. به همین دلیل، RAG عامل‌محور باید فقط زمانی مستقر شود که مسئله واقعاً به استدلال چند-مرحله‌ای و استفاده از ابزار نیاز دارد، نه به عنوان یک ارتقای کلی برای یک چت‌بات.
گام بعدی شما
- برای هر عامل، یک «سقف تعداد گام‌ها» (Turn Limit) سخت تعریف کنید تا از حلقه‌های بی‌نهایت جلوگیری شود.
- بنچمارک‌های تأخیر (Latency) را برای هر ابزار به‌صورت جداگانه اندازه بگیرید تا گلوگاه‌های مسیر را شناسایی کنید.
- قبل از پیچیده کردن معماری، بررسی کنید آیا یک مدل قدرتمندتر با همان ساختار ساده RAG می‌تواند پاسخ را تولید کند یا خیر.
اما مدیریت حافظه در این سیستم‌های توزیع‌شده حتی پیچیده‌تر است — به تحلیل ما درباره‌ی پنجره‌های متنی گسترده مراجعه کنید.
گفتگو