RePanda: Pandas-powered Tabular Verification and Reasoning

生成日:

RePanda: Pandas-powered Tabular Verification and Reasoning

Abstract(日本語訳)

表形式データのファクトチェックは、構造化された情報の正確性を確保するうえで重要である。しかし、既存手法はしばしば、推論過程が不透明なブラックボックスモデルに依存している。本論文では RePanda を提案する。これは、主張を実行可能な pandas クエリに変換する構造化された事実検証手法であり、解釈可能で検証可能な推論を可能にする。RePanda を学習するために、著者らは TabFact の訓練セットから PanTabFact を構築する。PanTabFact は、主張と、DeepSeek-Chat を用いて生成され自動エラー修正で精緻化された実行可能クエリを対応づけた構造化データセットである。DeepSeek-coder-7B-instruct-v1.5 を PanTabFact でファインチューニングした RePanda は、TabFact テストセットで 84.09% の accuracy を達成した。分布外(Out-of-Distribution; OOD)汎化を評価するため、著者らは WikiTableQuestions の質問応答ペアを事実主張として解釈し、このデータセットを WikiFact と呼ぶ。追加のファインチューニングなしに、RePanda は WikiFact で 84.72% の accuracy を達成し、他のすべてのベースラインを大きく上回って、強い OOD 頑健性を示した。特に、これらの結果は DeepSeek-Chat(671B)の zero-shot 性能に近く、本手法のファインチューニングが、はるかに大きなモデルの構造化推論を、ローカルで実行可能な小型の 7B モデルへ有効に蒸留していることを示している。PanTabFact は HuggingFace の datasets/AtoosaChegini/PanTabFact で公開されている。事実検証に加えて、RePanda は、正確な答えを取り出す実行可能クエリを生成することで、表形式データに対する質問応答にも拡張される。これを支えるため、著者らは WikiTableQuestions を pandas クエリに対応づけるデータセット PanWiki を導入する。PanWiki でファインチューニングした RePanda は、直接的な回答抽出で 75.1% の accuracy を達成した。これらの結果は、構造化された実行ベースの推論が、表形式データの検証と質問応答に有効であることを示している。

論文の面白いところ

この論文の要点は、表を読むモデルに「答え」を直接言わせるのではなく、「答えを得るための pandas 式」を書かせる点にある。通常の分類器なら、表と主張を入力して entailed か refuted かを返すだけで、どの行や列をどう見たのかは見えにくい。RePanda では、たとえば特定の venue に対応する home team を抽出し、その値が主張と一致するかを .eq(...).any() のような式で確かめる。推論の結果だけでなく、推論の手順が Python の式として残るため、誤りの調査や監査に使いやすい。

興味深いのは、この方針が単なる説明用の飾りではなく、accuracy にも効いている点である。TabFact では、同じ 7B モデルを直接分類にファインチューニングした場合の 67.85% に対し、pandas クエリを生成する RePanda は 84.09% に達している。分布外の WikiFact でも 84.72% で、直接分類の 74.10% を上回る。表形式データでは、自然文の意味だけでなく、行の選択、列の比較、集計といった操作が必要になる。pandas という既存の実行基盤に落とすことで、その操作をモデル内部の暗黙の表現に閉じ込めずに済む、という設計がわかりやすい。

問題設定

対象となる問題は、表形式データに基づく事実検証である。入力は、表 T と自然文の主張 s であり、出力はその主張が表から支持されるか、反証されるかである。たとえば、スポーツの試合結果表に対して「Lake Oval で試合をした home team は North Melbourne である」という主張が与えられる。この場合、モデルは venue 列から Lake Oval の行を探し、対応する home team が North Melbourne かどうかを確認しなければならない。

既存の表理解モデルでは、表をトークン列へ平坦化して Transformer に読ませる手法がよく用いられる。TAPAS や TAPEX はその代表であり、表を扱うための事前学習を導入している。しかし、複数行にまたがる比較、集計、条件付きの抽出では、表の構造そのものを失うと判断が難しくなる。さらに、分類結果だけを返す方式では、どの操作が失敗したのかを後から確認しにくい。法務、金融監査、報道でのファクトチェックのように、結果の根拠を点検したい場面では、この点が実用上の制約になる。

提案手法

RePanda は、自然文の主張を実行可能な pandas クエリ q_s に変換し、その実行結果によって真偽を判定する。形式的には、言語モデル f_θ が表と主張を受け取り、q_s = f_θ(s, T) を生成する。クエリは DataFrame df に対する一行の pandas 式であり、事実検証では True または False を返すように作られる。質問応答に用いる場合は、Boolean ではなく、表から該当する答えを抽出する式を生成する。

