跳转至

Same Content, Different Representations: A Controlled Study for Table QA

会议: ICLR 2026
arXiv: 2509.22983
代码: https://github.com/megagonlabs/RePairTQA
领域: NLP理解 / 表格问答
关键词: Table QA, 结构化表格, 半结构化表格, 表示形式, 诊断基准

一句话总结

首个控制变量研究：在保持表格内容完全相同的条件下变换表示形式（结构化 vs 半结构化），系统评估 NL2SQL、LLM、混合三类方法在不同表格大小/模式质量/查询复杂度下的鲁棒性，发现表示形式是影响 Table QA 性能的一阶因素。

研究背景与动机

  1. 领域现状：Table QA 方法主要分三个范式：NL2SQL（将自然语言转换为 SQL 执行）、LLM 直接推理、混合方法（SQL 检索 + LLM 推理）。现有基准数据集固定了表格格式，模型针对单一表示形式优化。

  2. 现有痛点：实际场景中表格既有严格 schema 的结构化形式，也有列不规则、单元格含自由文本的半结构化形式。但现有基准未系统研究"表示形式本身"对模型性能的影响，导致模型在跨格式场景下表现未知。

  3. 核心矛盾：要公平比较不同表示形式的影响，必须保证表格"内容完全相同"只改变"表示方式"。现有数据集无法满足这一条件，因为结构化和半结构化基准的底层数据本身就不同。

  4. 本文要解决什么？：(a) 如何在控制内容不变的条件下生成成对的结构化/半结构化表格？(b) 表格大小、连接操作、查询复杂度、模式质量各自如何影响不同范式？(c) 实际部署时如何选择最佳方法？

  5. 切入角度：通过 verbalization pipeline 将结构化表格中的列转化为自然语言描述，生成语义等价但结构不同的成对表格。

  6. 核心idea一句话：表示形式是 Table QA 的一阶变量——NL2SQL 在结构化输入上最强但半结构化下暴跌 30-45%，LLM 最鲁棒但精度有限，混合方法在半结构化场景最优。

方法详解

整体框架

输入为表格 + 自然语言问题，输出为答案。核心不是提出新的 QA 模型，而是构建诊断基准 RePairTQA：通过 verbalization pipeline 从现有结构化表格生成语义等价的半结构化版本，然后在四个维度（表格大小、连接操作、查询复杂度、模式质量）上划分诊断子集，系统评估三类方法。

关键设计

  1. Verbalization Pipeline（表格转换管线）:
  2. 做什么：将结构化表格转换为半结构化表格，保持语义不变
  3. 核心思路：三步流程——(1) 列选择：GPT-4o 选择适合 verbalize 的列，随机采样组合增加多样性；(2) 模板构造：针对选中的列组合生成自然语言模板，每组生成 5 个不同模板；(3) 序列化：将模板用实际值实例化，合并为一个自由文本列，删除原始结构化列

  4. 设计动机：语义保持是公平比较的前提。通过这种"保内容变形式"的方式，任何性能差异都可归因于表示形式本身

  5. 诊断子集划分（Diagnostic Splits）:

  6. 做什么：将基准数据集按四个维度切分为 7 个子集（S1-S5, M1-M2）
  7. 核心思路：从三个互补数据集构建——BIRD（干净 schema）、MMQA（多表推理）、TableEval（噪声 schema）。每个子集固定其他变量只变一个：S1 vs S4 比表格大小、S1 vs S2 比 schema 质量、S1 vs S3 比查询复杂度、S1-S5 vs M1-M2 比连接操作

  8. 设计动机：单独隔离每个因素的影响，避免混杂效应

  9. LLM-as-Judge 评估协议:

  10. 做什么：用 GPT-4o 替代传统的 Exact Match 评估
  11. 核心思路：让 GPT-4o 比较模型预测和金标准答案，判断语义是否正确，容忍表面形式差异（如不同数字格式、同义词替换）
  12. 设计动机：传统 EM/PM 对同义表述过于严格。人工标注 100 例验证显示 96% 一致率

