مقاله​

ژائو، جین، لی و گائو از دانشگاه پکن FinRAGBench-V را معرفی می‌کنند، یک بنچمارک دوزبانه که از اسناد مالی واقعی ساخته شده است: گزارش‌های تحقیقاتی، صورت‌های مالی، امیدنامه‌ها، مقالات آکادمیک، مجلات و اخبار. بدنه بازیابی قابل توجه است—۶۰,۷۸۰ صفحه چینی و ۵۱,۲۱۹ صفحه انگلیسی در تقریباً ۱,۱۰۰ سند برای هر زبان—که با ۱,۳۹۴ جفت سوال و جواب حاشیه‌نویسی شده توسط انسان همراه شده است. این سوالات هفت دسته را پوشش می‌دهند: استنتاج متن، استخراج نمودار و جدول، محاسبات عددی، پرس‌وجوهای حساس به زمان و استدلال چندصفحه‌ای. فراتر از مجموعه داده، دستاورد اصلی مقاله سیستم RGenCite است، یک سیستم پایه که پاسخ‌ها را همراه با استنادهای بصری در سطح پیکسل در قالب مختصات جعبه‌های محصورکننده (bounding-box) تولید می‌کند که مناطق خاصی از سند را که از هر ادعا پشتیبانی می‌کنند، علامت‌گذاری می‌کند.

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

• بازیابی چندوجهی با اختلاف فاحشی بر بازیابی صرفاً متنی غلبه می‌کند: ColQwen2، یک بازیاب بینایی-زبانی که بر اساس تعبیه‌های تصویر-صفحه ساخته شده است، به Recall@10 معادل ۹۰.۱۳٪ (چینی) و ۸۵.۸۶٪ (انگلیسی) دست می‌یابد. بهترین بازیاب‌های مبتنی بر متن، BM25 و BGE-M3، در حدود ۴۲.۷۱٪ متوقف می‌شوند. این شکاف یک خطای گرد کردن نیست.
• دقت تولید حتی برای مدل‌های پیشرو پایین است: GPT-4o در انگلیسی به دقت ۴۳.۴۱٪ (ROUGE 24.66) می‌رسد؛ o4-mini در چینی به ۵۸.۱۳٪ (ROUGE 38.55) دست می‌یابد. این‌ها مدل‌های اختصاصی برتر با سیستم‌های بازیابی قوی هستند.
• استناد در سطح صفحه کار می‌کند؛ در سطح بلوک نه: فراخوانی در سطح صفحه برای بهترین مدل‌ها بین ۷۵ تا ۹۳ درصد است. فراخوانی در سطح بلوک—یعنی دانستن اینکه دقیقاً کدام سلول جدول یا منطقه نمودار پایه یک ادعا است—به ۲۰ تا ۶۱ درصد کاهش می‌یابد. این شکاف اصلی برای قابلیت حسابرسی است.
• استدلال عددی و استنتاج چندصفحه‌ای اولین مواردی هستند که باعث شکست مدل‌ها می‌شوند: سوالاتی که نیاز به محاسبات در صفحات مختلف یا بازه‌های زمانی دارند، جایی هستند که دقت در تمام سیستم‌های آزمایش شده به شدت افت می‌کند.
• مدل‌های اختصاصی به طور قابل توجهی از جایگزین‌های متن‌باز بهتر عمل می‌کنند: شکاف بین APIهای بسته و مدل‌های متن‌باز در اینجا بزرگتر از اکثر بنچمارک‌های NLP است، که نشان می‌دهد استدلال مالی بصری برای مدل‌های باز هنوز حل نشده باقی مانده است.
• ارزیابی خودکار برای استنادها ناقص است: ارزیاب استناد مبتنی بر برش تصویر به همبستگی پیرسون r = 0.68 با قضاوت‌های انسانی دست می‌یابد—که منطقی است اما آنقدر قابل اعتماد نیست که بدون نمونه‌برداری به آن اعتماد کامل کرد.

چه چیزی درست است — و چه چیزی نه​

یافته مربوط به بازیابی، معتبرترین نتیجه مقاله است. شکاف تقریباً ۵۰ واحد درصدی بین بازیاب‌های چندوجهی و صرفاً متنی در بیش از ۶۰ هزار صفحه، بسیار بزرگتر از آن است که نادیده گرفته شود. وقتی یک سند مالی را قبل از نمایه‌سازی OCR می‌کنید، سیگنال‌های چیدمان ساختاری را از بین می‌برید—اینکه یک عدد در کدام ستون ظاهر می‌شود یا اینکه آیا عنوان یک شکل، تفسیر یک جدول را تغییر می‌دهد یا خیر—که مشخص شده است برای بازیابی اهمیت فوق‌العاده‌ای دارند.

اعداد مربوط به تولید صادقانه هستند اما تفسیر آن‌ها به تنهایی دشوار است. نویسندگان مشخص نکرده‌اند که چه مقدار از شکاف دقت مربوط به خطاهای بازیابی در مقابل شکست‌های تولید است. با توجه به اینکه Recall@10 در حال حاضر برای انگلیسی ۸۵.۸۶٪ است، بخش قابل توجهی از شکست‌ها باید مربوط به بخش تولید باشد تا بازیابی. دانستن این تفکیک مشخص می‌کرد که آیا گلوگاه در استدلال چندوجهی است یا چیزی بنیادی‌تر در مورد نحوه برخورد MLLMها با زبان مالی.

مجموعه ارزیابی شامل ۱,۳۹۴ جفت سوال و جواب برای گستره این بنچمارک کوچک است. با تقسیم بر هفت دسته و دو زبان، برخی بخش‌ها کمتر از ۲۰۰ مثال دارند. معناداری آماری یافته‌های سطح دسته به صورت ضمنی رها شده است. این موضوع برای یک مقاله بنچمارک غیرعادی نیست، اما به این معنی است که ساختن مقایسه‌های دست‌چین شده آسان خواهد بود.

پروتکل ارزیابی استناد یک مشارکت جالب است، اما همبستگی پیرسون r = 0.68 با رتبه‌بندی‌های انسانی آنقدر قوی نیست که بتوان ارزیابی خودکار را به عنوان حقیقت مطلق برای استناد در سطح بلوک در نظر گرفت. نویسندگان به این موضوع اذعان دارند؛ کارهای آینده روی معیارهای استناد بهتر به وضوح مشخص شده است.

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

Beancount روی فایل‌های دفتر کل متنی ساده اجرا می‌شود، که باعث می‌شود RAG صرفاً متنی برای پرس‌وجوی تراکنش‌های گذشته قابل دفاع باشد. اما وظیفه حسابداری گسترده‌تر شامل اسنادی است که قطعاً متن ساده نیستند: PDFهای صورت‌حساب بانکی، فاکتورهای اسکن شده، تصاویر رسیدها و گزارش‌های سالانه با جداول و نمودارهای تعبیه شده. لحظه‌ای که یک عامل Beancount نیاز پیدا می‌کند تا یک ورودی دفتر کل را با یک سند منبع تطبیق دهد (reconcile)—مثلاً تأیید کند که یک هزینه خاص با فاکتور موجود در پرونده مطابقت دارد—دقیقاً در حال انجام همان وظیفه‌ای است که FinRAGBench-V ارزیابی می‌کند.

یافته‌های مربوط به استناد در سطح بلوک برای این مورد استفاده اهمیت زیادی دارد. اگر یک عامل باید یک ورودی دفتر کل را با اشاره به یک ردیف خاص در یک PDF توجیه کند و بهترین سیستم موجود تنها به ۲۰ تا ۶۱ درصد فراخوانی در سطح بلوک دست می‌یابد، این سیستم آماده حسابرسی (audit-ready) نیست. هر خط لوله Beancount که با اسناد منبع اسکن شده در تماس است، تا زمانی که این عدد به طور قابل توجهی بهبود نیابد، به بازبینی انسانی (human-in-the-loop) نیاز دارد.

شکاف در مدل بازیابی نیز به شدت علیه خط لوله‌های صرفاً متنی برای دریافت اسناد استدلال می‌کند. تصویر یک رسید حاوی اطلاعات چیدمان است—فیلدهای مبلغ، نام فروشنده، موقعیت اقلام— که OCR آن‌ها را نابود می‌کند. آن اطلاعات چیدمان دقیقاً همان چیزی است که جمع کل یک سطر را از مبلغ مالیات متمایز می‌کند و FinRAGBench-V نشان می‌دهد که بازیاب‌های چندوجهی از آن به روش‌هایی استفاده می‌کنند که بازیاب‌های متنی نمی‌توانند.

چه چیزی در مرحله بعد بخوانیم​

