布吉岛 Agent

Appearance

2.2.4 图片、表格、图表、PDF 等复杂格式为什么更难处理？ ​

先给结论：复杂格式之所以难，不是因为它们“不能进 RAG”，而是因为其中大量有价值信息并不直接以干净文本形式存在。

对普通 Markdown 或网页正文来说，系统往往比较容易提取文字和层级。

但图片、表格、图表、PDF、扫描件里的知识，常常藏在版面结构里，而不只是藏在字面文本里。

难点一：文字不一定能被直接读出来 ​

比如：

  • 扫描版 PDF 的文字其实是一张图片
  • 图表里的标签和数值嵌在图像里
  • 截图里的说明文字需要 OCR 才能识别

这意味着系统第一步就不是“做检索”，而是“先想办法把内容读出来”。

而且“读出来”本身也分层次：

  • 能不能识别出文字
  • 能不能识别对位置
  • 能不能把标题、正文、表头、脚注分开

很多系统的问题不在于 OCR 完全失败，而在于它只识别出了字，却没有识别出字和结构的关系。

难点二：即使读出了文字，也可能丢掉结构 ​

复杂格式里，结构往往决定语义。

例如：

  • 表格的表头决定字段含义
  • 行列关系决定数字属于谁
  • 图表的坐标轴决定趋势含义
  • PDF 的章节和版面位置决定内容归属

如果只把这些内容粗暴转成一串文本，很多关键关系就会丢失。

这类结构一旦丢失，后面最容易出现的不是“一个字没识别出来”，而是“识别结果看起来像文本，但意思已经变了”。这比纯粹漏字更麻烦，因为它会让系统产生一种“看起来能用”的错觉。

难点三：阅读顺序不稳定 ​

对网页和 Markdown 来说，阅读顺序通常比较明确。

但在复杂 PDF 或版面文档里，系统可能会遇到：

  • 多栏排版
  • 浮动标题
  • 跨页表格
  • 图文穿插

这会导致提取后的文本顺序和人真正阅读时的顺序不一致，从而影响后续切块和检索。

比如一个双栏 PDF，如果系统先读左栏一半，再跳到右栏，再回到左栏，提取出来的文本可能句子都对，但前后逻辑已经乱了。后面即使再精细切块，也是在错误顺序上继续加工。

难点四：语义经常不只在文本里 ​

比如一张图表，真正重要的信息可能是：

  • 走势上升还是下降
  • 峰值出现在什么时间
  • 两条曲线之间谁更高

这些信息不是单纯 OCR 出文字就能完整表达的。

同样，一张复杂表格的意义也常常取决于：

  • 合并单元格
  • 缺失值
  • 单位说明
  • 脚注解释

所以复杂格式处理难，不只是“抽字难”，而是“语义恢复难”。

从工程视角看，这类问题往往至少有三种不同层级：

  • 识别问题：字有没有识别出来
  • 结构问题：表头、段落、图注、脚注有没有对应正确
  • 语义问题：图表趋势、表格关系、版面归属有没有被正确表达

不同层级的问题，需要的处理手段也不一样。OCR 只能解决一部分识别问题，不能自动解决全部结构和语义问题。

为什么这会直接影响 RAG ​

如果复杂格式处理不好，后面会出现几种典型问题：

  • 重要字段被漏掉
  • 表格数值和对应维度错配
  • 图表文字被抽出来，但趋势关系丢了
  • PDF 正文和页眉页脚混在一起
  • 同一段内容被拆得支离破碎

这样即使后面检索到了相关内容，模型看到的也已经不是原本正确的知识形态了。

更麻烦的是，这些错误往往不像“文档不存在”那样明显，而是会变成：

  • 检索结果看起来很相关，但关键数字对不上
  • 模型引用了表格内容，但维度和数值配错了
  • 答案里提到了趋势，但趋势方向说反了
  • 章节标题和正文错位，导致引用出处看起来不可信

这类错误最容易骗过只看表面流畅度的 Demo。

复杂格式通常要多走一步“结构恢复” ​

