Chain-of-Table: تکامل جداول در زنجیره استدلال مدل‌های زبانی بزرگ

من مدام به همان مشاهده ناخوشایند در مورد استدلال جدولی برمی‌گردم: وقتی مدل‌های زبانی بزرگ (LLMها) کار خود را روی جداول با استفاده از متن ساده زنجیره فکر (chain-of-thought) توضیح می‌دهند، در حال روایت یک نمایش هستند در حالی که درباره نمایش دیگری استدلال می‌کنند. مقاله Chain-of-Table، از تیم Google Research که در ICLR 2024 منتشر شد، این چالش را جدی گرفته و یک راهکار ساده پیشنهاد می‌دهد: اجازه دهید خودِ جدول حالت میانی استدلال را حمل کند، نه متن.

مقاله

وانگ و همکاران، Chain-of-Table را ارائه کردند: تکامل جداول در زنجیره استدلال برای درک جدول (arXiv:2401.04398, ICLR 2024). این مقاله شکافی را برطرف می‌کند که در هنگام اعمال پرامپتینگ استاندارد زنجیره فکر بر داده‌های جدولی ایجاد می‌شود: CoT در قالب زبان طبیعی استدلال می‌کند، اما جداول ساختارهای سازمان‌یافته‌ای هستند و روایت زبانی از تغییرات جدول، هم طولانی و هم با اتلاف اطلاعات همراه است. ایده اصلی این است که به LLM اجازه داده شود دنباله‌ای از عملیات‌های برنامه‌نویسی جدول را برنامه‌ریزی کند — فیلتر، گروه‌بندی، مرتب‌سازی، انتخاب ستون، افزودن ستون — و با اجرای هر یک، یک حالت میانی برای جدول تولید کند و آن جدول تکامل‌یافته را دوباره به عنوان ورودی برای مرحله بعد به LLM بدهد. پاسخ نهایی از آخرین وضعیت جدول تولید می‌شود، نه از یک زنجیره متنی طولانی. نویسندگان یک شباهت صریح با توسعه SQL ترسیم می‌کنند: یک تحلیلگر ماهر مراحل میانی را با CREATE TABLE ... AS SELECT می‌نویسد، نه یک پرس‌وجوی واحد و عظیم. Chain-of-Table این رویکرد را برای عامل‌های LLM رسمی‌سازی می‌کند.

این ارزیابی سه بنچمارک را پوشش می‌دهد: WikiTableQuestions (WikiTQ)، TabFact و FeTaQA. مدل اصلی مورد استفاده PaLM 2 است که با GPT-3.5 و LLaMA 2 70B نیز صحت‌سنجی شده است.

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

• روش Chain-of-Table به دقت معانی ۶۷.۳۱٪ در WikiTQ دست می‌یابد، در حالی که Dater (قوی‌ترین مدل پایه قبلی) به ۶۱.۴۸٪ رسیده بود؛ این یک بهبود ۵.۸۳ واحد درصدی است.
• در جداول با بیش از ۴۰۰۰ توکن، این برتری به ۱۰.۲۵+ امتیاز (۴۴.۸۷٪ در مقابل ۳۴.۶۲٪) می‌رسد که در عمل، بیشترین اهمیت را در این بخش دارد.
• دقت در TabFact به ۸۶.۶۱٪ در مقابل ۸۴.۶۳٪ برای Dater می‌رسد؛ امتیاز BLEU در FeTaQA نیز از ۲۹.۴۷ به ۳۲.۶۱ بهبود می‌یابد.
• پنج عملیات اصلی — f_select_row ، f_select_column ، f_group_by ، f_sort_by ، f_add_column — اکثر الگوهای استدلالی مشاهده شده در این بنچمارک‌ها را پوشش می‌دهند؛ عملیات f_group_by بیشترین نقش را در WikiTQ ایفا می‌کند، جایی که شمارش شایع‌ترین حالت شکست است.
• روش Chain-of-Table حداکثر به ۲۵ بار تولید نمونه برای هر سوال نیاز دارد، در حالی که Binder به ۵۰ و Dater به ۱۰۰ بار نیاز دارند — یک افزایش کارایی ۵۰ تا ۷۵ درصدی در کنار دقت بهتر که در تحقیقات LLM (جایی که معمولاً بین این دو توازن وجود دارد) بسیار غیرمعمول است.
• این رویکرد مستقل از مدل (model-agnostic) است: به طور مستمر در PaLM 2، GPT-3.5 و LLaMA 2 از مدل‌های پایه متن-CoT بهتر عمل می‌کند.

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

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

