TableRAG论文阅读: A Retrieval Augmented Generation Framework for Heterogeneous Document Reasoning

北京地铁1号线

777人浏览 · 2026-01-09 18:59:23

北京地铁1号线 · 2026-01-09 18:59:23 发布

Abstract

检索增强生成（RAG）在开放域问答中已展现出显著成效。然而，当应用于包含文本和表格组件的异构文档时，现有的RAG方法表现出关键的局限性。主流的将表格扁平化和分块策略破坏了其固有的表格结构，导致信息丢失，并损害了大型语言模型在多跳、全局查询中的推理能力。为应对这些挑战，我们提出了TableRAG，这是一个基于SQL的框架，它统一了对表格数据的文本理解和复杂操作。TableRAG迭代执行四个步骤：上下文敏感的查询分解、文本检索、SQL编程与执行以及组合式中间答案生成。我们还开发了HeteQA，一个旨在评估多跳异构推理能力的新基准。实验结果表明，TableRAG在公开数据集和我们的HeteQA上始终优于现有基线，为异构文档问答建立了新的最先进水平。

1 Introduction

基于异构文档的问答，需要对非结构化文本和结构化表格数据进行推理，带来了巨大的挑战。表格的特点是行列相互依赖，而自然语言文本是顺序性的。在一个统一的问答系统中弥合这种差异仍然是一项不简单的任务。

主流方法扩展了检索增强生成范式，其中表格被线性化为文本表示。通常，会采用分块策略，将扁平化的表格分割并与相邻的文本片段合并。在推理过程中，大型语言模型基于检索到的前N个分块生成答案。然而，这些方法主要适用于仅需对表格进行表面理解（如直接答案提取）的场景。当应用于交织着文本和表格元素的大篇幅文档时，现有的RAG方法表现出关键的局限性：

结构信息损失：表格结构完整性被破坏，导致信息丢失或引入无关上下文，从而阻碍了下游大型语言模型的性能。
缺乏全局视图：由于文档碎片化，RAG系统难以处理多跳全局查询，例如聚合、数学计算以及其他需要对整个表格有整体理解才能完成的推理任务。

图1展示了基于异构文档的问答任务的一个例子。如图所示，RAG方法在前N个最相关分块上计算百分比，而不是在整个表格上计算，因此导致了错误答案。

图1：异构文档问答任务示例

为了解决现有RAG系统的这些局限性，我们提出了TableRAG，一个基于SQL的框架，能够在文本理解和复杂表格数据操作之间动态转换。TableRAG通过将SQL作为接口来与表格交互。具体来说，该框架通过两阶段流程运行：离线数据库构建阶段和在线的迭代推理阶段。迭代推理过程包含四个核心操作：基于上下文的查询分解、文本检索、SQL编程与执行以及中间答案生成。SQL的使用使得通过将表格相关查询视为不可分割的推理单元来实现精确的符号执行，从而提高了计算效率和推理保真度。为了便于对异构文档上的多跳推理进行严格评估，我们引入了HeteQA，这是一个新颖的基准，包含九个不同领域的304个示例。每个示例都包含跨五种不同表格操作的组合。我们在已建立的公开基准和我们的HeteQA数据集上评估TableRAG，并与强大的基线（包括通用RAG和程序辅助方法）进行比较。实验结果表明，TableRAG始终达到了最先进的性能。总的来说，我们的贡献总结如下：

我们指出了现有RAG方法在异构文档问答背景下的两个关键局限性：结构信息损失和缺乏全局视图。
我们提出了TableRAG，一个基于SQL的框架，它统一了对表格数据的文本理解和复杂操作。TableRAG包含离线数据库构建阶段和一个四步在线的迭代推理过程。
我们开发了HeteQA，一个用于评估多跳异构推理能力的基准。实验结果表明，TableRAG在HeteQA和公开基准上优于RAG和程序化方法，确立了一个最先进的解决方案。

2 Task Formulation

