TableRAG：异构文档推理的检索增强生成框架

论文：TableRAG: A Retrieval Augmented Generation Framework for Heterogeneous Document Reasoning、项目代码

时间：2025.06.12

本文针对异构文档推理中的结构信息丢失和多跳、全局查询等问题，提出了TableRAG，通过“离线数据库+在线迭代推理”融合文本检索与SQL表格操作，并发布了覆盖多领域、多操作、多源查询的HeteQA基准。

一、论文动机

在基于异构文档（包含文本和表格组件）的问答任务中，传统RAG方法存在显著局限性：

1. 结构信息丢失：将表格扁平化（如转为Markdown）并进行分块处理，会破坏表格固有的行列依赖结构，导致信息丢失或引入无关上下文，影响大语言模型（LLM）的推理性能。
2. 缺乏全局视角：文档分块策略使系统难以处理多跳、全局查询（如数据聚合、数学计算），只能基于Top-N检索块推理，易产生错误结果。

在异构文档问答任务中，将任务输入定义为海量文档，记为 $(T,D)$ ，其中 T 表示文本内容，D 表示表格组件。给定用户问题 q，该任务的目标是优化函数 F，使其在给定文本和表格的组合语境下，能够生成正确答案 A： $F(D,T,q)\to A$​

二、论文方法

TableRAG是一种融合文本理解与表格复杂操作的混合框架，通过“离线数据库构建”和“在线迭代推理”两阶段解决异构文档推理问题，核心设计是用SQL作为表格交互接口，保障表格结构完整性与推理精确性。

2.1 离线阶段：数据库构建

该阶段目标是将异构文档转化为可高效检索与查询的结构化数据，包含3个关键步骤：

