PDF 解析到底难在哪？RAG 真正读懂 PDF，关键在这一步

把一批 PDF 导入知识库后，大模型给出的答案却频频“翻车”：有时答非所问，有时甚至会编出原文中根本不存在的内容。

问题其实未必出在大模型上。很多时候，我们都没有注意到：其实PDF 在进入 RAG 系统的那一刻，内容结构就已经被破坏了。

不少 PDF，特别是缺少结构化标签的 PDF，主要保存的是字符、坐标和样式信息，并没有完整记录段落、表格以及阅读顺序。它会告诉打印机“在坐标（x，y）的位置放置字符 A”，却不会说明“这段文字属于上一节的第三段”。

如果 PDF 中的物理坐标顺序与人类的阅读逻辑不同，那么只是简单按照位置提取内容，就可能把双栏论文的左右栏拼在一起，把跨页表格拆成多个片段，甚至切断一段话的首尾。

在这种情况下，由于输入 RAG 系统的内容已经错乱，所以大模型后续即使能够生成流畅的回答，也很难保证结论正确。轻则回答跑题，重则输出看似合理、实际错误的信息。尤其是在金融研报、合同审查等场景中，这类错误甚至会转化为实际的决策风险。

解决这个问题，关键是调整 PDF 解析方式：把 PDF 从一组面向打印和显示的内容指令，还原成带有逻辑结构的知识文本。

这正是合合信息通用文档解析（xParse）所处理的问题。

PDF 的“双重身份”，是解析中最棘手的地方

PDF 在 RAG 系统中容易“水土不服”，主要与两个特点有关：文件来源形态多样，并且内容存储方式特殊。

形态一：文本层 PDF

由 Word 或排版软件导出的 PDF，通常带有可选中的文字层。虽然这类文件可以直接提取文字，但是它棘手的地方在于内容过于碎片化。

文件往往不会明确记录“这是一个段落”或“这是一个表格”，而是会保存单个字符的坐标、字体和样式。如果页面采用双栏排版，那么按照坐标顺序提取时，左栏底部和右栏顶部就可能被错误拼接。

跨页表格也会遇到类似问题。表头可能位于上一页末尾，数据则延续到下一页开头。普通提取工具通常会把它们识别成两个互不关联的内容片段，原本完整的表格关系就这样丢失了。

形态二：扫描件 PDF

纯图像型扫描件 PDF，本质上是一组页面图像，文件中通常没有可以直接提取的有效文字层。

常见处理方式是先通过 OCR 把图片转换成文字，再进行内容提取。固然 OCR 能解决“图片中没有文字层”的问题，但是扫描件质量会直接影响识别结果。

倾斜、阴影、模糊、水印和印章遮挡，都可能造成文字或数字识别错误。如果 OCR 阶段已经把表格中的数字、合同金额或日期识别错了，那么下游大模型通常也很难自行纠正。

企业知识库里的 PDF 往往同时包含这两种形态。如果一套解析方案只能处理其中一种，那么面对另一种文件时，识别准确性和结构还原效果就容易出现问题。

实践中，不少团队使用开源工具处理扫描件时，会遇到识别率下降的问题，于是再增加一套工具处理文本层 PDF。结果往往是维护两三条并行链路，调试成本成倍增加，并且出现问题后，很难快速判断错误来自哪一条处理链路。

为什么只提取文字还不够？

面向大模型的 PDF 解析，目标不是简单地把文字“抠”出来，而是把 PDF 的物理布局重新组织成人类能够理解的逻辑结构。

系统需要识别哪些内容是标题，哪些内容属于正文；还要判断表格中的每一行对应哪一列表头，以及跨页内容应该如何拼接成完整单元。

xParse在处理 PDF 时，主要完成以下几类工作。

跨页表格自动拼接

当系统检测到表格跨页时，xParse 会判断相邻页面的表格结构是否一致，并把后续页面缺失的表头信息自动继承下来。

如果合并单元格跨越页面，那么系统会识别相关的跨页属性，把分散在两页中的内容合并成完整的逻辑单元。最终输出的是一个相对完整的表格对象，而不是多个彼此独立的表格碎片。

多栏阅读顺序还原

对于双栏或三栏排版的 PDF，xParse 会首先分析页面中的栏区边界，再按照“先左栏、后右栏、再处理跨栏元素”的顺序重建阅读路径。

如果页面中出现宽度超过单栏的表格或图片，那么系统会把它识别为独立元素，并插入对应的阅读位置，同时尽量保留图片、表格与上下文之间的关联关系。

