大家好，我是肆〇柒。在 RAG 系统中，传统问答系统在处理含文本与表格的异构文档时，常令用户困扰。华为云 BU 研究人员创新性地提出 TableRAG 框架，采用 SQL 执行与文本检索混合模式，尝试破解这一难题。在 HeteQA 基准测试集上，TableRAG 整体准确率相较于最佳基线方法提升超 10%，且能在 5 步内解决约 93.55% 的问题，为异构文档问答带来创新方法。

异构文档问答的困境

在企业 AI 应用落地的当下，构建能处理自然语言与结构化表格相结合文档的问答系统，已成为人工智能关键任务。然而，传统问答系统因主要基于纯文本，在处理含文本与表格的异构文档时，存在明显缺陷。现有语言模型在处理涉及表格的文档时，常因表格行与列关系混乱而降低回答准确性，尤其在需要跨文档多跳推理且涉及计算、聚合等操作时，性能受限，难以满足实际需求。

传统 RAG 把整张表压成 Markdown 后切块，行列关系被彻底打乱。当需要跨行聚合时，top-N 召回只能看到局部切片，导致 “只见树木、不见森林”。这图直观展示了线性化带来的偏差，后面将给出 TableRAG 的改进思路。

上图展示了异构文档问答任务的一个示例，传统 RAG 方法将表格线性化后切块，导致行列关系被打乱，无法进行跨行聚合操作，回答准确性受到影响。

TableRAG 框架：离线建库 + 在线四步迭代

框架总体架构

TableRAG（下文简称 “框架”）是一套 SQL 执行与文本检索混合（Hybrid SQL-Text Retrieval）系统，采用离线 - 在线两阶段处理流程，确保系统的高效性和准确性。

• • 离线阶段 ：主要负责将异构文档解析为结构化数据库。系统会分别提取文档中的表格与文本内容，并将其存储于不同的数据库中。表格存储于关系型数据库，以便支持后续的 SQL 查询操作；而文本内容则存储于分块知识库，用于快速检索相关文本信息。通过这种方式，离线阶段构建了两个并行的语料库，为在线阶段的问答处理奠定了坚实的数据基础。
• • 在线阶段 ：当用户提出问题时，系统进入在线处理阶段。该阶段通过四步迭代过程来逐步解答用户的问题，包括上下文敏感的查询分解、文本检索、SQL 编程与执行、组合式中间答案生成。系统会动态判断问题需要文本推理还是表格推理，并根据判断结果选择合适的策略，将文本检索和 SQL 执行的结果进行整合，最终生成准确、完整的答案。

SQL 把整张表视为不可分割的推理单元，一条语句即可完成多行过滤 + 聚合，而 Python - Pandas 需要把表全部加载到内存再逐行操作，大表场景下延迟高 1 - 2 个量级。

上图展示了 TableRAG 的总体架构，包括离线阶段的数据库构建和在线阶段的四步迭代推理过程。

关键组件解析

• • 上下文敏感查询分解（Context - Sensitive Query Decomposition）
  这是框架中至关重要的一步。它能够明确文本与表格在查询中的角色，基于检索到的表格内容与对应架构描述，制定子查询。以 “2008 年 Activision 发布的游戏有多少比例仍处于活跃状态” 为例，该模块会将其巧妙地分解为多个子查询，
  ① 找 Activision 2008 游戏表；
  ② 过滤 Live = Y；
  ③ 求占比。
  在商业文档问答中，面对 “某季度销售额增长且利润排名前 3 的产品类别” 这类复杂问题，查询分解模块同样能精准拆解，先定位相关产品类别文本信息，再聚焦表格中销售额与利润数据，逐步逼近最终答案，展现其强大的逻辑拆解能力。
• • 文本检索模块
  文本检索模块采用两阶段检索策略，以确保检索结果的准确性和相关性。
  首先，基于向量的召回阶段利用预训练语言模型将查询与文档分块嵌入密集向量空间，通过计算向量间的余弦相似度，快速筛选出与查询向量最相似的候选分块。
  接着，基于语义的重排序阶段对召回的候选分块进行进一步筛选和排序，选出与查询语义最匹配的顶级候选分块。
  在处理新闻报道与数据表格结合的文档时，这一模块能迅速定位与查询文本高度相关的段落，为后续答案生成提供丰富的文本依据。
• • SQL 编程与执行模块
  当子查询涉及表格数据推理时，SQL 编程与执行模块就会发挥作用。通过映射函数，该模块能够提取检索结果中表格架构信息，然后利用专用工具 fSQL 生成可执行 SQL 程序，并在预先构建的 MySQL 数据库上运行。
  以问题 “2008 年 Activision 发布的游戏有哪些” 为例，它会精准生成 SQL 语句 “SELECT game_name FROM games WHERE publisher = 'Activision' AND release_year = 2008”，并在数据库中执行，快速获取答案。
  在企业数据分析场景中，面对 “统计各部门加班时长超 10 小时的员工人数” 这类问题，也能毫无压力地生成相应 SQL 语句，高效查询企业考勤数据库。SQL 作为符号执行接口，将表格相关查询视为不可分割的推理单元，避免了 Python 等编程语言在处理大规模数据时的计算开销，凸显了其在表格数据操作中的核心价值。