1. 表格与文本分离处理

   • 从异构文档（Word、PDF、CSV等）中提取表格集合(D={$D_1,...,D_M$}和文本内容$T$。
   • 将表格转为Markdown格式$\hat{D}$，与原始文本(T)一同分块（1000token/块，200token重叠），并通过预训练模型（如BGEM3）编码为稠密向量，构建文本知识库。

2. 表格 schema 数据库构建

   • 为每个表格$D_i$生成标准化schema描述$S(D_i)$，包含表名、列名、数据类型及示例（模板如下）：

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

   • 建立“表格分块-原始schema”映射$f:{\hat{D}}_{i,j}\to S(D_i)$，${\hat{D}}_{i,j}$ 表示源自表 Dⁱ 的第j个块。这种映射确保了局部片段在语境上始终锚定于其来源的表结构。

3. 关系型数据库存储：将原始表格导入关系型数据库（如MySQL），支持后续SQL执行。

2.2 在线阶段：迭代推理（四步核心流程）

针对用户查询(q)，TableRAG通过多轮迭代逐步生成答案，每轮包含4个步骤：

步骤	核心任务	输入	输出	使用公式
上下文敏感查询分解	区分查询中需文本推理还是表格推理的部分	原始查询、文本数据库、映射函数f	子查询$q_t$	-
文本检索	获取与子查询相关的文本/表格分块	子查询$q_t$、文本知识库（包含文本和表格的Markdown形式分块及嵌入表示）	最终检索的文本块${\hat{T}}_{rerank}^{q_t}$	T ^ r e c a l l q t = t o p − N ( a r g m a x T ^ i ∈ { D ^ , T } c o s ( v T ~ i , v q t ) ) \hat{\mathcal{T}}_{recall }^{q_{t}}=top-N\left(arg max _{\hat{\mathcal{T}}_{i} \in\{\hat{\mathcal{D}}, \mathcal{T}\}} cos \left(v_{\tilde{\mathcal{T}}_{i}}, v_{q_{t}}\right)\right) T^recallqt​​=top−N(argmaxT^i​∈{D^,T}​cos(vT~i​​,vqt​​)) （向量召回，确定初始候选块） （后续语义重排序未明确公式表示，用模型评估筛选出最终结果）
SQL编程与执行	对需表格推理的子查询生成并执行SQL	检索结果${\hat{T}}_{rerank}^{q_t}$、映射函数f、子查询$q_t$、MySQL数据库	SQL执行结果$e_t$	$S^t=\left\{f\left({\hat{\mathcal{T}}}_i\right\}{\hat{\mathcal{T}}}_i\in {\hat{\mathcal{T}}}_{rerank}^{q_t}\right\}$ （提取相关表格模式集） $e_t=f_{SQL}\left(S^t,q_t\right)$ （生成并执行SQL程序得到结果）
中间答案生成	融合文本检索与SQL执行结果	SQL执行结果$e_t$、文本检索结果${\hat{T}}_{rerank}^{q_t}$	子查询的最终答案$a_t$	$a_t=F(e_t,{\hat{T}}_{rerank}^{q_t})$ （基于证据效用自适应加权可靠性得出答案，F为综合评估函数，具体形式未明确）

• 迭代终止条件：无更多子查询需分解，最终答案为最后一轮子查询答案$A=a_T$（最大迭代次数设为5）。

三、实验结果

为验证多跳异构推理能力，作者构建了HeteQA基准，弥补现有数据集在复杂表格操作与多源融合上的不足。

3.1 基准特点

• 数据规模：304个高质量示例，覆盖136个表格、5314个Wiki实体，支持单源（82%，仅文本/表格）和多源（18%，文本+表格）查询。
• 领域与操作多样性：涵盖9个语义领域（如文化、军事、科技），包含5类核心表格操作（条件筛选、统计聚合、排序、比例计算、嵌套逻辑）。
• 构建流程：采用“LLM生成+人工验证”策略：
  1. 从Wiki筛选≥20行、≥7列的表格，用Claude-3.7-sonnet生成含SQL/Python代码的查询；
  2. 人工验证代码可执行性与答案正确性，修正错误；
  3. 替换查询中的实体为Wiki引用（如将“Which driver”改为“What is the nationality of the driver”），增加推理难度。

3.2 实验设置与结果

3.2.1 实验配置

• 数据集：HeteQA + 2个公开基准（HybridQA：多跳异构QA；WikiTableQuestion：表格QA）。
• 基线模型：
  • Direct LLM：无检索，直接用LLM生成答案；
  • NaiveRAG：将表格扁平化后用传统RAG；
  • ReAct：基于prompt的多轮推理框架；
  • TableGPT2：用Python（Pandas）处理表格的生成模型。
• 评估指标：准确率（由Qwen-2.5-72B判定，输出0/1二元得分）。

3.2.2 核心实验结果

1. TableRAG性能最优：在所有数据集和LLM backbone（Claude-3.5、DeepSeek-V3、Qwen-2.5-72B）上，TableRAG准确率均高于基线，平均提升≥10%。例如：
   • 在HeteQA多源查询中，Claude-3.5 backbone下TableRAG准确率44.19%，高于ReAct（29.60%）和TableGPT2（32.24%）；
   • 在WikiTableQuestion（单源表格查询）中，DeepSeek-V3 backbone下TableRAG准确率80.40%，接近NaiveRAG（75.40%），但在多源任务中优势显著。注：“多源” 表示需要表格和文本信息的问题，而 “单源” 指仅依赖一种信息源类型的问题。
2. 基线局限性：
   • NaiveRAG：单源表格任务表现尚可，但多源任务因结构丢失准确率骤降；
   • ReAct：多源任务优于NaiveRAG，但因缺乏上下文敏感分解，易出现信息不全或误差传播；
   • TableGPT2：仅单源表格任务有效，多源任务因无法融合文本上下文准确率低。

3.2.3 消融实验

验证TableRAG各组件的必要性：

• 无上下文敏感分解：准确率下降约8%-12%（因分解未关联表格结构，子查询偏差大）；
• 无SQL执行：用Markdown表格替代SQL，准确率下降约15%-20%（因无法精确处理聚合、计算等操作）；
• 无文本检索：仅依赖SQL，在HybridQA（需文本实体提取）上准确率下降约10%（因丢失文本上下文）。

3.3 效率与误差分析

3.3.1 效率优势

• TableRAG迭代步骤更少：63.55%的实例可在<3步内解决，30%在3-5步解决，仅极少数需超过5步；
• 对比TableGPT2（多数实例需5步）和ReAct（步骤分布相近但准确率低），TableRAG在“效率-准确率”平衡上更优。

3.3.2 误差分析

TableRAG错误主要分为两类，且发生率低于基线：

1. 推理错误（SQL执行错误或查询分解偏差）：占比约20%-30%，低于ReAct（35%-40%）；
2. 任务未完成（拒绝回答或超迭代限制）：占比<5%，远低于TableGPT2（>15%，因无法融合文本上下文）。

四、论文局限

4.1 局限性

1. 依赖大模型能力：需高容量LLM（如Claude-3.5、Qwen-72B），小模型因缺乏指令微调，性能显著下降；
2. 语言单一性：HeteQA仅支持英文，多语言异构文档推理尚未探索；
3. SQL依赖限制：若表格无明确schema（如非结构化表格），SQL生成难度增加，可能影响性能。

4.2 未来方向

1. 扩展HeteQA至多语言基准；
2. 优化小模型适配性，降低计算资源需求；
3. 增强非结构化表格的schema自动生成能力，扩大适用场景。

五、与谷歌TableRAG的对比

2024年10月谷歌提出的TableRAG,对两者进行简单的对比：

1. Huawei Cloud 版：以“SQL+文本检索”为核心，解决异质文档的多跳推理问题，适合需要融合文本语义与表格结构的场景，牺牲部分扩展性换取模态融合能力；
2. Google 团队版：以“schema-单元格双检索”为核心，解决大规模纯表格的效率与精度问题，适合超大规模表格分析，牺牲模态融合能力换取极致扩展性。

选择需根据核心需求判断：若涉及文本与表格混合，优先前者；若为纯大规模表格处理，优先后者。

5.1 核心定位与解决痛点

维度	文档1（Huawei Cloud 版 TableRAG）	文档2（Google 团队版 TableRAG）
核心定位	聚焦异质文档推理（文本+表格混合），解决传统 RAG 处理表格时的结构丢失与全局视图缺失问题	聚焦大规模表格理解（百万级单元格），解决 LM 上下文长度限制与长表格推理效率问题
核心痛点	1. 表格线性化导致结构信息丢失； 2. 文档分片无法支持多跳全局查询（如聚合计算）	1. 全表输入超出 LM 上下文长度； 2. 长上下文“Lost-in-the-Middle”效应； 3. 全表编码计算成本过高
目标场景	异质文档问答（需同时处理文本语义与表格结构，如“结合文本描述与表格数据计算比例”）	大规模纯表格问答（如百万行表格的统计分析、条件查询，无需依赖外部文本）

5.2 技术框架对比

5.2.1 离线阶段：数据预处理与存储

模块	文档1（Huawei Cloud 版 TableRAG）	文档2（Google 团队版 TableRAG）
表格处理方式	1. 提取表格结构，构建关系型数据库（如 MySQL）； 2. 表格转 Markdown 格式，与文本一起分片构建文本知识库； 3. 建立“表格分片→原表 schema”的映射关系	1. 提取表格 schema（列名、数据类型、示例值），构建schema 数据库； 2. 提取distinct 列-单元格对（按频率截断），构建单元格数据库； 3. 支持“单元格编码预算 B”，避免全表编码
文本处理	必须处理（异质文档包含文本，需构建文本知识库用于文本检索）	无需处理（聚焦纯表格场景，不依赖外部文本）
存储核心	关系型数据库（支持 SQL 执行）+ 文本向量库	schema 向量库 + 单元格向量库（均为轻量级，与表格规模解耦）

5.2.2 在线阶段：推理流程

模块	文档1（Huawei Cloud 版 TableRAG）	文档2（Google 团队版 TableRAG）
核心推理逻辑	迭代四步流程（多轮分解-检索-执行-合成）	查询扩展+双检索+程序求解（单轮精准检索+LM 编程）
1. 查询处理	上下文敏感查询分解：根据检索到的表格 schema，将原查询拆分为文本子查询或表格子查询	表格查询扩展：LM 生成schema 查询（列名候选）与单元格查询（关键词候选）
2. 信息检索	- 文本检索：向量召回（Top-30）+ 语义重排序（Top-3）； - 表格检索：通过映射关系关联到原表 schema，触发 SQL 执行	- Schema 检索：用扩展查询匹配列名，获取相关列（含数据类型、示例）； - 单元格检索：用扩展查询匹配列-单元格对，获取关键值
3. 表格计算	SQL 执行：基于原表完整数据执行 SQL，获取精确结果（避免分片丢失信息）	程序辅助求解：将检索到的 schema/单元格传入 LM（如 ReAct），生成 Python/Pandas 代码执行计算
4. 结果合成	交叉验证“SQL 结果”与“文本检索结果”，自适应加权生成中间答案，迭代至无更多子查询	直接用检索到的关键信息辅助 LM 生成代码并执行，输出最终答案

5.2.3 关键技术差异

技术点	文档1（Huawei Cloud 版 TableRAG）	文档2（Google 团队版 TableRAG）
表格交互接口	SQL（优势：支持复杂聚合、全局计算，结果精确；依赖关系型数据库）	Python/Pandas（优势：灵活处理非结构化单元格（如自由文本），无需数据库部署）
检索机制	文本+表格关联检索（需同时处理两种模态），检索结果用于“子查询分解”	Schema+单元格双检索（纯表格模态），检索结果直接用于“代码生成”
迭代能力	支持多轮迭代（如“先通过文本检索确定时间范围，再通过 SQL 计算比例”）	单轮检索+求解（检索精度依赖查询扩展质量，不支持多轮分解）
token 复杂度	推理阶段 token 数与“子查询数量+SQL 结果长度”相关，与表格规模间接关联	编码阶段：O(min(D,B))（D 为 distinct 单元格数）； 推理阶段：O(K)（K 为检索结果数），与表格规模完全解耦

5.3 优缺点对比

维度	文档1（Huawei Cloud 版 TableRAG）	文档2（Google 团队版 TableRAG）
优点	1. 支持异质文档推理（文本+表格融合）； 2. SQL 执行确保表格计算精度（无分片信息丢失）； 3. 多轮迭代适应复杂多跳查询	1. 超大规模表格友好（与表格规模解耦，支持百万级单元格）； 2. 检索效率高（仅编码 distinct 单元格，token 成本低）； 3. 轻量部署（无需关系型数据库，仅需向量库）
缺点	1. 大规模表格扩展性差（依赖数据库性能，SQL 执行耗时）； 2. 文本检索增加系统复杂度； 3. 不支持非结构化单元格（如自由文本）	1. 不支持异质文档（无法处理外部文本）； 2. 依赖查询扩展质量（扩展失败则检索偏差）； 3. 单元格预算 B 可能丢失低频关键信息
适用场景	企业报告、学术论文等“文本+表格”混合文档的问答	数据仓库、业务报表等大规模纯表格的统计分析与查询