• ColPali: Efficient Document Retrieval with Vision Language Models — پیش‌نیاز ColQwen2 که رویکرد تعبیه تصویری صفحات را پایه‌گذاری کرد و بهترین بازیاب FinRAGBench-V بر اساس آن ساخته شده است [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — به پرسش و پاسخ بصری چند سندی با چارچوبی منعطف می‌پردازد که استدلال بصری تک‌مرحله‌ای و چندمرحله‌ای را در صفحات مختلف مدیریت می‌کند [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — یک بنچمارک مکمل از سال ۲۰۲۵ که حساسیت زمانی را در RAG چندوجهی مالی ارزیابی می‌کند و مستقیماً مکمل دسته سوالات حساس به زمان در FinRAGBench-V است [arXiv:2503.05185]

مقاله​

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 یک مشکل آموزشی است یا یک مشکل مهندسی پرامپت.

مقاله​

پی‌جی یو (Peijie Yu)، وی لیو (Wei Liu)، ایوان یانگ (Yifan Yang) و همکارانشان در علی‌بابا، WildToolBench (arXiv:2604.06185) را معرفی کردند؛ بنچ‌مارکی شامل ۲۵۶ سناریوی گفتگوی چند مرحله‌ای با ۱۰۲۴ وظیفه که از الگوهای رفتاری واقعی کاربران استخراج شده و بر پایه حدود ۱۶۰۰ API عمومی بنا شده است. استدلال اصلی این است که بنچ‌مارک‌های موجود نه به دلیل خوب بودن مدل‌ها، بلکه به دلیل مصنوعی بودن وظایف در حال اشباع شدن هستند. کاربران واقعی درخواست‌ها را با هم ترکیب می‌کنند، زمینه‌ای (context) را که دو مرحله قبل به اشتراک گذاشته بودند حذف می‌کنند و بین پرسیدن سوال ابزاری، احوال‌پرسی کوتاه و درخواست توضیح جابجا می‌شوند — گاهی اوقات همه این‌ها در یک پیام واحد. WildToolBench این حالت‌های شکست را در سه دسته چالش ساختاریافته عملیاتی می‌کند و هم دقت در سطح وظیفه و هم دقت بسیار سخت‌گیرانه‌تر در سطح جلسه (که مستلزم موفقیت در هر چهار وظیفه یک گفتگو است) را اندازه‌گیری می‌کند.

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

• دقت جلسه برای اکثر مدل‌ها به تک‌رقمی سقوط می‌کند: مدل Gemini-2.0-Flash-Thinking با ۱۴.۴۵٪ دقت جلسه پیشتاز است، Claude-4-Sonnet با ۱۲.۵۰٪ و GPT-4o با ۱۱.۷۲٪ در رتبه‌های بعدی هستند. گذراندن تمام وظایف در یک جلسه چهار مرحله‌ای به قدری دشوار است که حتی دقت ۶۰ درصدی در سطح وظیفه به دقت زیر ۱۵ درصدی در سطح جلسه تبدیل می‌شود — یک جریمه احتمالی تجمعی بر روی هر تعامل.
• سازمان‌دهی ترکیبی (Compositional orchestration) جدی‌ترین چالش است: توپولوژی‌های ابزاری ترکیبی (متوالی به علاوه موازی) سقف دقت مدل‌های برتر را به ۲۵٪ محدود می‌کنند، در حالی که این رقم برای زنجیره‌های صرفاً موازی یا متوالی بین ۵۴ تا ۶۲ درصد است. وقتی یک وظیفه نیازمند یک توزیع موازی (parallel fan-out) و پس از آن یک ادغام متوالی (sequential merge) باشد، مشکل هماهنگی از توانایی فعلی هر مدلی برای مدیریت قابل اطمینان فراتر می‌رود.
• نیت پنهان شکافی بزرگتر از آنچه قبلاً تصور می‌شد است: بنچ‌مارک WildToolBench تضمین می‌کند که ۱۰۰٪ وظایف شامل اطلاعات ضمنی یا بین‌مرحله‌ای باشند؛ در حالی که BFCL v3 تنها ۱۵.۷٪ را پوشش می‌دهد. وظایف با وابستگی دوربرد — جایی که اطلاعات مفقود شده مربوط به بیش از دو مرحله قبل است — دشوارترین نوع فرعی هستند و هیچ مدلی حتی در سطح وظیفه نتوانسته دقت ۵۰٪ را بشکند.
• انتقال‌های دستورالعمل خطاها را با نرخ خطی افزایش می‌دهند: هر سوئیچ سیاستی اضافی (وظیفه ابزار ← چت ← شفاف‌سازی ← وظیفه ابزار) دقت را تقریباً ۵ تا ۱۵ واحد درصد کاهش می‌دهد. در سه انتقال، مدل‌هایی که بیشترین تأثیر را پذیرفته‌اند ۳۰ واحد از دست می‌دهند. نویسندگان این پدیده را «خود-شرطی‌سازی» (self-conditioning) می‌نامند: پاسخ‌های قبلی باعث سوگیری در تفسیر مدل از دستورالعمل‌های بعدی می‌شوند، به گونه‌ای که اصلاح آن در میانه جلسه دشوار است.
• نرخ مسیر بهینه (Optimal Path Rate) زیر ۴۳٪ باقی می‌ماند: حتی زمانی که مدل‌ها وظایف را به درستی انجام می‌دهند، فراخوانی‌های API اضافی مصرف می‌کنند. Claude-4-Sonnet بهترین نرخ مسیر بهینه را با ۴۲.۷۴٪ به دست آورده است، به این معنی که اکثریت تکمیل‌های صحیح، گام‌های بیشتری از حد لازم برمی‌دارند — که هزینه‌ای مستقیم در تاخیر و توکن برای هر سیستم عملیاتی محسوب می‌شود.
• مدل‌های تخصصی استفاده از ابزار ضعیف‌تر از مدل‌های عمومی پیشرو عمل می‌کنند: مدل‌های xLAM-2-70B و ToolACE2-8B هر دو نرخ خطای نام‌گذاری اشتباه تابع بیش از ۳۰٪ را ثبت کرده‌اند که بدتر از GPT-4o یا Claude-4-Sonnet است. به نظر می‌رسد تنظیم دقیق (Fine-tuning) روی مجموعه‌داده‌های محدود استفاده از ابزار، به جای ایجاد استحکام، باعث شکنندگی مدل در هنگام مواجهه با تغییر توزیع به سمت رفتار واقعی کاربران می‌شود.

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

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

نقطه ضعف آن مقیاس است. ۱۰۲۴ وظیفه از ۲۵۶ سناریو برای یک اثر پژوهشی معتبر است، اما برای جدول امتیازاتی که قصد ردیابی ۵۷ مدل را در طول زمان دارد، کم به نظر می‌رسد. نویسندگان مستقیماً به این موضوع اذعان کرده و به یک خط لوله مقیاس‌بندی خودکار در کارهای آینده اشاره کرده‌اند. مسئله دیگر این است که عبارت «بر پایه گزارش‌های واقعی کاربران» بار سنگینی را به دوش می‌کشد: وظایف نهایی تا حدودی مصنوعی هستند و توسط یک سیستم چند-عاملی از الگوهای اولیه ساخته شده و سپس توسط ارزیاب‌های انسانی تایید شده‌اند. ادعا ریشه در واقعیت دارد اما داده‌ها دقیقاً همان چیزی نیست که در دنیای واقعی رخ داده — بلکه الهام‌گرفته از آن است. این موضوع در نحوه تفسیر لفظی سقف ۱۵ درصدی اهمیت دارد؛ اگر خط لوله تولید داده دشواری‌های مصنوعی ایجاد کرده باشد که کاربران واقعی عملاً از خود نشان نمی‌دهند، بخشی از این شکاف ممکن است پر شود.

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

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

سه حالت شکست ذکر شده دقیقاً با نحوه تعامل کاربران واقعی با یک عامل ثبت تراکنش (write-back) در Beancount مطابقت دارد. کاربر می‌پرسد: «ماه گذشته چقدر برای خواربار هزینه کردم، و در ضمن رسید امروز Whole Foods را هم اضافه کن» — این یک وظیفه ترکیبی است که در یک نوبت ارائه شده است. سپس ادامه می‌دهند: «در واقع مبلغ را ۴۷.۲۳ دلار بگذار نه ۴۲ دلار، الان چک کردم» — این یک اصلاح پارامتر است که مستلزم ردیابی وضعیت جلسه توسط عامل است. سپس می‌پرسند: «آیا آن دسته‌بندی درست است؟» — این یک درخواست شفاف‌سازی است و عامل نباید عملیات ثبتی را که همین الان تمام کرده دوباره اجرا کند. سقف ۲۵ درصدی در سازمان‌دهی ترکیبی مختلط و افت ۳۰ واحدی ناشی از انتقال‌های دستورالعمل، دقیقاً همان حالت‌های شکستی هستند که در یک عامل دفتر کل (ledger agent) در مواجهه با جلسات واقعی کاربران ظاهر می‌شوند.

یافته‌ای که نشان می‌دهد مدل‌های تخصصی استفاده از ابزار ضعیف‌تر از مدل‌های عمومی پیشرو عمل می‌کنند، به ویژه مرتبط است. اگر ما به فکر تنظیم دقیق یک مدل متن‌باز کوچک‌تر روی نمونه‌های فراخوانی ابزار خاص Beancount بودیم — که راهکاری بدیهی برای کاهش هزینه است — WildToolBench یک هشدار مستقیم است که تخصص ممکن است استحکام در برابر توزیع رفتارهای واقعی کاربران را قربانی کند. یافته نرخ مسیر بهینه نیز مهم است: عاملی که برای تکمیل یک وظیفه دو برابر بیشتر از API استفاده می‌کند، فقط ناکارآمد نیست؛ برای عملیات‌های ثبت تراکنش، فراخوانی‌های میانی تکراری می‌تواند دفتر کل را در وضعیت‌های میانی ناسازگار رها کند.

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

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — چارچوب آموزشی بنیادی که WildToolBench صراحتاً خود را در مقابل آن قرار می‌دهد؛ درک طراحی ارزیابی مصنوعی آن، دقیقاً نشان می‌دهد که اجرای زنده چه ارزشی را اضافه می‌کند.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — نزدیک‌ترین کار قبلی در زمینه استفاده واقعی از ابزار در چند مرحله؛ مقایسه دامنه‌های خرده‌فروشی/هواپیمایی در τ-bench با پوشش API عمومی در WildToolBench نشان می‌دهد که این چالش چقدر تعمیم‌پذیر است.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — اگر مشکل انتقال دستورالعمل از طریق کشف خودکار جریان‌های کاری بهتر برای عامل‌ها (به جای مقیاس‌بندی داده‌های آموزشی) قابل حل باشد، AFlow معتبرترین مکانیسم برای انجام این کار است.

مقاله​

گنگ، کای، وانگ، کوپل، ناکوف و گورویچ ادبیات نوظهور در زمینه تخمین اعتماد و کالیبراسیون LLM را در وظایف مختلف از پرسش و پاسخ چندگزینه‌ای تا تولید متن باز و ترجمه ماشینی بررسی می‌کنند. مشکل اصلی: LLMها می‌توانند هم بسیار دقیق باشند و هم کاملاً غیرقابل اعتماد، به شکلی که تشخیص این دو حالت از بیرون بسیار سخت است. این پیمایش فضای راه‌حل را به دو شاخه اصلی تقسیم می‌کند — روش‌های جعبه-سفید که از دسترسی به وضعیت‌های داخلی مدل بهره می‌برند، و روش‌های جعبه-سیاه که با مدل به عنوان یک ساختار مات برخورد می‌کنند — و در هر کدام، تمایز بیشتری بین تخمین اعتماد و کالیبراسیون پسینی (post hoc) قائل می‌شود.

این مقاله در NAACL 2024 (صفحات ۶۵۷۷–۶۵۹۵) منتشر شد که نسخه اصلاح شده در مارس ۲۰۲۴ از ارسالی در نوامبر ۲۰۲۳ توسط تیمی از دانشگاه TU Darmstadt، MBZUAI و دانشگاه هوش مصنوعی محمد بن زاید است.

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

• اعتماد جعبه-سفید از طریق لوجیت‌ها: ساده‌ترین رویکرد از احتمالات در سطح توکن یا لگاریتم احتمال نرمال‌سازی شده بر اساس طول به عنوان سیگنال اعتماد استفاده می‌کند. این روش‌ها کار می‌کنند اما با یک ابهام اساسی روبرو هستند: احتمال پایین توکن می‌تواند بازتاب دهنده اعتماد پایین به واقعیت باشد یا صرفاً یک عبارت‌بندی غیرمعمول — مدل ممکن است در مورد انتخاب کلمات مردد باشد در حالی که نسبت به واقعیت زیربنایی اطمینان دارد.

• اعتماد جعبه-سیاه مبتنی بر سازگاری (SelfCheckGPT): ماناکول و همکاران (EMNLP 2023) چندین نمونه خروجی را نمونه‌برداری کرده و سازگاری متقابل آن‌ها را با استفاده از BERTScore، NLI یا همپوشانی n-gram امتیازدهی می‌کنند. در اینجا نیازی به دسترسی به لوجیت نیست. بصیرت کلیدی: برای واقعیت‌هایی که LLM به خوبی می‌داند، نمونه‌های مکرر همگرا می‌شوند؛ برای واقعیت‌های توهمی، آن‌ها واگرا می‌شوند.

• آنتروپی معنایی: فارکوهار و همکاران (Nature, 2024) پاسخ‌های معادل از نظر معنایی را قبل از محاسبه آنتروپی خوشه‌بندی می‌کنند. یک LLM ممکن است "پاریس" و "پایتخت فرانسه" را متفاوت بیان کند — آنتروپی خام توکن این‌ها را واگرا می‌بیند، اما آنتروپی معنایی خیر. این یک گام کیفی رو به جلو نسبت به سازگاری در سطح توکن است که این پیمایش آن را زمینه‌سازی می‌کند.

• اعتماد کلامی ناکارآمد است: وقتی از مدل‌ها خواسته می‌شود درصد اعتماد خود را خروجی دهند، آن‌ها دچار بیش‌اطمینانی می‌شوند. کارهای تجربی (گروت و همکاران، TrustNLP در ACL 2024) نشان می‌دهد که GPT-3، GPT-3.5 و Vicuna همگی میانگین خطای کالیبراسیون مورد انتظار (ECE) بیش از ۰.۳۷۷ را برای اعتماد کلامی نشان می‌دهند، و پیش‌بینی‌ها بدون توجه به دقت واقعی در محدوده ۹۰–۱۰۰٪ خوشه‌بندی می‌شوند. حتی GPT-4 — که بهترین مدل کالیبره شده ارزیابی شده است — در هنگام استفاده از اعتماد کلامی برای تمایز بین پاسخ‌های درست و غلط، تنها به AUROC حدود ۶۲.۷٪ دست می‌یابد که به سختی بالاتر از شانس است.

• تکنیک‌های کالیبراسیون بسته به وظیفه متفاوت است: برای طبقه‌بندی، کالیبراسیون زمینه‌ای (کاهش سوگیری پیشین کلاس تخمین زده شده با یک پرامپت خالی "[N/A]") و رفع سوگیری موقعیتی (PriDE) به سوگیری‌های سیستماتیک شناخته شده می‌پردازند. برای تولید متن، کالیبراسیون احتمال توالی (SLiC) مدل‌ها را روی خروجی‌های رتبه‌بندی شده تنظیم دقیق می‌کند. مقیاس‌بندی دما (Temperature scaling) — ساده‌ترین اصلاح پسینی — در بسیاری از تنظیمات همچنان رقابتی باقی مانده است.

• هیچ بنچمارک واحدی وجود ندارد: مخرب‌ترین مشاهده ساختاری این پیمایش: هیچ بنچمارک واحدی وجود ندارد که روش‌های تخمین اعتماد را در وظایف و حوزه‌های مختلف پوشش دهد. این موضوع مقایسه دقیق روش‌ها را تقریباً غیرممکن می‌کند. این حوزه در حال مقایسه سیب با پرتقال است.

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

طبقه‌بندی ارائه شده مستحکم است. تمایز جعبه-سفید در مقابل جعبه-سیاه برای طراحی سیستم واقعاً مفید است، و برخورد با روش‌های مبتنی بر لوجیت در مورد محدودیت‌های آن‌ها صادقانه است — نویسندگان مستقیماً اشاره می‌کنند که احتمال توکن، اعتماد واقعی را با عدم قطعیت واژگانی خلط می‌کند. متخصصان معمولاً این خلط شدن را دست‌کم می‌گیرند.

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

نتایج اعتماد کلامی — AUROC حدود ۶۲.۷٪ برای خودِ اعتماد اعلام شده توسط GPT-4 — باید برای هر کسی که LLMها را در محیط عملیاتی مستقر می‌کند، یک دانش پایه و بدیهی باشد. اما اینطور نیست. مردم هنوز پرامپت‌هایی می‌فرستند که می‌پرسد "در مقیاس ۱ تا ۱۰، چقدر مطمئن هستی؟" و با پاسخ آن به عنوان یک مقدار معنادار برخورد می‌کنند. در حالی که اینطور نیست.

این پیمایش همچنین در مورد سوال کالیبراسیون RLHF ضعیف عمل کرده است: آیا آموزش پسینی با بازخورد انسانی کالیبراسیون مدل‌ها را بهتر می‌کند یا بدتر؟ شواهدی برای هر دو طرف وجود دارد و این پیمایش تا حد زیادی از آن عبور می‌کند.

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

داستان ایمنی ReDAct بر داشتن یک سیگنال عدم قطعیت کالیبره شده از مدل ارزان بنا شده است. این پیمایش روشن می‌کند که این کار در واقع چقدر دشوار است. سیگنال‌های مبتنی بر لوجیت در تنظیمات جعبه-سفید در دسترس هستند اما عدم قطعیت واژگانی و واقعی را با هم ترکیب می‌کنند. روش‌های مبتنی بر سازگاری در تنظیمات جعبه-سیاه کار می‌کنند اما به چندین نمونه به ازای هر تصمیم نیاز دارند — که برای یک عامل بازنویسی Beancount با توان عملیاتی بالا که دسته‌ای از ردیف‌های تراکنش را پردازش می‌کند، گران تمام می‌شود.

عملیاتی‌ترین یافته برای Bean Labs: آنتروپی معنایی، پاسخ‌های معادل از نظر معنایی را قبل از امتیازدهی سازگاری خوشه‌بندی می‌کند، که دقیقاً همان چیزی است که برای ردیف‌های دفتر کل اهمیت دارد؛ جایی که یک مدل ممکن است همان رابطه بدهکار/بستانکار را در چندین فرم نحوی متمایز بیان کند. یک عامل Beancount باید از خوشه‌بندی معنایی روی خروجی‌های نمونه‌برداری شده تراکنش‌ها استفاده کند — نه واریانس خام در سطح توکن — تا متوجه شود چه زمانی در حال توهم زدن نام یک حساب یا یک مبلغ است.

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

مطالعه بیشتر​

• Farquhar et al., "Detecting hallucinations in large language models using semantic entropy," Nature, 2024 — دقیق‌ترین روشی که از این چارچوب پیمایش بیرون می‌آید؛ ارزشش را دارد که به جای خلاصه پیمایش، متن کامل آن خوانده شود.
• Manakul et al., "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," EMNLP 2023 (arXiv:2303.08896) — روش مرجع مبتنی بر سازگاری؛ درک آن قبل از استقرار هرگونه سیگنال اعتماد جعبه-سیاه ضروری است.
• Groot et al., "Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models," TrustNLP at ACL 2024 (arXiv:2405.02917) — کامل‌ترین بازرسی تجربی از اینکه چگونه اعتماد کلامی در مدل‌ها و وظایف مختلف از کار می‌افتد.

مقاله​

سایبو گنگ، هادسون کوپر، میخال موسکال و همکارانشان در بخش تحقیقات مایکروسافت، JSONSchemaBench را معرفی کردند؛ بنچمارکی شامل ۹,۵۵۸ شما که از منابع واقعی تولیدی استخراج شده‌اند: امضاهای فراخوانی تابع GlaiveAI، مخازن گیت‌هاب که بر اساس پیچیدگی از ساده تا بسیار پیچیده دسته‌بندی شده‌اند، پیکربندی‌های API کوبرنتیز، شماهای تحلیل رویداد Snowplow و مجموعه JSONSchemaStore. آن‌ها شش چارچوب رمزگشایی محدود شده — Guidance، Outlines، Llamacpp، XGrammar، OpenAI Structured Outputs و Gemini — را در سه محور ارزیابی کردند: پوشش (چه بخشی از شماها توسط چارچوب قابل مدیریت است)، کارایی (سربار توکن در ثانیه در مقایسه با تولید نامحدود)، و کیفیت (دقت وظایف پایین‌دستی). جدول ارزیابی همچنین شامل مجموعه تست رسمی JSON Schema است که ۴۵ دسته‌بندی ویژگی را که هر موتور منطبقی باید از آن‌ها پشتیبانی کند، مستند می‌کند.

ادعای اصلی این است که پیچیدگی شِما، متغیر تعیین‌کننده‌ای است که چارچوب‌های توانمند را از چارچوب‌های شکننده جدا می‌کند و هیچ چارچوب واحدی در هر سه محور برتری ندارد.

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

• فروپاشی پوشش تحت پیچیدگی شِما. در شماهای ساده GlaiveAI، تمام چارچوب‌ها امتیازی بالای ۸۶٪ کسب کردند. اما در شماهای پیچیده گیت‌هاب (GitHub-Hard) — که شامل تودرتویی چندسطحی، تعاریف بازگشتی و محدودیت‌های الگوی پیچیده هستند — پوشش Guidance به ۴۱٪، Llamacpp به ۳۹٪، XGrammar به ۲۸٪ و Outlines به مقدار فاجعه‌بار ۳٪ سقوط کرد. OpenAI تنها به ۹٪ در GitHub-Hard رسید و Gemini در شماهای با پیچیدگی متوسط یا بالاتر، هیچ خروجی معتبری تولید نکرد.
• کوبرنتیز ضعف خاصی را در XGrammar آشکار می‌کند. علی‌رغم ادعاهای سرعت XGrammar، این چارچوب تنها به ۷٪ پوشش در شماهای کوبرنتیز دست یافت؛ احتمالاً به این دلیل که این شماها به الگوهای وابسته به متن متکی هستند که پیش‌محاسبات مستقل از متن XGrammar نمی‌تواند آن‌ها را مدیریت کند. پوشش در برابر بنچمارکی که شامل پیکربندی‌های کوبرنتیز است، برای عوامل تولیدی (production agents) اختیاری نیست.
• محدودیت ناقص خطرناک‌تر از خطای کامپایل است. XGrammar در برابر مجموعه تست JSON Schema، دچار ۳۸ مورد شکست در اعمال محدودیت شد — به این معنی که خروجی JSON تولید کرد که شِمای اعلام شده را نقض می‌کرد، اما وضعیت موفقیت را گزارش داد. Guidance تنها ۱ مورد از این شکست‌ها را داشت. برای یک عامل بازنویسی (write-back agent)، خطای کامپایل در زمان طراحی شناسایی می‌شود؛ اما شکست در اعمال محدودیت باعث فاسد شدن داده‌ها در زمان اجرا بدون هیچ سیگنالی می‌شود.
• قابلیت fast-forwarding در Guidance بهبود واقعی ۵۰ درصدی سرعت را به همراه دارد. زمانی که توالی‌های قطعی طولانی وجود داشته باشند (مثلاً نام فیلدها در یک ساختار ثابت شیء)، Guidance می‌تواند چندین توکن را در هر مرحله رمزگشایی به جلو ببرد. در مدل Llama-3.1-8B روی کارت A100، اجرای Guidance حدود ۶ تا ۹ میلی‌ثانیه به ازای هر توکن خروجی طول می‌کشد، در حالی که تولید نامحدود ۱۵ تا ۱۶ میلی‌ثانیه زمان می‌برد. Outlines با ۳۰ تا ۴۶ میلی‌ثانیه از تولید نامحدود کندتر است که عمدتاً به دلیل کامپایل اولیه خودکار (automaton compilation) است که ۳ تا ۸ ثانیه برای هر شِما زمان می‌برد.
• رمزگشایی محدود شده به میزان کمی دقت استدلال را بهبود می‌بخشد. در بنچمارک GSM8K (ریاضی)، Guidance دقت را از ۸۰.۱٪ (نامحدود) به ۸۳.۸٪ افزایش داد. در وظایف Last Letter و Shuffle Objects، بهبودها در محدوده ۱ تا ۳ واحد بود. این موضوع با نگرانی‌های گسترده مبنی بر اینکه اجبار به فرمت JSON کیفیت پاسخ را کاهش می‌دهد، در تضاد است — اما اندازه اثر به قدری کوچک است که انتخاب فرمت نباید عامل اصلی در انتخاب چارچوب باشد.
• هیچ چارچوبی تمام ۴۵ دسته‌بندی ویژگی JSON Schema را پوشش نمی‌دهد. Guidance تعداد ۱۳ دسته، Llamacpp و XGrammar هر کدام ۱ دسته و Outlines صفر دسته را پوشش می‌دهند. پیامد عملی این است که هر شمایی که از if/then/else ،unevaluatedProperties یا تعاریف بازگشتی $ref استفاده می‌کند، بسته به اینکه چه موتوری در پس‌زمینه است، رفتاری غیرقابل پیش‌بینی خواهد داشت.

چه چیزی درست است و چه چیزی نیست​

قوی‌ترین سهم این بنچمارک، تامین منابع شِما است. ارزیابی‌های قبلی از شماهای اسباب‌بازی یا مجموعه‌های تک‌منبعی استفاده می‌کردند. گنجاندن پیکربندی‌های کوبرنتیز در کنار امضاهای فراخوانی تابع، نوع درستی از تنوع تقابلی است. دسته‌بندی پیچیدگی (از بدیهی تا فوق‌پیچیده) همچنین به متخصصان یک منحنی کالیبراسیون می‌دهد: اگر شماهای شما شبیه فراخوانی‌های تابع GlaiveAI هستند، XGrammar یا Guidance هر دو مناسب هستند؛ اما اگر شبیه مانیفست‌های کوبرنتیز هستند، گزینه‌های شما به سرعت محدود می‌شوند.

نقطه ضعف اصلی، ارزیابی حریصانه (greedy) تک‌نمونه‌ای است. اندازه‌گیری پوشش با تنها یک بار تولید به ازای هر شِما، توانایی واقعی را کمتر از حد نشان می‌دهد — یک چارچوب ممکن است ۲۰٪ مواقع شکست بخورد اما در تلاش مجدد موفق شود. مقاله به این موضوع اذعان دارد اما اعداد pass@k نمونه‌برداری شده با دما (temperature-sampled) را گزارش نمی‌دهد، که برای سیستم‌های تولیدی که در صورت شکست دوباره تلاش می‌کنند، اهمیت دارد.

همچنین این مقایسه مدل‌های غیرقابل مقایسه را با هم ترکیب می‌کند. چارچوب‌های متن‌باز (Guidance, Outlines, Llamacpp, XGrammar) روی Llama-3.2-1B تست شده‌اند، در حالی که OpenAI و Gemini مدل‌های افشا نشده خود را اجرا می‌کنند. پوشش ۹ درصدی OpenAI در GitHub-Hard ممکن است به اندازه معماری رمزگشایی محدود شده، بازتاب‌دهنده توانایی مدل باشد. یک مقایسه منصفانه مستلزم دسترسی کنترل‌شده به مدل است — که نویسندگان بدیهی است نمی‌توانند ارائه‌دهندگان انحصاری را به آن مجبور کنند.

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

هر عامل بازنویسی Beancount خروجی ساختاریافته تولید می‌کند. اگر عامل، دستورالعمل‌های Beancount را قبل از تبدیل به نحو .beancount به صورت JSON تولید کند، یا اگر ابزارها را از طریق شماهای JSON فراخوانی کند، قابلیت اطمینان آن تولید JSON یک جزئیات نیست — بلکه تمام ماجراست. مقاله FinTrace نشان داد که مدل‌های پیشرو در استدلال بر روی خروجی ابزارها شکست می‌خورند؛ JSONSchemaBench مشکلی موازی را آشکار می‌کند: حتی قبل از استدلال، لایه قالب‌بندی ممکن است بی‌صدا خروجی غیرمنطبق صادر کند.

نتیجه کوبرنتیز به ویژه برای Beancount گویا است. شِماهای دفتر کل (Ledger schemas) صرفاً مجموعه‌ای از جفت‌کلید-مقدارهای مسطح نیستند. سلسله مراتب حساب‌ها، متادیتای تراکنش‌ها و ساختارهای برچسب، الگوهای بازگشتی تودرتویی ایجاد می‌کنند که مشابه اشیاء API کوبرنتیز هستند. چارچوبی که در کوبرنتیز امتیاز ۷٪ می‌گیرد، برای شماهای پیچیده دفتر کل آماده نیست، صرف‌نظر از اینکه سربار هر توکن آن چقدر سریع باشد.

حالت شکستِ محدودیت ناقص (under-constrained failure) چیزی است که خواب را از چشمان من می‌رباید. یک عامل Beancount که از XGrammar استفاده می‌کند، می‌تواند تراکنشی صادر کند که بررسی اعتبارسنجی داخلی چارچوب را پشت سر بگذارد اما شِمای واقعی را نقض کند — و عامل هیچ دلیلی برای تلاش مجدد نخواهد داشت. فساد بی‌صدا بدتر از شکست آشکار است.

موارد بعدی برای مطالعه​

• XGrammar (arXiv:2411.15100, Dong et al.) — مقاله فنی پشت یکی از سریع‌ترین چارچوب‌های تست شده، که تقسیم توکن‌های مستقل/وابسته به متن و علت فشار شماهای کوبرنتیز بر آن را توضیح می‌دهد.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — نشان می‌دهد که ماسک کردن توکن در رمزگشایی محدود شده می‌تواند توزیع احتمال مدل را تغییر دهد و یک الگوریتم نمونه‌برداری اصلاح‌شده پیشنهاد می‌کند؛ مبنای تئوریک برای نگرانی‌های کیفی که بنچمارک تنها به طور غیرمستقیم اندازه‌گیری می‌کند.
• XGrammar-2 (arXiv:2601.04426) — دنباله‌ای که XGrammar را به شماهای پویا در محیط‌های عاملی (agentic) گسترش می‌دهد، جایی که خودِ شِما در طول یک جلسه چندمرحله‌ای تغییر می‌کند؛ موضوعی که مستقیماً برای عوامل Beancount که فرمت خروجی خود را بر اساس نوع حساب‌های فعال تطبیق می‌دهند، مرتبط است.

مقاله‌ی علمی​

جی ژو، ییمین تیان و همکارانشان از تیم Qwen DianJin در Alibaba Cloud، مدیریت ثروت YINGMI و دانشگاه سوچو، FinMCP-Bench را معرفی می‌کنند؛ یک مجموعه ارزیابی با ۶۱۳ نمونه که ۱۰ دسته سناریوی مالی و ۳۳ زیرسناریو را پوشش می‌دهد. ابزارها شبیه‌سازی شده نیستند — ۶۵ سرور ابزار مالی واقعی و سازگار با MCP پشتوانه‌ی این معیار سنجش هستند که از لاگ‌های تولیدی واقعی دستیار مالی Qieman APP استخراج شده‌اند. نویسندگان نمونه‌ها را به سه نوع دسته‌بندی می‌کنند: ۱۴۵ مورد تک‌ابزاری، ۲۴۹ مورد چندابزاری و ۲۱۹ مورد چند نوبتی. آن‌ها شش مدل را آزمایش می‌کنند: خانواده Qwen3 با تعداد پارامترهای ۴ میلیارد، ۳۰ میلیارد و ۲۳۵ میلیارد (همگی با تفکر گسترده)، به علاوه DeepSeek-R1، GPT-OSS-20B و Seed-OSS-36B. معیارهای اصلی ارزیابی عبارتند از: دقت ابزار (Tool Precision)، بازیابی ابزار (Tool Recall)، امتیاز F1 ابزار و نرخ تطبیق دقیق (EMR) که مستلزم آن است که هر فراخوانی ابزار در یک توالی دقیقاً درست باشد.

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

• MCP به عنوان بستر ارزیابی: استفاده از تعاریف واقعی سرور MCP به جای طرح‌های API مصنوعی، شکاف بزرگ بین ارزیابی معیار سنجش و آنچه عامل‌ها واقعاً در سیستم‌های مالی مستقر شده با آن روبرو هستند را پر می‌کند.
• تقسیم‌بندی دشواری سه‌گانه: نمونه‌های تک‌ابزاری، چندابزاری و چند نوبتی صرفاً تفاوت کمی ندارند — آن‌ها حالت‌های شکست متفاوتی را از نظر کیفی آشکار می‌کنند.
• فروپاشی چند نوبتی: بهترین مدل (Qwen3-235B) به ۶۰٪ EMR در تک‌ابزاری، ۱۰.۶۲٪ EMR در چندابزاری و ۳.۰۸٪ EMR در چند نوبتی دست می‌یابد. افت از تک‌ابزاری به چند نوبتی ۲۰ برابر است.
• Tool F1 بخشنده‌تر است: همان مدل در این سه تنظیمات به ترتیب امتیازهای ۶۶.۸۵٪، ۶۹.۴۲٪ و ۴۱.۵۶٪ TF1 را کسب می‌کند — که نشان می‌دهد مدل‌ها اغلب ابزارهای درست را انتخاب می‌کنند اما در ترتیب‌بندی، پارامترگذاری یا پیگیری گفتگو دچار اشتباه می‌شوند.
• برتری بازیابی نسبت به دقت در تک‌ابزاری: مدل‌ها تمایل دارند در صورت عدم اطمینان، ابزارها را بیش از حد فراخوانی کنند تا کمتر از حد، که حالت شکست ایمن‌تری برای وظایف مالی است اما همچنان به معنای فراخوانی‌های API هدر رفته و نویز در مسیر استدلال است.
• مقیاس‌پذیری غیریکنواخت اندازه: Qwen3-30B به طور مداوم در تمام زیرسناریوها از Qwen3-4B بهتر عمل نمی‌کند و این فرض را که مدل‌های بزرگتر همیشه در استفاده از ابزارهای چند مرحله‌ای پیروز می‌شوند، می‌شکند.

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

استفاده از لاگ‌های تولیدی واقعی به عنوان منبع برای مثال‌های تک‌ابزاری، قوی‌ترین انتخاب روش‌شناختی در اینجا است. این کار معیار سنجش را به رفتار واقعی کاربر متصل می‌کند تا سناریوهای ابداع شده توسط پژوهشگران، که در ادبیات هوش مصنوعی مالی نادر است. نمونه‌های چندابزاری و چند نوبتی با استفاده از گراف‌های وابستگی و پرامپت‌های نقش‌آفرینی به صورت مصنوعی گسترش یافته‌اند، که با توجه به هزینه برچسب‌گذاری معقول است، اما ریسکی را به همراه دارد: فرآیند ترکیب تمایل دارد پرس‌وجوهای تمیزتر و واضح‌تری نسبت به آنچه کاربران واقعی می‌نویسند تولید کند. EMR ۳.۰۸ درصدی در چند نوبتی نگران‌کننده است اما باید با دقت تفسیر شود — EMR مستلزم آن است که کل توالی دقیقاً درست باشد، بنابراین یک فراخوانی اشتباه ابزار میانی باعث شکست کل وظیفه می‌شود. این یک استاندارد تولید سخت‌گیرانه و مسلماً غیرواقعی است؛ معیارهای امتیازدهی جزئی مانند TF1 داستان دقیق‌تری را بیان می‌کنند.

آنچه مقاله به آن نمی‌پردازد: تحلیلی وجود ندارد که آیا شکاف عملکرد در درجه اول یک مشکل درک ورودی است (مدل آنچه را که کاربر می‌خواهد اشتباه تفسیر می‌کند)، یک مشکل قالب‌بندی خروجی (قصد درست اما فراخوانی ابزار بدشکل)، یا یک مشکل استدلال (نتایج میانی اشتباه). بدون این تجزیه و تحلیل، سخت است بدانیم تلاش مهندسی را باید کجا سرمایه‌گذاری کرد. مقاله همچنین مدل‌ها را به صورت ایزوله ارزیابی می‌کند؛ هیچ آزمونی وجود ندارد که آیا افزودن یک مرحله تأیید یا تامل (reflection) تصویر چند نوبتی را تغییر می‌دهد یا خیر.

این معیار سنجش همچنین عمیقاً به ۶۵ ابزار خاص Qieman وابسته است، که انتقال نتایج به سایر پلتفرم‌های مالی با موجودی ابزارهای متفاوت را محدود می‌کند.

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

FinMCP-Bench نزدیک‌ترین ارزیابی منتشر شده به کاری است که یک عامل نوشتن (write-back) در Beancount واقعاً انجام می‌دهد: دریافت درخواست کاربر، شناسایی اینکه کدام ابزار (یا زنجیره‌ای از ابزارها) کاربرد دارد، فراخوانی آن‌ها به ترتیب و مدیریت نوبت‌های بعدی. EMR ۳.۰۸ درصدی در چند نوبتی، یک واقعیت تلخ است. یک عامل Beancount که اصلاح دفترکل چند مرحله‌ای را مدیریت می‌کند — مثلاً طبقه‌بندی مجدد مجموعه‌ای از تراکنش‌ها بین حساب‌ها در یک بازه زمانی، سپس مطابقت (reconciliation) و سپس تولید گزارش — دقیقاً همان نوع وظیفه چند نوبتی و چندابزاری است که مدل‌های فعلی تقریباً به طور کامل بر اساس استانداردهای تطبیق دقیق در آن شکست می‌خورند.

چارچوب MCP مستقیماً مرتبط است: API پایتون Beancount، رابط beanquery و لایه REST نرم‌افزار fava همگی می‌توانند به عنوان سرورهای MCP بسته‌بندی شوند. FinMCP-Bench به ما می‌گوید که پروتکل گلوگاه نیست — بلکه استدلال روی توالی‌های فراخوانی ابزار گلوگاه است.

یافته‌ای که نشان می‌دهد بازیابی ابزار از دقت فراتر می‌رود (مدل‌ها بیش از حد فراخوانی می‌کنند) برای ایمنی عملیات نوشتن نیز مهم است: عاملی که ابزار تغییر دفترکل را زمانی فراخوانی می‌کند که فقط خواندن لازم بوده، می‌تواند دفترکل را بی‌صدا فاسد کند. معیارهای ارزیابی با سوگیری به سمت دقت (precision-biased)، و نه سوگیری به سمت بازیابی، باید سیگنال ایمنی اولیه برای عامل‌های نوشتن باشند.

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

• JSONSchemaBench (arXiv:2501.10868) — قابلیت اطمینان خروجی ساختاریافته را در ۱۰ هزار طرح‌واره JSON ارزیابی می‌کند؛ مستقیماً به این موضوع می‌پردازد که آیا شکست‌های قالب‌بندی فراخوانی ابزار در FinMCP-Bench یک مشکل رمزگشایی محدود شده است یا خیر.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — چارچوب آموزشی بنیادی استفاده از ابزار که FinMCP-Bench خود را در برابر آن قرار می‌دهد؛ درک کاوش درخت جستجوی اول‌عمق آن روشن می‌کند که روش‌شناسی لاگ تولیدی FinMCP-Bench چه چیزی به آن اضافه می‌کند.
• WildToolBench (arXiv:2604.06185) — استفاده از ابزار را در پرس‌وجوهای واقعی کاربران در دنیای واقعی ارزیابی می‌کند؛ یافته‌ی آن مبنی بر اینکه هیچ مدلی در رفتار کاربران واقعی از دقت ۱۵٪ فراتر نمی‌رود، مکمل رویکرد لاگ تولیدی FinMCP-Bench است.

مقاله​

کائو و همکاران، FinTrace را معرفی می‌کنند؛ بنچمارکی شامل ۸۰۰ مسیر (trajectory) با حاشیه‌نویسی متخصص که ۳۴ دسته از وظایف مالی دنیای واقعی را در سطوح دشواری آسان، متوسط و سخت در بر می‌گیرد. نویسندگان ارزیابی خود را حول مجموعه‌ای از ۹ معیار سازماندهی شده در چهار محور بنا می‌کنند: صحت عمل (F1 فراخوانی ابزار، ارتباط با وظیفه)، کارایی اجرا (کارایی گام‌ها، نمره افزونگی)، کیفیت فرآیند (پیشرفت منطقی، بهره‌وری اطلاعات، نمره پیشرفت) و کیفیت خروجی (نرخ موفقیت وظیفه، کیفیت پاسخ نهایی). آن‌ها ۱۳ مدل زبانی بزرگ را ارزیابی کرده و همچنین FinTrace-Training را منتشر می‌کنند که مجموعه‌ای از ۸,۱۹۶ مسیر ترجیحی انتخاب شده برای تنظیم دقیق (fine-tuning) است.

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

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

• بهترین مدل، Claude-Opus-4.6، به امتیاز F1 فراخوانی ابزار ۰.۸۹۶ دست می‌یابد — که انتخاب قدرتمندی است — اما در بهره‌وری اطلاعات، که ضعیف‌ترین معیار در بین چهار معیار مربوط به خروجی است، تنها امتیاز ۳.۲۳ از ۵ را کسب می‌کند.
• نرخ موفقیت وظیفه Claude-Opus-4.6 برابر ۲.۶۵ از ۵ و کیفیت پاسخ نهایی آن ۳.۳۴ از ۵ است؛ حتی برترین مدل نیز به طور مداوم پاسخ‌های صحیح و کامل تولید نمی‌کند.
• مدل Qwen-3.5-9B الگوی ناقصی را نشان می‌دهد: کارایی گام (۱.۰۰۰) و افزونگی (۱.۰۰۰) نزدیک به کامل، زیرا تقریباً هیچ ابزاری را فراخوانی نمی‌کند که در F1 فراخوانی ابزار ۰.۱۰۹ منعکس شده است. کارآمد اما بی‌استفاده.
• آموزش بر روی FinTrace-Training معیارهای فرآیند میانی را بهبود می‌بخشد (پیشرفت منطقی با DPO از ۲.۲۹ به ۲.۵۶ و نمره پیشرفت از ۲.۰۰ به ۲.۳۰ افزایش می‌یابد)، اما کیفیت پاسخ نهایی همچنان محدود باقی می‌ماند — هیچ نسخه‌ای در مدل‌های کوچک به طور قابل توجهی از میانگین ۱.۲۱ در مقیاس ۱ تا ۵ فراتر نمی‌رود.
• روش DPO در سرکوب حالت‌های شکست فاجعه‌بار از SFT بهتر عمل می‌کند: سهم نمرات پیشرفت منطقی با امتیاز ۱، از ۱۱.۹٪ (SFT) به ۹.۵٪ (DPO) کاهش می‌یابد.
• بدترین زیردسته در تمام ۱۳ مدل، «پرسش و پاسخ استدلالی» (Reasoning QA) است که در آن Claude-Opus-4.6 تنها به امتیاز کلی ۰.۶۲ دست می‌یابد — یک سقف سخت که حتی توسط قوی‌ترین مدل پیشرو نیز لمس می‌شود.

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

یافته اصلی — اینکه انتخاب ابزار و استدلال بر روی ابزار قابل تفکیک هستند — انگیزه خوبی دارد و معیار چهار محوری یک مشارکت واقعی است. بنچمارک‌های قبلی مانند FinToolBench در ردیابی اجرا متوقف می‌شوند؛ FinTrace معیارهای کیفیت فرآیند قضاوت شده توسط LLM را اضافه می‌کند که نشان می‌دهد در این بین چه اتفاقی می‌افتد. ضریب کاپای کوهن ۰.۸۹ بین ارزیابان در اعتبارسنجی ۱۰۰ نمونه، برای بنچمارکی که بخشی از آن بر پایه داوران LLM است، امیدوارکننده است.

با این حال، چندین انتخاب روش‌شناختی، اعتبار اعداد را محدود می‌کند. ۳۴ دسته وظیفه در مقاله اصلی فهرست نشده‌اند — آن‌ها به ضمیمه B ارجاع داده شده‌اند — بنابراین نمی‌توانم بگویم چقدر نماینده عملکردهای مالی واقعی هستند. سطوح دشواری بر اساس رتبه‌های صدکی در میان مجموعه پرس‌وجوهای خود بنچمارک تعریف شده‌اند، که یک معیار دوری است: سخت فقط به معنای غیرمعمول نسبت به ۸۰۰ مسیر دیگر است، نه سخت به معنای مطلق.

تحلیل تنظیم دقیق ناامیدکننده است. آموزش یک مدل 9B بر روی FinTrace-Training استدلال میانی را بهبود می‌بخشد اما کیفیت پاسخ نهایی همچنان خراب باقی می‌ماند. مقاله این موضوع را به "قطع ارتباط" بین فرآیند و خروجی نسبت می‌دهد، اما علت آن را توضیح نمی‌دهد. محتمل‌ترین توضیح — اینکه یک مدل 9B فاقد یادآوری واقعیت‌ها و توانایی محاسباتی لازم برای وظایف مالی صرف نظر از کیفیت مسیر است — بی‌پاسخ مانده است. نمایش نتایج DPO فقط برای Qwen-3.5-9B نیز تشخیص اینکه آیا مدل‌های بزرگتر بهره بیشتری می‌برند یا خیر را غیرممکن می‌کند.

من همچنین نسبت به تجمیع نمرات کلی مشکوک هستم. ترکیب معیارهای الگوریتمی (F1 بین ۰ و ۱) با نمرات قضاوت شده توسط LLM در مقیاس‌های لیکرت ۱ تا ۵ از طریق نرمال‌سازی به [۰,۱] و میانگین‌گیری، انواع مختلف شکست را با هم در می‌آمیزد. مدلی که ابزارهای کاملاً اشتباه را فراخوانی می‌کند، از همان نوع خرابی مدلی نیست که ابزارهای درست را فراخوانی کرده و سپس خروجی را نادیده می‌گیرد.

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

یافته اصلی مستقیماً با مشکل بازنویسی (write-back) در Beancount مرتبط است. عاملی که به طور قابل اعتماد ابزارهای رابط خط فرمان (CLI) درست Beancount را فراخوانی می‌کند اما سپس خروجی را اشتباه تفسیر می‌کند — مثلاً پاسخ ترازنامه را اشتباه تجزیه کرده و در حساب اشتباهی ثبت می‌کند — بدتر از عدم اتوماسیون است: این کار ثبتی‌های دفتری (ledger entries) با اطمینان کاذب تولید می‌کند که برای یک بازبین معمولی درست به نظر می‌رسند.

معیار بهره‌وری اطلاعات موردی است که من برای هر عامل Beancount با دقت زیر نظر می‌گیرم. این واقعیت که بهترین مدل موجود در یک بنچمارک مالی کنترل‌شده، امتیاز ۳.۲۳ از ۵ را در این زمینه کسب می‌کند، باید یک محدودیت اجباری برای هرگونه استقرار عملیاتی باشد. این موضوع بر لزوم بازبینی انسانی اجباری برای هر عملیات بازنویسی تأکید می‌کند، حداقل تا زمانی که ببینیم این نمره به طور مداوم بالای ۴.۰ می‌رود.

FinTrace همچنین آنچه ReDAct هفته گذشته پیشنهاد داد را تایید می‌کند: معماری درست، استدلال LLM به صورت سرتاسری (end-to-end) نیست، بلکه خط لوله‌ای است که تاییدیه را برون‌سپاری می‌کند. عاملی که ابزارها را به خوبی انتخاب می‌کند (F1 ابزار ~0.9) و سپس نتایج را قبل از اقدام به یک مرحله اعتبارسنجی جداگانه می‌سپارد، دفاع‌پذیرتر از عاملی است که سعی می‌کند در یک مرحله روی خروجی خام ابزار استدلال کند.

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

• FinMCP-Bench (arXiv:2603.24943): مقاله مکمل که از MCP به عنوان استاندارد رابط ابزار استفاده می‌کند و نفر بعدی در لیست مطالعه است — مستقیماً با FinTrace قابل مقایسه است اما بر روی لایه پروتکل متفاوتی ساخته شده است.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): همزمان منتشر شده و فراخوانی ابزار را خارج از حوزه مالی ارزیابی می‌کند؛ مشخص می‌کند که آیا شکاف بهره‌وری اطلاعات مختص دامنه مالی است یا عمومی.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): همان حالت‌های شکست فراخوانی ابزار را از منظر داده‌های آموزشی هدف قرار می‌دهد و ممکن است توضیح دهد که DPO در FinTrace-Training چه چیزی را نادیده گرفته است.

