آیا مدل‌های زبانی بزرگ می‌توانند داده‌های جدولی را تحلیل کنند؟ چهار بنچمارک درباره هوش مصنوعی مالی چه می‌گویند

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

مقاله

فانگ و همکاران مقاله "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" را در TMLR 2024 (arXiv:2402.17944) منتشر کردند. این یک طبقه‌بندی ۴۱ صفحه‌ای است که سه حوزه را پوشش می‌دهد: پیش‌بینی خروجی‌های ساختاریافته از ویژگی‌های جدولی، تولید داده‌های جدولی مصنوعی و درک جداول به اندازه‌ای که بتوان به سوالات مربوط به آن‌ها پاسخ داد. بخش درک — پاسخ‌دهی به سوالات جدولی (TableQA)، تأیید فکت‌ها و استدلال ساختاری — جایی است که مرتبط‌ترین کارها برای هوش مصنوعی مالی در آن قرار دارد.

مقاله دیگری که در کنار آن خواندم، "Table Meets LLM: Can Large Language Models Understand Structured Table Data؟" نوشته سوئی و همکاران (WSDM 2024, arXiv:2305.13062)، رویکرد کنترل‌شده‌تری دارد: آن‌ها یک بنچمارک قابلیت درک ساختاری (SUC) با هفت وظیفه محدود تعریف کردند — بخش‌بندی جدول، تشخیص اندازه، تشخیص سلول‌های ادغام‌شده، جستجوی سلول، جستجوی معکوس، بازیابی ستون و بازیابی سطر — و GPT-3.5 و GPT-4 را مستقیماً آزمایش کردند. بدون زنجیره استدلال، بدون ترفندهای بازیابی. فقط: آیا مدل می‌تواند کاری را که می‌خواهیم انجام دهد؟

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

• شکاف فرمت واقعی و به طرز شگفت‌آوری بزرگ است. در بنچمارک SUC، سریال‌سازی HTML در مجموع حدود ۶.۷۶٪ بهتر از فرمت زبان طبیعی همراه با جداکننده (NL+Sep) عمل می‌کند. رتبه‌بندی — HTML > XML > JSON > Markdown > NL+Sep — در تمام وظایف ثابت است. فایل‌های Beancount به انتهای زبان طبیعی این طیف نزدیک‌تر هستند که یک زنگ خطر محسوب می‌شود.
• جستجوی سلول به طرز عجیبی دشوار است. GPT-3.5 تنها به دقت ۴۴٪ در جستجوی مستقیم سلول (یافتن مقدار در سطر X، ستون Y) دست می‌یابد. GPT-4 در همین وظیفه به ۷۳.۳۴٪ می‌رسد. برای یک عملیات قطعی که فرمول اکسل در میکروثانیه انجام می‌دهد، شکاف ۲۶ واحد درصدی بین مدل‌ها نگران‌کننده است.
• مثال‌های چند-نمونه‌ای (Few-shot) نقش ستون‌های نگهدارنده را دارند. حذف مثال‌های ۱-نمونه‌ای از پرامپت‌های SUC باعث کاهش ۳۰.۳۸ درصدی در دقت کلی تمام وظایف شد. درک ساختاری مدل به شدت توسط نمایش مثال‌ها پشتیبانی می‌شود، نه اینکه واقعاً نهادینه شده باشد.
• شکاف انسان و LLM در پاسخ‌دهی به سوالات جداول واقعی بسیار زیاد است. TableBench (arXiv:2408.09174, AAAI 2025) ۸۸۶ سوال را در حوزه‌های بررسی فکت، استدلال عددی، تحلیل داده و مصورسازی ارزیابی می‌کند. دقت انسان ۸۵.۹۱٪ است. GPT-4-Turbo امتیاز ۴۰.۳۸٪ و GPT-4o امتیاز ۴۲.۷۳٪ را کسب کردند. بهترین مدل‌های فعلی تقریباً در نیمی از سطح انسان در بنچمارکی عمل می‌کنند که برای بازتاب پیچیدگی جداول دنیای واقعی طراحی شده است.
• سقوط پیچیدگی در صفحات گسترده مالی شدید است. FinSheet-Bench (arXiv:2603.07316) مدل‌های LLM را روی قالب‌های صندوق‌های سهام خصوصی با پیچیدگی ساختاری متفاوت آزمایش می‌کند. جستجوهای ساده به دقت ۸۹.۱٪ می‌رسند. تجمیع‌های پیچیده به ۱۹.۶٪ سقوط می‌کنند. بزرگترین فایل تست (۱۵۲ شرکت، ۸ صندوق) میانگین دقت ۴۸.۶٪ را در تمام مدل‌ها نشان می‌دهد، که نسبت به ۸۶.۲٪ در ساده‌ترین فایل کاهش یافته است.
• جداول طولانی مدل‌ها را به طور کلی از کار می‌اندازند. نظرسنجی TMLR گزارش می‌دهد که فراتر از ۱۰۰۰ توکن، عملکرد GPT-3 به نزدیکی تصادفی سقوط می‌کند. حتی مدل‌هایی با پنجره بافت ۲۰۰ هزار تایی نیز به دلیل هزینه مرتبه دوم (quadratic) خود-توجهی روی توالی‌های طولانی، با مجموعه‌داده‌های حجیم دست و پنجه نرم می‌کنند.

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

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

