AutoGen: چارچوب‌های گفتگوی چند-عاملی برای هوش مصنوعی مالی

پس از آنکه Gorilla نشان داد یک مدل زبانی بزرگ (LLM) واحد می‌تواند فراخوانی هزاران API را به دقت بیاموزد، سوال طبیعی این است: چه اتفاقی می‌افتد اگر به چندین LLM نقش‌های متمایزی بدهیم و اجازه دهیم با یکدیگر گفتگو کنند؟ AutoGen (وو و همکاران، ۲۰۲۳) با ساخت چارچوبی برای گفتگوی چند-عاملی به این سوال پاسخ می‌دهد. مطالعه این مقاله در حال حاضر بسیار به موقع به نظر می‌رسد — چرا که اکثر سیستم‌های تولیدی هوش مصنوعی مالی که امروزه طراحی می‌شوند، به طور پیش‌فرض حداقل شامل سه عامل هستند.

مقاله

مقاله AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (وو، بانسال، ژانگ و همکاران، تحقیقات مایکروسافت، ۲۰۲۳) چارچوبی را پیشنهاد می‌کند که در آن «عامل‌های قابل گفتگو» (conversable agents) — که هر کدام توسط ترکیبی از یک LLM، ابزارها و ورودی انسانی پشتیبانی می‌شوند — تا زمان تکمیل یک وظیفه به یکدیگر پیام ارسال می‌کنند. این چارچوب دو نوع عامل داخلی را معرفی می‌کند: AssistantAgent (هدایت شده توسط یک LLM) و UserProxyAgent (که می‌تواند کد اجرا کرده و ورودی انسان را منتقل کند)، به علاوه یک GroupChatManager که نوبت‌ها را در گروه‌های بزرگتر مدیریت می‌کند.

ایده اصلی چیزی است که نویسندگان آن را «برنامه‌نویسی گفتگویی» (conversation programming) می‌نامند: به جای نوشتن دستیِ منطق هماهنگی در کد، شما از طریق پرامپت‌های سیستمی به زبان طبیعی مشخص می‌کنید که هر عامل باید چه کاری انجام دهد و اجازه می‌دهید تبادل پیام، جریان کنترل را مدیریت کند. مقاله این موضوع را در حل مسائل ریاضی، پرسش و پاسخ تقویت‌شده با بازیابی (RAG)، تصمیم‌گیری در ALFWorld و یک کاربرد تحقیق در عملیات به نام OptiGuide نشان می‌دهد.

ایده‌های کلیدی

• افزایش دقت در بنچمارک MATH: یک تنظیمات دو-عاملی AutoGen (یک دستیار LLM به همراه یک پروکسی اجرای کد) در مجموعه تست MATH به دقت ۶۹.۴۸٪ می‌رسد، در حالی که GPT-4 به تنهایی ۵۵.۱۸٪ دقت داشت — یک بهبود ۱۴ واحدی ناشی از افزودن بازخورد اجرای کد.
• حضور انسان در چرخه به عنوان یک شهروند درجه اول: عامل UserProxyAgent دارای یک human_input_mode قابل تنظیم است — ALWAYS (همیشه)، NEVER (هرگز)، یا TERMINATE (پایان) — به این معنی که می‌توانید سطح نظارت را بدون تغییر در منطق عامل، کم یا زیاد کنید.
• چت گروهی پویا: GroupChatManager سخنران بعدی را بر اساس وضعیت گفتگو و نه بر اساس یک ترتیب ثابت (round-robin) انتخاب می‌کند، که اجازه می‌دهد جریان‌های کاری در پاسخ به نتایج نوظهور منشعب شوند.
• بهبود ایمنی OptiGuide: افزودن یک عامل SafeGuard به جریان کاری بهینه‌سازی زنجیره تأمین، تشخیص کدهای ناامن را در GPT-4 تا ۸ واحد و در GPT-3.5 تا ۳۵ واحد F1 بهبود بخشید، در حالی که حجم کد کاربر را از ۴۳۰ خط به ۱۰۰ خط کاهش داد.
• بازیابی تعاملی: در وظایف پرسش و پاسخ، عامل دستیار می‌توانست با ارسال سیگنال UPDATE CONTEXT درخواست زمینه (context) اضافی کند؛ این مورد در حدود ۱۹.۴٪ از سوالات در Natural Questions فعال شد و امتیاز F1 کلی ۲۳.۴۰٪ بود.
• ترکیب‌پذیری در طراحی: هر عامل AutoGen خود یک «ابزار» معتبر است که عامل دیگر می‌تواند آن را فراخوانی کند، بنابراین خط‌لوله‌های سلسله‌مراتبی بدون نیاز به کدهای واسط خاص با هم ترکیب می‌شوند.

چه چیزی پابرجا می‌ماند — و چه چیزی نه

نتایج MATH و ALFWorld استوار هستند — مقایسه‌های کنترل‌شده و تکرارپذیر در برابر خطوط پایه مشخص با بنچمارک‌های واقعی. رقم ۶۹.۴۸٪ معنادار است زیرا مزیت بازخورد اجرای کد را در یک حلقه گفتگوی ساختاریافته ایزوله می‌کند.