با این حال، شکاف‌های واقعی نیز وجود دارد. تحلیل انتشار خطا (error propagation) سطحی است. اگر LLM در مرحله دوم از یک زنجیره پنج مرحله‌ای، آرگومان اشتباهی برای f_select_row تولید کند، تمام عملیات‌های بعدی روی یک جدول میانیِ خراب اجرا می‌شوند و پاسخ نهایی بی‌ارزش خواهد بود. مقاله دقت کلی را گزارش می‌کند اما تحلیل نمی‌کند که استدلال چند وقت یک‌بار به دلیل خطاهای مراحل اولیه در مقابل مراحل نهایی با شکست مواجه می‌شود یا اینکه آیا این رویکرد در برابر عملیات‌های نیمه‌اشتباه مقاوم است یا خیر. برای روشی که به دنباله‌ای از فراخوانی‌های صحیح وابسته است، این یک حذفیات معنادار است.

مجموعه عملیات‌ها نیز نوعی ریسک محسوب می‌شود. پنج عملیات اکثر الگوها را در WikiTQ و TabFact پوشش می‌دهند، زیرا آن بنچمارک‌ها بر اساس وظایف جداول رابطه‌ای طراحی شده بودند. جداول مالی در دنیای واقعی — ترازنامه‌ها، ترازهای آزمایشی دفتر کل، جداول مالیاتی — به طور معمول نیازمند پیوند (join) بین جداول مرتبط، تجمیع‌های محاسباتی مشروط (مجموع بدهکارها جایی که حساب با '۶' شروع می‌شود) و تبدیل‌های محوری (pivot) هستند. هیچ‌کدام از این‌ها در مجموعه عملیات‌ها نیستند. نویسندگان به طور ضمنی به این موضوع اذعان دارند اما آن را آزمایش نمی‌کنند.

در نهایت، هیچ توضیح تئوریکی در مورد اینکه چرا حالت‌های میانی جدول باید بهتر از متن میانی باشند، وجود ندارد. شهود جذاب است، اما مقاله کاملاً تجربی است. کارهای بعدی (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) سریعاً به سمت رویکردهای ترکیبی تطبیقی رفتند که استدلال SQL و متن را با هم ترکیب می‌کنند؛ این نشان می‌دهد جامعه علمی همان شکافی را دید که من دیدم: عملیات‌های صرفاً جدولی به طور جهانی بهتر نیستند، بلکه فقط در بنچمارک‌های آزمایش شده بهتر عمل می‌کنند.

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

برای عامل‌های دفتر کل Beancount، معماری Chain-of-Table تقریباً به طور کامل با آنچه من در یک خط لوله بازنویسی (write-back) می‌خواهم مطابقت دارد. یک پرس‌وجوی Beancount مانند «هزینه‌های خالص من به تفکیک دسته در سه ماهه اول، به استثنای تراکنش‌های دارای برچسب :ignore چقدر است؟» دقیقاً به همان نوع تغییرات جدولی متوالی نیاز دارد که مقاله پیشنهاد می‌دهد: فیلتر کردن ردیف‌ها بر اساس تاریخ، فیلتر بر اساس برچسب، گروه‌بندی بر اساس دسته حساب و جمع مبالغ. اگر عامل بتواند این کار را به عنوان زنجیره‌ای از عملیات‌های میانی صریح برنامه‌ریزی کند (به جای تولید یک پرس‌وجوی واحد یا استدلال متنی درباره آن)، ردپای حسابرسی قابل خواندن خواهد بود و هر مرحله به طور مستقل قابل تایید است.

بهبود کارایی در جداول بزرگ نیز مستقیماً مرتبط است. یک دفتر کل Beancount چندساله با ده‌ها هزار تراکنش، در هنگام تبدیل به جدول به راحتی از ۴۰۰۰ توکن فراتر می‌رود. بهبود ۱۰ امتیازی در آن شرایط یک یافته مصنوعی در بنچمارک نیست؛ بلکه نشان‌دهنده اتفاقی است که واقعاً می‌افتد وقتی جدول باید قبل از استدلال دقیق، به تدریج محدود شود.

قطعه گمشده برای Beancount، عملیات پیوند (join) است. حسابداری دوطرفه تراکنش‌ها را در چندین حساب به هم متصل می‌کند و هر وظیفه مغایرت‌گیری نیازمند استدلال در حداقل دو خط زمانی حساب است. Chain-of-Table به شکل منتشر شده نمی‌تواند این را بیان کند. گسترش دایره عملیات‌ها برای شامل شدن پیوندهای بین‌حسابی، گام مهندسی بعدیِ بدیهی برای یک عامل استدلال‌گر Beancount در سطح تولید است.

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

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — مفهوم عملیات را به سمت تولید SQL توسط چند عامل گسترش می‌دهد که شکاف عملیات join را برطرف می‌کند.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — استدلال تطبیقی را معرفی می‌کند که بین عملیات‌های جدولی و CoT متنی سوئیچ می‌کند؛ مستقیم‌ترین ادامه برای Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — رویکرد تجزیه مکمل برای SQLهای پیچیده روی شِماهای بزرگ، که برای طراحی رابط زبان طبیعی beanquery مرتبط است.