TableLlama: 7Bのオープンモデルはテーブル理解においてGPT-4に匹敵するか？

先週のMAC-SQLログを読み、テーブルベースのエージェントにおける最大の弱点について考えさせられました。それは、クエリを生成する以前の、モデル自体のテーブル構造とセマンティクスの理解能力です。TableLlama (NAACL 2024) は、そのレイヤーに直接切り込んでいます。クエリインターフェースを改善するのではなく、タスク固有のエンジニアリングなしで幅広いテーブルタスクを処理できる汎用的なオープンソースモデルを構築することを目指しています。私が今これを読んでいるのは、Beancountエージェントが直面するテーブル理解の諸問題において、7Bのオープンモデルが実際にGPT-4に匹敵しうるのかという問いに対する、最も直接的な答えだからです。

論文の概要

オハイオ州立大学のTianshu Zhang、Xiang Yue、Yifei Li、Huan SunらによるTableLlamaは、Llama 2 (7B)を「TableInstruct」と呼ぶ新しいインストラクションチューニングデータセット（11のテーブルタスクにわたる260万の例）でファインチューニングしたものです。テーブルがもたらす長いコンテキストに対応するため、彼らはLongLoRAを採用しました。これは、完全な再学習なしでコンテキストウィンドウを8Kトークンまで拡張する、パラメータ効率の良い拡張アプローチです。評価対象は、8つのドメイン内タスク（列型アノテーション、関係抽出、エンティティリンク、スキーマ拡張、行補完、階層的テーブルQA、強調セルQA、事実検証）と、モデルが学習していない6つのドメイン外データセットに及びます。

核心となる主張は、単一のファインチューニング済みオープンモデルが、ほとんどのドメイン内ベンチマークにおいてタスク固有のSOTA（最高水準）に匹敵または上回り、ドメイン外でもベースのLlama 2モデルを絶対値で5〜44ポイント上回る（いくつかのタスクでGPT-4との差を縮めることを含む）という点です。

主なアイデア

• ドメイン内タスクにおいて、TableLlamaは構造認識タスクでGPT-4を圧倒しています：列型アノテーション（F1 94.39対31.75）、関係抽出（F1 91.95対52.95）、FeTaQA BLEU（39.05対21.70）、HiTab実行精度（64.71対48.40）。
• ドメイン外データセットでは、状況が逆転します。GPT-4はWikiTQの精度（68.40対35.01）やHybridQA（58.60対39.38）でリードしています。これらは、構造的なパターンマッチングよりも、テーブルに対する構成的なマルチホップ推論を必要とするタスクです。
• WikiSQLはクエリ生成能力の差を鮮明に浮き彫りにしています。TableLlamaのスコアは50.48%であるのに対し、SOTAは92.70%です。この42ポイントの差は、自然言語からクエリへのインターフェースを構築する者にとって、最も実務的に重要な数字です。
• ここではLongLoRAが重要な役割を果たしています。金融テーブルは長くなりがちです。コンテキストウィンドウの拡張がなければ、この種のタスク全体が7Bモデルの手には負えないものになっていたでしょう。
• 著者らは、計算リソースの制約により7Bサイズに限定したことを認めており、13Bや70Bのバリアントについては評価されていません。

評価できる点と課題

ベンチマークの設定には、精査が必要な「不適切な比較」が含まれています。ドメイン内の比較では、ファインチューニングされたTableLlamaとゼロショットのGPT-4を戦わせています。列型アノテーションのようなTURLベースのタスクにおいて、GPT-4のF1スコアが31.75であることは、GPT-4が根本的に列型を理解できないことを意味するのではなく、特定の出力形式を期待するデータセットに対して、フォーマット固有の調整なしのゼロショットプロンプトが失敗したことを意味します。より誠実な比較は、両モデルがトレーニングデータを見ていないドメイン外のタスクで行われるべきであり、そこでの差は謙虚に受け止めるべきものです：WikiTQの精度は35.01対68.40です。

WikiTQは適切なストレステストです。なぜなら、「1990年以前に記録が樹立された種目で、最も多くのメダルを獲得した国はどこか？」といった、テーブルセルをまたぐ真の構成的推論を必要とするからです。WikiTQにおけるTableLlamaのGPT-4に対する33ポイントの劣勢は、構造的タスクに対するインストラクションチューニングが、必ずしもリレーショナル（関係性）な推論に自動的に転移しないことを示す明確なシグナルです。

スキーマ拡張とエンティティリンクでの勝利は実質的で意義深いものです。これらのタスクは、ゼロショットのGPT-4プロンプトが苦戦するような、テーブル構造の理解を真に必要とします。しかし、それらは推論よりも検索に近いタスクでもあり、これらの結果がどこまで汎用化できるかには限界があります。

別の懸念点として、260万例のTableInstructデータセットは多大なエンジニアリングの成果ですが、非常に異なるタスクタイプを単一のインストラクション形式に押し込めています。どのタスクタイプが互いに干渉しているのか、あるいはどのタスクがドメイン外での利益に寄与しているのかを示すアブレーション研究（構成要素の除去実験）がありません。オハイオ州立大学グループによる自身のフォローアップベンチマーク（TableBench, AAAI 2025）では、TableInstructでファインチューニングされたモデルはGPT-3.5に匹敵するパフォーマンスを達成したものの、依然としてGPT-4には及ばないことが判明しており、元の論文の楽観論はかなり和らげられています。

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

Beancountの元帳は構造化されたテーブルです。すべてのエントリに日付、勘定科目、金額、およびオプションのメタデータがあります。この論文のテーブルタスクは、Beancountエージェントが実行する必要のある操作に直接マッピングされます。列型アノテーションは、どの勘定科目がどの勘定科目タイプ（資産、負債、費用）に属するかを理解することに対応します。エンティティリンクは、不一致な取引明細の間で支払受取人名を解決することに対応します。そして、WikiSQLの差は、まさにbeanqueryの自然言語インターフェースの問題に直結します。

ここでの結果から冷静な視点が得られます。7Bのファインチューニング済みモデルは、元帳の構造認識を実用的なレベルで確実に処理できますが、上位モデルを介在させずに、自由形式の質問を正しいbeanquery式に変換する役割を任せるには、まだ信頼が足りません。WikiSQLの精度が50%（SOTAは93%）であるということは、オープンモデルのみのbeanqueryインターフェースでは、馴染みのない表現の質問に対して約半分の確率で誤ったクエリを生成することを意味します。書き込みを行うエージェントにとって、この失敗率は高すぎます。人間がレビューする読み取り専用のクエリインターフェースであれば、ドラフトとしては許容できるかもしれません。

LongLoRAの貢献は直接応用可能です。数年分のBeancount元帳は容易に8Kトークンを超えます。ここでのアプローチは、膨大な計算リソースなしで、長いテーブルに対してファインチューニングを行う方法を示しています。

次に読むべきもの

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — オハイオ州立大学グループによる自身のフォローアップ研究。より複雑なテーブルQAにおいて30以上のLLMをベンチマークした結果、TableInstructによるファインチューニング後でも、オープンモデルとGPT-4の差は解消されないことを明らかにしました。
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — インストラクションチューニングとは対照的に、合成SQL実行で事前学習を行う手法。テーブル理解における事前学習対ファインチューニングの議論における重要なベースラインです。
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — 標準的なTableInstructのレシピが実際に汎用化されるのか、そしてどのようなデータ構成の選択が最も重要なのかを問う最近の研究。