آنچه ضعیف‌تر است، تحلیل هزینه و تأخیر (latency) است، یا بهتر بگوییم، نبود آن. هر نوبت در GroupChat یک فراخوانی کامل LLM را با کل تاریخچه گفتگوی انباشته شده تحریک می‌کند. یک جریان کاری چهار-عاملی با ده دور گفتگو، حداقل به معنای چهل فراخوانی LLM است که هر کدام پنجره بافت (context window) رو به رشدی دارند. این مقاله هرگز هزینه توکن یا تأخیر را برای هیچ‌یک از کاربردهای خود گزارش نمی‌کند. در یک خط‌لوله حسابداری زنده که هزاران تراکنش را پردازش می‌کند، این نادیده گرفتن یک بحث آکادمیک نیست — بلکه تعیین‌کننده کاربردی بودن یا نبودن کل رویکرد است.

استعاره برنامه‌نویسی گفتگویی نیز شکننده‌تر از آن چیزی است که در دموها به نظر می‌رسد. GroupChatManager سخنران بعدی را با پرامپت کردن LLM برای انتخاب از میان لیستی از عامل‌ها برمی‌گزیند. این انتخاب خود یک مرحله تولید متن احتمالی (probabilistic) است، به این معنی که جریان کنترل می‌تواند به روش‌های ظریفی دچار خطا شود که هیچ خطایی (exception) ایجاد نمی‌کنند. برای عاملی که وظیفه نوشتن در دفتر کل را بر عهده دارد — جایی که ترتیب عملیات اهمیت دارد و یک فراخوانی ابزار اشتباه می‌تواند یک ورودی دفتر روزنامه را خراب کند — انتخاب غیرقطعی سخنران یک ریسک واقعی است.

در نهایت، تمام وظایف ارزیابی شده تک‌جلسه‌ای و کوتاه‌مدت هستند. هیچ آزمایشی وجود ندارد که در آن عامل‌ها وضعیت (state) را در طول روزها انباشته کنند، دستورالعمل‌های متناقض را مدیریت کنند، یا نیاز به حل تعارض بین حافظه قدیمی عامل و یک ورودی جدید در دفتر کل داشته باشند. این‌ها دقیقاً سناریوهایی هستند که در جریان‌های کاری واقعی حسابداری رخ می‌دهند.

چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد

دلیل استفاده از سیستم‌های چند-عاملی در هوش مصنوعی مالی روشن است: مغایرت‌گیری، ثبت سند و گزارش‌دهی ذاتاً موضوعات مجزایی هستند. یک خط‌لوله Beancount می‌تواند یک LedgerReaderAgent داشته باشد که دفتر کل را به صورت فقط-خواندنی پرس‌وجو می‌کند، یک ReconcilerAgent که تراکنش‌ها را با صورت‌حساب‌های بانکی مقایسه می‌کند، یک WriterAgent که ورودی‌های جدید را پیشنهاد می‌دهد، و یک ReviewerAgent که آن‌ها را پیش از نهایی شدن ثبت، بر اساس قوانین سرفصل حساب‌ها (chart-of-accounts) بررسی می‌کند. الگوی UserProxyAgent در AutoGen انتزاع مناسبی برای WriterAgent است — این عامل می‌تواند نوشتن واقعی در دفتر کل را اجرا کرده و نتیجه را به عنوان پیامی بازگرداند که ReviewerAgent آن را بازرسی می‌کند.

یافته مربوط به SafeGuard در OptiGuide مستقیم‌ترین یافته قابل انتقال است: افزودن یک عامل تأیید اختصاصی برای شناسایی اقدامات ناامن، تشخیص را به میزان قابل توجهی بهبود بخشید و این تشخیص درون حلقه گفتگو اتفاق افتاد نه به عنوان یک حسابرسی پس از واقعه. این دقیقاً همان معماری است که من برای امنیت بازنویسی (write-back) در Beancount می‌خواهم — یک تأییدکننده که ثبت سند را مسدود می‌کند، نه عاملی که پس از وقوع خطا هشدار می‌دهد.

مشکل انتخاب غیرقطعی سخنران قابل حل است: شما می‌توانید GroupChatManager را با یک تابع پایتون قطعی (deterministic) که بر اساس محتوای پیام مسیریابی می‌کند، جایگزین کنید. اما باید بدانید که این کار را انجام دهید، و مقاله این موضوع را به عنوان یک نگرانی برجسته نمی‌کند.

آنچه باید در ادامه بخوانید

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) — بنچمارک LLMها در هشت محیط عاملی متمایز از جمله وب‌گردی، کدنویسی و دستکاری پایگاه داده؛ شکاف بین مدل‌های تجاری و متن‌باز یافته کلیدی است و مستقیماً در انتخاب مدل‌های پایه برای خط‌لوله‌های عامل‌های مالی کاربرد دارد.
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) — الگوی AutoGen را مستقیماً برای بازارهای مالی با عامل‌های متخصص تحلیلگر، پژوهشگر، معامله‌گر و مدیر ریسک پیاده‌سازی می‌کند؛ نتایج نسبت شارپ و حداکثر افت سرمایه اولین اعداد واقعی عملکرد را برای سیستم‌های مالی چند-عاملی ارائه می‌دهند.
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia et al., arXiv:2407.01514) — استدلال می‌کند که یک رویکرد ساده و بدون عاملِ دو مرحله‌ای (مکان‌یابی و سپس تعمیر) در SWE-bench از چارچوب‌های پیچیده چند-عاملی بهتر عمل می‌کند؛ یک وزنه تعادلی مفید در برابر این فرض که عامل‌های بیشتر همیشه کمک‌کننده هستند.