损失函数 / 训练策略

本文不训练模型，而是评估现有方法。评估的方法包括： - LLM: GPT-4o, Gemini-2.5-flash, Qwen3-235B（直接推理） - NL2SQL: LLM-NL2SQL（两阶段管线）, XiYan（多生成器集成） - 混合: H-STAR（SQL+LLM 路由）, Weaver（逐步工作流）

实验关键数据

主实验（RQ1: 结构化 vs 半结构化总体对比）

模型 结构化准确率(%) 半结构化准确率(%) 下降(%)
GPT-4o 45.37 41.93 3.44
Gemini-2.5-flash 52.07 50.78 1.29
LLM-NL2SQL 69.14 38.65 30.49
XiYan 69.55 24.08 45.47
H-STAR 49.48 47.14 2.34
Weaver 62.19 57.70 4.49

消融实验（按维度分析）

因素 关键发现 影响最大的方法
表格大小 长表格导致所有方法下降，LLM 最敏感 GPT-4o: 70%→28.9%
连接操作 NL2SQL 在结构化多表上受益(+10%)，半结构化下崩溃 LLM-NL2SQL: 82.3%→多表结构化
查询复杂度 LLM 在 lookup 上~70%，组合推理下大幅下降 所有方法都受影响
Schema质量 噪声 schema 严重影响 NL2SQL，混合方法最鲁棒 XiYan: 结构化→半结构化暴跌

关键发现

  • 表示形式是一阶因素：NL2SQL 方法在半结构化下性能暴跌 30-45%，是最脆弱的范式
  • 没有万能方法：结构化用 NL2SQL，半结构化用混合方法，简单查询用 LLM
  • Verbalization 有时反而帮助 LLM：半结构化的自然语言描述更贴近 LLM 预训练数据，在 lookup 任务上混合方法甚至在半结构化下更好
  • 长表格是普遍难点：所有方法在长表格上都显著下降，但 NL2SQL 在长结构化表格上保持 62.9%
  • 模型规模不能解决表示敏感性：Gemini-2.5-Pro 也展现出相同的结构化 vs 半结构化差距

亮点与洞察

  • 控制变量的实验设计极为巧妙：保持信息内容完全相同只变表示形式，使所有性能差异都可归因于表示本身。这种方法论可迁移到其他模态（如知识图谱 vs 文档）的对比研究。
  • 决策树式方法选择指南非常实用：根据数据条件（结构化/半结构化 × 表格大小 × schema 质量 × 查询复杂度）给出最优方法推荐，直接指导实际部署。
  • 发现 verbalization 有时反而帮助 LLM 推理，挑战了"结构化一定更好"的直觉。

局限性 / 可改进方向

  • 仅覆盖三个基准数据集，领域多样性不足（缺少金融、生物医学等专业领域）
  • 表格大小限制在能放入上下文窗口内，未考虑需要分块或检索的超长表格
  • Verbalization 由 GPT-4o 生成模板，可能引入模型偏差
  • 未评估更多新兴方法（如基于 RAG 的表格问答系统）
  • Multi-table 场景下混合方法的支持有限，未来需设计更好的跨表推理模块

相关工作与启发

  • vs BIRD/Spider: 这些基准固定结构化格式，RePairTQA 通过 verbalization 增加半结构化维度，是首个控制变量基准
  • vs H-STAR/Weaver: 本文不是提出新方法，而是系统评估这些方法的表示鲁棒性
  • 对实际系统设计的启示：应根据数据条件自适应选择推理范式，而非使用单一方法

评分

  • 新颖性: ⭐⭐⭐⭐ 首个控制变量的表格表示研究，实验设计新颖
  • 实验充分度: ⭐⭐⭐⭐⭐ 7个诊断子集、7个模型、5个研究问题，分析极为系统
  • 写作质量: ⭐⭐⭐⭐ 结构清晰，图表丰富，决策树总结实用
  • 价值: ⭐⭐⭐⭐ 对 Table QA 方法选择有重要指导意义