TableMaster: استدلال تطبیقی برای درک جداول با مدل‌های زبانی بزرگ (LLMs)

دفترکل Beancount در اصل یک جدول ساختاریافته است: حساب‌ها به عنوان ستون‌ها، زمان به عنوان یک محور، و مبالغ و ارزها به عنوان مقادیر. هر عاملی که روی آن استدلال می‌کند باید همان کاری را انجام دهد که TableMaster انجام می‌دهد — یافتن سطرها و ستون‌های صحیح، درک معنای اعداد، و انتخاب بین محاسبه نمادین یا استدلال زبانی. TableMaster اثر لانگ کائو و هانبینگ لیو (arXiv:2501.19378) توانمندترین خط لوله درک جدول است که تاکنون بدون تنظیم دقیق (fine-tuning) دیده‌ام، و می‌خواستم بدانم آیا واقعاً وضعیت پیشرفته این حوزه را به روشی اصولی ارتقا می‌دهد یا فقط تا زمانی که بنچ‌مارک تغییر کند، از اکتشافات پرامپت‌نویسی استفاده می‌کند.

مقاله

TableMaster یک چارچوب مبتنی بر پرامپت است که به چهار حالت شکست خاص که LLMها در پرسش و پاسخ جدولی نشان می‌دهند، می‌پردازد: آن‌ها در مکان‌یابی سلول مربوطه در یک جدول بزرگ مشکل دارند، بافت معنایی کدگذاری شده در سرستون‌ها را از دست می‌دهند، هنگام استدلال در متن ساده دچار توهم محاسباتی می‌شوند، و زمانی که استدلال نمادین (SQL، Python) با داده‌های نویزدار یا مختلط مواجه می‌شود، از کار می‌افتند. نویسندگان به هر شکست با یک ماژول اختصاصی پاسخ می‌دهند که در یک خط لوله سه‌مرحله‌ای مونتاژ شده است. مرحله اول یک «جدول تمرکز» می‌سازد — یک زیرجدول هرس شده که فقط شامل سطرها و ستون‌های مرتبط با پرس‌وجو است — که از جستجوی ستون با رتبه‌بندی LLM و فیلتر کردن سطر مبتنی بر SQL استفاده می‌کند. مرحله دوم این زیرجدول را به زبان طبیعی شفاهی‌سازی می‌کند و بررسی می‌کند که آیا بخش استخراج شده واقعاً برای پاسخ به سوال کافی است یا خیر، و در صورت نیاز آن را به صورت تکراری گسترش می‌دهد. مرحله سوم استدلال تطبیقی را اعمال می‌کند: یک LLM برای هر پرس‌وجو تصمیم می‌گیرد که آیا زنجیره فکر (chain-of-thought) را روی توصیف شفاهی اجرا کند یا پایتون یا SQL تولید و اجرا کند، به طوری که مسیر نمادین توسط توصیف زبان طبیعی هدایت می‌شود تا مواردی را که مقادیر جدول رشته‌های نامرتب هستند (به جای اعداد تمیز) مدیریت کند.

هیچ مدل جدیدی آموزش داده نشده است. همه چیز روی LLMهای چندمنظوره (GPT-3.5-turbo، GPT-4o-mini، Llama-3.1-70B) از طریق پرامپت‌نویسی اجرا می‌شود.

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

• در WikiTQ با GPT-4o-mini، TableMaster به ۷۸.۱۳٪ می‌رسد، در حالی که Chain-of-Table به ۵۵.۶۰٪ و PoTable به ۶۴.۷۳٪ در همان مدل دست یافته‌اند — یک بهبود ۱۳.۴۰ واحدی نسبت به بهترین خط پایه بعدی.
• همین الگو در GPT-3.5-turbo (۶۸.۲۱٪ در مقابل بهترین قبلی حدود ۵۸٪) و Llama-3.1-70B (۷۷.۹۵٪) تکرار شده است که نشان می‌دهد دستاوردها مختص یک مدل خاص نیستند.
• در TabFact (تأیید واقعیت)، TableMaster با GPT-4o-mini به ۹۰.۱۲٪ در مقابل ۸۴.۲۴٪ برای Chain-of-Table می‌رسد — یک بهبود کوچک‌تر اما پایدار.
• تحلیل ابلیشن (Ablation) نشان می‌دهد که حذف استدلال متنی بیشترین ضربه را می‌زند (۴.۲۸-٪)، و پس از آن حذف استخراج ساختار (۳.۳۸-٪). سوئیچ تطبیقی بین حالت‌ها واقعاً نقش تعیین‌کننده‌ای دارد.
• اندازه جدول اصلی‌ترین پیش‌بینی‌کننده شکست است: عملکرد با افزایش تعداد سطر، ستون و توکن، صرف‌نظر از مدل، به طور یکنواخت کاهش می‌یابد.
• استدلال نمادین در جداول نویزدار ۳۱.۸٪ افت می‌کند در حالی که استدلال متنی ۲۰.۵٪ افت دارد — مسیر نمادینِ هدایت‌شده توسط متن دقیقاً برای تلطیف این حالت شکست وجود دارد.
• استدلال متنی به تنهایی در پرس‌وجوهای محاسباتی سنگین ۲۰.۱٪ افت می‌کند در حالی که در وظایف غیر محاسباتی ۷۲.۴٪ افت دارد — که دقیقاً نشان می‌دهد چرا سوئیچ ترکیبی اهمیت دارد.

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

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

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