学習データとして、著者らは TabFact から PanTabFact を構築した。TabFact には表、主張、真偽ラベルがあるが、明示的な推論手順はない。そこで DeepSeek-Chat を用いて各主張に対応する pandas クエリを生成し、論理修正、構文修正、フィルタリングを通じて、実行可能でラベルと一致するクエリを残す。最終的に TabFact の 95.68% にあたる 88,299 件の有効クエリが得られている。

モデル本体には DeepSeek-coder-7B-instruct-v1.5 を用い、PanTabFact で autoregressive にファインチューニングする。推論時には、生成された pandas 式を実行して判定を得る。式が構文エラーや実行時エラーを起こした場合には、エラーメッセージをモデルへ戻し、最大 4 回まで構文修正を試みる。質問応答用には、WikiTableQuestions から 1,200 件の PanWiki を作り、質問を答え抽出用の pandas クエリへ変換するように学習させている。

結果

TabFact テストセットで、RePanda は 84.09% の accuracy を得た。同じ DeepSeek-coder-7B-instruct-v1.5 を直接分類器としてファインチューニングした Finetuned-Direct は 67.85% であり、pandas クエリを介した方式との差は 16.24 ポイントである。zero-shot の直接分類は 50.76%、zero-shot の pandas 生成は 51.82% にとどまるため、クエリ形式の学習データを作ってファインチューニングすることが重要であることも示されている。

分布外評価として、WikiTableQuestions の質問応答ペアを事実主張へ変換した WikiFact でも評価している。PanTabFact だけで学習した RePanda は、追加のファインチューニングなしに 84.72% を達成した。300 件の真の主張と、それを改変して作った 300 件の偽の主張からなる均衡データでは、全体で 87.00% であった。TAPEX は 50.16%、TAPAS は 60.16%、PASTA は 49.67% であり、この設定では RePanda が大きく上回る。

表に対する質問応答では、PanWiki の 1,200 件だけでファインチューニングした RePanda が WikiTableQuestions で 75.1% を得た。TabLaP の 76.6% には届かないが、SynTQA(GPT)の 74.4% や Mix SC の 73.6% と同程度である。訓練例の少なさを考えると、pandas クエリを生成して実行する設計は、事実検証だけでなく回答抽出にも使えると見てよい。エラー修正の ablation では、TabFact が 78.02% から 84.09%、WikiFact が 74.43% から 84.72%、WikiTableQuestions が 67.59% から 75.1% に上がっており、実行可能性を保つ仕組みが性能に強く関わっている。

具体例

ある表に、1952 年の VFL シーズンの試合結果が並んでいるとする。列には home team、away team、venue、crowd などがあり、Lake Oval の行では home team が south melbourne になっている。ここで入力の主張が「Lake Oval で試合をした home team は North Melbourne である」なら、RePanda は表を眺めて直接 False と言うのではなく、df[df['venue'] == 'lake oval']['home team'].eq('north melbourne').any() のような pandas 式を生成する。この式は、まず venue が lake oval の行だけを取り出し、その home team が north melbourne と一致するかを調べ、該当行があれば True を返す。

期待される出力は False である。なぜなら、該当する行の home team は south melbourne であり、north melbourne ではないからである。この例で間違えやすいのは、表の別の行に north melbourne が出てくるため、単語の出現だけを見てしまう場合である。また、大文字小文字や表記揺れを正しく処理しないと、実際には一致する値を見落とすこともある。RePanda の利点は、誤答した場合でも、生成された pandas 式を見れば、venue の条件を間違えたのか、home team ではなく away team を見たのか、あるいは .any() のような集約を誤ったのかを追える点にある。

制約

本論文の評価は、基本的に 1 件の入力が 1 つの表を持つ設定に限られている。複数の表をまたぐ結合、階層構造を持つ表、外部テキストと表を組み合わせる推論は扱っていない。そのため、実務でよくあるリレーショナルデータベースや複数スプレッドシートを横断する監査へ、そのまま適用できるかは未確認である。また、pandas 式を実行する設計は検証可能性を高める一方で、実行環境の安全性や、生成コードのサンドボックス化も必要になる。

それでも、この論文は表理解を「分類」から「実行できる手続きの生成」へ寄せることで、性能と説明可能性を同時に扱っている。表に対する LLM 応用では、自然文で理由を説明させるより、実際に動くクエリを出させた方が検証しやすい場合がある。RePanda は、その方針を pandas という実務で広く使われる道具に接続して示した研究である。