在异构文档问答任务的背景下，我们将任务输入定义为大篇幅文档，表示为 $(\mathcal{T},\mathcal{D})$ ，其中 $\mathcal{T}$ 表示文本内容， $\mathcal{D}$ 指表格组件。给定一个用户问题 q，本任务的目标是优化一个函数 $\mathcal{F}$ ，该函数在给定组合的文本和表格上下文的情况下，能够产生正确答案 $\mathcal{A}$ ：

$\mathcal{F}(\mathcal{D},\mathcal{T},q)\rightarrow\mathcal{A}$

3 TableRAG Framework

3.1 概述与设计原则

我们提出了 TableRAG，一个旨在保持表格结构完整性并促进异构推理的基于 SQL 的框架。如图 2 所示，TableRAG 由离线和在线工作流程组成。离线阶段负责数据库构建，而在线阶段则促进迭代推理。推理过程分为四个阶段展开：基于上下文的查询分解，以识别查询中文本和表格模态各自的角色；文本检索；SQL 编程与执行，此操作仅为需要表格数据推理的子查询选择性地调用；以及组合式中间答案生成。优先使用 SQL 的动机在于它能够利用符号化执行在结构化数据上的表达优势，从而使用户查询中的表格组件能够被视为整体的推理单元。相比之下，其他语言（如 Python）在处理大规模数据或复杂工作负载时会带来巨大的计算开销。

图2：TableRAG的整体架构

3.2 数据库构建

在离线阶段，我们首先从异构文档中提取结构化组件，得到一组表格 $\mathcal{D}=\{\mathcal{D}_{1},\ldots,\mathcal{D}_{M}\}$ 。为了实现信息检索，我们构建了两个平行语料库：一个文本知识库和一个表格模式数据库。文本知识库包含原始文本 $\mathcal{T}$ 以及每个表格的 Markdown 呈现形式，记为 $\tilde{\mathcal{D}}$ 。 $\tilde{\mathcal{D}}$ 和 $\mathcal{T}$ 都被分割成块，然后使用预训练的语言模型嵌入到密集向量表示中。对于表格模式数据库的构建，我们通过以下模板为每个表格 $\mathcal{D}_i$ 生成一个标准化的模式描述 $S(\mathcal{D}_i)$ 来表示它：

表格模式模板

{
        "table_name": "<表格名>",
        "columns": [
                ["<列名>", "<类型>", "<示例>"],
        ...
        ]
}

接着，我们定义一个从每个扁平化的表格块到其原始表格模式的映射：

$f : \hat{\mathcal{D}}_{i,j} \rightarrow S(\mathcal{D}_i)$

其中 $\hat{\mathcal{D}}_{i,j}$ 表示从表格 $\hat{\mathcal{D}}_i$ 导出的第 j 个块。此映射确保局部片段在上下文中仍锚定于其来源的表格结构。这些表格也被摄入到关系型数据库（如 MySQL）中，以支持后续在线推理中的符号化查询执行。

3.3 迭代推理

为解决需要对文本和表格进行组合推理的多跳全局查询，我们引入了一个与公式（1）中 $\mathcal{F}$ 相一致的迭代推理过程。该过程包含四个核心操作：基于上下文的查询分解、文本检索、程序与SQL执行以及组合式中间答案生成。通过重复的分解与解决循环，逐步构建出查询的解决方案。详细的提示模板见附录G。

基于上下文的查询分解 我们在推理过程中明确划分文本和表格模态的各自角色。虽然一个与表格相关的查询可能涉及多个语义推理步骤，但其表格解决方案可以坍缩为单个可执行操作。因此，对全局查询的有效分解不仅需要语法上的分割，还需要对底层数据源的结构性认知。为此，我们首先从文本数据库中检索出最相关的表格内容，并通过映射函数 f 将其链接到相应的表格模式描述 $S(\mathcal{D}^{t})$ 。基于此，我们在第 t 次迭代中构建一个子查询 $q_{t}$ 。

文本检索 我们部署了一个检索模块，该模块在两个连续阶段运行：基于向量的召回，随后是语义重排。给定一个输入查询 $q_{t}$ ，将其与文档块一起编码到一个共享的密集嵌入空间。然后，我们选择与查询嵌入具有最高余弦相似度的前 N 个候选：