مقایسه با Chain-of-Table نیز به دلیل بافت موضوعی کمی اغراق‌آمیز است. ارزیابی اصلی Chain-of-Table از PaLM 2 و GPT-3.5 استفاده کرده بود — عدد ۵۵.۶۰٪ برای Chain-of-Table که برای GPT-4o-mini نشان داده شده، ممکن است به دلیل عدم بهینه‌سازی پرامپت‌های Chain-of-Table برای آن مدل باشد تا یک مزیت معماری واقعی. این موضوع نتیجه را باطل نمی‌کند، اما به این معنی است که شکاف اصلی باید به عنوان حد بالای بهبود واقعی خوانده شود.

این مقاله از ژانویه ۲۰۲۵ تاکنون شش بار بازبینی شده که غیرمعمول است. دامنه تحقیق به مجموعه‌داده‌های انگلیسی و جداول تا چند صد سطر محدود شده است. هیچ تحلیلی از هزینه‌های اضافی ارائه نشده است — هر پرس‌وجو اکنون به چندین فراخوانی LLM نیاز دارد (رتبه‌بندی ستون، SQL سطر، بررسی کفایت، شفاهی‌سازی، مسیریابی، استدلال) و با قیمت مدل‌های پیشرو، این هزینه به سرعت انباشته می‌شود.

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

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

محدودیتی که برای دفترکل‌ها بیشترین اهمیت را دارد، مقیاس است. جداول WikiTQ حداکثر چند ده سطر و تعداد کمی ستون دارند؛ یک دفترکل Beancount واقعی چندساله هزاران ورودی دارد. مقاله نشان می‌دهد که عملکرد با اندازه جدول به طور یکنواخت کاهش می‌یابد و فراتر از چند صد سطر را آزمایش نکرده است. استخراج جدول تمرکز برای رفع این مشکل در نظر گرفته شده است، اما فیلتر سطر مبتنی بر SQL خودش یک پرس‌وجوی تولید شده توسط LLM روی کل جدول است — که یعنی به جای حل مشکل سخت، آن را جابجا می‌کند. تعامل با حافظه سلسله‌مراتبی به سبک MemGPT یا با یک لایه beanquery ایندکس‌شده، گام بعدی منطقی است.

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

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

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — مستقیم‌ترین پیش‌درآمد برای مسیریابی تطبیقی TableMaster، با استراتژی استخراج دو مرحله‌ای ابتدا ستون و سپس سطر؛ ارزش مقایسه مستقیم معماری‌ها را دارد تا بفهمیم TableMaster چه چیزی اضافه کرده است.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — در حالی که TableMaster پرس‌وجو را هدف قرار می‌دهد، نمایش جدول و خط لوله نرمال‌سازی آن برای شناسایی ناهنجاری نیز به همان اندازه مرتبط است؛ امتیازدهی مبتنی بر احتمال در AnoLLM به مرحله پیش‌پردازش مشابهی نیاز دارد.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — به نظر می‌رسد ایده استخراج از کل به جزء را به جداول چندوجهی گسترش می‌دهد؛ اگر نیاز باشد بصری‌سازی‌های دفترکل Beancount (نمودارها، صورت‌حساب‌های PDF) با ورودی‌های متنی ساختاریافته تطبیق داده شوند، این مقاله مرتبط خواهد بود.