rag-">大模型RAG场景下文档图表的处理方案

一、问题的提出：为什么表格是RAG的”硬骨头”

在构建基于大语言模型的检索增强生成（RAG）知识库时，绝大多数团队最初都会把注意力集中在文本切分策略、向量化模型选型、召回排序算法上。然而真正落地到企业文档场景后，你会发现一个被严重低估的难点：文档中的表格和图表。

企业级文档——无论是产品说明书、合同条款、财务报表还是技术规范——都大量使用表格来承载关键信息。这些表格往往具有以下特征：

• 合并单元格普遍存在：表头跨列、行分组跨行，视觉上清晰的层级结构在纯文本化之后会彻底崩塌；
• 语义依赖于结构：同一个数字放在不同的行、列交叉点上，含义完全不同；
• 与上下文强耦合：表格前面通常有一段说明文字，表格本身是对这段文字的补充或例证。

如果处理不当，会出现两类典型故障：

故障一：检索到了，但模型读不懂。
向量检索命中了包含表格的文档片段，但返回给大模型的内容是一堆顺序错乱的文本片段，模型无法还原表格的行列关系，只能给出模糊甚至错误的回答。

故障二：信息提取出来了，但语义发生了偏移。
按行逐条提取表格内容时，遇到合并单元格会导致数据错位——本该属于某一行的”调整逻辑”被错误地分配给了相邻行，最终生成的内容与原始文档含义不符。

这两类问题的本质是同一个：表格的信息密度不在文字本身，而在文字的空间排列关系中。任何丢失结构信息的处理方式，都会造成不可逆的语义损失。

二、核心思路：让表格以”模型能理解的结构化形式”进入上下文

解决上述问题的关键，是找到一个既能完整保留表格结构语义、又能被大语言模型准确理解的中间表示形式。

经过实践验证，HTML表格标记是目前最理想的方案，原因有三：

1. 大语言模型对HTML有天然的理解能力。主流大模型在预训练阶段接触了大量HTML文档，对 <table>、<thead>、<tr>、<td>、<th>、rowspan、colspan 等标签的语义有充分认知；
2. HTML能精确表达合并单元格。colspan 和 rowspan 属性可以无损还原跨行跨列的合并关系，这是Markdown表格语法做不到的；
3. HTML是纯文本，可以直接嵌入到Prompt上下文中，不需要额外的二进制解析步骤。

基于这个思路，整个处理链路可以拆解为三个阶段：读取 → 转换 → 拼接。

三、三阶段处理链路详解

3.1 阶段一：读取——从原始文档中识别并提取表格

第一个阶段的目标是从各种格式的源文档（PDF、Word、扫描件等）中准确识别出表格区域，并将其提取为一种中间数据结构。

关键工作包括：

• 版面分析：区分正文段落、标题、表格、图片等不同元素，确定表格的边界框；
• 表格结构识别：检测表格的行线、列线，推断出单元格的网格布局；
• 单元格内容提取：对每个单元格进行OCR或文本抽取，得到单元格内的文字内容；
• 合并关系标注：识别哪些单元格存在跨行或跨列合并。

这一阶段的输出通常是一个二维的单元格矩阵，每个单元格带有位置信息（行索引、列索引、跨行数、跨列数）和内容。

对于扫描件或图片型PDF，还需要依赖OCR能力；对于原生电子文档，则可以直接解析底层结构。无论哪种路径，最终都要归一化到统一的中间表示，便于后续处理。

3.2 阶段二：转换——将表格结构转换为HTML

拿到单元格矩阵后，第二阶段的任务是将其转换为标准的HTML表格。

转换算法的核心逻辑：

1. 遍历单元格矩阵，跳过已被合并覆盖的位置；
2. 对每个有效单元格，判断其是否为表头（通常根据位置和样式判断），决定使用 <th> 还是 <td>；
3. 若单元格存在跨列，添加 colspan="N" 属性；若存在跨行，添加 rowspan="N" 属性；
4. 按行组装 <tr>，最后包裹在 <thead> 和 <tbody> 中。

举个具体例子。假设原始文档中有一个调价机制表格，包含”情况””网上月均幅度””示例””调整逻辑””结算调整幅度示例”等列，其中”调整逻辑”列在某些行中跨两列合并，”情况”列存在跨三行合并。经过转换后，会得到类似这样的HTML结构：

<table>
  <thead>
    <tr>
      <th>情况</th>
      <th>网上月均幅度</th>
      <th>示例</th>
      <th colspan="2">调整逻辑</th>
      <th>结算调整幅度示例</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td></td>
      <td>幅度超过(含)5.00%</td>
      <td>5.50%</td>
      <td colspan="2">不进行市场调研，以网上月均幅度为准</td>
      <td>5.50%</td>
    </tr>
    <tr>
      <td></td>
      <td>幅度未超过±5.00%</td>
      <td>±3.00%</td>
      <td colspan="3">不进行市场调研，不调整执行价格</td>
    </tr>
    <tr>
      <td rowspan="3">幅度超过(含)-5.00%</td>
      <td rowspan="3">-5.50%</td>
      <td rowspan="3">启动市场调研</td>
      <td>6.00%</td>
      <td>6.00%</td>
    </tr>
    <tr>
      <td>±3.00%</td>
      <td>不调整</td>
    </tr>
    <tr>
      <td>-6.00%</td>
      <td>-5.50%</td>
    </tr>
  </tbody>
</table>

这样的HTML片段送入大模型后，模型能够准确还原出表格的层级关系：哪些数据属于同一个分组、哪些列是合并的、每一行的完整语义是什么。

为什么不用Markdown表格？
Markdown的表格语法（| a | b |）不支持 rowspan 和 colspan，遇到合并单元格时只能靠空格填充或重复内容来”凑”，模型很容易产生歧义。对于结构简单的表格，Markdown尚可胜任；但对于企业文档中常见的复杂表格，HTML是更可靠的选择。

3.3 阶段三：拼接——将HTML表格重新嵌入文档上下文

第三阶段常被忽略，但对最终效果影响巨大。表格从来不是孤立存在的，它总是嵌入在文档的某个章节中，前后有说明文字、标题、编号。

拼接的策略是：

• 保留表格前后一定范围内的上下文文本（如前后各一个段落）；
• 保留章节标题和编号，帮助模型定位表格所属的业务语境；
• 将转换后的HTML表格插入到原本的位置，形成一个新的、结构完整的文档片段。

例如，原始文档中的”4.2.1 年度废旧商品调价”章节，包含标题”4.2.1.1 常规类品种调价机制”、一段说明文字、以及一个调价逻辑示例表格。拼接后的文档片段应该是：

4.2.1 年度废旧商品调价
4.2.1.1 常规类品种调价机制（废钢废铝等单一材质类）：
20XX年9月结算价格不作调整，10月1日起按以下调价机制进行调整：
月度价格调整逻辑示例
<table>
  ...（完整的HTML表格）...
</table>

这个片段被向量化后存入向量数据库。检索时，命中的是带表格结构的完整上下文，而不是一堆散乱的文本行。

四、工程实践中的关键细节

4.1 切分策略要围绕表格结构调整

传统的定长切分或按段落切分，很容易把表格从中间截断。建议在切分时以表格为原子单位——一个表格连同它的前置说明和后置结论作为一个chunk，不要拆分。如果表格本身过大，可以在行分组（tbody中的逻辑分组）层面切分，但必须在每个切分片段中保留表头。

4.2 向量化时对HTML标签做适当处理

直接对HTML全文做向量化，标签本身会引入噪声。一种常见做法是：**向量化时使用表格的文