مقاله​

Jiaxuan Lu و همکارانش FinToolBench (arXiv:2603.08262، مارس ۲۰۲۶) را معرفی کردند که به ادعای آن‌ها اولین بنچمارک اجرایی و واقعی برای ارزیابی عوامل یادگیرنده ابزار مالی است. چارچوب‌بندی آن‌ها صریح است: ارزیابی‌های فعلی هوش مصنوعی مالی بر پرسش و پاسخ استاتیک روی اسناد متمرکز هستند، در حالی که بنچمارک‌های عمومی استفاده از ابزار مانند ToolLLM با امور مالی صرفاً به عنوان یک دسته API دیگر بدون محدودیت‌های انطباق خاص دامنه برخورد می‌کنند. FinToolBench سعی می‌کند فضای بین این دو حالت شکست را پر کند.

این بنچمارک ۷۶۰ ابزار مالی اجرایی — شامل ۲۶۱ نقطه پایانی زنده از RapidAPI و ۴۹۹ رابط کاربری از AkShare — را با ۲۹۵ پرس‌وجوی ارزیابی که به دقت انتخاب شده‌اند، جفت می‌کند که به ۱۶۶ مورد تک‌ابزاری و ۱۲۹ مورد چندابزاری تقسیم می‌شوند. ابزارها دامنه‌های سهام، اوراق قرضه، صندوق‌ها، فارکس، مشتقات، اقتصاد کلان و رمزارز را پوشش می‌دهند. نکته مهم این است که این‌ها APIهای واقعی و قابل فراخوانی هستند، نه کدهای شبیه‌سازی شده (stubs). نویسندگان همچنین FATR (Finance-Aware Tool Routing) را معرفی می‌کنند، یک عامل پایه که از بازیابی BGE-M3 (۲۰ کاندیدای برتر)، کارت‌های ابزار حاشیه‌نویسی شده با ویژگی‌های مالی و یک برنامه‌ریز ReAct آگاه از محدودیت‌ها که به پنج مرحله محدود شده است، استفاده می‌کند.

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

• اجرا گلوگاه نیست — استدلال روی خروجی‌ها گلوگاه است. GPT-4o دارای بالاترین امتیاز نرم شرطی (CSS = 0.670) است، به این معنی که وقتی با موفقیت ابزاری را فراخوانی می‌کند، پاسخ‌های درستی می‌دهد، اما تنها در ۲۲.۷٪ مواقع ابزارها را فراخوانی می‌کند (TIR = 0.227). در مقابل، Qwen3-8B در ۸۷.۱٪ مواقع ابزارها را فراخوانی می‌کند اما تنها در ۴۰.۴٪ از موارد موفقیت، به پاسخ درست می‌رسد.
• عدم تطابق قصد، شکست اصلی در انطباق (Compliance) است. نرخ عدم تطابق قصد (IMR) در اکثر مدل‌ها از ۵۰٪ فراتر می‌رود، به این معنی که عوامل به طور معمول فراخوانی‌هایی با قصد تراکنشی انجام می‌دهند در حالی که پرس‌وجو فقط نیاز به جستجوی اطلاعاتی دارد. این یک مشکل جدی در زمینه‌های مالی تحت نظارت است.
• تزریق ویژگی‌های مالی به انطباق کمک می‌کند بدون اینکه به توانایی‌ها آسیب بزند. کارت‌های ابزار در سیستم پایه FATR — که هر ابزار را با ویژگی‌هایی نظیر به‌روز بودن، نوع قصد و دامنه نظارتی حاشیه‌نویسی می‌کند — فراخوانی داده‌های قدیمی (TMR) و تخلفات دامنه‌ای (DMR) را بدون کاهش قابل توجه نرخ فراخوانی کاهش می‌دهند.
• پرس‌وجوهای چندابزاری شکاف قابلیت اطمینان را آشکار می‌کنند. ۱۲۹ پرس‌وجوی چندابزاری نیازمند زنجیره‌ای از فراخوانی‌ها و انتقال خروجی‌ها بین مراحل هستند؛ عملکرد در مقایسه با موارد تک‌ابزاری به شدت افت می‌کند، که با یافته‌های FinTrace و TheAgentCompany همخوانی دارد.
• مدل‌های کوچک می‌توانند در فراخوانی از مدل‌های بزرگ پیشی بگیرند اما در استدلال نه. TIR مدل Qwen3-8B که ۰.۸۷۱ است در مقابل ۰.۲۲۷ مدل GPT-4o نشان می‌دهد که مدل‌های کوچک‌تر در فراخوانی "شتاب‌زده‌تر" هستند، اما CER (نرخ اجرای شرطی) ۰.۳۳۹ برای Qwen3-8B در مقابل ۰.۶۱۸ برای GPT-4o نشان می‌دهد که GPT-4o زمانی که تصمیم به فراخوانی ابزار می‌گیرد، بسیار دقیق‌تر عمل می‌کند.

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

انتخاب بنچمارک برای استفاده از APIهای واقعاً زنده و اجرایی، مشارکت اصلی و واقعی آن است. APIهای شبیه‌سازی شده (Mocked) راز کثیف بنچمارک‌های استفاده از ابزار بوده‌اند: ۱۶,۰۰۰ API در ToolLLM تأثیرگذار به نظر می‌رسند تا زمانی که متوجه شوید ارزیابی از یک LLM به عنوان قاضی استفاده می‌کند تا حدس بزند آیا یک فراخوانی کار "می‌کرد" یا نه. FinToolBench از این موضوع اجتناب می‌کند.

معیارهای انطباق (TMR، IMR، DMR) از نظر مفهومی درست هستند — عوامل مالی باید تفاوت بین دریافت قیمت بسته شدن دیروز و شروع یک معامله را بدانند — اما توضیحات مقاله در مورد چگونگی اجرای این طبقه‌بندی‌ها ضعیف است. مشخص نیست که آیا برچسب‌های واقعیت پایه (ground-truth) برای نوع قصد (اطلاعاتی در مقابل تراکنشی) توسط کارشناسان حقوقی یا انطباق تأیید شده‌اند یا صرفاً توسط نویسندگان مجموعه داده اختصاص یافته‌اند. این موضوع در عمل بسیار حائز اهمیت است.

فهرست مدل‌ها نیز به طور عجیبی محدود است: Doubao-Seed-1.6، Qwen3-8B، GLM-4.7-Flash و GPT-4o. هیچ خبری از Claude Sonnet یا Gemini 2.5 نیست که مقایسه‌های طبیعی محسوب می‌شدند. جدول نتایج نشان می‌دهد که GPT-4o یک داده پرت با دقت بالا اما پوشش کم است؛ من مشتاقم بدانم آیا رفتار استفاده از ابزار Claude به الگوی محافظه‌کارانه GPT-4o نزدیک‌تر است یا الگوی تهاجمی Qwen3-8B.

مجموعه ارزیابی ۲۹۵ پرس‌وجویی طبق استانداردهای بنچمارک‌های مدرن کوچک است. با ۷۶۰ ابزار، نرخ پوشش ۲۹۵ پرس‌وجو به این معنی است که اکثر ابزارها هرگز آزمایش نمی‌شوند. مقاله آمار پوشش به ازای هر دامنه را گزارش نمی‌دهد، که به این معنی است که اعداد اصلی می‌توانند تحت تأثیر زیرمجموعه‌ای از دامنه‌های با پوشش خوب مانند سهام و اقتصاد کلان باشند.

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

عوامل بازنویسی Beancount — هر عاملی که bean-add را فراخوانی می‌کند، یک فایل دفتر کل (ledger) را اصلاح می‌کند یا beanquery را اجرا می‌کند — دقیقاً با حالت‌های شکستی روبرو هستند که FinToolBench آشکار می‌کند. مشکل عدم تطابق قصد مستقیماً ترجمه می‌شود: یک عامل Beancount که وقتی کاربر یک سوال خواندنی می‌پرسد، دستور نوشتن صادر می‌کند، همان امضای شکست IMR را دارد. بُعد به‌روز بودن داده‌ها نیز به مشکل فراخوانی وضعیت دفتر کل کش‌شده و قدیمی مربوط می‌شود، در حالی که کاربر انتظار موجودی فعلی را دارد.

تنش بین دقت و پوشش (GPT-4o در مقابل Qwen3-8B) نیز مستقیماً مرتبط است. برای بازنویسی Beancount، من رفتار فراخوانی محافظه‌کارانه GPT-4o را ترجیح می‌دهم — TIR پایین اما CER و CSS بالا — تا یک مدل با فراخوانی بالا که مکرراً ابزار اشتباه را اجرا می‌کند. هزینه‌ی نوشتن‌های اشتباه بسیار بیشتر از انجام ندادن هیچ عملیاتی (no-ops) است.

رویکرد FATR در حاشیه‌نویسی ابزارها با ویژگی‌های انطباق به جای تکیه بر مدل برای استنتاج آن‌ها، یک الگوی طراحی ارزشمند برای پذیرش است. بسته‌بندی ابزارهای CLI در Beancount با متادیتای صریح درباره اینکه آیا یک فراخوانی فقط‌خواندنی است یا تغییردهنده، و اینکه آیا به وضعیت فعلی دفتر کل دسترسی دارد یا بایگانی‌شده، همان ایده‌ای است که در مقیاسی کوچک‌تر اعمال می‌شود.

چه چیزی را بعداً بخوانیم​

• FinTrace (arXiv:2604.10015) — ارزیابی در سطح مسیر در ۳۴ دسته وظایف مالی با ۹ معیار؛ مستقیماً ارزیابی تک‌فراخوانی FinToolBench را به توالی‌های چند مرحله‌ای گسترش می‌دهد و Qwen-3.5-9B را با DPO برای بهبود استدلال میانی تنظیم دقیق می‌کند.
• FinMCP-Bench (arXiv:2603.24943) — ۶۱۳ نمونه روی ۶۵ ابزار مالی مبتنی بر MCP که فراخوانی‌های تک‌ابزاری، چندابزاری و چند نوبتی را آزمایش می‌کند؛ چارچوب MCP مستقیماً با رابط‌های ابزار Beancount مرتبط است.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — مقاله ToolBench که FinToolBench صراحتاً خود را در مقابل آن قرار می‌دهد؛ درک آنچه بنچمارک‌های مبتنی بر API شبیه‌سازی شده می‌توانند و نمی‌توانند اندازه‌گیری کنند، روشن می‌کند که اجرایی بودن FinToolBench واقعاً چه ارزشی افزوده است.

مقاله​

OmniEval یک شبکه ارزیابی دو بعدی ایجاد می‌کند: پنج کلاس وظیفه (پرسش و پاسخ استخراجی، استدلال چند مرحله‌ای، پرسش و پاسخ مقایسه‌ای، پرسش و پاسخ طولانی و پرسش و پاسخ گفتگویی) که با ۱۶ موضوع مالی (بازارهای سهام، بانکداری سرمایه‌گذاری، صندوق‌ها، بیمه اموال و غیره) تلاقی دارند. نتیجه یک بنچمارک ساختاریافته با ۱۱.۴ هزار نمونه تست تولیدشده خودکار، ۱.۷ هزار نمونه برچسب‌گذاری شده توسط انسان و یک پیکره بازیابی با ۳۶۲ هزار سند است که از شش منبع داده مالی چینی گردآوری شده است (BSCF-DB با ۱۹۳ هزار سند، FinGLM با ۵۵ هزار، BAAI-Fin با ۴۸ هزار، خزش‌های وب رسمی، فایل‌های PDF و محتوای مالی ویکی‌پدیا). این بنچمارک همچنین شامل یک ارزیاب LLM تنظیم‌شده (fine-tuned) است — مدل Qwen2.5-7B-Instruct که بر روی ۹۱۰ نمونه برچسب‌گذاری شده توسط انسان آموزش دیده است — که کیفیت تولید را در شاخص‌های دقت، توهم، کامل بودن، بهره‌وری و دقت عددی امتیازدهی می‌کند. این مقاله در EMNLP 2025 منتشر شد.

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

