Chain-of-Table: LLM推論チェーンにおけるテーブルの進化
テーブル推論に関して、私はいつも同じ違和感に突き当たります。LLMがプレーンな思考の連鎖（chain-of-thought, CoT）テキストを使用してテーブルに対する作業を説明するとき、彼らはある表現をナレーションしながら、実際には別の表現について推論しているのです。ICLR 2024で発表されたGoogle Researchの論文「Chain-of-Table」は、この緊張関係を真摯に捉え、シンプルな解決策を提案しています。すなわち、中間的な推論状態をテキストではなく、テーブル自体に持たせるのです。
論文の概要
Wangらは「Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding」（arXiv:2401.04398, ICLR 2024）を発表しました。この論文は、テーブルデータに適用された標準的な思考の連鎖プロンプティングが残したギャップに対処し ています。CoTは自然言語で推論しますが、テーブルは構造化された成果物であり、テーブル操作の言語によるナレーションは冗長で情報損失を伴います。核となるアイデアは、LLMに一連のプログラム的なテーブル操作（フィルタリング、グループ化、ソート、列の選択、列の追加）を計画させ、それぞれを実行して中間的なテーブル状態を生成し、その進化したテーブルを次のステップの入力としてLLMにフィードバックすることです。最終的な回答は、長いテキストの連鎖からではなく、最終的なテーブル状態から生成されます。著者らはSQL開発との明確な類似性を指摘しています。熟練したアナリストは、単一の巨大なクエリではなく、中間的な CREATE TABLE ... AS SELECT ステップを書きます。Chain-of-Tableは、LLMエージェントのためにその慣習を形式化したものです。
評価はWikiTableQuestions (WikiTQ)、TabFact、FeTaQAの3つのベンチマークで行われました。主要なモデルはPaLM 2で、GPT-3.5およびLLaMA 2 70Bでのクロスバリデーションも行われています。
主なアイデア
- Chain-of-Tableは、WikiTQにおいて67.31%の標示精度（denotation accuracy）を達成し、以前の最強のベースラインであるDaterの61.48%に対して+5.83ポイントの向上を実現しました。
- 4,000トークンを超えるテーブルでは、そのアドバンテージは+10.25ポイント（44.87%対34.62%）に拡大します。これは、この手法が実務で最も重要となる領域です。
- TabFactの精度はDaterの84.63%に対して86.61%に達し、FeTaQAのBLEUスコアは29.47から32.61に向上しました。
- 5つの原子的な操作（
f_select_row,f_select_column,f_group_by,f_sort_by,f_add_column）は、これらのベンチマークで観察される推論パターンの大部分をカバーしています。特に、カウントが主要な失敗モードであるWikiTQでは、f_group_byが最も大きな役割を果たします。 - Chain-of-Tableは、1つの質問につき最大25サンプルの生成で済みます。これはBinderの50サンプル、Daterの100サンプルと比較して50〜75%の効率向上であり、精度向上と効率化が同時に達成されるのはLLM研究において非常に珍しいことです。
- このアプローチはモデルに依存しません。PaLM 2、GPT-3.5、LLaMA 2の一貫してテキストCoTのベースラインを上回っています。
評価できる点と課題
この論文の中心となる実証的な貢献は堅実です。ベンチマークは標準的であり、ベースラインは公平で、効率性に関する物語も説得力があります。テーブル自体を散文でナレーションするのではなく、明示的な中間表現にすることは、直感的な動機に基づいたクリーンなアイデアです。特に大きなテーブルでの結果は最も納得のいく証拠です。テーブルがコンテキストに収まりきらない場合、操作によって重要な部分を段階的に削ぎ落としていくことは、さらにテキストを生成するよ りも明らかに優れています。
一方で、現実的なギャップも存在します。誤差の伝播（error propagation）に関する分析は表面に留まっています。5段階のチェーンの2段階目でLLMが誤った f_select_row の引数を生成した場合、それ以降のすべての操作は破損した中間テーブルに対して実行され、最終的な回答はゴミ同然になります。論文では総合的な精度は報告されていますが、推論の失敗が初期のステップのミスによるものか、後半のミスによるものか、あるいはこの手法が部分的に誤った操作に対して堅牢であるかどうかは分析されていません。一連の正しい呼び出しに依存する手法にとって、これは重大な欠落です。
操作の語彙についても賭けの側面があります。WikiTQやTabFactのパターンのほとんどを5つの操作がカバーしているのは、それらのベンチマークがリレーショナルなテーブルタスクを中心に設計されているためです。現実世界の財務テーブル（貸借対照表、元帳試算表、税務スケジュールなど）では、関連するテーブル間の結合（join）、条件付きの計算集計（「勘定科目が'6'で始まる場合の借方合計」など）、ピボット変換が日常的に必要となります。これらは操作セットに含まれていません。著者らはこれを暗黙的に認めていますが、テストはしていません。
最後に、なぜ中間的なテーブル状態が中間的なテキストよりも優れているのかという理論的な説明がありません。直感的には魅力的ですが、論文は純粋に実証的です。後続の研究（TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025）は、SQLとテキスト推論を混合する適応的なハイブリッドアプローチへと急速に移行しました。こ れは、純粋なテーブル操作が普遍的に優れているわけではなく、テストされたベンチマークにおいて優れていたという私の見解をコミュニティも共有していることを示唆しています。
財務AIにとっての重要性
Beancount元帳エージェントにとって、Chain-of-Tableのアーキテクチャは、私がライトバック・パイプライン（write-back pipeline）に求めているものとほぼ完璧に一致します。「:ignoreタグが付いたトランザクションを除き、第1四半期のカテゴリ別の純費用はいくらか？」というBeancountクエリは、まさにこの論文が提案する一連のテーブル変換を必要とします。日付による行のフィルタリング、タグによるフィルタリング、勘定科目カテゴリによるグループ化、金額の合計です。エージェントがこれを単一のクエリを生成したり散文で推論したりするのではなく、明示的な中間操作のチェーンとして計画できれば、監査証跡は読みやすくなり、各ステップを独立して検証できるようになります。
大きなテーブルでの効率向上も直接的に関連します。数万件のトランザクションを含む数年分のBeancount元帳は、具体化されると容易に4,000トークンを超えます。その領域での10ポイントの向上はベンチマーク上の産物ではなく、推論を正確にする前にテーブルを段階的に絞り込む必要がある際に実際に起こることを反映しています。
Beancountに欠けている要素は結合（join）操 作です。複式簿記は勘定をまたいでトランザクションをリンクさせており、いかなる照合（reconciliation）タスクも少なくとも2つの勘定科目のタイムラインをまたいだ推論を必要とします。発表されたままの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生成へと拡張し、結合の欠落に対処しています。
- 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の自然言語インターフェース設計に関連します。