• • 组合式中间答案（Compositional Intermediate Answer）生成模块
  该模块负责结合 SQL 执行结果与文本检索结果，进行综合推理。它会根据结果的一致性、可靠性权重，得出子查询最终答案。若 SQL 执行结果与文本检索结果出现矛盾，模块会深入评估两者，仔细解释差异，并基于评估结果给出最佳判断。
  例如，在整合企业财务报表表格数据与业务分析文本时，若表格显示某产品利润增长，但文本分析提及市场反馈不佳，组合式中间答案生成模块会综合考虑这些信息，给出包含详细情况说明的全面答案，确保用户获得准确且富有洞察力的决策依据。

TableRAG 框架通过离线阶段构建双库，在线阶段经四步迭代处理用户问题，各关键组件协同运作，精准应对异构文档问答挑战。

实验：准确率提升 10%，5 步内解决 90% 问题

实验设置与主要结果

为了验证上述设计的有效性，研究者在 3 个公开基准及自建 HeteQA 上进行了系统性实验。

• • 数据集 ：实验涵盖了 HeteQA 以及 HybridQA、WikiTableQuestions 等公共基准测试集。其中，HybridQA 是涉及表格与文本信息的多跳问答数据集，WikiTableQuestions 则是跨多领域的表格问答数据集，这些数据集从不同角度对 TableRAG 进行了全方位的考验。
• • 主要结果 ：TableRAG 在多个基准测试中以卓越的性能超越所有基线方法。在 HeteQA 数据集上，TableRAG 使用不同骨干 LLM 时，整体准确率相较于最强基线方法均有至少 10% 的提升 。这主要得益于 TableRAG 的符号推理能力，它能够精准地处理表格数据，有效融合文本与表格信息，从而更好地适应异构文档的复杂查询需求。

对比可见，TableRAG 在所有骨干模型上均领先，随后我们将通过消融实验揭示领先原因。

单源问题性能对比：

多源问题性能对比：

具体参考：

上表展示了 TableRAG 与基线模型在多个基准测试中的性能对比，TableRAG 在所有骨干模型上均领先。

消融研究与错误分析

• • 消融研究 ：对比完整架构与三种消融变体，深入分析各组件对模型性能的影响。在 HybridQA 上，文本检索模块尤为关键；在 HeteQA 上，SQL 执行模块更具影响力。通过消融研究，充分凸显了 TableRAG 文本检索与程序执行推理组件的互补性，证明了完整架构的优越性。
• • 错误分析 ：TableRAG 的错误输出主要分为推理失败与任务未完成两类。与 ReAct、TableGPT2 对比，TableRAG 的失败率显著降低，通常在 5 次内迭代出有效响应。在某次实验中，TableRAG 出现了 SQL 执行错误，原因是生成的 SQL 语句存在语法问题，这表明在复杂查询条件下，SQL 生成的准确性仍需进一步提升。这充分体现了 TableRAG 设计的合理性，尤其是上下文敏感查询分解与选择性 SQL 执行规划，使其在处理复杂查询时更加稳健可靠。

错误案例举例：HeteQA 中 query “Which comedy film released in July-Dec 2012 had the most cast members?” TableRAG 生成 SQL 时遗漏 genre LIKE '%Comedy%'，导致返回非喜剧片；人工修正后准确率恢复。

上图展示了 TableRAG 在 HybridQA 和 HeteQA 基准上的消融研究结果，表明各组件对模型性能的重要影响。

上图展示了 TableRAG、TableGPT2 和 ReAct 的错误分析，TableRAG 的失败率显著低于其他方法。

效率分析

通过对执行迭代分布的分析，TableRAG 在 HeteQA 上展现了惊人的效率。约 63.55% 的实例在 5 步内解决，30% 恰好 5 步解决。相比 TableGPT2 平均执行步骤多，ReAct 执行步骤分布相似但性能差，这表明 TableRAG 在执行效率和推理准确率方面均表现出色。这一优势主要归因于 SQL 基于表格推理的强大能力，它能够快速、精准地处理表格数据，减少不必要的迭代步骤，提升整体效率。

上图展示了 TableRAG、ReAct 和 TableGPT2 在 HeteQA 上的执行迭代分布对比，TableRAG 在较少的迭代步骤内解决了大部分问题。

