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

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

۱. افت کیفیت تحلیل در جابه‌جایی بین ایجنت‌ها
وقتی تحلیل و استدلال بین چند ایجنت تقسیم میشه، کانتکست آسیب می‌بینه. مثلاً ایجنت سوم مشکل پوشش بیمه رو پیدا می‌کنه اما ایجنت چهارم پیشنهاد میده بازاریاب‌های بیشتری به منطقه بفرستیم!

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

۲. استفاده از LLM برای کارهای قطعی (Deterministic)
سپردن تحلیل‌های آماری یا گشتن دنبال آنومالی‌ها در دیتابیس به LLM فقط نویز و هالوژنیشن ایجاد می‌کنه.

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

۳. جستجوی بدون چارچوب در دیتابیس
اگر ایجنت بدون محدودیت در جدول‌ها بگرده، ارتباطات اشتباه بین داده‌ها می‌سازه و فرض‌های نامربوط مطرح می‌کنه.

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

نتیجه این تغییرات: حذف کامل انحراف کانتکست و کاهش زمان تحلیل‌های چندهفته‌ای به چند دقیقه.
منبع:
Youtube: https://youtube.com/watch?v=u6jJcIFDLE4

@DevTwitter | <Mehdi Allahyari/>