TableMaster：LLMを用いたテーブル理解のための適応的推論

Beancountの元帳は、その本質において構造化されたテーブルです。勘定科目は列、時間は一つの軸、金額と通貨は値として機能します。これを推論するエージェントは、TableMasterが行うこと、つまり適切な行と列を見つけ、数値の意味を理解し、記号的に計算するか言語で推論するかを選択するというプロセスを同様に実行しなければなりません。Lang Cao氏とHanbing Liu氏によるTableMaster (arXiv:2501.19378) は、ファインチューニングなしで私がこれまでに見た中で最も有能なテーブル理解パイプラインです。これが実際に原理的な方法で最新技術を前進させているのか、それとも単にベンチマークが動くまでプロンプティングのヒューリスティクスを積み重ねているだけなのかを理解したいと考えました。

論文の内容

TableMasterは、LLMが表形式の質問応答で示す4つの特定の失敗モードに対処するプロンプトベースのフレームワークです。その失敗モードとは、巨大なテーブルから関連するセルを特定できないこと、列ヘッダーにエンコードされたセマンティックな文脈を見落とすこと、プレーンテキストでの推論時に算術計算のハルシネーションを起こすこと、そして記号的推論（SQLやPython）がノイズの多いデータや混合型のデータに直面した際に破綻することです。著者らは、それぞれの失敗に対応する専用モジュールを用意し、それらを3段階のパイプラインに組み立てました。

第1段階では、LLMによる列ランク付けルックアップとSQLベースの行フィルタリングを使用して、クエリに関連する行と列のみを含む削減されたサブテーブルである「フォーカス・テーブル (table-of-focus)」を構築します。第2段階では、このサブテーブルを自然言語に言語化（verbalize）し、抽出されたスライスが実際に質問に答えるのに十分かどうかを確認し、不十分な場合は反復的に拡張します。第3段階では適応的推論を適用します。LLMがクエリごとに、言語化された説明に対して思考の連鎖 (chain-of-thought) を実行するか、あるいはPythonやSQLを生成して実行するかを決定します。記号的なパスは、テーブルの値がクリーンな数値ではなく乱雑な文字列である場合に対処するため、自然言語の説明によってガイドされます。

新しいモデルはトレーニングされていません。すべてはプロンプトを通じて、汎用LLM（GPT-3.5-turbo、GPT-4o-mini、Llama-3.1-70B）上で動作します。

主なアイデア

• GPT-4o-miniを使用したWikiTQにおいて、TableMasterは78.13%に達しました。同じモデルでのChain-of-Tableの55.60%、PoTableの64.73%と比較して、次点のベースラインから13.40ポイントの向上を実現しています。
• 同じパターンはGPT-3.5-turbo（68.21% vs 以前の最高約58%）やLlama-3.1-70B（77.95%）でも見られ、この成果が特定のモデルに依存しないことを示しています。
• TabFact（事実検証）において、TableMasterはGPT-4o-miniで90.12%に達しました。Chain-of-Tableの84.24%と比較して、小規模ながら一貫した改善が見られます。
• アブレーション研究により、テキスト推論を除去した場合の影響が最も大きく（–4.28%）、次いで構造抽出の除去（–3.38%）であることが明らかになりました。モード間の適応的な切り替えは、真にシステムの根幹を支えています。
• テーブルのサイズが失敗の支配的な予測因子です。モデルに関わらず、行数、列数、トークン数が増加するにつれて、パフォーマンスは単調に低下します。
• ノイズの多いテーブルでは、テキスト推論が20.5%低下するのに対し、記号的推論は31.8%低下しました。テキストガイド付きの記号パスは、まさにこの失敗モードを和らげるために存在します。
• 計算を多用するクエリではテキスト推論のみだと20.1%低下するのに対し、非計算タスクでは72.4%低下します。これは、なぜハイブリッドな切り替えが重要なのかを如実に物語っています。

評価できる点と懸念点

4つの課題に対する診断は十分に動機付けられており、実際の失敗例と明確に対応しています。アブレーション研究も誠実です。どのコンポーネントを取り除いても悪影響があり、その大きさはそのコンポーネントが実際にどれだけ使用されていたかに比例しています。これは、コンポーネントを取り除いてもモデルがそれを回避する方法を学んでいるために何も変わらないという、通常のアブレーションよりも強力な結果です。

