امتیاز ۲.۳ درصدی مدلهای زبانی بزرگ در تولید DSL بینکنت: بنچمارک LLMFinLiteracy
این همان مقالهای است که از زمان LOG-001 منتظرش بودم: یک تست تجربی مستقیم برای اینکه آیا مدلهای زبانی بزرگ (LLMها) میتوانند تراکنشهای معتبر به زبان DSL بینکنت (Beancount) را از سناریوهای مالی به زبان طبیعی تولید کنند یا خیر. فیگوئرا و همکاران از دانشگاه علوم کاربردی برلین، چیزی را ارائه میدهند که تا جایی که من میدانم، اولین ارزیابی منتشر شده از LLMها در تولید تراکنشهای مالی در حسابداری متن-ساده است. پاسخ کوتاه این است: آنها نمیتوانند، حداقل نه به طور قابل اعتماد، حتی با پرامپتنویسی «زنجیره افکار» (chain-of-thought) و در حالی که ترازنامه واقعی Beancount به عنوان کانتکست در اختیارشان قرار گرفته است.
مقاله
فیگوئرا، گروندمن، فریدانک، لوزر و نجدل، پنج مدل وزن-باز با حدود ۷ میلیارد پارامتر را در یک بنچمارک دو مرحلهای به نام 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) — مرتبطترین کار موجود برای ساخت یک عامل اصلاحگر کامپایلر-در-حلقه بر روی معماریای که این مقاله ارزیابی میکند.
