TAPAS: SQL不要の弱教師ありテーブルQA、そしてそれがBeancountに意味すること
私はこれまでBIRD、DIN-SQL、MAC-SQLといったtext-to-SQLの系譜に時間を費やしてきましたが、それらすべてに共通する、ある前提に疑問を投げかけたいと思います。それは、「テーブルQA（質問応答）における正しいインターフェースはSQLの生成である」という点です。Google ResearchのHerzigらによって発表されたTAPAS（ACL 2020）は、逆の賭けに出ています。TAPASはクエリを一切生成しません。その代わりに、セルを選択し、オプションでスカラー集計を適用するだけで、回答の外延（denotations）のみからエンドツーエンドで学習されます。
論文の概要
TAPASは、標準的な位置IDとセグメントIDの上に6つの新しい埋め込み次元を追加することで、テーブルをエ ンコードするようにBERTを拡張しています。列IDと行IDは、各トークンがテーブルグリッドのどこに位置するかを示します。ランクIDは、ソート可能な列内の相対的な数値順序をエンコードします（ランク0は比較不能、i番目に小さい値にはランクi+1）。「前回の回答（Previous Answer）」インジケーターは、前の会話ターンで選択されたセルにフラグを立てます。質問トークンとテーブルトークンを区別するバイナリセグメント埋め込みと組み合わせることで、TAPASに7つのタイプのトークン表現が与えられます。
推論時、モデルはセルごとの確率に閾値を設けることでセルのセットを選択し、4つの集計演算子（NONE、COUNT、SUM、またはAVERAGE）のいずれかを適用して最終的な回答を生成します。中間のSQLや論理形式は存在しません。事前学習は、620万件の英語版Wikipediaのテーブルとテキストのペアに対して、標準的なMasked Language Model（MLM）の目的関数を実行します。
主なアイデア
- 列/行の埋め込みは非常に重要です。アブレーション（構成要素の削除実験）によると、これらを削除するとSQAで19.4ポイント、WikiSQLで10.6ポイント、WikiTQで11.6ポイント精度が低下し、これは他のどのアーキテクチャ構成要素よりも大きな影響です。
- テーブルの事前学習もほぼ同様に重要です。事前学習を省くと、ファインチューニング後でもSQAで12.5ポイント、WikiTQで11.1ポイント精度が低下します。
- SQA（会話型テ ーブルQA）において、TAPASは精度を55.1%から67.2%へと12ポイント向上させました。「前回の回答」トークン埋め込みは、個別の状態トラッカーなしで会話の継続性を機能させるメカニズムです。
- WikiSQL（単一テーブル、主に検索と集計）では、TAPASは83.6%に達し、SQL生成を全く行わずに、SOTA（最先端）のセマンティックパーサーの83.9%にほぼ並びました。
- WikiSQLからWikiTQ（マルチステップ、マルチカラム推論）への転移学習では48.7%を達成し、当時のSOTAを4.2ポイント上回りました。SQAからの転移では48.8%となりました。
- 弱教師あり学習は、コスト効率に関する主要な主張です。モデルは（質問、SQL、回答）の3つ組ではなく、（質問、回答）のペアで学習されるため、SQLの専門知識がなくても大規模なコーパスに注釈を付けることができます。
評価できる点、できない点
「多くのテーブルQAの質問は、セルを選択し、4つのスカラー演算のいずれかを適用することで解決できる」という核心的な洞察は、テストされたベンチマークにおいて経験的に妥当であることが証明されています。しかし、WikiTQに関する論文の正直なエラー分析は示唆に富んでいます。エラーの37%は著者自身によっても分類不能であり、16%はモデルが実行できない文字列操作を必要とし、10%は複雑な時間的推論を含んでいました。つまり、TAPASの限界は集計演算子が間違 っていることにあるのではなく、質問のカテゴリー全体が構造的に範囲外であることにあります。
512トークンの制約は高い壁です。約500セルを超えるテーブルは切り捨てられなければならず、モデルには複数テーブルにまたがる推論のメカニズムがありません。これはチューニングの問題ではなく、アーキテクチャ上の問題です。また、モデルは集計を入れ子にすることもできません。「平均残高が0より大きい口座は何個ありますか？」という質問には、2つのパス（COUNT述語内の平均）が必要ですが、4つの演算子を持つヘッドではこれを表現できません。
TAPEX（ICLR 2022）は、WikipediaのテーブルMLMを、自動生成されたプログラムによる合成SQL実行に置き換えることで、事前学習のボトルネックに直接対処し、WikiTQを57.5%（+4.8）、SQAを74.5%（+3.5）まで押し上げました。これは意味のある差です。しかし、TAPEXもテーブルサイズと構成の深さに関する同じアーキテクチャ上の制限を継承しています。
どちらの論文も触れていない、より深い未解決の問いは、セル選択パラダイムが、実用的な面でSQL生成よりも現実世界のテーブルQAに適しているかどうかです。これはベンチマークの精度ではなく、監査可能性と正確性の保証の観点からです。セル選択は不透明です。回答は得られますが、プログラムは得られません。SQL生成は冗長ですが検証可能です。本番環境での利用においては、このトレードオフは数ポイントの精度よりも重要になります。
なぜこれが金融AIにとって重要なのか
Beancountの元帳は、実質的にはフラットで構造化されたテーブルです。行に勘定科目、列に金額、日付、通貨、タグが並びます。TAPASの直接的なセル選択パラダイムは、「3月の食費の合計は？」といった最も一般的な元帳クエリに自然に適合します。これらは、フィルタリングされた行に対するまさにSUMとCOUNTの集計です。「前回の回答」埋め込みは、ユーザーがクエリを洗練させる（「では、昨年はどうでしたか？」など）会話型セッションにおいて直接役立ちます。
しかし、大規模なBeancount元帳はTAPASの制約を打破してしまいます。数千のトランザクションを含む数年分の元帳は、512トークンの予算を桁違いに超えます。勘定科目の階層構造は、行グループをまたぐ推論を必要とします。「過去3年間の平均よりも純流出が多い口座はどれか？」といったクエリには、4つの演算子では表現できない入れ子状の集計が必要です。そして決定的なのは、書き戻し（write-back）の安全性において、セル選択には変更を確定する前にチェックできる監査可能なプログラムが存在しないことです。SQLであれば、少なくとも検査可能な成果物が得られます。
私の暫定的な結論としては、セル選択パラダイムは、1ヶ月分のトランザクションや単一の口座履歴といった、小規模な元帳スナップショットに対する自然言語の読み取り専用クエリレイヤーとしては適切なインターフェースです。元帳全体の推論や書き戻しを伴うものについては、プログラム合成アプローチ（SQLスタイルであれ、Beancount DSLであれ）の方が依然として安全で表現力に優れています。
次に読むべきもの
- TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — WikipediaのMLMを合成SQL実行に置き換えた直接の後継モデル。プログラムでの事前学習が、テーブルQAにおいてテキストでの事前学習に勝るかどうかを直接解明しています。
- Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — GPT-3を使用してテーブルに対してSQLやPythonでプログラムを生成し、WikiTQでSOTAを達成。セル選択派が向き合うべきハイブリッドアプローチです。
- OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — 自然なテーブルコーパスと合成SQLデータを単一の事前学習レシピに統合。TAPASとTAPEXが競合するのではなく、補完的であるかどうかをテストしています。