和普通纯文本不同，这类内容更常见的处理顺序通常是：

  1. 先做 OCR 或文本抽取。
  2. 再做版面分析，恢复标题、段落、表格、图片、图注、脚注这些块级结构。
  3. 对表格、图表做额外结构化处理。
  4. 最后才决定哪些内容可以进入常规切块和检索链路。

这一步之所以重要，是因为很多复杂内容真正该切的，不是“抽出来的整段文本”，而是“恢复结构之后的语义单元”。

比如：

  • 表格更适合按表为单位或按行列关系整理后再处理
  • 图表更适合补一层结构化描述或人工摘要
  • PDF 正文更适合在章节边界上切块，而不是按页硬切

表格、图表、扫描件，其实不是同一种难 ​

很多时候它们会被统称为“复杂格式”，但难点并不完全一样。

表格 ​

表格最难的是关系恢复。真正有意义的通常不是某个单元格，而是：

  • 它所在的行和列
  • 它对应的表头
  • 它的单位和统计口径
  • 它是不是合并单元格的一部分

图表 ​

图表最难的是趋势和比较关系。即使 OCR 把标题、坐标轴、图例全读出来，也未必能自动得到：

  • 哪条曲线更高
  • 什么时候拐点出现
  • 哪个时间段变化最快

扫描件和图片 PDF ​

扫描件最难的是基础识别质量和版面稳定性。它们经常同时存在：

  • 倾斜
  • 模糊
  • 印章遮挡
  • 复印噪声
  • 手写标注

这时后面的问题可能还没开始，前面的识别结果就已经不稳了。

处理复杂格式时，更应该关注什么 ​

做这类数据接入时，重点通常不是“先堆更多模型”，而是：

  • 文本提取是否完整
  • 版面结构是否保留
  • 表格关系是否恢复
  • 图片和图表是否需要额外描述
  • 提取结果是否做人工抽检

很多场景下，复杂格式要先做结构恢复，再进入常规 RAG 流程。

如果你正在设计接入方案，更实用的检查点通常是：

  • OCR 后的文本是否和原文大致一致
  • 标题和正文有没有串位
  • 表格是否保留了表头、单位和行列对应关系
  • 图片、图表是否需要额外的说明文本
  • 页眉页脚、页码、目录是否已被当作噪声处理
  • 提取结果是否做过人工抽样校验

这些检查比单纯看“抽出了多少文本”更重要。

一个更现实的落地顺序 ​

如果你现在要接这类数据，比较现实的推进方式通常是：

  1. 先选价值最高、格式最稳定的一批文档。 不要一开始就把所有扫描件、表格、图表一起接进来。

  2. 先建立抽样校验机制。 至少随机抽一些页面，人工对比原文和解析结果，确认主要结构没有明显错位。

  3. 再决定不同格式分别怎么处理。 表格、图表、扫描件最好分开看，不要期望一条解析链路全都做得同样好。

  4. 最后再进入常规 RAG 流程。 也就是在结构质量已经基本可信之后，再谈切块、索引、检索和生成。

这比一开始就追求“全部自动化入库”更现实。

哪些情况先不要急着进 RAG ​

如果你遇到下面这些情况，通常更应该先补解析质量，而不是急着入库：

  • OCR 结果错误很多，关键数字经常识别错
  • 表格表头经常丢失或串列
  • 双栏、多栏 PDF 的阅读顺序经常混乱
  • 图表里的趋势关系无法稳定恢复
  • 页眉页脚、目录、页码大量混入正文

因为这时候继续往后做检索和生成，只会把前面的错误放大。

一个实用判断 ​

如果某类内容的核心意义严重依赖下面这些因素：

  • 版面位置
  • 行列关系
  • 图形关系
  • 视觉布局

那它就不适合被简单当成普通纯文本处理。

更直接一点说：

如果你把它转成一段纯文本之后，读者已经很难再还原原意，那说明这类内容还没准备好进入最基础的文本型 RAG 流程。

一句话总结 ​

复杂格式更难处理，不是因为它们不能成为知识源，而是因为它们的知识往往嵌在“文字 + 结构 + 视觉关系”里。RAG 要真正用好这类内容，首先要尽量把这些关系保留下来。