پرش به محتوای اصلی

آیا عامل‌های LLM می‌توانند مدیر مالی باشند؟ شبیه‌سازی ۱۳۲ ماهه EnterpriseArena شکاف بزرگی را فاش می‌کند

· زمان مطالعه 8 دقیقه
Mike Thrift
Mike Thrift
Marketing Manager

بلندپروازانه‌ترین پرسش در هوش مصنوعی مالی در حال حاضر این نیست که «آیا یک LLM می‌تواند به سوالی درباره ترازنامه پاسخ دهد؟» بلکه این است که «آیا یک LLM می‌تواند سرمایه یک شرکت را در طول زمان مدیریت کند بدون اینکه تمام شود؟» مقاله یی هان و همکاران با عنوان آیا عامل‌های LLM می‌توانند مدیر مالی باشند؟ (arXiv:2603.23638) پلتفرم EnterpriseArena را برای آزمایش دقیق همین موضوع ساخته است، و پاسخ این است: به سختی، و نه به روش‌هایی که انتظارش را دارید.

مقاله

2026-07-11-can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark

EnterpriseArena یک شبیه‌سازی ۱۳۲ ماهه (۱۱ ساله) از تخصیص منابع در سطح مدیر مالی (CFO) است. هر گام زمانی نشان‌دهنده یک ماه است. عامل مشاهدات جزئی از امور مالی سطح شرکت، اسناد تجاری ناشناس و سیگنال‌های اقتصاد کلان استخراج شده از داده‌های FRED، CBOE و S&P Global را دریافت می‌کند. این عامل بودجه‌ای معادل ۲۰ فراخوانی ابزار در ماه دارد که در چهار عملیات توزیع شده است: تأیید وضعیت نقدینگی، بررسی سوابق مالی، تحلیل شرایط بازار و پیش‌بینی جریان‌های نقدی. عامل باید یکی از سه اقدام را انتخاب کند: بستن دفاتر (تطبیق)، درخواست تأمین مالی (سهام یا بدهی با نتایج تصادفی) یا عبور (Pass). محدودیت اصلی این است که موجودی نقد شرکت باید در هر گام زمانی غیرمنفی بماند؛ تخطی از این قانون باعث پایان قسمت با امتیاز صفر می‌شود. به شرط بقا، عامل ارزش نهایی شرکت را تحت فرمول Rev_T × 5 + Cash_T − 5,000 × N_tools به حداکثر می‌رساند، که صراحتاً استفاده بیش از حد از ابزار را جریمه می‌کند.

یازده LLM مورد ارزیابی قرار گرفتند، از جمله Gemini-3.1-Pro، Claude-Haiku-4.5، GPT-5.4، DeepSeek-V3.1، Llama-3.3-70B، Qwen3.5-397B و Qwen3.5-9B، در کنار یک خط پایه خبره انسانی که توسط دو حرفه‌ای مالی با به ترتیب ۸ و ۱۴ سال تجربه تأیید شده بود.

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

  • نرخ بقا در مدل‌های مختلف به شدت متفاوت است: Qwen3.5-9B در ۸۰٪ اجراها زنده می‌ماند، Gemini-3.1-Pro در ۵۰٪، Claude-Haiku-4.5 و GLM-5 هر کدام در ۲۰٪، و GPT-5.4، DeepSeek-V3.1، Llama-3.3-70B، Mistral-Small-24B و Mixtral-8x7B هر کدام در ۰٪. میانگین کلی LLMها ۲۶٪ است.
  • مدل‌های بزرگتر لزوماً از مدل‌های کوچکتر بهتر عمل نمی‌کنند: Qwen3.5-9B (با ۹ میلیارد پارامتر، ۸۰٪ بقا، ۷۸.۸ میلیون دلار ارزش نهایی) به طور قاطعانه Qwen3.5-397B (با ۳۹۷ میلیارد پارامتر، ۲۰٪ بقا) و GPT-5.4 (با ۰٪ بقا) را شکست می‌دهد.
  • شکاف با انسان‌ها بسیار زیاد است: خط پایه انسانی به ۱۰۰٪ بقا و ۱۵۲.۲ میلیون دلار (± ۲۹.۶ میلیون دلار) ارزش نهایی دست می‌یابد؛ میانگین LLMها ۲۸.۲ میلیون دلار با ۲۶٪ بقا است.
  • بستن دفاتر گلوگاه حیاتی است: خبرگان انسانی دفاتر را در ۹۴.۳٪ از گام‌های زمانی می‌بندند (تطبیق می‌دهند)؛ میانگین LLMها ۱۹.۳٪ است. این اقدامی است که صورت‌های مالی واقعی را تولید کرده و تصمیمات منطقی بعدی را ممکن می‌سازد.
  • جمع‌آوری اطلاعات بدون اقدام مرگبار است: Qwen3.5-397B در طول شبیه‌سازی به میزان بالایی از ابزارهای تحلیل بازار و پیش‌بینی استفاده می‌کند، اما تقریباً هرگز دفاتر را نمی‌بندد (نرخ بستن دفاتر ۰.۰٪) و تقریباً هرگز درخواست تأمین مالی نمی‌کند و با وجود «دانستن» آنچه در حال رخ دادن است، به دلیل اتمام نقدینگی از بین می‌رود.
  • جریمه بودجه ابزار اهمیت دارد: فرمول امتیازدهی فعالانه عامل‌هایی را که به جای عمل کردن، به طور وسواسی فقط بررسی می‌کنند جریمه می‌کند، محدودیتی که بازتاب‌دهنده هزینه فرصت واقعی است.

