Large language model for table processing: a survey
| 項目 | 内容 |
|---|---|
| 論文ID | P05 |
| 区分・分類 | 論文・枠組み・サーベイ |
| 著者・所属 | Weizheng Lu, Jing Zhang, Ju Fan, Zihao Fu, Yueguo Chen, Xiaoyong Du（School of Information, Renmin University of China / Key Laboratory of Data Engineering and Knowledge Engineering / WPS Office, Kingsoft Co.） |
| 発表先 | Frontiers of Computer Science |
| 発表日 | 2025-01-12 |
| 引用数 | 51（OpenAlex 2026-10-06時点） |
| 言語 | 英語 |
| URL | https://doi.org/10.1007/s11704-024-40763-6 |
| 論文/pdf/P05.pdf | |
| 読んだ範囲 | 全文 |
論文タイプ
サーベイ。LLM/VLM による表処理の研究を「表の種類とタスク」「表データ表現」「表の学習」「表のプロンプティング」の4分類で整理したレビュー論文。
研究の目標
表（スプレッドシート・Web表・DB・文書内の表）に関わる作業を LLM/VLM で自動化する研究の全体像と方向性を示すこと。表は LLM の事前学習に使う平文と構造が違うため、次の3点が難しいとする。
| 難しさ | 内容 |
|---|---|
| 構造化データ | 行・列・スキーマを持つ2次元構造。逐次テキストで学習した LLM は多次元の理解が苦手 |
| 複雑な推論 | 比較・集計などの数値演算、列型注釈・欠損検出などのデータ準備、特徴量設計・可視化などの分析 |
| 外部ツール | 人は Excel・Python・SQL で表を扱う。LLM もこれらを統合して使う必要がある |
既存サーベイ（Dong et al., Badaro et al.）が BERT/BART 系の小型モデルの事前学習・ファインチューニングに偏るのに対し、プロンプティング・エージェント型の手法と、新しいスプレッドシート操作・データ分析タスクまで扱う点を貢献とする。
技術的なやり方
表の種類とタスク
| 種類 | 特徴 | AI の使われ方 |
|---|---|---|
| Spreadsheet (SS) | 世界人口の1/10が利用。結合セル・階層列・注釈など不規則なレイアウト | 操作の自動化（copilot） |
| Web table (WT) | HTML/markdown/JSON/XML。ページタイトル等の文脈を持つ | Table QA |
| Database (DB) | 作成時にスキーマが明示。SQL で操作 | NL2SQL |
| Document (DOC) | 画像・PDF・Word 内の表。位置特定と抽出が必要 | 検出・構造化・表形式への変換 |
表タスクは12種（Table QA、Table fact verification、Table-to-text、Data cleaning、Column/Row/Cell population、Entity linking、Column type annotation、Spreadsheet manipulation、NL2SQL、Data analysis、Table detection、Table extraction）。代表データセットは WikiTableQuestion、TabFact、ToTTo、TURL、SpreadsheetBench、Spider、DS-1000、TableBank、PubTabNet。
エンドユーザー視点では、表データのライフサイクルを Data Entry → Data Cleaning → Data CRUD → Data Analysis → Data Visualization の5段階、AI との関わり方を Beside（アプリ横の copilot）・Inside（AI が製品の中核）・Outside（AI が複数アプリを横断）の3型に分ける。
表データ表現
| 対象 | 内容 |
|---|---|
| テキスト（内容） | markdown への線形化が一般的。CSV/markdown/JSON/HTML/pandas DataFrame の比較では HTML と区切り記号付き NL（markdown・CSV）が最も有効。結合セル・階層列には SpreadsheetLLM のアンカー方式＋転置インデックス風 JSON |
| テキスト（スキーマ） | NL2SQL では CREATE TABLE 文で表現。外部キー情報と「with no explanation」の指示が有効 |
| 視覚・レイアウト | 画像形式の表が VLM の複雑推論を助けるとの報告（Deng et al.）。LayoutLM は OCR/PDF パーサで前処理、Table-LLaVA は HTML 表を画像化して学習データを増強。視覚埋め込みは ResNet または ViT、レイアウト埋め込みは座標を [0,1000] に正規化 |
表の学習
| 区分 | 手法 | 例 |
|---|---|---|
| Pre-LLM（10億パラメータ未満） | モデル構造・エンコード・学習目的の改変 | TaPas、TaBERT、TURL、TABBIE、TaPEx、RESDSQL、LayoutLM |
| Table tuning | 既存の表データセットを (Instruction, Table, Output) 形式にして指示調整 | TableLlama（11タスク14データセット）、Table-GPT（18種の合成プロセス＋3レベル増強） |
| Code tuning | SQL/Python を生成するコード LLM | WizardCoder（Evol-Instruct）、Magicoder（OSS-Instruct）、Lemur（コード:テキスト=10:1）、DAAgent、SENSE（strong/weak data を DPO で学習）、FinSQL |
| Hybrid | コード LLM を表データセットで調整。基盤はコード LLM が最良 | TableLLM、StructLM |
| Continue pre-training | 小型 LLM に SQL・NL・NL-to-code データを追加学習 | CodeS |
| SLMs + LLMs | SLM が SQL スケッチを生成し LLM が補完・修正 | ZeroNL2SQL |
| Table VLM | 視覚エンコーダの事前学習（LLM 凍結）→ 全体の指示調整の2段階 | TableVLM、Table-LLaVA、TabPedia、PixT3 |
表のプロンプティング
LLM エージェント（記憶・計画・行動モジュール）の共通ワークフローを示し、計画を A_t = P(A_t | I, S_t, Q, H_{t-1})（I: 指示、S_t: 表の状態、Q: クエリ、H: 履歴）と定式化。
| モジュール | 技術 | 例 |
|---|---|---|
| 計画：分解 | CoT・least-to-most に倣い複雑タスクを分割 | DIN-SQL、DEA-SQL、TabSQLify、Dater |
| 計画：反省と修正 | self-consistency・投票、過去行動の見直し | DAIL-SQL、MCS-SQL、ReAcTable、SheetCopilot、SheetAgent、SelfEvolve |
| 行動：Table QA・NL2SQL | Python/SQL で表と対話 | Binder、ReAcTable（SQL 生成・Python 生成・直接回答） |
| 行動：SS 操作・分析 | API を原子的行動として定義 | SheetCopilot（VBA API）、SheetAgent（Python/SQL が VBA より適すると判断）、Data-Copilot |
| 行動：複数タスク | データとスキーマを探索してから行動を計画 | StructGPT、UniDM、TAP4LLM、ChatPipe |
| その他 | few-shot 例の選択（類似性＋多様性）、ロールプレイ | DAIL-SQL、Tapilot-Crossing |
リソース
新しいベンチマークを「頑健性（RobuT、Dr.Spider）」「人手ラベル（DS-1000、InfiAgent-DABench、Tapilot-Crossing。BIRD は gold SQL の誤りとノイズがあり、修正後は DIN-SQL が zero-shot より劣る場合があると報告）」「実世界ワークロード（ScienceBenchmark、SpreadsheetBench）」「大規模（AnaMeta、GitTables、SchemaPile、ComplexTable）」で整理。OSS は LlamaIndex、DB-GPT、Vanna、PandasAI、RetClean。
結果
他論文の数値を集めた比較（Table 3。数値は各論文からの引用）。
| 種類 | 手法 | パラメータ | 学習トークン | WikiTQ | FeTaQA | WikiSQL | Spider | 平均推論回数 |
|---|---|---|---|---|---|---|---|---|
| SLM training | TaPEX | 0.14B | − | 38.55 | − | 83.90 | 15.04 | 1 |
| SLM training | TaPas | 0.11B | − | 31.60 | − | 74.20 | 23.05 | 1 |
| LLM training | TableLlama | 7B | 3.3B | 48.82 | 67.73 | 43.70 | − | 1 |
| LLM training | TableLLM | 13B | 1.1B | 62.40 | 74.50 | 90.70 | 83.40 | 1 |
| Prompting | CodeLlama | 13B | − | 43.44 | 57.24 | 38.30 | 21.88 | 1 |
| Prompting | GPT-3.5 | − | − | 58.45 | 71.18 | 81.70 | 67.38 | 1 |
| Prompting | GPT-4 | − | − | 74.09 | 78.35 | 84.00 | 69.53 | 1 |
| Prompting agent | StructGPT(GPT-3.5) | − | − | 52.45 | 11.80 | 67.80 | 84.80 | 3 |
| Prompting agent | Binder(GPT-3.5) | − | − | 61.61 | 12.77 | 78.60 | 52.55 | 50 |
| Prompting agent | DATER(GPT-3.5) | − | − | 53.40 | 18.26 | 58.20 | 26.52 | 100 |
著者の考察：
| 観点 | 学習ベース | プロンプティング／エージェント |
|---|---|---|
| 利点 | private に学習・展開でき第三者へのデータ漏洩がない | 強い LLM（GPT）のプロンプティングが多くのタスクで最良 |
| コスト | 7B のファインチューニングに通常 80GB GPU×8。7B を float16 でロードするだけで最低 14GB | LLM を繰り返し呼ぶ（平均推論回数 3〜100）。ReAct＋実行フィードバックは時間がかかる |
| 精度 | 4ベンチマーク中、LLM 学習が勝るのは1つのみで GPT-4 が優る。7B の TableLlama はタスク特化モデルに勝てない。NL2SQL では LLM と SLM に明確な勝者なし。データ分析では Lemur・DAAgent は GPT-4 を超えない。Table-GPT は GPT-3.5/ChatGPT を全表タスクで上回る | ハードコードされたプロンプトテンプレートに依存し転移性が低い |
| その他 | 人手注釈は高コスト、合成は品質が懸念。GPT を教師にした蒸留が主流で GPT が性能の上限 | 第三者サービスへのプライバシー問題。表構造の理解は弱く、TIS ベンチマークでは多くの LLM が約50%（ほぼランダム）、GPT-4 で 66.1% |
限界・課題
| 課題 | 内容 |
|---|---|
| 多様なユーザー入力 | 実運用ではクエリが曖昧（「この表を分析して」、表と無関係な質問）。表のスキーマ・内容は独自で、既存学習データは Web の単純な表か LLM 合成に偏る。実ビジネスを網羅する学習データの構築が高コスト。ドメイン特化データを安価に合成する方法が研究方向 |
| 遅く深い思考 | OpenAI o1 のような長い内部 CoT で性能が上がる。学習では正確な CoT の取得が難しく（人手は高コスト、自動生成は精度保証が困難）、プロンプティングでは各研究のハードコードされた CoT ワークフローの転移性が弱い。推論回数と精度のバランスが課題 |
要点
LLM/VLM による表処理の研究を、表の4形式・12タスク・データ表現・学習・プロンプティング（エージェントの計画と行動）の軸で整理した包括サーベイ。 4ベンチマークの比較で GPT-4 のプロンプティングが多くで最良、学習ベースは private 展開できるがコストが高いと整理。 課題は実運用の曖昧な入力・独自スキーマへの対応と、CoT による「遅い思考」の低コスト化。