• مواردی که به صورت خودکار تولید شده بودند، در بررسی پذیرش انسانی نرخ ۸۷.۴۷٪ را کسب کردند، به این معنی که تقریباً ۱ مورد از هر ۸ مورد تولید شده کنار گذاشته شده است — که نرخ نویز ناچیزی برای یک بنچمارک نیست.
• بهترین بازیاب (GTE-Qwen2-1.5B) به MAP معادل ۰.۴۳۷۰ و MRR معادل ۰.۴۴۹۱ در مجموعه خودکار دست یافت، به این معنی که حتی با قوی‌ترین بازیاب آزمایش‌شده، متن رتبه اول کمتر از نیمی از مواقع صحیح است.
• دقت تولید (ACC) در تمامی ترکیبات بازیاب-LLM از ۰.۳۲۳۸ تا ۰.۴۴۷۶ متغیر بود — بهترین پیکربندی به کمتر از نیمی از سوالات پاسخ درست می‌دهد.
• دقت عددی (NAC) تامل‌برانگیزترین یافته است: ۰.۰۶۵۹ تا ۰.۳۵۹۵. بهترین سیستم اعداد مالی را در حدود ۳۶٪ مواقع درست تشخیص می‌دهد؛ بدترین سیستم نزدیک به صفر است.
• ارزیاب تنظیم‌شده به ۷۴.۴٪ توافق با برچسب‌گذاری انسانی (κ = ۰.۶۴۸۶) دست یافت که به طور قابل توجهی بهتر از خط‌بست‌های مبتنی بر پرامپت (۵۵-۷۱٪) عمل کرد — اما همچنان یک ارزیابی از هر چهار ارزیابی با قضاوت انسانی همخوانی ندارد.
• استدلال چند مرحله‌ای و پرسش و پاسخ گفتگویی به طور مداوم سخت‌ترین کلاس‌های وظیفه بودند.

چه چیزی پابرجاست — و چه چیزی نه​

طراحی ارزیابی ماتریسی واقعاً مفید است. بنچمارک‌های قبلی مالی (FinanceBench، FinQA، DocFinQA) ارزیابی را به عنوان یک محور واحد — معمولاً دقت پاسخ — در نظر می‌گیرند و تنوع ساختاری در نحوه شکست RAG را نادیده می‌گیرند. دانستن اینکه یک سیستم در پرسش و پاسخ استخراجی خوب عمل می‌کند اما در استدلال چند مرحله‌ای ضعیف است، قابل بهره‌برداری است؛ اما دانستن میانگین کل امتیازات اینطور نیست. شبکه OmniEval این تنوع را مرئی می‌کند و این یافته که عملکرد در موضوعات مختلف ناهماهنگ است، دقیقاً همان نتیجه‌ای است که متخصصان باید قبل از استقرار سیستم ببینند.

با این حال، محدودیت‌های واقعی وجود دارد که می‌خواهم صریحاً به آن‌ها اشاره کنم. پیکره متنی به شدت چینی است: پنج منبع داده از شش منبع، داده‌های مالی چینی هستند (BSCF، FinGLM، BAAI-Fin) و ششمین مورد ویکی‌پدیای چینی است. مقاله نتایج را به تفکیک زبان گزارش نمی‌دهد — فقط اعداد کلی را ارائه می‌دهد. این موضوع باعث می‌شود هر امتیازی در مقاله به عنوان ادعایی درباره RAG مالی به طور کلی، در مقابل RAG مالی روی متن چینی با بازیاب‌ها و LLMهای تخصصی چینی (GTE-Qwen2-1.5B، Qwen2.5-72B، Yi15-34B) مورد تردید باشد. کاربران مالی انگلیسی‌زبان نمی‌توانند مستقیماً از این اعداد استفاده کنند.

ارزیاب LLM بر روی ۹۱۰ نمونه برچسب‌دار آموزش دیده است. این مقدار کمی است. توافق ۷۴.۴٪ انسانی در κ = ۰.۶۴۸۶ به عنوان نقطه شروع قابل دفاع است، اما به این معنی است که خود چارچوب ارزیابی نویز قابل توجهی وارد می‌کند. اگر بنچمارک برای مقایسه سیستم‌هایی استفاده شود که تفاوت چند درصدی دارند، واریانس ارزیاب سیگنال اصلی را از بین می‌برد.

خط لوله تولید خودکار — که در آن GPT-4 سوالات تست را تولید می‌کند و انسان‌ها با نرخ پذیرش ۸۷.۴۷٪ فیلتر می‌کنند — همچنین سوالی درباره آلودگی (contamination) ایجاد می‌کند که مقاله به آن نمی‌پردازد: سوالات تولید شده توسط GPT-4 ممکن است به گونه‌ای با نقاط قوت مدل‌های کلاس GPT-4 همسو باشد که مدل‌های قدیمی‌تر یا کوچک‌تر را به صورت سیستماتیک در وضعیت نامساعدی قرار دهد.

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

امتیازات دقت عددی اعدادی هستند که من مدام به آن‌ها باز می‌گردم: ۰.۰۶۵۹–۰.۳۵۹۵. اگر بهترین سیستم RAG آزمایش‌شده در یک ارزیابی بنچمارک شده، اعداد مالی را فقط ۳۶٪ مواقع درست تشخیص دهد، هر عامل بازنویسی Beancount که بر روی یک خط لوله RAG ساده ساخته شده باشد، داده‌های دفترکل را خراب می‌کند. فرمت Beancount سخت‌گیرانه است — یک مبلغ، تاریخ یا نام حساب اشتباه منجر به خطای تجزیه یا یک خطای حسابداری پنهان می‌شود که می‌تواند در طول سال‌های مالی منتشر شود. این بنچمارک شواهد عینی به ما می‌دهد که بازیابی RAG و تولید LLM هنوز برای بازنویسی مستقیم در دفترکل بدون یک لایه اعتبارسنجی، به اندازه کافی قابل اعتماد نیستند.

ساختار کلاس‌های وظیفه نیز به خوبی با موارد استفاده Beancount مطابقت دارد. پرسش و پاسخ استخراجی معادل جستجوهای ساده موجودی است. استدلال چند مرحله‌ای معادل سوالاتی مانند «سود خالص من پس از مالیات در بازه Q1-Q3 چقدر است؟» می‌باشد. پرسش و پاسخ گفتگویی معادل کاربری است که در طول یک جلسه به طور مکرر یک درخواست مغایرت‌گیری را اصلاح می‌کند. یافته OmniEval مبنی بر اینکه وظایف چند مرحله‌ای و گفتگویی سخت‌ترین هستند، دقیقاً خبر بدی برای طراحی عامل Beancount است: موارد ساده تقریباً خوب هستند؛ اما موارد واقعی جایی هستند که سیستم از هم می‌پاشد.

چه چیزی را در ادامه بخوانیم​

• ARES: چارچوب ارزیابی خودکار برای تولید تقویت‌شده با بازیابی (arXiv:2311.09476، NAACL 2025) — نزدیک‌ترین آنالوگ حوزه عمومی به رویکرد تنظیم دقیق ارزیاب OmniEval؛ مقایسه متدولوژی ARES با OmniEval روشن می‌کند که آیا انتخاب‌های طراحی ارزیاب LLM اصولی هستند یا موردی.
• RAGEval: چارچوب تولید مجموعه داده ارزیابی RAG سناریو-محور (ACL 2025, aclanthology.org/2025.acl-long.418) — تولید سناریوی خودکار برای ارزیابی RAG؛ متدولوژی تولید خودکاری را که OmniEval استفاده می‌کند گسترش می‌دهد و ممکن است به نگرانی‌های مربوط به آلودگی پاسخ دهد.
• FinRAGBench-V: بنچمارکی برای RAG چندوجهی با ارجاع بصری در حوزه مالی (arXiv:2505.17471) — ارزیابی RAG را به اسناد مالی چندوجهی (جداول، نمودارها) گسترش می‌دهد؛ از آنجا که کاربران Beancount به طور فزاینده‌ای تصاویر رسید و صورت‌حساب‌های PDF را در کنار دفترکل‌های متنی ساده دارند، مرتبط است.

مقاله​

بررسی شو و دینگ (arXiv:2409.01980) پیشنهاد می‌کند که تشخیص ناهنجاری و تشخیص داده‌های خارج از توزیع (OOD) مبتنی بر LLM به دو کلاس سطح بالا سازماندهی شوند: LLMها برای تشخیص (Detection)، که در آن مدل مستقیماً ناهنجاری‌ها را شناسایی می‌کند، و LLMها برای تولید (Generation)، که در آن مدل داده‌های آموزشی را تقویت می‌کند یا توضیحات به زبان طبیعی ارائه می‌دهد که به یک تشخیص‌دهنده در پایین‌دست خوراک می‌دهد. هر کلاس بیشتر تقسیم می‌شود. تشخیص به روش‌های مبتنی بر پرامپت (LLMهای منجمد یا تنظیم‌شده که با پرامپت‌های زبان طبیعی فراخوانی می‌شوند) و روش‌های مبتنی بر تضاد (مدل‌های خانواده CLIP که با مقایسه قطعات تصویر با توضیحات متنی، ناهنجاری را امتیازدهی می‌کنند) تقسیم می‌شود. تولید به روش‌های مبتنی بر تقویت داده (تولید برچسب‌های شبه-OOD یا نمونه‌های اقلیت مصنوعی) و روش‌های مبتنی بر توضیح (تولید منطق‌های زبان طبیعی برای رویدادهای علامت‌گذاری شده) تقسیم می‌شود.

لیست مطالعه همراه در گیت‌هاب حدود ۳۹ مقاله را پوشش می‌دهد: ۲۴ مقاله در تشخیص، ۱۰ مقاله در تقویت داده و ۵ مقاله در توضیح.

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

• روش‌های مبتنی بر تضاد در تشخیص ناهنجاری تصویر غالب هستند. WinCLIP به AUROC ۹۱.۸٪ و ۸۵.۱٪ در طبقه‌بندی و بخش‌بندی ناهنجاری صفر-شات (Zero-shot) روی MVTec-AD بدون هیچ‌گونه تنظیم خاصِ مجموعه داده دست می‌یابد که با روش‌های نظارت‌شده آموزش‌دیده روی آن مجموعه داده رقابت می‌کند.
• LLMهای منجمد در داده‌های غیرمتنی با شکاف مدالیته مواجه می‌شوند. این بررسی صراحتاً خاطرنشان می‌کند که «فراخوانی مستقیم LLMهای منجمد برای نتایج تشخیص ناهنجاری یا OOD در انواع مختلف داده‌ها، به دلیل شکاف ذاتی مدالیته بین متن و سایر مدالیته‌های داده، اغلب منجر به عملکرد پایین‌تر از حد بهینه می‌شود.»
• تنظیم LoRA و آداپتور بخش زیادی از این شکاف را جبران می‌کند. روش‌هایی مانند AnomalyGPT و AnomalyCLIP با تکنیک‌های کارآمد از نظر پارامتر (Parameter-efficient) تنظیم دقیق می‌شوند و به‌طور قابل‌توجهی از همتایان منجمد خود بهتر عمل می‌کنند.
• تولید به عنوان ابزار تقویت داده کمتر از حد مورد استفاده قرار گرفته است. برچسب‌های شبه-OOD در سطح کپشن تولید شده توسط BLIP-2 در تشخیص OOD بهتر از جایگزین‌های در سطح کلمه و توضیحات عمل می‌کنند، که نشان می‌دهد نظارت متنی غنی‌تر حتی برای وظایف بصری نیز اهمیت دارد.
• تولید مبتنی بر توضیح، جدیدترین زیرمجموعه است. سیستم‌هایی مانند Holmes-VAD و VAD-LLaMA فراتر از پرچم‌های باینری عمل کرده و منطق‌های زبان طبیعی برای رویدادهای ناهنجار، عمدتاً در ویدئوهای نظارتی، تولید می‌کنند.
• داده‌های جدولی تقریباً غایب هستند. این بررسی تنها به یک روش — "Tabular" توسط لی و همکاران (۲۰۲۴) — اشاره می‌کند که ردیف‌های جدولی را به پرامپت‌های متنی تبدیل کرده و با LoRA تنظیم دقیق می‌کند، اما هیچ آمار مقایسه‌ای ارائه نمی‌دهد.

چه چیزی پابرجاست و چه چیزی نه​

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

آنچه نمی‌توانم بپذیرم، قاب‌بندی مقاله به عنوان بررسی جامع تشخیص ناهنجاری به‌طور کلی است. پوشش مطالب به‌طور مفرط بر تصاویر نقص‌های صنعتی (MVTec-AD, VisA) و ویدئوهای نظارتی (UCF-Crime, XD-Violence) متمرکز است. از حدود ۳۹ مقاله فهرست شده، تقریباً هیچ‌کدام به داده‌های جدولی یا مالی نمی‌پردازند. سری‌های زمانی چند ارجاع دارند. داده‌های جدولی تنها یک جمله سهم برده‌اند. این یک نقشه چشم‌انداز برای Bean Labs نیست — این نقشه‌ای برای محققان بینایی ماشین است که می‌خواهند از CLIP برای تشخیص نقص استفاده کنند.

نویسندگان اذعان می‌کنند که «محدودیت فضا مانع از خلاصه‌های دقیق معیارها شده است»، که راهی مودبانه برای گفتن این است که هیچ جدول مقایسه‌ای وجود ندارد. برای یک مقاله مروری، نبود ترکیب کمی (Quantitative Synthesis) یک شکاف بزرگ است. خوانندگان نمی‌توانند بدون پیگیری جداگانه تک‌تک مقالات ارجاع شده، تصمیم بگیرند کدام پارادایم برای مورد استفاده آن‌ها بهتر است.

چالش توهم (Hallucination) به عنوان یک مسئله باز فهرست شده است، اما پرداختن به آن سطحی است — ریسک را نام می‌برد بدون اینکه تحلیل کند کدام پارادایم‌های تشخیص بیشتر یا کمتر مستعد هستند، یا اینکه چگونه تولید مبتنی بر توضیح ممکن است توهمات را از طریق بررسی انسانی قابل تشخیص‌تر کند.

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

دو زیرمجموعه علی‌رغم پوشش سنگین تصویری، مرتبط هستند. اول، زیرمجموعه تولید مبتنی بر توضیح دقیقاً همان چیزی است که عوامل حسابرسی Beancount به آن نیاز دارند: نه فقط یک پرچم که نشان دهد یک ورودی دفتر کل ناهنجار است، بلکه یک جمله به زبان طبیعی که دلیل آن را توضیح دهد. حسابرسان مالی نمی‌توانند بر اساس یک خروجی باینری عمل کنند. دوم، سکوت تقریباً کامل بررسی درباره تشخیص ناهنجاری جدولی خود آموزنده است — این تایید می‌کند که رشته مطالب AnoLLM، CausalTAD و AD-LLM که من دنبال کرده‌ام، یک حوزه پیشرو است نه یک مسیر پرتردد، و طراحی ابزارهای حسابرسی مبتنی بر LLM برای دفاتر کل Beancount مستلزم ترکیب بینش‌هایی از تشخیص ناهنجاری بینایی است که هنوز به محیط‌های جدولی منتقل نشده‌اند.

توازن بین پرامپت‌نویسی و تنظیم دقیق (Prompting-vs-tuning) کاربردی‌ترین یافته است: پرامپت‌نویسی صفر-شات به عنوان یک تخمین اولیه کار می‌کند اما از شکاف مدالیته رنج می‌برد؛ تنظیم دقیق مبتنی بر LoRA روی مثال‌های برچسب‌دار معرف، این شکاف را می‌بندد. برای استقرار Beancount با مثال‌های ناهنجاری برچسب‌دار از دفاتر کل تاریخی، مسیر تنظیم دقیق قابل‌اعتمادتر از پرامپت‌نویسی محض به نظر می‌رسد.

چه چیزی را بعداً بخوانیم​

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — از جاسازی‌های Sentence-transformer مدل زبانی روی ورودی‌های واقعی دفتر کل استفاده می‌کند؛ پلی مستقیم از چارچوب این بررسی به مورد استفاده جدولی Beancount.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — خط لوله چند‌عاملی برای تشخیص ناهنجاری داده‌های بازار؛ الگوی هماهنگی چند‌عاملی ممکن است به حسابرسی دفتر کل نیز منتقل شود.
• AnomalyGPT (arXiv:2308.15366) — یک LVLM تنظیم‌شده برای تشخیص ناهنجاری صنعتی با مکان‌یابی در سطح پیکسل؛ خواندن این مقاله روشن می‌کند که «تنظیم LLM برای تشخیص» از نظر معماری واقعاً به چه معناست، چیزی که بررسی حاضر توصیف کرده اما توضیح نمی‌دهد.

مقاله​

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

راه حل آن‌ها در مفهوم بسیار ظریف است. آن‌ها توجه را به دو مؤلفه جمع‌شونده تجزیه می‌کنند: مرتبط بودن (آنچه ما می‌خواهیم) و سوگیری مکانی (آنچه نمی‌خواهیم). برای جداسازی عبارت سوگیری، آن‌ها یک «سند ساختگی» — محتوای پرکننده غیر اطلاعاتی — را در هر موقعیت از همان بافت عبور می‌دهند و توزیع توجه حاصل را ثبت می‌کنند. توجه به آن سند ساختگی، تقریبی از پیشین مکانی خالص است. کسر کردن آن از امتیازات توجه واقعی، باقیمانده‌ای را به جا می‌گذارد که بهتر نشان‌دهنده مرتبط بودن واقعی است:

توجه کالیبره شده = Attn(document, k) − Attn(dummy, k)

سپس از امتیازات بازقیاس شده برای رتبه‌بندی مجدد یا وزن‌دهی مجدد به اسناد بازیابی شده قبل از مرحله نهایی تولید پاسخ استفاده می‌شود. نکته حیاتی این است که هیچ آموزشی لازم نیست. کالیبراسیون در زمان استنتاج روی ۱۶ لایه آخر رمزگشا و تمام سرهای توجه اعمال می‌شود. هزینه آن O(K) پاس پیشروی اضافی است که K تعداد اسناد بازیابی شده است — غیرچشمگیر اما قابل پیش‌بینی.

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

• سوگیری توجه U-شکل ذاتی معماری مدل است و حتی در مدل‌هایی که صراحتاً با اهداف بافت طولانی آموزش دیده‌اند نیز باقی می‌ماند.
• عبور دادن یک سند ساختگی (خالی/نویز) از همان بافت بازیابی، پیشین مکانی را ایزوله می‌کند؛ کسر کردن آن سوگیری را بدون هیچ‌گونه تنظیم دقیق (finetuning) حذف می‌کند.
• معیار Recall@3 در مجموعه داده NaturalQuestion (با K=20 و قرار دادن سند اصلی در میانه) با کالیبراسیون از ۲۰.۵۲٪ به ۶۸.۳۲٪ جهش می‌کند؛ در K=10، از ۳۶.۳۸٪ به ۷۴.۲۷٪ می‌رسد.
• دقت پاسخگویی به سوالات (End-to-end QA) زمانی که سند اصلی در میانه بافت باشد، ۶ تا ۱۵ واحد درصد بهبود می‌یابد؛ این بهبودها در ۲۲ مورد از ۲۴ پیکربندی آزمایشی صادق است.
• این روش از شش خط پایه مقایسه‌ای عملکرد بهتری دارد: توجه وانیلا (vanilla attention)، رتبه‌بندی تولید پرس‌وجو، پرامپتینگ تولید مرتبط بودن، مرتب‌سازی توجه (Peysakhovich & Lerer 2023)، بازآرایی پرامپت و LongLLMLingua-rk.
• این روش بر روی NaturalQuestion (۲۶۵۵ پرس‌وجوی واقعی روی ویکی‌پدیا) و SynthWiki (۹۹۰ ورودی مصنوعی تولید شده توسط GPT-4) ارزیابی شد.

چه چیزی پابرجاست — و چه چیزی نه​

نتیجه اصلی خیره‌کننده است و من آن را باور دارم. شکاف Recall@3 از ۲۰.۵۲٪ به ۶۸.۳۲٪ برای اسناد اصلی در میانه بافت، عددی نیست که با بررسی دقیق از بین برود — این نشان‌دهنده چیزی واقعی درباره نحوه توزیع توجه است. طراحی بدون نیاز به آموزش یک مزیت کاربردی واقعی است: می‌توانید این را بدون دست زدن به وزن‌های مدل، روی هر خط لوله RAG موجود قرار دهید.

با این حال، من ملاحظاتی دارم. اول، رویکرد «سند ساختگی» فرض می‌کند که سوگیری مکانی تقریباً از نظر موقعیت تفکیک‌پذیر و جمع‌شونده است — یک تجزیه خطی که خود نویسندگان اشاره کرده‌اند ممکن است بیش از حد ساده‌انگاری باشد. سوگیری توجه واقعی ممکن است به روش‌های غیرخطی با محتوا در تعامل باشد. دوم، پاس‌های پیشروی اضافی O(K) به عنوان هزینه «قابل قبول» معرفی شده‌اند اما هرگز از نظر تأخیر یا هزینه بنچ‌مارک نشده‌اند. در یک سیستم تولیدی با ۲۰ مورد بازیابی، شما به جای یک پاس، ۲۱ پاس پیشرو برای هر پرس‌وجو اجرا می‌کنید. برای یک عامل Beancount که صدها تراکنش را تریاژ می‌کند، این ضریب اهمیت دارد.

سوم — و این جالب‌ترین محدودیت است — نویسندگان اشاره می‌کنند که سوگیری مکانی ممکن است در واقع برای وظایف خاصی مفید باشد. برای مثال، سوگیری تازگی (Recency bias) ممکن است همان چیزی باشد که باعث می‌شود مدل به ورودی‌های اخیر دفتر کل نسبت به ورودی‌های قدیمی‌تر وزن درستی بدهد. حذف بدون تبعیض سوگیری می‌تواند به وظایفی که در آن‌ها موقعیت یک سیگنال معتبر است، آسیب برساند. این موضوع تایید شده اما مطالعه نشده است.

در نهایت، آزمایش‌ها از NaturalQuestion و یک مجموعه داده مصنوعی استفاده می‌کنند. اسناد تخصصی مالی — جداول متراکم، پرونده‌های چندساله، ورودی‌های دفتر کل با ساختار تکراری — با متون ویکی‌پدیا در حوزه عمومی بسیار متفاوت هستند. این کالیبراسیون قبل از ادعای کارایی برای RAG مالی، باید روی آن توزیع‌ها اعتبارسنجی شود.

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