چه چیزی تایید می‌شود — و چه چیزی نه

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

طبقه‌بندی حالت‌های شکست که نویسندگان از طریق مطالعات موردی شناسایی کرده‌اند معتبر است: GPT-5.4 به نرخ عبور ۹۹.۱٪ دست می‌یابد (به این معنی که تقریباً در هر گام زمانی با انجام ندادن هیچ کاری اقدام می‌کند)، در حالی که Qwen3.5-397B تحلیل را با عمل اشتباه می‌گیرد. این‌ها حالت‌های شکست رفتاری متمایزی هستند که راهکارهای متفاوتی می‌طلبند.

چیزی که من کمتر نسبت به آن متقاعد شده‌ام: محیط اقتصاد کلان تصادفی از نویز گاوسی برای تقریب شوک‌های بازار استفاده می‌کند، که خود نویسندگان اذعان دارند نمی‌تواند رویدادهای «قوی سیاه» یا غیرمنطقی بودن انسان را بازتولید کند. بودجه ابزار ۲۰ فراخوانی در ماه نیز تا حدودی خودسرانه است — مدیران مالی واقعی با این نوع محدودیت نرخ پرس‌وجو در حافظه خود روبرو نیستند، که این سوال را ایجاد می‌کند که آیا بنچ‌مارک در حال اندازه‌گیری قضاوت مالی در افق طولانی است یا چیزی نزدیک به «RAG تحت فشار منابع». ساختار تک‌عاملی محدودیت صریح دیگری است که نویسندگان نام برده‌اند: مدیران مالی واقعی در سلسله مراتب‌های کنترلرها، تحلیل‌گران FP&A و تیم‌های خزانه‌داری فعالیت می‌کنند و مقاله تلاشی برای شبیه‌سازی این موضوع نمی‌کند.

این یافته که اندازه مدل بقا را پیش‌بینی نمی‌کند، جالب و احتمالا واقعی است، اما مکانیسم آن به خوبی توضیح داده نشده است. نویسندگان بدون باز کردن کامل این موضوع که آیا این شکست در پیروی از دستورالعمل‌ها، انسجام در بافت طولانی (long-context) یا کالیبراسیون ریسک است، به آن اشاره کرده‌اند.

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

عمل بستن دفاتر در EnterpriseArena اساساً همان مرحله تأیید balance و تطبیق دفتر کل در Beancount است — لحظه‌ای که عامل پیش از اقدام، به یک دیدگاه واقعی از وضعیت مالی متعهد می‌شود. این یافته که LLMها در ۸۰٪ مواقع از این کار چشم‌پوشی می‌کنند، مستقیماً به مشکل ایمنی بازنویسی (write-back safety) مربوط می‌شود: عاملی که قبل از اقدام از تطبیق خودداری می‌کند، عاملی است که بر اساس وضعیتی منقضی یا توهم‌زده عمل می‌کند. برای اتوماسیون Beancount، این نشان می‌دهد که مرحله تطبیق باید در هر حلقه عاملی اجباری و قابل تأیید باشد — نه اختیاری.

افق ۱۳۲ ماهه نیز مستقیماً با مدیریت چندساله دفتر کل قابل مقایسه است. این یافته که آگاهی موقعیتی پایدار در طول زمان کاهش می‌یابد، همان کاهشی است که در یک عامل Beancount که پنج سال سابقه تراکنش را مدیریت می‌کند انتظار داریم: حتی اگر عامل تمام داده‌ها را در بافت خود داشته باشد، ممکن است در ماه ۶۰ به طور منسجم بر اساس آن‌ها عمل نکند. این نشان می‌دهد که نقاط بازرسی تطبیق اجباری دوره‌ای — و نه فقط پرس‌وجوی واکنشی — در جلسات طولانی‌مدت عامل Beancount ضروری هستند.

تله جمع‌آوری اطلاعات که Qwen3.5-397B در آن گرفتار می‌شود، یک هشدار طراحی مفید است: عامل‌های مجهز به ابزارهای بازیابی زیاد ممکن است بازیابی را به تعهد ترجیح دهند، به خصوص زمانی که هزینه یک اقدام اشتباه (خرابی دفتر کل) بالا باشد. محدودیت‌های بودجه ابزار از نوعی که EnterpriseArena استفاده می‌کند، می‌تواند به اجرای انضباط عملیاتی در عامل‌های بازنویسی Beancount کمک کند.

پیشنهادات برای مطالعه بیشتر

  • EcoGym (arXiv:2602.09514) — یک بنچ‌مارک اقتصادی مکمل در افق زمانی طولانی در محیط‌های فروشندگی، فریلنسری و عملیاتی در بیش از ۱۰۰۰ گام؛ هیچ مدلی در هر سه محیط برتری ندارد، که نشان می‌دهد حالت‌های شکست در EnterpriseArena مختص یک طراحی بنچ‌مارک خاص نیستند.
  • AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — طراحی گردش کار را به عنوان جستجوی فضای کد با MCTS و بازخورد LLM بازتعریف می‌کند؛ اگر EnterpriseArena نشان می‌دهد که رفتارهای عاملی طراحی شده به صورت دستی شکست می‌خورند، AFlow گام بعدی بدیهی برای کشف خودکار خط لوله‌های بهتر است.
  • ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — چارچوب بنیادی آموزش و ارزیابی استفاده از ابزار؛ درک نحوه یادگیری رفتار فراخوانی ابزار در ToolLLM روشن می‌کند که آیا شکست در اجتناب از اقدام در EnterpriseArena یک مشکل آموزشی است یا یک مشکل مهندسی پرامپت.