$\hat{\mathcal{T}}^{q_{t}}_{recall}=\text{top-}N\left(\arg\max_{\hat{\mathcal{T}}_{i}\in\{\hat{\mathcal{D}},\mathcal{T}\}}cos(\mathbf{v}_{\hat{\mathcal{T}}_{i}},\mathbf{v}_{q_{t}})\right)$

在随后的重排阶段，召回到的候选块会通过一个更具表达力的相关性模型重新评估，产生最终的前 k 个选择，记为 $\hat{\mathcal{T}}^{q_{t}}_{rerank}$ 。

SQL编程与执行 为了支持对表格数据的精确推理，我们引入了一种“编程-执行”机制，该机制仅在子查询推理涉及表格时被选择性地调用。具体来说，我们检查检索结果中是否有任何内容源自表格来源。对于排名靠前的集合 $\hat{\mathcal{T}}^{q_{t}}_{rerank}$ 中的每个块，我们应用映射函数（公式2）提取其关联的模式，得到一个表格模式集合：

$S^{t}=\{f(\hat{\mathcal{T}}_{i}) \mid \hat{\mathcal{T}}_{i}\in\hat{\mathcal{T}}^{q_{t}}_{rerank}\}$

如果集合 $S^{t}$ 为空，则跳过此模块。否则，我们以当前子查询 $q_{t}$ 和相应的模式上下文作为输入来推导精确答案。为实现这一点，我们利用关系型数据的结构化查询执行能力，并使用 SQL 作为中间形式语言。一个以 LLM 为后端的专用工具 $f_{SQL}$ 生成可执行的 SQL 程序，并将其应用于预构建的 MySQL 数据库，形式化如下：

$e_{t}=f_{SQL}(S^{t},q_{t})$

中间答案生成 对于子查询 $q_{t}$ ，TableRAG 可以从两个异构信息源中获益：来自 SQL 数据库的执行结果 $e_{t}$ ，以及来自文档数据库的文本检索结果 $\hat{\mathcal{T}}^{q_{t}}_{rerank}$ 。这两个数据源都提供了部分或完整的证据。它们引入了不同的失败模式：SQL 执行可能产生错误结果或执行错误，而文本检索可能产生不完整或误导性的上下文。因此，来自这些来源的结果可能相互印证，也可能相互矛盾。为解决此问题，我们采用了一种组合式推理机制。对执行结果 $e_{t}$ 和检索到的文本块 $\hat{\mathcal{T}}^{q_{t}}_{rerank}$ 进行交叉验证，以确认一致性并指导答案选择。每个子查询的最终答案通过根据每个来源的证据效用自适应地加权其可靠性来得出，即 $a_{t}=\mathcal{F}(e_{t},\hat{\mathcal{T}}^{q_{t}}_{rerank})$ 。

一旦查询分解模块确定不再需要进一步的子查询，TableRAG 就终止迭代推理过程，产生最终答案 $\mathcal{A}=a_{T}$ ，其中 T 表示执行的总迭代次数。

4 Benchmark Construction

在本节中，我们介绍HeteQA，一个用于评估跨异构文档的多跳推理能力的新基准。

4.1 数据收集

HeteQA需要高级操作，例如算术计算、嵌套逻辑等。为了在标注保真度和可扩展性之间取得平衡，我们采用了一种人在回路协作策略，将大型语言模型与人工验证相结合。构建流程分为三个阶段：

查询生成 我们从Wikipedia数据集中整理表格来源。为了便于深入分析，我们将选择范围限制在至少有20行和7列的表格，并应用结构去重以消除相似模式间的冗余。对于每个保留的表格，我们定义了一套高级操作，例如条件过滤和统计聚合。这些操作作为构建复杂查询的基础单元。利用Claude-3.7-sonnet模型，我们提示其基于这些基础单元组合生成查询。每个生成的查询都配以SQL和Python的可执行代码。我们执行相关代码并获得答案。最后对查询和答案进行去重处理，以提升数据集的多样性。完整的实现细节见附录A。