ارتباط مستقیم واضح است: تمام گزارش‌های ما از زمان DocFinQA حول همین مشکل می‌چرخیدند. وقتی یک عامل Beancount برای پاسخ به سوالی مانند «تطبیق ماه مارس با صورت‌حساب بانکی»، ۲۰ ورودی مرتبط دفتر کل را بازیابی می‌کند، به ورودی‌های میانه پنجره بازیابی شده به طور سیستماتیک نسبت به ورودی‌های ابتدا و انتهای بافت، توجه کمتری می‌شود. این یک شکست در بازیابی نیست — این یک شکست در بخش تولید (generation) است که هیچ مقدار بهبودی در رتبه‌بندی بازیابی آن را حل نخواهد کرد.

کالیبراسیون «یافتن در میان» یک راهکار کاهش ریسک محتمل است که نیازی به بازآموزی مدل زیربنایی ندارد و می‌تواند مستقیماً در مرحله تولید هر خط لوله پاسخگویی به سوالات دفتر کل اعمال شود. نگرانی هزینه O(K) واقعی است اما قابل مدیریت است — یک پنجره بازیابی ۲۰ سندی با یک مدل با اندازه متوسط هنوز در محدوده عملی قرار دارد. چیزی که من دوست دارم قبل از استقرار آن ببینم، اعتبارسنجی روی داده‌های با ساختار Beancount است: آیا اصلاح مکانی به طور یکنواخت کمک می‌کند، یا ناخواسته سیگنال تازگی را که باعث می‌شود تراکنش‌های اخیر قابل اعتمادتر از تراکنش‌های قدیمی باشند، سرکوب می‌کند؟

اصل گسترده‌تر — اینکه مکانیسم‌های توجه، پیشین‌های مکانی را مستقل از مرتبط بودن محتوا کدگذاری می‌کنند و این پیشین‌ها را می‌توان بدون بازآموزی کالیبره کرد — ارزش نگه داشتن دارد. این امر راه را برای کالیبراسیون‌های مشابه برای سایر سوگیری‌ها باز می‌کند: سوگیری فراوانی توکن، نرمال‌سازی طول ورودی، و سوگیری پرحرفی در تولید.

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

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — پیشنهاد مقیاس‌بندی یک بعد از حالت پنهان به جای کسر امتیازات توجه؛ ارزش مقایسه مستقیم با رویکرد «یافتن در میان» را دارد.
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — مورد بعدی در لیست مطالعه؛ رشته‌های AnoLLM، CausalTAD و AD-LLM را در یک طبقه‌بندی واحد به هم پیوند می‌دهد.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — تشخیص اصلی که «یافتن در میان» به آن پاسخ می‌دهد؛ مطالعه آن برای درک پیش‌زمینه ضروری است.

مقاله​

سیستم ReDAct (Reason-Defer-Act) بر اساس پارادایم پرامپت‌نویسی ReAct ساخته شده و یک معماری عامل دومدلی را معرفی می‌کند. یک مدل کوچک ارزان — مانند Qwen3-80B، Llama3.3-70B یا Llama4-Maverick — تمام مراحل را به‌طور پیش‌فرض مدیریت می‌کند. در هر مرحله، این مدل یک ردپای استدلال (reasoning trace) و سپس یک اقدام (action) تولید می‌کند. سیستم عدم قطعیت در سطح توکن را فقط برای مرحله تولید اقدام اندازه‌گیری کرده و آن را با یک آستانه کالیبره‌شده مقایسه می‌کند. اگر عدم قطعیت از آن آستانه فراتر رود، مرحله توسط یک مدل بزرگ گران‌قیمت (GPT-5.2، Qwen3-235B یا Qwen3-480B) دوباره اجرا می‌شود؛ در غیر این صورت، اقدام مدل کوچک اجرا می‌گردد.

معیارهای عدم قطعیت مبتنی بر نظریه اطلاعات هستند و تنها به احتمالات لگاریتمی (log-probabilities) در سطح توکن نیاز دارند: احتمال توالی (مجموع لگاریتم احتمال منفی)، پرپلکسیتی (نرمال‌شده بر اساس طول) و میانگین آنتروپی توکن (میانگین آنتروپی در موقعیت‌های مختلف توکن). آستانه از طریق مجموعه‌ای از خروجی‌های مدل کوچک با انتخاب مقداری که تعداد هدف برای فراخوانی مدل بزرگ در هر اپیزود (K) را ایجاد کند، کالیبره می‌شود.

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

• اندازه‌گیری عدم قطعیت در مرحله اقدام، نه مرحله استدلال. یک آزمایش کمکی بر روی ۲,۴۱۱ مرحله ALFWorld نشان داد که عدم قطعیت در سطح استدلال قدرت تشخیص ضعیفی بین مراحل صحیح و غلط دارد؛ در حالی که پرپلکسیتی در سطح اقدام به عنوان پیش‌بینی‌کننده صحت، ROC-AUC و PRR به‌مراتب بالاتری دارد.
• تعویق بر اساس PPL با ترکیب Qwen3-80B + GPT-5.2 به دقت ۸۰.۸٪ ± ۱.۱٪ در ALFWorld می‌رسد که از GPT-5.2 به تنهایی (۷۸.۳٪ ± ۱.۹٪) فراتر می‌رود، در حالی که هزینه‌ آن ۱۶.۲۵ دلار در مقابل ۴۵.۲۱ دلار است — یعنی تقریباً ۶۴٪ ارزان‌تر.
• حدود ۱۵٪ از مراحل در عمل به تعویق می‌افتند تا با هدف کالیبراسیون تقریباً ۱۰٪ مطابقت داشته باشند؛ این شکاف به این دلیل به وجود می‌آید که مسیرهای شکست‌خورده (کوتاه‌تر) سهم نامتناسبی در بودجه تعویق دارند.
• تعویق تصادفی با همان نرخ، امتیاز ۷۷.۰٪ را کسب می‌کند — که هنوز بهتر از حالت فقط مدل کوچک (۶۸.۳٪) است، اما بدتر از تعویق هدایت‌شده توسط سنجش عدم قطعیت (UQ). سیگنال عدم قطعیت واقعاً اهمیت دارد، نه فقط عمل فراخوانی بیشتر مدل بزرگ.
• MiniGrid فضای بهبود کمتری نشان می‌دهد. Qwen3-80B + GPT-5.2 با تعویق PPL به ۹۵.۰٪ می‌رسد در حالی که GPT-5.2 به تنهایی ۹۹.۰٪ است. دایره لغات محدودتر وظایف در اینجا باعث می‌شود وقتی مدل کوچک از نظر ساختاری ناتوان است، سقف سخت‌تری برای رویکرد تعویق ایجاد شود.
• توزیع تعویق وابسته به وظیفه است. ALFWorld در مراحل بعدی (تاریخچه پرامپت طولانی‌تر) بیشتر تعویق می‌دهد، در حالی که MiniGrid الگویی دو‌وجهی وابسته به موقعیت اولیه عامل نشان می‌دهد. این بدان معناست که کالیبراسیون آستانه ثابت در یک خانواده وظیفه بهتر از بین خانواده‌های مختلف تعمیم می‌یابد.

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

یافته تجربی اصلی معتبر است: پرپلکسیتی روی رشته اقدام، جایگزین مناسبی برای تشخیص احتمال خطای یک مرحله است. تجزیه استدلال/اقدام در ReAct طبیعتاً نقطه تمیزی را برای پیوست کردن سیگنال عدم قطعیت فراهم می‌کند و آزمایش کمکی پیش‌بینی صحت، توجیه مکانیکی واقعی برای این انتخاب طراحی ارائه می‌دهد.

آنچه من کمتر نسبت به آن متقاعد شده‌ام: نتیجه "فراتر رفتن از مدل بزرگ به تنهایی" در ALFWorld است. ۸۰.۸٪ ± ۱.۱٪ در مقابل ۷۸.۳٪ ± ۱.۹٪ در یک انحراف معیار همپوشانی دارند. نویسندگان این موضوع را به نقاط قوت مکمل نسبت می‌دهند — مدل کوچک مراحل روتین را بدون ریسک‌پذیری‌های گاه‌به‌گاه مدل بزرگ انجام می‌دهد — اما هیچ تحلیل جزئی‌تری (ablation) برای تایید این روایت وجود ندارد. این نتیجه می‌تواند به سادگی ناشی از نویز باشد.

انتخاب بنچمارک نیز محدودکننده است. ALFWorld و MiniGrid شبیه‌سازی‌های خانگی متنی و مسیریابی در جهان شبکه‌ای هستند — محیط‌های محدودی که فراخوانی ابزار، اجرای کد یا بازیابی اسناد چندگانه را به چالش نمی‌کشند. اینکه آیا تعویق کالیبره‌شده با عدم قطعیت در آن تنظیمات غنی‌تر (تنظیماتی که برای Beancount مرتبط هستند) پابرجا می‌ماند یا خیر، بی‌پاسخ مانده است. همچنین انتخاب GPT-5.2 به عنوان مدل بزرگ، بازتولید اعداد هزینه را دشوار می‌کند.

فرآیند کالیبراسیون دارای یک چرخش حل‌نشده است: آستانه روی همان توزیعی انتخاب می‌شود که روی آن کالیبره شده است، بدون اعتبارسنجی جداگانه. نویسندگان تغییر توزیع بین کالیبراسیون (خروجی‌های مدل کوچک) و ارزیابی (خروجی‌های ترکیبی) را می‌پذیرند، اما پایداری آستانه را به کارهای آینده واگذار می‌کنند.

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

عامل‌های ثبت بازگشت Beancount در هر تراکنش دقیقاً با همین پرسش تعویق مواجه هستند. یک خرید خواربار روتین نیاز به دسته‌بندی دارد؛ اما یک معامله ارزی چندمرحله‌ای غیرمعمول با یادداشت‌های نیمه‌منطبق، نیاز به بازبینی انسانی دارد. روش فعلی یا اتوماسیون کامل (پرخطر) است یا بازبینی کامل انسانی (گران). چارچوب ReDAct یک راه میانی عملی را پیشنهاد می‌دهد: مدل ارزان را اجرا کنید و زمانی که پرپلکسیتی روی ورودی پیشنهادی در دفتر روزنامه (journal) از آستانه کالیبره‌شده فراتر رفت، آن را ارجاع دهید.

بستر مالی دو ملاحظه را اضافه می‌کند که در مقاله به آن‌ها پرداخته نشده است. اول، تعویق در اینجا اغلب باید به معنای توقف و پرسش از کاربر باشد، نه فراخوانی یک LLM بزرگتر — معیار صحت دفتر کل، نیت کاربر است، نه امتیاز یک بنچمارک. دوم، بازگشت‌ناپذیری یک ورودی ثبت‌شده در Beancount بالاتر از یک شیء اشتباه قرار داده شده در ALFWorld است. هدف کالیبراسیون K احتمالاً باید به جای اولویت دادن به دقت مدل کوچک، به سمت محافظه‌کاری در ارجاع تنظیم شود.

سیگنال کاهش ۶۴ درصدی هزینه، حتی با این ملاحظات، ارزش جدی گرفتن را دارد. اگر یک عامل Beancount تراکنش‌های یک ماه را پردازش کند و تنها ۱۵٪ از تصمیمات دسته‌بندی به مدل گران‌قیمت نیاز داشته باشند، اقتصاد اجرای یک عامل ثبت بازگشت توانمند بسیار بهتر به نظر می‌رسد.

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

