TAPAS：无需 SQL 的弱监督表格问答及其对 Beancount 的意义

我一直在关注“文本转 SQL”的演进路径——如 BIRD、DIN-SQL、MAC-SQL 等——但所有这些研究都基于一个我想质疑的假设：即表格问答（Table QA）的正确接口是生成 SQL。由 Google Research 的 Herzig 等人发表的 TAPAS (ACL 2020) 则采取了截然相反的策略。它从不生成查询，而是通过选择单元格并视情况应用标量聚合，仅依靠答案指称（answer denotations）进行端到端训练。

论文解读

TAPAS 扩展了 BERT 以编码表格，在标准的位置 ID 和分段 ID 基础上增加了六个新的嵌入维度。列 ID（Column ID）和行 ID（Row ID）标记了每个标记（token）在表格网格中的位置。排名 ID（Rank ID）编码了可排序列中的相对数值顺序（0 表示不可比较，i+1 表示第 i 个最小值）。前序回答（Previous Answer）指示符标记了在之前的对话轮次中被选中的单元格。结合区分问题标记和表格标记的二进制分段嵌入，这构成了 TAPAS 的七类标记表示。

在推理时，模型通过对每个单元格的概率进行阈值处理来选择一组单元格，然后应用四种聚合操作之一——NONE（无）、COUNT（计数）、SUM（求和）或 AVERAGE（平均值）——来得出最终答案。这一过程不产生中间 SQL 或逻辑形式。预训练是在 620 万个英文维基百科“表格-文本”对上运行标准的掩码语言模型（MLM）目标。

核心观点

• 列/行嵌入至关重要。消融实验显示，移除它们会导致 SQA 的准确率下降 19.4 个百分点，WikiSQL 下降 10.6 个百分点，WikiTQ 下降 11.6 个百分点——这一影响远大于任何其他架构组件。
• 表格预训练同样重要。即使在微调后，移除预训练也会使 SQA 准确率下降 12.5 个百分点，WikiTQ 下降 11.1 个百分点。
• 在 SQA（对话式表格问答）上，TAPAS 将准确率从 55.1% 提升至 67.2%，实现了 12 个百分点的跨越。前序回答标记嵌入是使对话承接在无需独立状态追踪器的情况下得以实现的关键机制。
• 在 WikiSQL（单表，主要是查询和聚合）上，TAPAS 达到了 83.6%——在完全不生成 SQL 的情况下，基本追平了当时 83.9% 的最先进语义解析器（SOTA）。
• 迁移学习：从 WikiSQL 迁移到 WikiTQ（多步骤、多列推理）达到了 48.7%，比当时的 SOTA 高出 4.2 个百分点。SQA 迁移则达到了 48.8%。
• 弱监督是其核心成本优势：该模型基于（问题，答案）对进行训练，而非（问题，SQL，答案）三元组，因此无需 SQL 专家即可标注大规模语料库。

哪些依然有效，哪些已经过时

该研究的核心洞察——即许多表格问答可以通过选择单元格并应用四种标量运算之一来解决——在测试的基准测试中得到了经验验证。但作者对 WikiTQ 坦诚的错误分析颇具启发性：37% 的错误无法被作者分类，16% 需要模型无法完成的字符串操作，10% 涉及复杂的时间推理。这意味着 TAPAS 的上限不在于聚合算子的错误，而在于整类问题在结构上超出了其处理范围。

512 个标记（token）的限制是一道硬伤。拥有超过约 500 个单元格的表格必须被截断，且该模型没有多表推理机制。这不是一个微调问题，而是一个架构问题。模型也无法进行嵌套聚合：例如“有多少个账户的平均余额大于零？”这类问题需要两次传递（在 COUNT 谓词内部进行 AVERAGE 计算），这是四操作头无法表达的。

TAPEX (ICLR 2022) 通过将维基百科表格 MLM 替换为在自动生成的程序上执行合成 SQL，直接解决了预训练瓶颈，将 WikiTQ 提升至 57.5% (+4.8)，SQA 提升至 74.5% (+3.5)。这是一个显著的进步。但 TAPEX 继承了相同的关于表格大小和组合深度的架构限制。

两篇论文都没有解决的更深层问题是：从实际应用角度来看，单元格选择范式是否比 SQL 生成更适合现实世界的表格问答——这里考量的不是基准测试准确率，而是可审计性和正确性保证。选择单元格是不透明的：你得到了答案，但没有程序。SQL 生成虽然冗长，但是可验证的。对于生产环境，这种权衡比几个百分点的准确率提升更重要。

对金融人工智能的意义

Beancount 账本实际上是一个扁平的结构化表格：行是账户，列是金额、日期、货币和标签。TAPAS 的直接单元格选择范式自然地对应了最常见的账本查询——“3 月份在杂货上的支出总额是多少？”——这正是对过滤后的行进行 SUM 和 COUNT 聚合。前序回答嵌入对于用户细化查询的对话式场景（“那去年呢？”）非常有用。

但大规模的 Beancount 账本突破了 TAPAS 的限制。一个拥有数千条交易的多年期账本所占用的标记预算会高出 512 个数量级。账户层级结构需要跨行组的推理。像“哪些账户的净流出大于其过去三年的平均水平？”这样的查询需要嵌套聚合，而四操作头无法表达。关键的一点是：为了确保写回（write-back）安全，单元格选择无法提供可在提交更改前检查的可审计程序。SQL 至少提供了一个可检查的产物。

我的初步结论是：对于小型账本快照（一个月的交易、单个账户的历史记录）上的自然语言只读查询层，单元格选择范式是正确的接口。对于全账本推理以及任何涉及写回的操作，程序合成方法（无论是 SQL 风格还是 Beancount DSL）仍然更加安全且更具表达力。

延伸阅读

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) —— 直接后继者，将维基百科 MLM 替换为合成 SQL 执行；直接回答了在表格问答中，基于程序预训练是否优于基于文本预训练。
• 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 是否互补而非竞争。