TableRAG 在实验中表现卓越，准确率相较基线提升超 10%，且 5 步内解决约 93.55% 问题，效率与准确率兼具。

HeteQA：304 题、9 领域、5 类表格操作

创建目的

为了严格评估多跳异构推理能力，开发 HeteQA 基准测试集显得尤为必要。现有的公共数据集在多跳推理、跨文本与表格复杂查询方面存在明显不足，难以全面衡量模型在异构文档问答中的真实性能。HeteQA 的提出正是为了弥补这一缺陷，为研究人员提供一个更具挑战性和代表性的评估平台。

数据收集方法与特点

HeteQA 基准测试集包含 304 个高质量示例，涵盖 9 个语义领域，全面覆盖多个行业的业务场景。数据集涉及 5 类表格操作，包括过滤（Filtering）、分组（Grouping）、聚合（Aggregation）、计算（Calculation）、排序（Sorting）等常见且关键的操作类型。其中，82% 的答案基于单一来源，18% 基于多来源，充分体现了异构文档问答中信息来源的多样性和复杂性。此外，数据集中包含 136 个独特表格及 5314 个维基知识实体，为模型提供了丰富的知识背景和推理素材，使其能够在复杂的查询中准确地定位和整合信息。

局限性

尽管实验结果亮眼，研究者也坦诚指出了当前实现的两点主要瓶颈。

TableRAG 虽在性能上取得突破，但其有效性在一定程度上依赖于底层 LLM 的能力。在实现细节中提及，使用不同骨干 LLM 时，性能表现存在差异，在 Qwen - 2.5 - 7B 上准确率相对 72B 下降约 30%。这表明 TableRAG 对语言模型的性能要求较高，限制了其在一些资源受限环境中的应用。此外，HeteQA 基准测试集目前仅涵盖英语，这限制了 TableRAG 在多语言环境中的应用与评估。对于其他语言的异构文档问答任务，TableRAG 的适用性有待进一步验证与拓展，这也在一定程度上制约了其在国际舞台上的广泛应用。

另外，我注意到，实际部署时，社区反馈的两个常见坑点是：MySQL 8.0.24 在 Ubuntu 22.04 需额外安装 libtinfo5 否则初始化失败；dev_excel.zip 必须解压到 dataset/hybridqa/dev_excel/ 而非根目录，否则 ingestion 报路径错误。现阶段最小复现配置：单卡 A100 80 GB + MySQL 8.0 + Claude-3.5-Sonnet，可在 2 小时内跑完 HeteQA 全量 304 例，显存峰值 ~65 GB。

总结：为什么 TableRAG 值得你关注？

现在，可以一句话总结 TableRAG 的核心价值：它把“表格”从被切碎的文本重新升格为可精确查询的“一等公民”。

1. 1. 先破后立
   传统 RAG 把表当 Markdown 字符串切块——行列关系断裂，聚合、排序全局操作无从谈起；TableRAG 离线阶段就把表写进 MySQL，在线阶段用 SQL 把整张表当作不可拆分的推理单元，彻底解决了“结构信息丢失”和“缺乏全局视野”两大痛点。
2. 2. 四步迭代，SQL 与文本双轮驱动
   • 上下文敏感的查询分解：先拆问题，再决定是查文本还是跑 SQL。
   • 向量召回 + 语义重排：兼顾速度和相关性。
   • SQL 生成 + 执行：把复杂的过滤、聚合、排序一次性推给数据库，性能与准确性兼得。
   • 组合式答案：SQL 结果与文本片段交叉验证，自动消歧。
   在 304 题的 HeteQA 上，93.55% 的查询 5 步内收敛，平均准确率较基线再提 10%。
3. 3. 留得青山在，也留得局限
   高算力依赖（72 B 模型才能发挥全部潜力）、英语单语场景仍是现实门槛；但框架本身不挑 LLM，开源仓库已给出 MySQL + A100 的 2 小时复现脚本，开源可在此基础上继续打磨。

如果你正在为金融报表、科研论文或产品手册里“文字+表格”的问答场景头疼，TableRAG 提供了一条可落地的新路径：让表格回归表格，让 SQL 去做它最擅长的事。开源代码地址见参考资料，想了解更多细节的朋友，建议上手摸一下。各位，看过此文有什么感想？如有其他想法可以在评论区留言，我们聊聊。或者加入“觉察流”社区群，与群里的小伙伴一起学习、交流。加入方法，私信回复“入群”“加群”即可。

如果你关注 RAG（Retrieval-Augmented Generation）相关的技术，可以点击订阅主题👉“RAG 检索增强生成”。

#觉察流 #AI全栈 #AI论文 #AI社区 #开源 #开源项目 #TableRAG #异构文档问答 #SQLText混合框架 #多跳推理 #检索增强生成 #RAG #企业文档分析 #财务报表问答 #跨表格聚合计算