答案验证 为了确保正确性和可靠性，每个实例都经过人工标注者的手动检查。他们的任务是验证执行结果对于相应的查询是否准确。如果发现差异，他们负责修正底层代码和最终答案。

文档参考 为了支持整合表格和文本信息的查询，我们利用相关的Wikipedia文档来增强实例。具体来说，人工标注者会替换查询中的某些实体为基于参考的表述。例如，查询"Which driver ..."可以改述为"What is the nationality of the driver ..."。这种实体替换可以改变问题的主题及其相应答案，或者在保持原始答案不变的情况下改变查询措辞。标注指南和标注者概况详见附录B。

4.2 讨论

HeteQA中的每个数据实例由一个查询、其对应的答案、可执行的SQL语句以及执行得到的答案组成。通过我们的数据收集流程，我们构建了304个高质量示例，其答案基于单源数据和多源数据。所得基准覆盖了136个不同的表格和5314个维基知识实体。为了描述数据集的特征，我们分析了其语义领域和表格推理操作的类型。如图3所示，HeteQA涵盖了9个语义多样的领域，并包含5个主要的表格操作类别。总之，HeteQA构成了一个结构多样、语义广泛的资源，用于推进异构文档上的问答研究。

图3：HeteQA的领域分布和表格操作分布。

5 Experiments

5.1 实验设置

5.1.1 数据集

我们在 HeteQA 以及涵盖两种设置的多个已建立基准上评估 TableRAG 的性能：

HybridQA（Chen 等人，2020 年）一个涉及表格和文本信息的多跳问答数据集。在我们的评估中，我们仅保留表格包含超过 100 个单元格的数据案例。

WikiTableQuestion（Pasupat 和 Liang，2015 年）一个跨不同领域的表格问答数据集。其查询需要一系列数据操作，包括比较、聚合等。

5.1.2 实施细节

在文本检索过程中，我们使用 BGE-M3 系列模型（Chen 等人，2024a,b）。在召回阶段，我们保留前 30 个候选，随后通过重排序从中选择前 3 个。为处理大量输入，文本被分块为 1000 个 token 的片段，连续片段之间有 200 个 token 的重叠。迭代循环最多进行 5 次迭代。对于骨干大语言模型，我们使用 Claude-3.5-Sonnet 作为代表性闭源大语言模型，而 Deepseek-V3、Deepseek-R1（Guo 等人，2025 年）和 Qwen-2.5-72B（Yang 等人，2024 年）则作为开源对应模型。在线迭代推理过程中的所有模块均保持使用一致的后端模型。我们使用准确率作为评估指标，由 Qwen-2.5-72B 进行评估，该模型给出 0 或 1 的二元评分。提示词见附录 G，使用精确匹配指标评估的结果见附录 D。

5.1.3 基线方法

我们通过将 TableRAG 与三种不同的基线方法进行基准测试来评估其性能：（1）使用大语言模型直接生成答案。（2）NaiveRAG，该方法将表格数据处理为线性化的 Markdown 格式文本，随后应用标准的 RAG 流程。（3）ReAct（Yao 等人，2023 年），一种基于提示的范式，旨在协同大语言模型的推理、行动与外部知识源。（4）TableGPT2（Su 等人，2024 年）采用基于 Python 的执行模块，在模拟环境中生成代码（例如 Pandas）来推导答案。这些基线方法的详细实施细节见附录 C，额外的基线比较见附录 D。

5.2 主要结果

表1：TableRAG与多个基线模型在跨基准测试中的性能对比，通过大语言模型作为评判器的准确性进行评估。“多源”指需要同时使用表格与文本信息的问题，“单源”指仅依赖单一类型信息源的问题。