評価が難しいと感じるのは、適応的推論分類器そのものです。クエリをテキストに送るかコードに送るかの決定は、プロンプト下でLLMによって行われます。このルーティングがどの程度の頻度で正しいのか、ミスファイア（例：計算をテキストに送る）が起きた時に何が起こるのか、あるいは単純なルール（クエリに算術演算子が含まれているか？）でも同等のパフォーマンスを発揮するのではないかといった点は、論文では報告されていません。アブレーションにおいてテキスト推論が最大の貢献要素であることを考えると、ほとんどのクエリはデフォルトでテキストパスを通り、記号ブランチが担う割合はフレームワークが示唆するよりも小さいのではないかと推測されます。

Chain-of-Tableとの比較も、コンテキストによってわずかに誇張されています。Chain-of-Tableの元の評価ではPaLM 2とGPT-3.5が使用されていました。GPT-4o-miniで示されたChain-of-Tableの55.60%という数値は、真のアーキテクチャ上の優位性というよりも、そのモデルに対するChain-of-Tableのプロンプトの調整不足を反映している可能性があります。これは結果を無効にするものではありませんが、見出しのギャップは真の改善の上限として読み取るべきであることを意味します。

この論文は2025年1月以来6回の改訂を経ており、これは異例です。対象範囲は英語のデータセットと数百行までのテーブルに限定されています。コストオーバーヘッドに関する分析は提示されていません。各クエリには、列のランキング、行のSQL、十分性チェック、言語化、ルーティング、推論という複数のLLM呼び出しが必要になり、フロンティアモデルの価格ではそのコストは急速に膨らみます。

なぜこれが金融AIにとって重要なのか

TableMasterが対処する失敗モードは、Beancount元帳エージェントが遭遇すると予想される失敗モードそのものです。40の勘定科目に3年分の取引が記録された元帳は、大規模でセマンティック豊かなテーブルです。「2023年第3四半期のフリーランスの仕事による純利益はいくらだったか？」という問いには、適切な勘定科目の特定（列ルックアップ）、日付によるフィルタリング（行ルックアップ）、「フリーランス」が複数の勘定科目名に対応することの理解（セマンティックな強化）、そして金額の正確な合計（記号的算術）が必要です。beanqueryインターフェースに適用されたTableMasterのパイプラインは、まさにこれらのステップを攻略することになります。

元帳にとって最も重要な制限はスケールです。WikiTQのテーブルはせいぜい数十行、数列ですが、実際の数年間にわたるBeancountの元帳には数千のエントリがあります。論文では、テーブルサイズとともにパフォーマンスが単調に低下することが示されており、数百行を超えるテストは行われていません。フォーカス・テーブルの抽出はこれに対処することを目的としていますが、SQLベースの行フィルタ自体がフルテーブルに対するLLM生成クエリであり、問題を解決するのではなく移動させているに過ぎません。MemGPTスタイルの階層メモリや、インデックス化されたbeanqueryレイヤーとの相互作用が、自然な次のステップとなるでしょう。

テキストガイド付きの記号パスは、Beancountに直接適用可能です。元帳の金額は、多くの場合、メタデータ（通貨コード、ロット注釈、取得価額マーカー）に囲まれており、単純なPythonの浮動小数点パーサーでは失敗してしまいます。コードが何を計算すべきかを自然言語の説明で補完し、コード生成の根拠（グラウンディング）とすることは賢明な緩和策ですが、実際のBeancountエクスポート形式で系統的な評価を行う必要があります。

次に読むべきもの

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — TableMasterの適応的ルーティングの最も直接的な前身であり、2段階の「列、次に行」の抽出戦略を採用しています。TableMasterが何を追加したかを理解するために、アーキテクチャを直接比較する価値があります。
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — TableMasterはQAを対象としていますが、テーブルの表現と正規化パイプラインは異常検知にも同様に関連しています。AnoLLMの尤度ベースのスコーリングには、同様の前処理段階が必要です。
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — 粗から密への抽出アイデアをマルチモーダルなテーブルに拡張しているようです。Beancount元帳の可視化（チャート、PDF明細）を構造化されたテキストエントリと照合する必要がある場合に役立ちます。