标题层级自动构建

xParse 会结合字体大小、加粗等视觉特征与语义相似度分析，判断文本片段对应的标题层级，并识别标题与下属正文之间的从属关系。

虽然标题与正文之间可能夹着图表，或者分别位于不同页面，但是系统仍会通过版面分析判断内容归属，并构建相应的文档结构。

完成上述处理后，xParse 可以把解析结果输出为 Markdown 或 JSON。这两种格式更适合作为大模型和 RAG 系统的输入，下游系统也可以根据自己的分块策略与检索需求继续处理。

扫描件 PDF 的“低质量图”怎么救？

扫描件 PDF 的难点不只在于“识别文字”，还在于能否先把文字看清楚。

手机拍摄的合同可能存在页面倾斜和阴影，历史档案扫描件可能模糊或带有水印，盖有红章的 PDF 还可能出现文字被部分遮挡的情况。因为这些问题会限制 OCR 的识别效果，所以图像预处理是扫描件解析中的重要环节。

而xParse就内置了图像预处理能力。自动切边矫正可以检测页面的倾斜角度，并将页面旋转到水平状态；如果图像存在透视变形，那么系统还会进行梯形还原。

智能去水印和去印章功能则通过深度学习模型分离前景干扰与底层文字，尽可能降低水印和印章对识别过程的影响，并识别没有被完全遮挡的文字区域。这些处理会在解析流程中自动完成，通常不需要用户额外调用独立的图像处理接口。

在表格识别方面，xParse 不只是提取单元格里的文字，还会尝试还原表格的逻辑结构，包括表头、数据区域以及单元格之间的行列关系。

对于无线表格，也就是没有边框线的表格，系统会通过文本坐标、对齐方式和字体样式推断行列边界。面对合并单元格与嵌套表头时，也可以尝试还原层级关系，并输出结构化数据。

文档解析终究存在能力边界。如果印章遮挡严重、文字笔画完全断裂，或者原始图像分辨率很低，那么识别结果仍可能出现偏差。

这类文档通常需要加入人工抽检。特别是涉及金额、日期、合同编号等关键字段时，保留复核机制会更稳妥。

企业部署 PDF 解析时，还需要评估什么？

PDF 解析质量会影响大模型回答的可信度，但在企业场景中，处理速度和数据安全同样需要纳入评估。

在处理速度方面，xParse 分别针对在线单文档和离线批量处理场景进行了优化。具体吞吐量会受到文档类型、文件大小以及部署环境影响，因此更适合结合真实文档样本进行 POC 测试。

在部署方式方面，xParse 提供三种选择：

云端 API：适合快速验证和互联网服务场景，可以开箱使用。

私有化部署：可以部署在企业本地服务器中，支持数据在企业本地环境内处理，并且支持信创环境适配。

端侧 SDK：主要面向扫描仪、扫描笔等硬件设备的集成场景。

如果企业对数据安全要求较高，那么可以选择私有化部署；如果当前目标是快速验证产品能力，那么云端 API 通常更方便。企业可以根据自身的 IT 架构、数据安全要求和业务场景选择对应方案。

企业实际处理的文档也很少只有 PDF，往往还会混合 Word、Excel、PPT 和图片。xParse 使用一套统一 API 覆盖上述多种文件格式，并且统一输出为 Markdown 或 JSON。

这样可以减少针对不同格式重复开发解析链路的工作，也能降低研发团队长期维护多套处理链路的成本。

投研知识库场景下，解析环节能带来什么变化？

假设某金融机构正在搭建基于内部研报和公告的投研知识库。该机构每年需要处理大量 PDF，包括采用双栏排版的行业研报、包含跨页财务报表的上市公司年报，以及带有红色公章和手写批注的扫描件公告。

在原有方案中，文本层 PDF 和扫描件 PDF 需要分别进入不同的处理链路。跨页表格经常被拆散，表格中的财务数据也反复出现错位，进而影响知识库问答的准确率。

引入 xParse 后，预期可以把不同来源的 PDF 纳入统一解析链路：跨页表格自动拼接，多栏内容按照识别出的阅读顺序输出，印章和手写批注对底层文字识别的干扰也有所降低。

解析结果可以通过 Markdown 格式接入 RAG 系统。如果前置解析中的结构错误减少，那么后续分块、检索和问答所使用的数据基础也会更稳定，并且有望减少因 PDF 解析错误造成的回答偏差。

点击下方图片，了解更多合合信息通用文档解析（xParse）产品信息，申请获取 POC 测试支持。