• KnowNo (Ren et al., 2023, CoRL): "روبات‌هایی که کمک می‌خواهند: هم‌ترازی عدم قطعیت برای برنامه‌ریزهای مدل زبانی بزرگ" — از پیش‌بینی منسجم (conformal prediction) برای کالیبره کردن یک ضمانت پوشش در مورد زمان درخواست کمک استفاده می‌کند. ReDAct با آن مقایسه نشده است؛ درک توازن بین ضمانت‌های منسجم و کالیبراسیون آستانه پیش از انتخاب رویکرد نهایی مهم است. [arXiv:2307.01928]
• بررسی تخمین اعتماد و کالیبراسیون در مدل‌های زبانی بزرگ (Guo et al. updated, NAACL 2024) — طبقه‌بندی سیستماتیک اعتماد لفظی، روش‌های مبتنی بر نمونه‌برداری و کالیبراسیون پس از واقعه؛ پیش‌زمینه تئوری برای تصمیم‌گیری در مورد اینکه آیا پرپلکسیتی جایگزین درستی برای عدم قطعیت است یا اینکه مقیاس‌بندی لوجیت کالیبره‌شده عملکرد بهتری خواهد داشت. [arXiv:2311.08298]
• UALA: عامل زبانی آگاه از عدم قطعیت (Han, Buntine, Shareghi) — یک آستانه عدم قطعیت ساختاری مشابه را برای تصمیم‌گیری در مورد فراخوانی ابزار (فراخوانی ابزار در مقابل تکیه بر دانش مدل) اعمال می‌کند و فراخوانی‌های ابزار را بیش از ۵۰٪ کاهش می‌دهد؛ مکمل مستقیم ReDAct برای محور استفاده از ابزار در عدم قطعیت عامل. [https://uala-agent.github.io/]

مقاله​

OpenHands (Wang et al., 2024; ICLR 2025) یک پلتفرم متن‌باز برای ساخت و ارزیابی عامل‌های LLM است که به عنوان توسعه‌دهندگان نرم‌افزار عمومی عمل می‌کنند. این مقاله که توسط Xingyao Wang و Graham Neubig در یک تیم ۲۴ نفره رهبری شده است، ادعا می‌کند که اکثر فریم‌ورک‌های عامل فعلی یا برای کارهای تحقیقاتی بیش از حد محدود هستند (حلقه‌های وظیفه سخت‌کد شده) یا برای تولید بیش از حد محدودند (متن‌بسته یا تک‌منظوره) و نمی‌توانند به عنوان یک پایه مشترک برای جامعه تحقیقاتی خدمت کنند. OpenHands سعی می‌کند این مشکل را با ارائه یک زمان‌اجرای استاندارد، یک انتزاع تمیز از عامل و ۱۵ بنچمارک ارزیابی یکپارچه تحت یک مخزن با لایسنس MIT حل کند.

زمان‌اجرا (Runtime) یک محیط ایزوله Docker شامل یک Bash Shell، یک سرور Jupyter IPython و یک مرورگر Chromium تحت کنترل Playwright است. عامل‌ها از طریق سه نوع اکشن اصلی تعامل دارند: IPythonRunCellAction برای پایتون، CmdRunAction برای دستورات شل، و BrowserInteractiveAction برای پیمایش وب. یک ابتدایه‌ی هماهنگی چند-عاملی به نام AgentDelegateAction به یک عامل اصلی اجازه می‌دهد تا عامل‌های فرعی تخصصی ایجاد کند. ستون فقرات پیش‌فرض CodeAct است — که در ابتدا به عنوان یک مقاله مستقل منتشر شد و استدلال می‌کرد که کد بهترین فضای اکشن یکپارچه برای عامل‌های LLM است — و پلتفرم چندین پیاده‌سازی عامل از جمله یک CodeActAgent عمومی و یک BrowsingAgent تخصصی را ارائه می‌دهد.

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

• کد به عنوان فضای اکشن جهانی: CodeAct تمام اکشن‌های عامل (ویرایش فایل، فراخوانی API، تبدیل داده‌ها) را در پایتون یا Bash تجمیع می‌کند و به LLM اجازه می‌دهد در همان رسانه‌ای که به شدت روی آن آموزش دیده، استدلال کند. این کار باعث دور زدن شکنندگی طرحواره‌های JSON می‌شود که عامل‌های فراخوان تابع (Function-calling) را دچار مشکل می‌کند.
• زمان‌اجرای ایزوله Docker: هر عامل در یک کانتینر مجزا اجرا می‌شود، بنابراین عامل‌ها می‌توانند آزادانه کد دلخواه را بدون به خطر انداختن ماشین میزبان اجرا کنند؛ این یک پیش‌نیاز برای هر عامل مالی در محیط تولید است که ممکن است اعتبارنامه‌های واقعی به آن سپرده شود.
• ۱۵ بنچمارک در یک مهار: SWE-Bench Lite (ترمیم کد)، HumanEvalFix (رفع باگ)، WebArena (پیمایش وب)، GPQA (استدلال سطح فارغ‌التحصیلی)، GAIA (حل وظایف عمومی) و ده مورد دیگر. تجمیع این‌ها در یک مکان از ارزیابی‌های گزینشی (Cherry-picked) جلوگیری می‌کند.
• CodeActAgent + claude-3.5-sonnet به امتیاز ۲۶٪ در SWE-Bench Lite و ۷۹.۳٪ در HumanEvalFix دست می‌یابد؛ BrowsingAgent به ۱۵.۵٪ در WebArena می‌رسد — رقابت در سطح Zero-shot بدون هیچ آموزش خاصِ وظیفه.
• عملکرد GAIA: ۳۲.۱٪ با GPTSwarm، که بسیار پایین‌تر از خط پایه ۹۲ درصدی انسانی است — همسو با هر بنچمارک عامل عمومی دیگر که شکاف ۶۰ تا ۷۰ امتیازی بین انسان و عامل را نشان می‌دهد.
• مقیاس جامعه: ۷۱.۴ هزار ستاره در گیت‌هاب و بیش از ۱۸۸ مشارکت‌کننده در زمان ارسال به ICLR؛ TheAgentCompany از OpenHands به عنوان مهار ارزیابی خود استفاده کرد و به آن جایگاه دوفاکتوی زیرساخت بنچمارک را بخشید.

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

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

با این حال، پوشش بنچمارک‌ها بیشتر آرمانی است تا سیستماتیک. این ۱۵ بنچمارک انواع وظایف و سطوح دشواری بسیار متفاوتی را بدون یک چارچوب مشخص برای نحوه تجمیع یا مقایسه نتایج در بر می‌گیرند. گزارش ۲۶٪ در SWE-Bench Lite در کنار ۷۹.۳٪ در HumanEvalFix در همان مقاله، این خطر را دارد که این تصور را ایجاد کند که یک عامل به طور همزمان متوسط و عالی است — در حالی که وظایف به سادگی قابل مقایسه نیستند. نویسندگان روش‌شناسی اصولی برای تجمیع بنچمارک‌های چندگانه ارائه نمی‌دهند.

فرض CodeAct — مبنی بر اینکه کد قالب اکشن جهانیِ درستی است — مورد مناقشه است. این روش برای وظایف توسعه خوب عمل می‌کند، اما یک لایه میانجی پایتون/Bash را بر هر اکشنی تحمیل می‌کند که باعث افزایش تأخیر می‌شود و زمانی که معنای اکشن به وضوح به کد نگاشت نمی‌شود (دستورات مبهم کاربر، APIهای صرفاً مبتنی بر زبان طبیعی) با شکست مواجه می‌شود. مقاله در برابر فضاهای اکشن غیر-کد بنچمارک نمی‌گیرد تا ثابت کند این مزیت واقعی است و نه صرفاً ناشی از قدرت مدل LLM زیربنایی.

شاید مهم‌ترین شکاف، شکاف بین ارزیابی و استقرار (Deployment) باشد. عدد ۲۶٪ در SWE-Bench از یک بنچمارک نسبتاً تمیز و با مشخصات دقیق به دست آمده است. گزارش‌های جامعه و رشته‌های مسائل گیت‌هاب به طور مداوم قابلیت اطمینان بسیار پایین‌تری را در وظایف دنیای واقعی مبهم یا طولانی‌مدت توصیف می‌کنند — همان حالت شکستی که TheAgentCompany مستند کرده بود. مقاله به چگونگی اندازه‌گیری یا بهبود استحکام تحت نویزِ مشخصات وظایف واقع‌گرایانه نمی‌پردازد.

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

OpenHands نزدیک‌ترین چیز به یک زیربستر عامل مشترک است که جامعه در اختیار دارد. اگر Bean Labs زیرساخت ارزیابی برای عامل‌های Beancount بسازد، معماری زمان‌اجرا در اینجا — سندباکس Docker، اکشن‌های پایتون/Bash، بک‌اندهای LLM قابل تعویض — به جای بازسازی، ارزش پذیرش دارد. ابتدایه‌ی AgentDelegateAction به طور طبیعی با یک خط لوله عامل مالی نگاشت می‌شود که در آن یک هماهنگ‌کننده سطح بالا وظایف را به عامل‌های فرعی تخصصی واگذار می‌کند: یکی برای خواندن دفتر کل، یکی برای نشانه‌گذاری موارد غیرعادی، و یکی برای پیشنهاد ثبت در دفتر کل (write-back) که یک انسان آن را بازبینی می‌کند.

اعداد SWE-Bench و TheAgentCompany با هم یک پیش‌فرض تأمل‌برانگیز را ایجاد می‌کنند: حتی بهترین عامل‌های موجود، تقریباً ۲۶ تا ۳۰ درصد از وظایف نرم‌افزاری واقع‌گرایانه و بدون ابهام را کامل می‌کنند. اتوماسیون دفتر کل مالی سخت‌تر است — تراکنش‌ها اغلب مبهم هستند، شعاع تخریب خطاها واقعی است و قصد کاربر مکرراً به طور ناقص مشخص می‌شود. استنتاج درست این نیست که عامل‌ها آماده نیستند، بلکه این است که اولین استقرارهای مولد باید گردش‌کارهای «یک‌بار نوشتن» با محدوده دقیق (پیشنهادات دسته‌بندی، نشانه‌گذاری مغایرت‌ها) باشند، نه ویرایش‌های چندمرحله‌ای و خودمختار دفتر کل.

چه چیزی را در ادامه بخوانیم​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — یک مدل ارزان را با یک مدل گران جفت می‌کند و تنها زمانی که عدم قطعیت بالا باشد به مدل گران ارجاع می‌دهد؛ مستقیماً به این موضوع می‌پردازد که یک عامل به سبک OpenHands چگونه باید تصمیم بگیرد که چه زمانی یک ثبت در Beancount را برای بازبینی به انسان ارجاع دهد.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — شامل ۸۰۰ توالی وظیفه با برچسب‌گذاری کارشناسی در ۳۴ سناریوی مالی؛ روش ارزیابی که OpenHands برای استفاده از ابزارهای طولانی‌مدت خاصِ حوزه مالی فاقد آن است.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — ۶۱۳ نمونه در ۶۵ ابزار مالی واقعی MCP؛ مستقیماً با نحوه ارزیابی یک عامل Beancount ساخته شده بر روی زمان‌اجرای OpenHands در یک استقرار واقعی MCP مرتبط است.

مقاله​

مقاله Fin-RATE که در فوریه ۲۰۲۶ توسط یدونگ جیانگ، جونرونگ چن و همکارانشان در دانشگاه ییل و موسسات همکار منتشر شد، بنچ‌مارکی را معرفی می‌کند که از ۲۴۷۲ سند SEC مربوط به ۴۳ شرکت در ۳۶ صنعت بین سال‌های ۲۰۲۰ تا ۲۰۲۵ ساخته شده است. این بنچ‌مارک ۷۵۰۰ جفت پرسش و پاسخ منتخب کارشناسان را در سه نوع وظیفه سازماندهی می‌کند که منعکس‌کننده جریان کار تحلیل‌گران حرفه‌ای است: DR-QA (جزئیات و استدلال در یک سند واحد)، EC-QA (مقایسه بین-موجودیتی دو شرکت در یک موضوع مشترک) و LT-QA (ردیابی طولی یک شرکت در دوره‌های گزارش‌دهی مختلف). هر نوع وظیفه شامل ۲۵۰۰ سوال است. ارزیابی روی ۱۷ مدل زبانی بزرگ انجام شده است - از مدل‌های منبع‌بسته شامل GPT-4.1 و GPT-5 گرفته تا مدل‌های عمومی منبع‌باز مانند DeepSeek-V3 و Llama-3.3-70B، و مدل‌های تخصصی مالی مانند Fin-R1، Fino1-14B، FinanceConnect-13B و TouchstoneGPT-7B. امتیازدهی از یک چارچوب یکپارچه "LLM-به‌عنوان-داور" با سه داور مستقل (GPT-5، DeepSeek-V3.2، Qwen3-235B) استفاده می‌کند که هر پاسخ را بر اساس صحت و پنج بعد تحلیلی رتبه‌بندی می‌کنند.

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

• با افزایش پیچیدگی وظایف، عملکرد کاهش می‌یابد: دقت از DR-QA (تک‌سندی) به LT-QA (طولی) ۱۸.۶۰ درصد و از DR-QA به EC-QA (بین-موجودیتی) ۱۴.۳۵ درصد کاهش می‌یابد (میانگین تمام ۱۷ مدل).
• مدل GPT-5 با جستجوی وب بهترین عملکرد را دارد، اما اوج دقت آن در هر سه نوع وظیفه تنها حدود ۴۳ تا ۴۴ درصد است؛ رقمی ناامیدکننده برای بنچ‌مارکی که قرار است بازتاب‌دهنده جریان کار تحلیل‌گران واقعی باشد.
• مدل Fin-R1 که یک مدل استدلالی تخصصی در امور مالی است، در DR-QA به ۵۷.۴۸ درصد می‌رسد اما در EC-QA به ۳.۳۲ درصد سقوط می‌کند؛ افتی ۵۴ امتیازی که بسیار فراتر از کاهش عملکرد در مدل‌های عمومی است.
• در تنظیمات RAG، عملکرد تمام مدل‌ها به زیر ۲۷ درصد می‌رسد، در حالی که در حالت "زمینه طلایی" عملکرد تا ۵۷.۴۸ درصد است؛ این نشان می‌دهد که گلوگاه اصلی نه خود مدل، بلکه خط لوله بازیابی (retrieval pipeline) است.
• مقاله یک طبقه‌بندی ۱۳ نوعی از خطاها را در چهار دسته معرفی می‌کند: توهم و تضاد، خطاهای عددی و معنایی خاصِ مالی، خطاهای درک پرس‌وجو/زمینه و شکست‌های سطح بازیابی. "فقدان شواهد" مسئول ۷۵.۴۴ درصد خطاها در وظیفه EC-QA تحت سیستم RAG است.
• مدل‌های تخصصی مالی علیرغم تسلط بهتر بر واژگان مالی، نرخ توهم سیستماتیک بالاتری نسبت به مدل‌های عمومی در وظایف پیچیده نشان می‌دهند.

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

ساختار سه مسیری این بنچ‌مارک واقعاً خوب طراحی شده است. اکثر بنچ‌مارک‌های مالی (مانند FinQA، TAT-QA، FinanceBench) پرسش و پاسخ را به عنوان یک وظیفه تک‌سندی در نظر می‌گیرند. Fin-RATE یکی از اولین مواردی است که صراحتاً مقایسه بین-موجودیتی و ردیابی طولی را به عنوان وظایف درجه اول مدل‌سازی می‌کند و نتایج نشان‌دهنده یک شکاف اساسی است: مدل‌های زبانی فعلی پرسش و پاسخ‌های افشای مالی منفرد را به شکل قابل قبولی مدیریت می‌کنند، اما به محض اینکه نیاز به سنتز اطلاعات از میان اسناد، موجودیت‌ها یا دوره‌های زمانی مختلف باشد، از هم می‌پاشند.

سقوط Fin-R1 خیره‌کننده‌ترین یافته مقاله است و فکر می‌کنم به آن کم‌توجهی شده است. یک مدل بهینه‌سازی شده برای امور مالی که در استخراج تک‌سندی برتری دارد، ظاهراً خود را در یک بن‌بست آموزش داده است: این مدل الگوهای پاسخگویی در یک سند را یاد گرفته، نه استراتژی‌های استدلالی برای مرتبط کردن موجودیت‌ها و دوره‌های زمانی. این یک هشدار جدی علیه تنظیم دقیق (fine-tuning) محدود به دامنه بدون نظارت صریح بر استدلال چندسندی است. مدل احتمالاً روی الگوی سطحی "عدد را در سند پیدا کن" بیش‌برازش (overfit) شده و هیچ مسیر تعمیم‌دهی برای "مقایسه این عدد با عدد معادل در سند دیگری از یک شرکت دیگر" ندارد.

با این حال، نگرانی‌های متدولوژیکی وجود دارد که باید به آن‌ها اشاره کرد. GPT-5 همزمان یکی از مدل‌های مورد ارزیابی و یکی از سه داوری است که به پاسخ‌ها امتیاز می‌دهد. نویسندگان برای کاهش سوگیری فردی از سه داور استفاده کرده‌اند که کمک‌کننده است، اما همپوشانی داور-مدل با قوی‌ترین مدل مورد ارزیابی نگران‌کننده است. مقاله توافق بالای بین داوران را گزارش می‌کند اما به طور جداگانه مشخص نمی‌کند که چه بخشی از پاسخ‌های GPT-5 توسط خود GPT-5 امتیازدهی شده و آیا امتیازهای خودارزیابی GPT-5 به طور سیستماتیک با دو داور دیگر تفاوت دارد یا خیر. هرگونه سوگیری در خودارزیابی می‌تواند نتیجه نهایی بهترین مدل مطالعه را بیش از حد نشان دهد.

نمونه ۴۳ شرکتی نیز اندک است. پوشش انواع اسناد ستودنی است (10-K, 10-Q, 8-K, 6-K, DEF 14A و چندین سری S و SC)، اما همان ۴۳ شرکت در تمام وظایف تکرار می‌شوند. مدل‌هایی که افشاهای این شرکت‌ها را در مرحله پیش‌آموزش دیده‌اند، مزیتی غیرقابل اندازه‌گیری دارند و مقاله شامل هیچ‌گونه تحلیل آلودگی داده‌ها نیست.

یافته‌های مربوط به بازیابی مهم اما ناقص هستند. مقاله شناسایی می‌کند که عملکرد RAG به دلیل شکست در بازیابی، حدود ۳۰ امتیاز نسبت به زمینه طلایی سقوط می‌کند. اما تنها یک تنظیمات بازیابی واحد را بنچ‌مارک می‌کند؛ یعنی با شکست بازیابی به عنوان یک تشخیص برخورد می‌کند تا چیزی که بخواهد آن را به طور سیستماتیک تغییر دهد. یک مقاله تکمیلی که معماری‌های مختلف بازیابی را روی Fin-RATE بررسی کند، بسیار کاربردی‌تر خواهد بود.

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

حسابرس دفترکل Beancount دقیقاً به همان دو قابلیتی نیاز دارد که Fin-RATE نشان داد دچار مشکل هستند: ردیابی طولی (این حساب در طول سال‌های مالی چگونه تغییر کرد؟) و مقایسه بین-موجودیتی (آیا ترازنامه این شرکت فرعی با صورت مالی تلفیقی مطابقت دارد؟). افت دقت ۱۸.۶۰ درصدی در ردیابی زمانی، عدد ملموسی است که باید انتظارات ما را از هر عامل Beancount که در چندین دوره گزارش‌دهی استدلال می‌کند، تنظیم کند. اگر مدل‌های پیشرو در پرسش و پاسخ طولی SEC با "زمینه طلایی" در ۴۳ درصد شکست می‌خورند، یک عامل Beancount که در تاریخچه‌های چندساله دفترکل پیمایش می‌کند باید با بازیابی صریح، ارجاع زمانی و امکان ارجاع به انسان طراحی شود - نه فقط با استنتاج مستقیم مدل زبانی.

یافته‌ی مربوط به غلبه بازیابی، بیش از همه برای اولویت‌بندی طراحی سیستم اهمیت دارد. اگر عملکرد در حالت زمینه طلایی تقریباً دو برابر عملکرد RAG است، سرمایه‌گذاری درست روی خرد کردن بهتر متن (chunking)، انتخاب قطعات و بازیابی است - نه یک مدل زبانی پایه قدرتمندتر. این مشابه همان چیزی است که DocFinQA برای اسناد طولانی SEC پیدا کرد: گلوگاه اصلی، خط لوله اطراف مدل است.

هشدار مربوط به Fin-R1 نیز مستقیماً در مورد Beancount صدق می‌کند. تنظیم دقیق روی نحو DSL زبان Beancount و الگوهای تراکنش ممکن است مدلی تولید کند که تولید ورودی‌های ساده را به خوبی انجام دهد، اما در فرآیند تطبیق چند-حسابی و چند-دوره‌ای که حسابرسی را مفید می‌کند، با شکست مواجه شود. تخصص‌گرایی بدون آموزش استدلال چندسندی دقیقاً به همان روش‌هایی که Fin-RATE اندازه‌گیری می‌کند، شکننده است.

چه چیزی را بعداً بخوانیم​

• Fin-R1 (arXiv:2503.16252) — برای درک اینکه چه تنظیمات آموزشی چنین عملکرد ضعیفی را در اسناد چندگانه ایجاد کرده و آیا استدلال چندسندی اصلاً جزو اهداف بوده است یا خیر.
• FinTrace (arXiv:2604.10015) — ارزیابی در سطح مسیرِ فراخوانی ابزار توسط مدل‌های زبانی در ۳۴ دسته وظایف مالی؛ این مطالعه دیدگاه پرسش و پاسخ ایستا در Fin-RATE را با تشخیص سطح فرآیند (جایی که مدل‌ها ابزارهای درست را فراخوانی می‌کنند اما در استدلال روی نتایج شکست می‌خورند) تکمیل می‌کند.
• OpenHands (arXiv:2407.16741) — پلتفرم عامل باز که زیربنای ارزیابی‌های TheAgentCompany است؛ درک معماری آن روشن می‌کند که کدام قابلیت‌های پایه عامل‌ها در دسترس بوده و کدام شکاف‌ها ناشی از دشواری وظیفه است نه محدودیت‌های پلتفرم.

مقاله​

چانیول چوی، جیهون کوون و همکاران در یک شرکت هوش مصنوعی مالی، مجموعه‌ای از داده‌ها شامل ۵,۷۰۳ سه‌تایی پرس‌وجو-شواهد-پاسخ که توسط کارشناسان حاشیه‌نویسی شده و از یک سرویس پرسش و پاسخ تحلیل‌گر صندوق پوشش ریسک واقعی تهیه شده است، ارائه می‌دهند. اسناد شامل پرونده‌های فرم 10-K از ۴۹۰ شرکت شاخص S&P 500 هستند که از SEC EDGAR جمع‌آوری شده‌اند. آنچه FinDER را از بنچمارک‌های قبلی متمایز می‌کند، بخش پرس‌وجو است: ۸۹.۸۶٪ از پرس‌وجوها شامل سه یا چند اختصار یا کوته‌نوشت تخصصی حوزه هستند. به جای "درآمد کل شرکت X برای سال مالی ۲۰۲۳ چقدر است؟"، یک تحلیل‌گر واقعی ممکن است تایپ کند "GOOGL 10-K FY23 revs breakdown by segment". این دیتاست در کارگاه ICLR 2025 در مورد پیشرفت‌های هوش مصنوعی مالی منتشر شد و بعداً در ICAIF 2025 ظاهر گردید.

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

• بازخوانی بازیابی در تمام سطوح به طور تکان‌دهنده‌ای پایین است: E5-Mistral (بهترین بازیاب متراکم) در مجموع تنها ۲۵.۹۵٪ بازخوانی بافتار را به دست می‌آورد؛ BM25 به ۱۱.۶۸٪ می‌رسد. دسته "مالی" (Financials) — که مستقیم‌ترین ارتباط را با حسابداری دارد — سخت‌ترین دسته است: به ترتیب ۱۵.۸۴٪ و ۶.۴۲٪.
• ابهام در پرس‌وجو به تنهایی ۸.۲ واحد از دقت می‌کاهد: نویسندگان با آزمایش E5-Mistral بر روی ۵۰۰ پرس‌وجو، جملات بازنویسی شده با ساختار مناسب (دقت ۳۳.۹) را با پرس‌وجوهای مختصر واقعی (دقت ۲۵.۷) مقایسه می‌کنند. این شکاف کاملاً مربوط به مدیریت اختصارات/کوته‌نوشت‌هاست و نه پیچیدگی سند.
• کیفیت بازیابی گلوگاه اصلی برای تولید (Generation) است: مدل‌های زبانی بزرگ (LLM) بدون بافتار امتیازی نزدیک به صفر (۹-۱۰٪ پاسخ صحیح) می‌گیرند؛ با ۱۰ پاراگراف برتر بازیابی شده به ۲۹-۳۴٪ می‌رسند؛ و با بافتار ایده‌آل (اوراکل) به ۶۰-۶۸٪ جهش می‌کنند. این شکاف ۳۵ واحدی بین شرایط واقع‌بینانه و شرایط ایده‌آل، بزرگتر از شکاف بین مدل‌های متن‌باز و مدل‌های پیشرو (Frontier) است.
• محاسبات ترکیبی حتی با بازیابی خوب هم شکست می‌خورند: وظایف محاسباتی چند مرحله‌ای (پرس‌وجوهای ترکیبی) تنها به حدود ۲۰٪ صحت در هر چهار مدل — Claude-3.7-Sonnet، GPT-o1، DeepSeek-R1-Distill و Qwen-QWQ — حتی با ۱۰ پاراگراف برتر بازیابی شده می‌رسند. GPT-o1 در وظایف ضرب با ۴۲.۹۰٪ پیشتاز است اما در تقسیم به ۲۷.۷۸٪ سقوط می‌کند.
• رتبه‌بندی مجدد توسط LLM بهبود متوسط اما ثابتی ایجاد می‌کند: با اجازه دادن به مدل‌ها برای رتبه‌بندی مجدد ۱۰ نتیجه برتر E5-Mistral قبل از پاسخگویی، Claude-3.7-Sonnet به F1 معادل ۶۳.۰۵ و GPT-o1 به ۶۲.۹۰ می‌رسد. Deepseek-R1-Distill با ۶۰.۰۱ عقب می‌ماند، علی‌رغم عملکرد قوی در استدلال‌های ساختاریافته در جاهای دیگر.
• دشواری دسته‌بندی‌ها نابرابر است: بازیابی پرس‌وجوهای مربوط به ریسک آسان‌ترین است (E5-Mistral: بازخوانی ۳۳.۰۷)؛ امور مالی همچنان سخت‌ترین باقی می‌ماند (۱۵.۸۴). این موضوع با ساختار پرس‌وجو همبستگی دارد — افشای ریسک از نثر زبان طبیعی استفاده می‌کند، در حالی که جداول مالی از نمادگذاری عددی متراکم بهره می‌برند.

آنچه پابرجاست — و آنچه نیست​

مشارکت اصلی این مقاله مستحکم است: این یک توزیع پرس‌وجوی واقعی از تحلیل‌گران شاغل است و مشکل اختصارات واقعی است. هر بنچمارکی که از ویکی‌پدیا یا جمع‌سپاری به سبک FinQA ساخته شده باشد، این نکته را از دست می‌دهد. ساختار ارزیابی سه سطحی — بدون بافتار، بازیابی واقع‌بینانه، بافتار ایده‌آل — طراحی درستی است؛ این ساختار به وضوح کیفیت بازیابی را از کیفیت استدلال جدا می‌کند و شکاف باقی‌مانده در تولید را نشان می‌دهد (هنوز حدود ۳۲-۳۴٪ شکست حتی با بافتار کامل در سوالات کیفی وجود دارد).

جایی که مقاله ضعیف‌ترین عملکرد را دارد، در بازتولیدپذیری (Reproducibility) است. در زمان انتشار، دیتاست به صورت عمومی در دسترس نبود — نویسندگان بیان کردند که "قصد دارند آن را بعداً به صورت عمومی منتشر کنند". این یک مشکل بزرگ برای یک مقاله کارگاهی است که خود را به عنوان یک استاندارد ارزیابی معرفی می‌کند. بنچمارک‌هایی که منتشر نمی‌شوند، بنچمارک نیستند؛ آن‌ها مطالعه موردی هستند. از آنجایی که این مقاله در ICAIF 2025 ظاهر شده، ممکن است انتشار آن دنبال شده باشد، اما نسخه arXiv این موضوع را تأیید نمی‌کند.

ارزیابی بازیابی نیز تنها از چهار مدل تک‌مرحله‌ای (BM25, GTE, mE5, E5-Mistral) استفاده می‌کند. هیچ بازیابی ترکیبی، هیچ گسترش پرس‌وجویی، هیچ HyDE یا مرحله بازنویسی که به طور خاص مشکل اختصارات را هدف قرار دهد، وجود ندارد. با توجه به اینکه نویسندگان شکاف ناشی از اختصارات را دقیقاً مشخص کرده‌اند، تعجب‌آور است که راه حل بدیهی را آزمایش نمی‌کنند: گسترش پرس‌وجو (مثلاً تبدیل "GOOGL" به "Alphabet Inc.") قبل از بازیابی. این آزمایش غایب است.

نتایج تولید مستحق خواندن دقیق‌تری است. عملکرد ۹-۱۰ درصدی بدون بافتار یک حد پایین مفید نیست — عملاً صفر است — اما سقف ۶۰-۶۸ درصدی اوراکل آموزنده‌تر از آن چیزی است که به نظر می‌رسد. حتی با داشتن پاراگراف صحیح در دست، بهترین مدل‌ها در تقریباً یک‌سوم سوالات کیفی و چهارپنجم محاسبات ترکیبی شکست می‌خورند. این سقف مهم است: به این معنی است که بازیابی به تنهایی نمی‌تواند مشکل را حل کند.

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

توزیع پرس‌وجوها در FinDER به خوبی با نحوه تعامل کاربران Beancount با یک عامل دفتر کل (Ledger Agent) مطابقت دارد. کاربری که سال‌ها حساب‌های خود را نگه داشته است، پرس‌وجوهای مختصر و بافت‌محور تایپ می‌کند — "AMZN card Q3 reimb؟" به جای "بازپرداخت‌های کارت اعتباری آمازون در سه ماهه سوم چقدر است؟". مدل‌های جاسازی استاندارد در بازیابی ورودی‌های صحیح شکست خواهند خورد زیرا آن‌ها بر روی متن‌های تمیز زبان طبیعی آموزش دیده‌اند. افت دقت ۸.۲ واحدی از پرس‌وجوهای تمیز به واقعی احتمالاً برای حوزه دفتر کل شخصی محافظه‌کارانه است، جایی که علائم اختصاری خاصِ فرد ("prop mgmt fee" برای "property management fee") حتی از اختصارات استاندارد SEC هم از داده‌های آموزشی دورتر هستند.

سقف بازخوانی بافتار ۲۵.۹۵ درصدی در E5-Mistral یک تابع اجباری است: هر خط لوله RAG در Beancount باید برای کسر بزرگی از شواهد از دست رفته بودجه‌بندی کند. یک نتیجه این است که بازیابی مجدد با بازخوانی بالا (چندین گذر، فرمولاسیون‌های پرس‌وجوی متنوع) مهم‌تر از فشار آوردن برای بهبود F1 در یک گذر واحد است. نتیجه دیگر این است که عادی‌سازی پرس‌وجو — نگاشت کوته‌نوشت‌های کاربر به نام‌های متعارف حساب‌ها قبل از بازیابی — باید یک مرحله پیش‌پردازش صریح باشد و به مدل جاسازی واگذار نشود.

دقت ۲۰ درصدی محاسبات ترکیبی حتی با بافتار ایده‌آل، سیگنال جداگانه‌ای است: برای وظایف محاسباتی Beancount، گلوگاه تولید، استدلال است و نه بازیابی. برون‌سپاری به سبک PAL (تولید کدهای محاسباتی پایتون به جای محاسبات متنی آزاد) همچنان پاسخ درستی برای وظایف عددی است، صرف نظر از اینکه بازیابی چقدر خوب شود.

برای مطالعه بیشتر​

• Fin-RATE (arXiv:2602.07294) — بنچمارک مکمل برای ردیابی چنددوره‌ای در پرونده‌های SEC؛ دقت در وظایف زمانی ۱۸.۶۰٪ کاهش می‌یابد، که مستقیماً همان مشکل دفتر کل چندساله Beancount است.
• IRCoT (arXiv:2212.10509, ACL 2023) — درهم‌تنیدگی بازیابی با استدلال زنجیره افکار (CoT)؛ ساختار بازیابی چندگذر مستقیماً به بازخوانی پایین تک‌گذر که FinDER افشا می‌کند، می‌پردازد.
• گسترش پرس‌وجو با LLMها برای بازیابی تخصصی دامنه — هنوز هیچ مقاله بنچمارک واحدی این موضوع را به خوبی پوشش نمی‌دهد، اما شکاف اختصارات در FinDER آن را به یک اولویت تحقیقاتی درجه اول تبدیل می‌کند؛ جستجو برای "HyDE financial domain" و "query expansion SEC filings 2025" نقطه شروع مناسبی است.

مقاله​

مقاله «گمشده در میان: چگونه مدل‌های زبانی از زمینه‌های طولانی استفاده می‌کنند» توسط نلسون اف. لیو، کوین لین، جان هویت، اشوین پارانجپه، میشل بویلاکوا، فابیو پترونی و پرسی لیانگ، دو آزمایش هدفمند را اجرا می‌کند: پاسخ‌گویی به سوالات چند سندی در NaturalQuestions-Open (با ۱۰، ۲۰ و ۳۰ سند بازیابی شده) و بازیابی مصنوعی کلید-مقدار (با ۷۵، ۱۴۰ و ۳۰۰ جفت). در هر آزمایش، آن‌ها به طور سیستماتیک مکان قرارگیری سند مرتبط یا جفت کلید-مقدار را در زمینه ورودی — ابتدا، میانه یا انتها — تغییر می‌دهند در حالی که بقیه موارد ثابت است. یافته شفاف است: عملکرد یک منحنی U-شکل را با پایین‌ترین نقطه در میان زمینه دنبال می‌کند و این منحنی در تمام مدل‌های آزمایش‌شده ظاهر می‌شود.

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

• منحنی U-شکل واقعی و ثابت است. در تنظیمات پرسش و پاسخ با ۲۰ سند، عملکرد در موقعیت اول تقریباً ۷۵٪ بود و در موقعیت ۱۰ به حدود ۵۵٪ کاهش یافت، پیش از آنکه در موقعیت ۲۰ به حدود ۷۲٪ بازگردد — شکافی حدوداً ۲۰ امتیازی بین لبه‌ها و مرکز.
• تمام مدل‌ها از الگوی مشابهی پیروی می‌کنند. مدل‌های آزمایش‌شده شامل مدل‌های بسته و متن‌باز، کوچک و بزرگ هستند: GPT-3.5-Turbo (4K و 16K)، GPT-4، Claude-1.3 (8K و 100K)، MPT-30B-Instruct و LongChat-13B. منحنی U-شکل در تک‌تک آن‌ها ظاهر شد، از جمله مدل‌هایی که صراحتاً برای پنجره‌های زمینه گسترده بازاریابی شده بودند.
• حتی Claude-1.3-100K نیز مصون نیست. نسخه ۱۰۰ هزار توکنی مشابه سایرین عمل کرد. داشتن یک پنجره زمینه طولانی به این معنا نیست که مدل واقعاً به طور یکنواخت به تمام بخش‌های آن توجه می‌کند.
• خط پایه کتاب-بسته کفِ دلسردکننده‌ای را تعیین می‌کند. GPT-3.5-Turbo بدون هیچ سندی ۵۶.۱٪ از سوالات NaturalQuestions را به درستی پاسخ داد؛ با دسترسی مستقیم (oracle) به تنها یک سند مرتبط، این رقم به ۸۸.۳٪ رسید. اما در بدترین موقعیت‌های میانی در تنظیمات ۲۰ سندی، عملکرد به زیر خط پایه کتاب-بسته سقوط کرد — به این معنی که افزودن زمینه بیشتر عملاً مضر بوده است.
• مدل‌های رمزگذار-رمزگشا (Flan-T5-XXL, Flan-UL2) در طول آموزش خود قوی‌تر هستند اما وقتی زمینه‌ها از آن فراتر می‌روند، دچار افت می‌شوند. تفاوت معماری اهمیت دارد، اما هر دو هنوز در مقیاس بزرگ افت عملکرد نشان می‌دهند.
• علت ریشه‌ای، ماسک کردن توجه علی (Causal Attention Masking) است. هر توکن فقط می‌تواند به توکن‌های قبلی توجه کند، بنابراین موقعیت‌های ابتدایی وزن توجه کل بیشتری را در سراسر مدل نسبت به موقعیت‌های میانی جمع‌آوری می‌کنند. اثرات تازگی (Recency effects) نیز انتهای زمینه را به بالا می‌کشد.

چه چیزی معتبر است — و چه چیزی نیست​

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

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

همچنین شکافی وجود دارد که نویسندگان عمدتاً به آن اذعان می‌کنند اما آن را پر نمی‌کنند: آن‌ها هرگز آزمایش نمی‌کنند که آیا تنظیم دقیق دستورالعمل (instruction fine-tuning) یا RLHF حساسیت موقعیتی را تغییر می‌دهد یا خیر، بلکه فقط تأثیر پنجره زمینه بزرگتر را بررسی می‌کنند. با توجه به اینکه علت ریشه‌ای معماری است (ماسک کردن علی)، گمان می‌کنم تنظیم دستورالعمل آن را حل نکند، اما مقاله این موضوع را تأیید نمی‌کند.

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

این مقاله توضیح ساختاری را برای الگوی تجربی که مدام با آن برخورد می‌کنم ارائه می‌دهد. DocFinQA در پرونده‌های طولانی SEC شکست خورد. IRCoT و FLARE هر دو چندین قطعه را بازیابی کرده و قبل از استدلال آن‌ها را به هم متصل می‌کنند. هر خط لوله RAG که در زمینه مالی دیده‌ام، قطعات بازیابی شده را به صورت متوالی در پرامپت می‌ریزد و امیدوار است که مدل به مورد درست توجه کند.

پیامد این موضوع برای ایجنت‌های Beancount ملموس است. اگر یک ایجنت ده ورودی دفتر کل را به عنوان زمینه بازیابی کند، ورودی‌های موقعیت‌های ۳ تا ۷ در بالاترین خطر نادیده گرفته شدن یا ایجاد توهم (hallucination) هستند. این یک مشکل بازیابی نیست — یک مشکل ارائه (presentation) است. دو پاسخ از این مقاله حاصل می‌شود: یا مرتبط‌ترین ورودی‌ها را در ابتدا (و انتها) قرار دهید، یا اصلاً آن‌ها را به هم متصل نکنید و هر بار روی یک قطعه استدلال کنید.

این یافته همچنین روایت «مدل‌های زبانی با زمینه طولانی» را پیچیده می‌کند. هر فصل یک مدل جدید پنجره زمینه بزرگتری را اعلام می‌کند. این مقاله می‌گوید طولانی بودن پنجره به این معنا نیست که اگر شواهد را به طور یکنواخت در آن توزیع کنید، همان‌طور که فکر می‌کنید عمل خواهد کرد. یک مدل با زمینه ۱۲۸ هزار توکنی که تراکنش مرتبط را در موقعیت ۶۰ هزار دفن می‌کند، بدتر از یک مدل با زمینه ۴ هزار توکنی است که دقیقاً قطعه درست را بازیابی می‌کند.

برای ایمنی بازنویسی (write-back safety)، پیامدها نگران‌کننده است: اگر از مدل خواسته شود یک جلسه دفتر کل را خلاصه کند و قانون سیاستی مربوط به «این تراکنش را ثبت نکن» در میان یک پرامپت سیستم طولانی ظاهر شود، مدل ممکن است طوری رفتار کند که انگار هرگز آن قانون را نخوانده است.

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

• «پیدا شده در میان: چگونه مدل‌های زبانی با استفاده از رمزگذاری موقعیتی Plug-and-Play از زمینه‌های طولانی بهتر استفاده می‌کنند» (Zhang et al., arXiv:2403.04797) — رمزگذاری موقعیتی چند مقیاسی (Ms-PoE) را به عنوان یک اصلاح بدون نیاز به آموزش از طریق مقیاس‌بندی RoPE پیشنهاد می‌کند؛ ادعای بهبود تا ۳.۸ امتیاز در Zero-SCROLLS را دارد که مستقیماً به منحنی U-شکل می‌پردازد.
• «هرگز در میان گم نشوید: تسلط بر پاسخ‌گویی به سوالات در زمینه طولانی با آموزش تجزیه‌محور مستقل از موقعیت» (arXiv:2311.09198) — رویکردی مخالف را در پیش می‌گیرد و مدل را آموزش می‌دهد تا صراحتاً نسبت به موقعیت بی‌تفاوت باشد؛ مقایسه با Ms-PoE مشخص می‌کند که آیا تنظیم دقیق یا ترفندهای زمان استنتاج اهرم بهتری هستند.
• «کاهش سوگیری موقعیتی در مدل‌های زبانی بزرگ از طریق مقیاس‌بندی یک بعد واحد» (arXiv:2406.02536) — بعد خاص حالت‌های مخفی موقعیتی را که مسئول سوگیری است شناسایی کرده و بدون نیاز به آموزش مجدد آن را مقیاس‌بندی می‌کند؛ جراحی‌ترین اصلاح پیشنهادی تا به امروز، مرتبط با استقرار مدل‌های موجود بدون آموزش مجدد.

مقاله​

تیان‌کای یانگ، یی نیان و همکارانشان در USC و Texas A&M، بنچ‌مارک AD-LLM را معرفی کردند (arXiv:2412.11142, ACL Findings 2025). این نخستین بنچ‌مارکی است که LLMها را به‌طور سیستماتیک در سه پارادایم تشخیص ناهنجاری روی مجموعه‌داده‌های NLP ارزیابی می‌کند. محیط آزمایش، طبقه‌بندی تک‌کلاسه (One-class classification) است: داده‌های آموزشی فقط شامل نمونه‌های نرمال هستند و مدل باید ناهنجاری‌ها را در زمان آزمایش شناسایی کند. پنج مجموعه‌داده — شامل AG News، BBC News، IMDB Reviews، N24 News و SMS Spam — همگی از وظایف طبقه‌بندی متن مشتق شده‌اند که در آن‌ها یک دسته به عنوان «ناهنجار» تعیین شده است. این مقاله دو مدل GPT-4o و Llama 3.1 8B Instruct را در برابر ۱۸ مدل پایه بدون نظارت سنتی قرار می‌دهد که شامل روش‌های سرتاسری (CVDD, DATE) و ترکیبات دو مرحله‌ایِ جاسازی‌ بعلاوه تشخیص‌دهنده (OpenAI embeddings + LUNAR, LOF, Isolation Forest و غیره) می‌شوند.

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

• تشخیص بدون آموزش (Zero-shot) برای متن به‌خوبی کار می‌کند. GPT-4o امتیاز AUROC بین ۰.۹۲۹۳ تا ۰.۹۹۱۹ را در پنج مجموعه‌داده در تنظیمات نرمال+ناهنجار کسب کرد؛ Llama 3.1 به امتیاز ۰.۸۶۱۲ تا ۰.۹۴۸۷ رسید. بهترین خط پایه سنتی، یعنی OpenAI + LUNAR، در AG News امتیازی حدود ۰.۹۲ گرفت که GPT-4o بدون هیچ آموزشی با آن برابری کرده یا از آن پیشی گرفت.
• تقویت مصنوعی داده‌ها به‌طور مستمر اما اندک کمک می‌کند. نمونه‌های مصنوعی تولید شده توسط LLM باعث بهبود خط لوله OpenAI + LUNAR در هر پنج مجموعه‌داده شد. تقویت از طریق توصیف دسته‌ها نیز اکثر خطوط پایه را بهبود بخشید، اگرچه دستاوردها نابرابر بود؛ برای مثال Llama 3.1 امتیاز AUROC را در IMDB Reviews تا ۰.۰۷+ افزایش داد، اما نتایج در جاهای دیگر کوچک‌تر بود.
• انتخاب مدل حلقه ضعیف زنجیره است. GPT-o1-preview مدل‌هایی را توصیه می‌کند که در اکثر مجموعه‌داده‌ها از میانگین عملکرد خط پایه فراتر می‌روند و گاهی به بهترین روش نزدیک می‌شوند (مثلاً در IMDB Reviews و SMS Spam). اما هرگز به‌طور قابل‌اطمینانی بهترین عملکرد را شناسایی نمی‌کند و نویسندگان اذعان دارند که توصیه‌ها بر اساس ورودی‌های ساده‌ای است که فاقد آمارهای اختصاصی مجموعه‌داده هستند.
• شکاف میان مدل‌های متن‌باز و تجاری واقعی است. برتری AUROC مدل GPT-4o نسبت به Llama 3.1 8B بسته به مجموعه‌داده بین ۴ تا ۱۳ واحد است؛ شکافی که با الگوی مشاهده شده در مقالات تشخیص ناهنجاری جدولی بدون آموزش همخوانی دارد.
• تشخیص ناهنجاری NLP هنوز فاقد یک بنچ‌مارک قطعی است. پنج مجموعه‌داده که همگی از بدنه طبقه‌بندی مشتق شده‌اند، کم است. مقاله همراه NLP-ADBench (EMNLP Findings 2025) این دامنه را به هشت مجموعه‌داده و ۱۹ الگوریتم گسترش می‌دهد، اما همچنان از همان ساختار «دسته معنایی به عنوان ناهنجاری» استفاده می‌کند که این وظایف را تا حدی مصنوعی جلوه می‌دهد.

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

یافته‌های مربوط به تشخیص بدون آموزش معتبر هستند. استفاده از LLMها به عنوان امتیازدهنده بدون تنظیم دقیق روی داده‌های ناهنجاری برچسب‌دار، زمانی که کلاس ناهنجاری از نظر معنایی منسجم باشد، واقعاً مفید است — یک پیام اسپم به روش‌هایی از یک پیام معمولی متمایز می‌شود که یک مدل زبانیِ خوب‌آموزش‌دیده آن را درک می‌کند. اعداد AUROC بالا هستند و مقایسه با خطوط پایه قویِ مبتنی بر جاسازی‌های OpenAI منصفانه است.

با این حال، دامنه تحقیق به شکلی محدود است که مقاله آن را کمتر از حد واقعی جلوه می‌دهد. در هر پنج مجموعه‌داده، ناهنجاری‌ها به عنوان یک دسته موضوعی متفاوت کدگذاری شده‌اند — اسپم در مقابل پیامک قانونی، اخبار یک ناشر خاص در مقابل خروجی‌های توزیع‌شده. این بدان معناست که LLM در اصل در حال انجام طبقه‌بندی موضوعی است؛ وظیفه‌ای که صراحتاً برای آن پیش‌آموزش دیده است. این بنچ‌مارک شامل ناهنجاری‌های معنایی در یک دسته واحد نمی‌شود (مثلاً تراکنش‌های غیرعادی در یک نوع حساب یکسان)، که دقیقاً همان نوع ناهنجاری است که برای حسابرسی مالی اهمیت دارد.

وظایف تقویت داده و انتخاب مدل نیز روی همان پنج مجموعه‌داده ارزیابی شده‌اند، بنابراین مقاله در نهایت بنچ‌مارک می‌کند که آیا LLMها می‌توانند برش‌های کمی متفاوت از همان مشکل محدود را به مقدار ناچیزی بهتر کنند یا خیر. نویسندگان آزادانه شش محدودیت را فهرست کرده‌اند — از جمله اینکه آن‌ها فقط زیرمجموعه‌ای از LLMها را آزمایش کرده‌اند، رژیم‌های آموزشی Few-shot و تنظیم دقیق را حذف کرده‌اند و برای انتخاب مدل به ورودی‌های ساده تکیه کرده‌اند — که از نظر علمی صادقانه است اما نشان می‌دهد این بنچ‌مارک چقدر مقدماتی است.

یک نتیجه که شکاکان باید به آن توجه کنند: امتیازهای AUPRC برای هر دو مدل به‌طور قابل‌توجهی پایین‌تر از AUROC است. مدل Llama 3.1 در BBC News به AUROC ۰.۸۶۱۲ می‌رسد اما AUPRC آن تنها ۰.۳۹۶۰ است که بازتاب‌دهنده عدم تعادل کلاس‌ها در ساختار تک‌کلاسه است. در بافت‌های حسابرسی با دقت بالا، AUPRC معیار معنادارتری است و در اینجا تصویر کمتر خوشایند است.

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

برنامه Bean Labs شامل دو مورد استفاده برای تشخیص ناهنجاری است: شناسایی اقلام غیرعادی دفتر کل در زمان واقعی (جدولی، ساختاریافته) و پرچم‌گذاری متن‌های روایی مشکوک در فاکتورها، یادداشت‌ها یا تیکت‌های پشتیبانی (NLP غیرساختاریافته). AD-LLM مستقیماً به مورد دوم می‌پردازد و سقف واقع‌بینانه‌ای به ما می‌دهد: GPT-4o می‌تواند ناهنجاری‌های سطح موضوعی را در متن با AUROC بالای ۰.۹۳ در مجموعه‌داده‌های تمیز و متعادل به‌صورت بدون آموزش تشخیص دهد. این یک دانش پیشین مفید است، اما ناهنجاری‌های شرح دفتر کل ظریف‌تر هستند — یادداشت فاکتوری که یک سرویس روتین را توصیف می‌کند اما متعلق به فروشنده‌ای است که برای الگوهای مشکوک پرچم‌گذاری شده، یک مسئله طبقه‌بندی موضوعی نیست. این بنچ‌مارک یک نقطه شروع فراهم می‌کند، نه یک پاسخ نهایی.

یافته‌های مربوط به انتخاب مدل نیز برای طراحی سیستم جالب است. این رویا که از یک LLM بپرسیم «از کدام تشخیص‌دهنده ناهنجاری برای این مجموعه‌داده استفاده کنم؟» و پاسخی قابل‌اعتماد بگیریم، هنوز محقق نشده است. این بدان معناست که انتخاب بین تنظیم دقیق به سبک AnoLLM، پرامپت‌نویسی علی به سبک CausalTAD، یا یک روش جاسازی کلاسیک، همچنان نیازمند قضاوت انسانی یا ارزیابی تجربی سیستماتیک است و نمی‌توان آن را به یک مشاور LLM واگذار کرد.

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

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — بنچ‌مارک مکمل از همان گروه، شامل هشت مجموعه‌داده و ۱۹ الگوریتم؛ بافت وسیع‌تری از خطوط پایه کلاسیک را ارائه می‌دهد که دامنه پنج مجموعه‌داده‌ای AD-LLM قادر به پوشش آن نیست.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — بررسی کامل چشم‌انداز رویکردهای تشخیص ناهنجاری مبتنی بر LLM در قالب‌های متنی، تصویری و جدولی؛ جایگاه AD-LLM را نسبت به کارهای قبلی مشخص می‌کند.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — همتای جدولی؛ مقایسه رویکرد مبتنی بر احتمال (Likelihood) آن با استراتژی بدون آموزشِ مبتنی بر پرامپت در AD-LLM، روشن می‌کند که کدام پارادایم برای اقلام دفتر کل Beancount مناسب‌تر است.

مقاله​

وانگ و همکاران CausalTAD را پیشنهاد می‌کنند، روشی که بر روی تشخیص‌دهنده‌های ناهنجاری LLM به سبک AnoLLM قرار می‌گیرد و یک تغییر هدفمند ایجاد می‌کند: به جای سریال‌سازی ردیف‌های جدولی با ترتیب ستونی تصادفی یا دلخواه، وابستگی‌های علّی بین ستون‌ها را کشف کرده و قبل از اینکه LLM ردیف را بخواند، آن‌ها را برای رعایت آن وابستگی‌ها بازآرایی می‌کند.

این مقاله دارای دو بخش متحرک است. اول، یک ماژول ترتیب‌بندی ستون مبتنی بر علّیت. نویسندگان چارچوب استخراج عامل COAT را تطبیق می‌دهند: یک LLM متادیتای ستون‌ها و نمونه‌ها را می‌خواند تا عامل‌های معنایی سطح بالا را استخراج کند (برای تراکنش‌های کارت اعتباری، عاملی مانند "جبران خدمات" ممکن است ستون‌های مبلغ و پذیرنده را در بر بگیرد). از این عوامل، سه الگوریتم کشف علّی — PC، LiNGAM و FCI — هر کدام یک گراف علّی جهت‌دار روی عوامل می‌سازند. سپس مسئله بازآرایی ستون‌ها به یک "مسئله ترتیب‌بندی خطی" (Linear Ordering Problem) تبدیل می‌شود: یافتن جایگشت π که مجموع وزن‌های لبه‌های جهت‌دار را به حداکثر برساند، به طوری که ستون‌های "علت" قبل از ستون‌های "معلول" در متن سریال‌سازی شده ظاهر شوند. از آنجایی که LP دارای بسیاری از راه حل‌های نزدیک به بهینه است، آن‌ها K ≈ ۱۰ ترتیب را در محدوده ۹۰٪ بهینه نمونه‌برداری کرده و میانگین آن‌ها را محاسبه می‌کنند.

دوم، یک ماژول وزن‌دهی مجدد آگاه از علّیت. همه ستون‌ها به یک اندازه مرتبط نیستند. ستونی که بر بسیاری از عوامل تأثیر می‌گذارد، وزن بالاتری دریافت می‌کند: αj = |M⁻¹(cj)|، یعنی تعداد عواملی که در آن‌ها مشارکت دارد. امتیاز نهایی ناهنجاری، میانگین وزنی احتمالات لگاریتمی منفی به ازای هر ستون در K ترتیب است.

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

• ترتیب ستون‌ها یک تورش استقرایی (inductive bias) غیرقابل چشم‌پوشی برای LLMهای خودرگرسیونی است: قرار دادن ستون "علت" قبل از ستون "معلول" به مدل اجازه می‌دهد هنگام تخصیص احتمال به معلول، روی زمینه (context) صحیح شرط‌بندی کند.
• کشف علّی در سطح عامل (به جای سطح ستون خام) به متد اجازه می‌دهد تا جداول با انواع مختلط را مدیریت کند، جایی که کشف علّی مستقیم بین ستون‌های ناهمگون نویز زیادی دارد.
• در ۶ مجموعه داده معیار با نوع مختلط، CausalTAD با SmolLM-135M به میانگین AUC-ROC ۰.۸۳۴ در مقابل ۰.۸۰۳ در AnoLLM می‌رسد — یک بهبود مطلق ۳.۱ واحدی با همان مدل پایه.
• به طور خاص در مجموعه داده Fake Job Posts، امتیاز CausalTAD برابر ۰.۸۷۳ در مقابل ۰.۸۰۰ در AnoLLM است — یک افزایش نسبی ۹.۱ درصدی که به اندازه کافی بزرگ است تا در یک سیستم غربالگری واقعی اهمیت داشته باشد.
• در ۳۰ مجموعه داده معیار عددی ODDS، مدل CausalTAD به بهترین میانگین AUC-ROC دست می‌یابد و به طور مداوم از خط‌های پایه کلاسیک (Isolation Forest، ECOD، KNN) و روش‌های عمیق (DeepSVDD، SLAD) پیشی می‌گیرد.
• هر سه الگوریتم کشف علّی در مطالعه حذفی (ablation) بر ترتیب‌بندی تصادفی غلبه کردند؛ LiNGAM در مجموعه‌های داده مختلط کمی بهتر از PC و FCI عمل کرد.

چه چیزی منطقی است — و چه چیزی نیست​

ادعای اصلی — که ترتیب علّی ستون‌ها کمک می‌کند — به خوبی پشتیبانی می‌شود. مطالعه حذفی شفاف است: جایگزینی ترتیب تصادفی با هر یک از سه روش کشف علّی، نتایج را در معیار Fake Job Posts بهبود می‌بخشد (از ۰.۸۳۲ به ۰.۸۷۰–۰.۸۷۳)، و وزن‌دهی مجدد بر اساس تعداد عوامل در هر پیکربندی کمک بیشتری می‌کند. این یک روایت معتبر است.

چیزی که من کمتر متقاعدکننده می‌دانم، فرض بوت‌استرپینگ است. گراف علّی با استفاده از یک LLM برای استخراج عوامل معنایی از همان داده‌هایی ساخته می‌شود که سیستم قرار است تحلیل کند. اگر LLM دامنه را اشتباه درک کند — مثلاً برای یک سیستم حسابداری سفارشی با نام ستون‌های غیر استاندارد — استخراج عامل اشتباه خواهد بود، و یک گراف علّی بد مسلماً بدتر از ترتیب‌بندی تصادفی است زیرا یک تورش سیستماتیک ایجاد می‌کند. نویسندگان به این ریسک اعتراف می‌کنند ("به توانایی LLMها برای استخراج عوامل بستگی دارد") اما دقت استخراج عامل را به طور مستقل ارزیابی نمی‌کنند.

همچنین یک مسئله سربار محاسباتی وجود دارد که جدی‌تر از آن چیزی است که مقاله نشان می‌دهد. اجرای سه الگوریتم کشف علّی، حل یک LP، نمونه‌برداری از K ترتیب و سپس اجرای استنتاج روی K نسخه سریال‌سازی شده از هر نقطه تست، هزینه استنتاج را در K ضرب می‌کند. برای یک دفتر کل با میلیون‌ها ورودی، این موضوع اهمیت دارد. مقاله خاطرنشان می‌کند که "کارهای آینده ممکن است بر بهبود کارایی متمرکز شوند" اما هیچ پروفایل‌بندی بتنی ارائه نمی‌دهد.

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

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

تراکنش‌های Beancount دارای ساختار علّی واقعی هستند: مبلغ ثبت (posting amount) به طور علّی باعث انتخاب حساب می‌شود، حساب باعث انتظار طرف مقابل می‌شود و متن یادداشت (memo) از نظر علّی پایین‌دست هر سه قرار دارد. سریال‌سازی تصادفی ستون‌ها این را نادیده می‌گیرد، به این معنی که مدلی به سبک AnoLLM عبارت "یادداشت: خواربار | حساب: هزینه‌ها:غذا | مبلغ: ۴۲۰۰ دلار" را به همان راحتی نسخه با ترتیب صحیح می‌بیند.

CausalTAD راهی اصولی برای رمزگذاری "مبلغ و حساب اول می‌آیند" بدون کدنویسی سخت آن به عنوان یک قاعده ارائه می‌دهد. برای عوامل حسابرسی Bean Labs، این یک انتخاب معماری عملی را پیشنهاد می‌کند: قبل از امتیازدهی به دسته‌ای از تراکنش‌ها برای ناهنجاری، یک بار گراف علّی را روی شمای ستون‌های دفتر کل کشف کنید، سپس از آن ترتیب ثابت برای تمام استنتاج‌های بعدی استفاده کنید. سربار فقط یک بار در سطح شما پرداخت می‌شود، نه به ازای هر تراکنش.

مثال تشخیص تقلب کارت اعتباری در مقاله اساساً دارای همان ساختار وظیفه تشخیص ناهنجاری دفتر کل است: ویژگی‌های ناهمگون، برچسب‌های کمیاب و یک ترتیب علّی که متخصصان دامنه به طور شهودی می‌دانند اما LLMها در غیر این صورت آن را نادیده می‌گیرند.

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

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — معیار سیستماتیک در سه پارادایم تشخیص ناهنجاری LLM که CausalTAD در آن جای می‌گیرد؛ خواندن آن به جای مقایسه تک‌بعدی AnoLLM و CausalTAD، چشم‌انداز کاملی را ارائه می‌دهد.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — چارچوب استخراج عاملی که CausalTAD از آن اقتباس کرده است؛ درک نحوه عملکرد آن روشن می‌کند که کیفیت گراف علّی کجا می‌تواند با شکست مواجه شود.
• Causal discovery in heterogeneous data: a survey — برای درک مزایای نسبی PC در مقابل LiNGAM در مقابل FCI روی داده‌های جدولی نوع مختلط، زیرا مقاله با هر سه به عنوان موارد قابل تعویض برخورد می‌کند اما آن‌ها فرض‌های استقلال متفاوتی دارند.

مقاله​

AnoLLM شناسایی ناهنجاری‌های جدولی را به جای یک مسئله طبقه‌بندی مبتنی بر پرامپت، به عنوان تخمین چگالی مدل زبانی بازتعریف می‌کند. به جای اینکه از LLM خواسته شود نام ردیف‌های مشکوک را بگوید، نویسندگان یک مدل زبانی پیش‌آموزش‌دیده را روی ردیف‌های آموزشی سریالی‌سازی شده‌ی درون-توزیعی (نرمال) تنظیم دقیق (fine-tune) می‌کنند، سپس به هر ردیف آزمایشی بر اساس لگاریتم احتمال منفی (Negative Log-Likelihood یا NLL) تحت آن توزیع آموخته شده، امتیاز می‌دهند. ردیفی که اصلاً شبیه توزیع آموزشی نباشد، NLL بالایی دریافت می‌کند — که همان امتیاز ناهنجاری است. دیگر خبری از فرمت شاخص، پارس کردن خروجی یا استخراج شکننده‌ی Regex نیست.

سریالی‌سازی، هر ردیف جدول را به یک رشته زبان طبیعی شامل نام ویژگی‌ها و مقادیر آن‌ها تبدیل می‌کند. برای ستون‌های با مقدار متنی، NLL به ازای هر ستون نرمال‌سازی می‌شود تا از سوگیری طول جلوگیری شود، چرا که در غیر این صورت توضیحات طولانی‌تر به طور مکانیکی هزینه‌های احتمال بالاتری را انباشته می‌کردند. برای ستون‌های عددی و طبقه‌بندی‌شده، NLL خام در سطح توکن در کل فیلد جمع زده می‌شود. مدل در یک محیط نیمه‌نظارتی — که فقط ردیف‌های با برچسب نرمال وارد آموزش می‌شوند — تا ۲۰۰۰ مرحله با استفاده از آموزش توزیع‌شده روی GPU تنظیم دقیق می‌شود.

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

• مشکل قالب خروجی: رویکردهای قبلی پیش‌بینی شاخص، از LLM می‌خواستند که شاخص‌های ردیف‌های ناهنجار را از یک دسته (batch) به طور قابل اعتماد خروجی دهد. مدل‌های خانواده Llama مکرراً شاخص‌های اشتباه را با مقادیر جفت می‌کنند، شاخص‌هایی فراتر از اندازه دسته تولید می‌کنند یا صرفاً همه چیز را به عنوان ناهنجار لیست می‌کنند. NLL این مشکل را کاملاً دور می‌زند.
• AnoLLM بهترین عملکرد را در شش مجموعه‌داده بنچمارک با انواع ویژگی‌های ترکیبی، از جمله شناسایی تقلب در بیمه خودرو و مجموعه‌داده‌های تقلب تجارت الکترونیک از Kaggle به دست می‌آورد.
• در ۳۰ مجموعه‌داده بنچمارک ODDS که عمدتاً عددی هستند، AnoLLM هم‌تراز با بهترین روش‌های کلاسیک عمل می‌کند — نه لزوماً بهتر، بلکه صرفاً رقابتی.
• نرمال‌سازی NLL به ازای هر ستون برای ویژگی‌های متنی، یک تصمیم مهندسی کوچک اما حیاتی است: بدون آن، توضیحات یک تراکنش با سی توکن، امتیاز را نسبت به یک مبلغ دو رقمی تحت‌الشعاع قرار می‌دهد که یک سوگیری استقرایی اشتباه است.
• زمینه مبنای آموزش: رویکرد صفر-شات GPT-4 (arXiv:2406.16308) به متوسط AUROC معادل ۷۴.۱ در ODDS دست می‌یابد که با ECOD (۷۵.۵) و KNN (۷۰.۷) قابل مقایسه است. مزیت AnoLLM به طور خاص در مجموعه‌داده‌هایی ظاهر می‌شود که ویژگی‌های متنی و طبقه‌بندی‌شده حامل سیگنال‌های ناهنجاری معناداری هستند.

چه چیزی منطقی است — و چه چیزی نیست​

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

آنچه مرا نگران می‌کند، شکاف هزینه-فایده است که مقاله کمتر به آن پرداخته است. AnoLLM به تنظیم دقیق و سرویس‌دهی یک LLM برای استنتاج نیاز دارد — یک تعهد زیرساختی قابل توجه در مقایسه با اجرای ECOD یا IsolationForest روی یک CPU در عرض چند ثانیه. در بنچمارک ODDS (صرفاً عددی)، AnoLLM فقط "هم‌تراز" است و نه بهتر. بنابراین توجیه استفاده از AnoLLM کاملاً در رژیم داده‌های ترکیبی است، جایی که شش مجموعه‌داده ارزیابی شده از شناسایی تقلب در Kaggle هستند. شش مجموعه‌داده، پایه تجربی ضعیفی برای یک توصیه قوی است، به ویژه از آنجا که مجموعه‌داده‌های بنچمارک Kaggle تمایل دارند طرح‌واره‌های تمیز، معنای ستون ثابت و حقایق زمینی مشخص داشته باشند — تمام چیزهایی که داده‌های دفترکل واقعی اغلب فاقد آن هستند.

مشکل ترتیب ستون‌ها نیز باز باقی مانده است. CausalTAD (arXiv:2602.07798) بلافاصله این شکاف را شناسایی کرد: AnoLLM ستون‌ها را با ترتیب دلخواه سریالی‌سازی می‌کند و روابط علی بین فیلدها را نادیده می‌گیرد. برای داده‌های ساختاریافته با زنجیره‌های علی شناخته شده — مثلاً نوع حساب بر محدوده‌های مجاز تراکنش تأثیر می‌گذارد، که خود بر طرف حساب مورد انتظار تأثیر می‌گذارد — این یک محدودیت واقعی است. CausalTAD مرتب‌سازی مجدد را به عنوان یک مسئله ترتیب‌بندی خطی مطرح می‌کند و بهبود مستمری را نسبت به AnoLLM در بیش از ۳۰ مجموعه‌داده گزارش می‌دهد. اینکه این شکاف وجود داشت و به این سرعت پیدا شد، نشان می‌دهد که طراحی سریالی‌سازی AnoLLM کاملاً سنجیده نبوده است.

همچنین یک سوال مقیاس وجود دارد که مقاله به آن پاسخ نمی‌دهد: در چه حجمی از نمونه‌های آموزشی نرمال، تنظیم دقیق یک LLM نسبت به، مثلاً، یک مدل یادگیری عمیق جدولی که مستقیماً روی ویژگی‌های عددی آموزش دیده، ارزشش را پیدا می‌کند؟ برای دفترکل‌های شخصی Beancount با چند هزار ورودی، هزینه محاسباتی ممکن است به راحتی هرگونه افزایش دقت را بی‌اثر کند.

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

ورودی‌های دفترکل Beancount دقیقاً همان نوع داده‌های با نوع ترکیبی هستند که AnoLLM هدف قرار می‌دهد: مبالغ (عددی)، نام حساب‌ها (متن ساختاریافته)، ذینفع/توضیحات (متن آزاد)، برچسب‌ها (طبقه‌بندی‌شده) و تاریخ‌ها (ساختاریافته). یک ردیف واحد مانند 2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400 اطلاعات را در تمام این انواع به طور همزمان کدگذاری می‌کند. تشخیص‌دهنده‌های ناهنجاری کلاسیک در اینجا دچار مشکل می‌شوند زیرا به مدیریت جداگانه برای هر نوع ستون نیاز دارند و همبستگی بین آن‌ها را از دست می‌دهند — الگوی مشترکی که می‌گوید فاکتورهای "AWS" باید در محدوده خاصی باشند و به حساب مشخصی برخورد کنند.

رویکرد NLL در AnoLLM، در اصل، این الگوهای مشترک را از ورودی‌های تاریخی نرمال یاد می‌گیرد و انحرافات را در هر ترکیبی از ستون‌ها علامت‌گذاری می‌کند. این پتانسیل وجود دارد که این روش از JETهای مبتنی بر قانون یا آزمون‌های آماری تک‌ستونی مفیدتر باشد.

با این حال، محدودیت حسابداری دوطرفه یک دانش ساختاری است که AnoLLM نمی‌تواند صرفاً از ردیف‌های سریالی‌سازی شده یاد بگیرد — بدهکار باید با بستانکار برابر باشد، سلسله مراتب حساب‌ها باید رعایت شود. این تغییرناپذیرهای دامنه، محدودیت‌های سخت هستند، نه نظم‌های آماری، و هیچ مقداری از تنظیم دقیق LLM روی ردیف‌های تاریخی، اگر داده‌های آموزشی حاوی استثنائات یا خطاهای گرد کردن باشند، نمی‌تواند آن‌ها را به طور قابل اعتماد اعمال کند. معماری درست احتمالاً امتیازدهی NLL مدل AnoLLM را برای ناهنجاری‌های معنایی با بررسی‌های صریح قوانین برای ناهنجاری‌های ساختاری ترکیب می‌کند.

چه چیزی را در ادامه بخوانیم​

• CausalTAD (arXiv:2602.07798) — مستقیماً AnoLLM را با تزریق ترتیب علی ستون‌ها بهبود می‌بخشد؛ فوری‌ترین پیگیری برای ارزیابی.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — ارزیابی سیستماتیک چندپارادایمی را ارائه می‌دهد که در مقالات روش‌های فردی جای آن خالی است.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — مدل BE-GREAT که AnoLLM از آن به عنوان مبنا استفاده می‌کند؛ درک آن روشن می‌کند که AnoLLM در واقع فراتر از پیش‌بینی شاخص چه چیزی را بهبود بخشیده است.

مقاله​

فیگوئرا، گروندمن، فریدانک، لوزر و نجدل، پنج مدل وزن-باز با حدود ۷ میلیارد پارامتر را در یک بنچمارک دو مرحله‌ای به نام LLMFinLiteracy ارزیابی می‌کنند. وظیفه ۱ از مدل‌ها می‌خواهد سناریوهای متنی ایجاد کنند که بر یک نسبت نقدینگی خاص (نسبت جاری، آنی یا نقدی) تأثیر بگذارد، با استفاده از ترازنامه واقعی فصلی یکی از پنج شرکت لیست شده در شاخص DAX (ایرباس، بایر، دویچه تلکام، مرسدس بنز، اس‌اپ). وظیفه ۲ از مدل‌ها می‌خواهد آن سناریوها را به تراکنش‌های قابل کامپایل Beancount ترجمه کنند. کامپایلر Beancount به عنوان بررسی‌کننده نهایی صحت نحو (syntax) عمل می‌کند و متخصصان انسانی صحت معنایی را ارزیابی می‌کنند. مقاله یک طبقه‌بندی خطای ۱۲گانه در دو وظیفه معرفی می‌کند و از یک پرامپت ۹ مرحله‌ای زنجیره افکار استفاده می‌کند که شامل قوانین حسابداری دوطرفه، یک مثال ورودی/خروجی و ترازنامه واقعی شرکت در قالب Beancount است. مدل‌های مورد ارزیابی — Llama-3-8B، Qwen-2-7B، Mistral-7B، CodeLlama-7B و CodeQwen-1.5-7B — همگی به دلیل حساسیت داده‌های مالی، به صورت محلی (on-premise) اجرا شدند. پیکره متنی شامل ۱۵۰۰ نمونه تولید شده است که ۳۰۰ ورودی طبقه‌بندی شده توسط متخصصان انسانی ارزیابی شده‌اند.

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

• تنها ۷ مورد از ۳۰۰ جفت سناریو-تراکنش ارزیابی شده (۲.۳٪) به طور کامل و سرتاسری درست بودند؛ حتی با محدود کردن ارزیابی به سه مدل چندمنظوره، این نرخ تنها به ۳.۸٪ می‌رسد.
• دو مدل برتر، Qwen-2-7B و Mistral-7B، تنها در ۲۱.۶۷٪ و ۲۰.۰۰٪ مواقع سناریوهای درست و در ۱۶.۶۷٪ و ۱۰.۰۰٪ مواقع تراکنش‌های قابل کامپایل صحیح تولید می‌کنند.
• مدل‌های تخصصی کدنویسی (CodeLlama, CodeQwen) در هر دو وظیفه امتیاز ۰٪ کسب کردند؛ آن‌ها به قالب پرامپت با رشته متنی "Processed — Waiting for next input" پاسخ دادند و وظیفه را کاملاً نادیده گرفتند.
• نحو (Syntax) گلوگاه نیست: هیچ مدلی حتی یک خطای نحوی تولید نکرد. شکست‌ها کاملاً در استدلال حسابداری نهفته است — خطاهای تراز (balance errors) در Qwen-2 (۶۱.۶۷٪) و Llama-3 (۳۸.۳۳٪) غالب هستند، در حالی که Mistral بیشتر به حساب‌هایی ارجاع می‌دهد که در ترازنامه ارائه شده وجود ندارند (۴۵٪ خطای حساب ناشناخته).
• بخش قابل توجهی از تراکنش‌هایی که با موفقیت کامپایل می‌شوند، از نظر معنایی اشتباه هستند — ترفند مورد علاقه مدل‌ها این است که کاهش یک بدهی را «فروش بدهی خود» بنامند، که وجه نقد را افزایش می‌دهد اما به دلیلی اشتباه.
• استفاده از GPT-4o به عنوان داور خودکار در شناسایی تناقضات در تمامی ۱۰ سناریوی بی‌معنی که به آن نشان داده شد شکست خورد، که تایید می‌کند خودارزیابی LLM فیلتر کیفی قابل اعتمادی برای خروجی‌های حسابداری نیست.
• مدل‌ها عمدتاً از مثال ورودی/خروجی موجود در پرامپت کپی می‌کنند تا اینکه بخواهند تعمیم دهند: ۷ جفت صحیح شباهت زیادی به ساختار تراکنش مثال ارائه شده دارند.

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

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

با این حال، محدودیت‌های آشکاری وجود دارد که نویسندگان عمدتاً به آن‌ها اذعان دارند. پنج مدل وزن-باز ۷ میلیاردی متعلق به سال‌های ۲۰۲۳-۲۰۲۴، بخش کوچکی از چشم‌انداز توانمندی‌ها هستند؛ GPT-4o و Claude به دلایل حریم خصوصی کنار گذاشته شدند، که قابل درک است اما به این معنی است که عدد شاخص (۲.۳٪ صحیح) توانمندی‌های لبه تکنولوژی را دست‌کم می‌گیرد. فرمول‌های نسبت‌های مالی به عمد از پرامپت‌ها حذف شدند تا دانش دامنه ذاتی تست شود — انتخابی متدولوژیک و جالب، اما انتخابی که نتایج را با هر سیستمی که به طور منطقی مستندات فرمول‌ها را شامل می‌شود، غیرقابل مقایسه می‌کند. همچنین ۳۰۰ نمونه ارزیابی شده توسط انسان در پنج مدل، سه نسبت و پنج شرکت، حجم اندکی است؛ خانه‌های جدول برای هر مدل-نسبت بیش از حد کوچک هستند (۱۲ نمونه) تا بتوان نتایج قاطعی درباره واریانس گرفت.

جالب‌ترین شکاف روش‌شناختی، نبود هیچ‌گونه پروتکل تکرارشونده یا مبتنی بر بازخورد است. نه فراخوانی ابزار (tool-calling)، نه خوداصلاحی، و نه حلقه بازخورد کامپایلر — فقط تولید یک‌باره (one-shot). با توجه به اینکه CRITIC (LOG-012) و کارهای مشابه نشان می‌دهند که اصلاح تعاملی با ابزار به طور قابل توجهی دقت را در کارهایی با خروجی‌های قابل تایید بهبود می‌بخشد، یک آزمایش «کامپایلر-در-حلقه» Beancount می‌توانست درباره قابلیت استقرار سیستم اطلاعات بسیار بیشتری بدهد.

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

هر تصمیم طراحی برای عامل نوشتاری Bean Labs بر این فرض استوار است که LLMها با DSL بین‌کنت چه کار می‌توانند بکنند. این مقاله اولین تکیه‌گاه تجربی است. یافته‌های اصلی دلسردکننده اما به شکلی مفید قابل تفسیر هستند.

اول، حالت‌های شکست خاص هستند، نه تصادفی. خطاهای تراز و حساب‌های ناشناخته دو مشکل اصلی هستند و هر دو با یک حلقه بازخورد کامپایلر قابل حل می‌باشند: کامپایلر Beancount دقیقاً به شما می‌گوید کدام حساب ناشناخته است و آیا تراکنش تراز هست یا خیر. معماری عاملی که بر روی خروجی کامپایلر تکرار می‌کند — به جای اینکه یک بار تولید کند و متوقف شود — باید عملکردی بسیار بهتر از نتایج یک‌باره در اینجا داشته باشد. دوم، نحو (Syntax) «رایگان» است. مدل‌ها به وضوح گرامر ظاهری Beancount را یاد گرفته‌اند؛ آن‌ها فقط نمی‌توانند به طور قابل اعتماد قصد مالی را به جابجایی‌های صحیح حساب ترجمه کنند. این تمایز برای اینکه بدانیم کجا باید در پرامپت‌نویسی و ریزتنظیم (fine-tuning) سرمایه‌گذاری کنیم، اهمیت دارد. سوم، این یافته که GPT-4o نمی‌تواند کیفیت حسابداری را به طور خودکار ارزیابی کند، سطح انتظار را برای هر سیستم تایید خودکار بالا می‌برد: شما به کامپایلر، به علاوه بررسی‌های موردی توسط متخصصان دامنه نیاز دارید، نه یک منتقد LLM.

این مقاله همچنین چیزی را تایید می‌کند که من از کار روی تشخیص ناهنجاری (LOG-049) به آن مشکوک بودم: LLMهایی که روی تراکنش‌های مالی کار می‌کنند، بیش از حد به راحتی تراکنش را کامپایل و ارسال می‌کنند. دسته «اشتباه | قابل کامپایل» — تراکنش‌هایی که بررسی نحو را می‌گذرانند اما از نظر معنایی غلط هستند — دقیقاً همان حالت شکستی است که یک محافظ ایمنی نوشتاری باید آن را شناسایی کند. یک تراکنش می‌تواند کاملاً تراز باشد و همچنان درآمد را به عنوان کاهش بدهی ثبت کند، که توسط هیچ بررسی صرفاً نحوی قابل شناسایی نیست.

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

• AnoLLM: مدل‌های زبانی بزرگ برای تشخیص ناهنجاری‌های جدولی (OpenReview:7VkHffT5X2, ICLR 2025) — امتیازدهی ناهنجاری بر اساس احتمال به عنوان جایگزینی برای رویکرد تشخیص دسته‌ای؛ به طور طبیعی با سیگنال کامپایلر Beancount ترکیب می‌شود تا ورودی‌های ساختاری معتبر اما از نظر آماری ناهنجار را علامت‌گذاری کند.
• ReDAct: تعویق آگاه از عدم قطعیت برای عامل‌های LLM (arXiv:2604.07036) — تصمیمات با اطمینان پایین را به یک مدل بزرگتر یا انسان ارجاع می‌دهد؛ مستقیماً به این سوال پاسخ می‌دهد که یک عامل نوشتاری Beancount چه زمانی باید به جای ادامه دادن پس از حلقه بازخورد کامپایلر، کار را به بازبینی انسانی واگذار کند.
• CRITIC: مدل‌های زبانی بزرگ می‌توانند با نقد تعاملی ابزار خود را اصلاح کنند (arXiv:2305.11738, ICLR 2024) — مرتبط‌ترین کار موجود برای ساخت یک عامل اصلاح‌گر کامپایلر-در-حلقه بر روی معماری‌ای که این مقاله ارزیابی می‌کند.