آنچه به آن مشکوک هستم: تکنیک خود-افزایی (پرامپتینگ دو مرحله‌ای که در آن پرامپت اول از مدل می‌خواهد مقادیر بحرانی را قبل از پاسخ دادن شناسایی کند) بهبودهایی بین ۰.۸۴ تا ۵.۶۸ درصد در بنچمارک‌هایی مانند TabFact و ToTTo ایجاد می‌کند. این‌ها اعداد واقعی از آزمایش‌های واقعی هستند، اما حاشیه‌ای‌اند. این تکنیک مشکل اساسی را حل نمی‌کند — بلکه یک وصله مهندسی پرامپت روی درک ساختاری واقعاً ضعیف است.

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

یافته FinSheet-Bench مبنی بر اینکه تجمیع‌های پیچیده امتیاز ۱۹.۶٪ می‌گیرند، جدی‌ترین زنگ خطر مالی در اینجا است. تجمیع پورتفوی، گزارش‌های سطح صندوق و مقایسه‌های چند دوره‌ای دقیقاً همان عملیاتی هستند که گزارشگری مالی را غیربدیهی می‌کنند — و دقیقاً همان‌جایی هستند که LLMها از هم می‌پاشند.

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

دفترهای کل Beancount جدول هستند. وقتی یک عامل خودکار یک دفتر کل را برای شناسایی ناهنجاری‌ها، تولید گزارش‌ها یا تصمیم‌گیری برای ثبت سند می‌خواند، در حال انجام استدلال جدولی است. شواهد نشان می‌دهد که مدل‌های فعلی جستجوهای ساده را نسبتاً خوب انجام می‌دهند (بازیابی سلول در ۷۳٪ برای GPT-4) اما در عملیاتی که بیشترین اهمیت را دارند دچار فروپاشی می‌شوند: تجمیع‌های چند مرحله‌ای، تخمین اندازه برای دفترهای کل بزرگ و استدلال روی تغییرات ساختاری.

یافته مربوط به سریال‌سازی پیامدهای عملی فوری دارد. اگر من فایل‌های Beancount را به یک LLM تزریق می‌کنم، فرمتی که انتخاب می‌کنم قبل از نوشتن حتی یک خط منطق عامل، چندین درصد روی دقت تأثیر می‌گذارد. نحو بومی Beancount به انتهای "NL+Sep" سلسله‌مراتب فرمت نزدیک است — برای انسان‌ها خوانا، برای LLMها نامطلوب. تبدیل به یک واسطه ساختاریافته‌تر (مانند یک جدول JSON یا HTML از تراکنش‌ها) قبل از تغذیه به مدل ممکن است ارزش هزینه پیش‌پردازش را داشته باشد.

سقوط پیچیدگی در مقیاس بزرگ، هوشیارکننده‌ترین یافته است. یک دفتر کل Beancount واقعی برای یک کسب‌وکار کوچک ممکن است هزاران تراکنش، ده‌ها حساب و تاریخچه چند ساله داشته باشد. نتایج FinSheet-Bench نشان می‌دهد که وقتی یک جدول به اندازه‌ای بزرگ می‌شود که واقعاً اهمیت پیدا می‌کند، دقت LLM به محدوده‌ای سقوط می‌کند که برای ثبت خودکار اسناد مالی ایمن نیست.

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

• TableLLM (arXiv:2311.09206) — مدل تنظیم‌شده‌ای (fine-tuned) که روی ۱۶۹ جدول Kaggle آموزش دیده است؛ گزارش شده که به طور قابل توجهی بهتر از GPT-4 در پیش‌بینی جدولی عمل می‌کند، که نشان می‌دهد تنظیم اختصاصی هنوز رویکرد درستی برای وظایف جدولی خاص حوزه مالی است.
• TAT-QA (arXiv:2105.07624) — مجموعه‌داده‌ای مخصوص استدلال گسسته روی اسناد مالی ترکیبی (جداول + متن، مانند گزارش‌های سود)؛ مدل TAT-LLM همراه آن مستقیم‌ترین پیشینه برای اعمال مدل‌های تخصصی در استدلال جداول مالی است.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — روی اختلالات خصمانه مانند جابجایی سطرها و تغییر ترتیب ستون‌ها تمرکز دارد؛ اگر یک عامل Beancount نسبت به تغییر ترتیب مقاوم باشد، سیگنالی است که نشان می‌دهد ساختار را درک کرده است نه فقط موقعیت را.