表 1 展示了基于不同 LLM 骨干模型的主要结果。我们得出几个关键观察：（1）ReAct 框架在多源数据上显示出相较于朴素 RAG 的优势，但在需要表格推理的单源数据上表现下降。这归因于多轮推理过程中的上下文不敏感性。本可以通过单个 SQL 执行解决的查询被分解为多个子查询。这种过度碎片化可能会在执行过程中引入错误或不完整信息（尤其是在涉及筛选、聚合等操作时），可能导致级联失败。（2）TableGPT2 仅在单源查询（如 WikiTQ）上产生可接受的结果，突显了其处理多源查询能力的有限性。这反映了其在异构信息环境中缺乏泛化能力。（3）TableRAG 超越了所有基线，相较于最强替代方案实现了至少 10% 的性能提升。值得注意的是，它在单源和多源数据上均表现出鲁棒的性能。这一性能提升归因于符号推理的引入，使其能够有效适应异构文档。此外，在不同 LLM 骨干模型上性能的一致性突显了 TableRAG 的架构通用性和与广泛骨干模型的兼容性。

5.3 消融研究

图4：基于DeepSeek-V3主干模型，在HybridQA和HeteQA基准测试上的消融研究

为阐明 TableRAG 框架中每个组件的相对重要性，我们评估了完整架构与三个消融变体：（1）不包含上下文感知查询分解，即在不以检索到的表格模式为条件的情况下执行查询分解。（2）不包含 SQL 执行，即用 Markdown 表格格式替换 SQL 编程与执行模块。（3）不包含文本检索，即仅通过基于表格的 SQL 执行操作，不利用如 Wikipedia 文档等文本资源。结果总结于图 4。所有模块都对 TableRAG 的整体性能有所贡献，尽管它们在各个基准上的相对影响不同。在 HybridQA 上，文档检索被证明尤为关键，因为该基准强调提取以实体为中心或数值的线索。相反，对于 HeteQA，SQL 执行的影响更大，因为这些查询涉及嵌套操作，而基于 SQL 的符号推理对此有益。这些发现突显了 TableRAG 文本检索与程序执行推理组件的互补性设计。

6 Efficiency

6.1 执行动态

图5：TableRAG、ReAct与TableGPT2在HeteQA上的执行迭代次数对比

我们通过检查 TableRAG 执行迭代的分布来评估其效率，如图 5 所示。执行长度分为四类：少于 3 步、3-5 步、恰好 5 步以及超过 5 步。在评估的方法中，TableGPT2 的平均执行步数最高，众数值集中在五步左右。相比之下，TableRAG 始终需要更少的步数，大约 63.55% 的实例在少于五步内解决，另有 30.00% 的实例恰好五步内解决，仅有极少数案例在给定的迭代限制下未能解决。虽然 ReAct 在执行步数上显示出类似的分布，但其整体性能仍显著低于 TableRAG。这些结果表明，TableRAG 在执行效率和推理准确性上均表现优异。这归功于其引入了基于 SQL 的表格推理。

6.2 延迟

表2：延迟评估（以秒为单位测量）

我们使用 Qwen-72B-Instruct 作为一致的骨干模型来评估延迟性能。如表 2 所示，TableRAG 在每步平均时间和总时间效率上均比 ReAct 产生更低的延迟。这主要归因于：（1）TableRAG 执行更少的迭代次数，并采用计算高效的符号化 SQL 执行。（2）ReAct 在每一步都执行推理，并在达成最终决策前消耗更多步骤，因此产生了更大的时间开销。

7 Analysis

7.1 错误分析

图6：基于DeepSeek-V3与Qwen-2.5-72B主干模型，TableRAG、TableGPT2及ReAct在HeteQA基准测试上的错误分析。

除了将 TableRAG 的整体性能与既定基线进行评估外，我们还进行了详细的错误分析，以描述预测失败的性质。总体上，错误的输出主要分为两大类：（1）推理失败，归因于 SQL 执行错误或中间查询分解缺陷，以及（2）任务未完成，通常表现为拒绝回答或在超过最大迭代限制时终止。预测分布如图 6 所示。值得注意的是，TableGPT2 表现出此类失败的频率最高，这主要归因于其整合维基文档上下文线索的能力有限。这一限制常常导致模型要么明确拒绝响应，要么承认其无法做到。相比之下，ReAct 缺乏上下文感知的查询分解和代码执行模拟机制，对于本可通过单一结构化查询解决的问题，却常常进行不必要的复杂推理步骤。在评估的方法论中，TableRAG 表现出最低的失败率。其在五次迭代内始终能够产生有效响应的能力，突显了其设计的有效性——特别是其使用的上下文感知查询分解和选择性基于 SQL 的执行规划。

7.2 跨领域预测

图7：TableRAG与ReAct在不同领域中的性能分布。

图 7 展示了使用不同骨干大语言模型实例化的 TableRAG 与 ReAct 框架在各个领域的对比评估。结果显示，TableRAG 在大多数领域始终优于 ReAct，证明了其在异构文档问答方面的有效性。只有某些领域，例如文化领域，在使用 Qwen 骨干模型的 TableRAG 上表现出相对较弱的性能。对数据分布的更仔细检查表明，这种性能下降可能源于领域特定实例的稀疏性。

8 Related Work

8.1 检索增强生成

检索增强生成已成为缓解幻觉（Zhang 等人，2023a）和提升大型语言模型生成响应可靠性（Lewis 等人，2020；Guu 等人，2020）的一个稳健范式。RAG 方法从知识库中检索信息，随后将最相关的文档片段融入生成过程（Gao 等人，2023；Zhu 等人，2024；Borgeaud 等人，2022）。然而，这种直接的检索过程常常产生可能缺乏关键细节的噪声片段，从而降低了后续生成的质量。因此，最近的进展集中在任务自适应的检索机制上。这方面值得注意的框架包括 Self-RAG（Asai 等人，2023）、RQRAG（Chan 等人，2024）等。尽管有这些创新，RAG 在处理异构上下文时仍面临挑战（Satpute 等人，2024）。

8.2 基于大型语言模型的表格推理

表格推理指的是开发一种基于表格数据响应用户查询的系统（Lu 等人，2025）。主流的表格推理方法大致可分为两类。第一类围绕通过提示工程利用 LLMs。例如，Tab-CoT（Jin 和 Lu，2023）应用思维链推理来建立表格结构化的推理过程。类似地，Chain-of-Table（Wang 等人，2024）将 CoT 方法扩展到表格场景，为更复杂的基于表格的查询实现了多步推理过程。第二类涉及使用程序处理表格数据。Tabsqlify（Nahid 和 Rafiei，2024）采用文本到 SQL 的方法将表格分解为更小的、上下文相关的子表。DATER（Ye 等人，2023a）采用少量提示策略将大表简化为更易管理的子表，使用一种解析-执行-填充技术来生成中间 SQL 查询。BINDER（Cheng 等人，2022；Zhang 等人，2023b）整合了 Python 和 SQL 代码以从表格中推导答案。InfiAgent-DABench（Hu 等人，2024）利用一个基于 LLM 的智能体，该智能体进行规划、编写代码、与 Python 沙盒交互并综合结果来解决基于表格的问题。

9 Conclusion

我们解决了现有 RAG 方法在处理结合文本和表格数据的异构文档时的局限性。当前方法损害了表格的结构完整性，导致信息丢失以及在全局、多跳推理任务中性能下降。为克服这些问题，我们引入了 TableRAG，一个 SQL 驱动的框架，它将文本理解与精确的表格操作相整合。为严格评估我们方法的性能，我们还提出了一个新的基准 HeteQA。在公共数据集和 HeteQA 上的实验评估表明，TableRAG 显著优于现有的基线方法。

Limitations

虽然 TableRAG 表现出强大的性能，仍有几个局限性值得考虑：

TableRAG 的有效性与底层大语言模型的能力密切相关。我们的实现利用了如 Claude、DeepSeek-V3 和 Qwen-72B-Instruct 等高容量模型，它们具有很强的泛化能力。缺乏专门指令微调的较小模型可能会出现明显的性能下降。这表明，要获得有竞争力的结果可能需要大量的计算资源。
HeteQA 基准仅限于英语。这一限制源于跨多种语言整理高质量异构源的困难。因此，跨语言泛化仍有待探索。在未来的工作中，我们旨在将 HeteQA 扩展到多语言环境，从而拓宽我们评估框架的适用性和鲁棒性。