企业官网建设流程全解析

PDF 解析的技术演进：从规则驱动到 Agent 协作

PDF 是全世界最通用的文档格式，也是最让人头疼的文档格式。它从诞生起就不是为"机器理解"设计的——PDF 只管"把字画在哪"，不管"这段话什么意思"。所以 PDF 解析这件事，几十年来一直是文档处理领域的核心难题。

这篇文章按时间线梳理 PDF 解析的三条技术路线，最后聊一下我们团队WPS开放平台在工程实践中走通的一条新路径。

一、传统 PDF 解析：规则驱动的时代

传统 PDF 解析本质上在做一件事：把 PDF 文件里"画上去"的字符和坐标，还原成机器可读的结构化数据。手段分三条线。

1. 直接解析 PDF 内部结构

PDF 文件本身是结构化的——每个页面是一个内容流（Content Stream），里面是绘制指令：Tj（显示文本）、TJ（带间距显示文本）、坐标变换矩阵等。工具如 PDFBox、PyMuPDF、iText 直接读这些指令，提取出"字符 + 坐标"。

这条路的优点是快，文本保真度高（因为是直接读取，不经过 OCR）。缺点也很明确：拿到的只是一堆带坐标的字符碎片，没有语义。哪些字符属于同一段落？哪个矩形区域是表格？哪个是标题？全要靠下游规则再加工。

2. 传统 OCR 处理扫描件

对于扫描型 PDF（整页是图片），只能走 OCR。传统 OCR（Tesseract、ABBYY、汉王等）的核心是模式匹配：把字符图像做特征提取（笔画、轮廓、拓扑结构），去字符库里比对形状。

传统 OCR 认"形"不认"义"——它知道这个字符是"A"，但不知道它是一个标题的首字母。输出的是字符 + 置信度，版面语义完全丢失。

3. 版面分析：几何规则假设

传统方案的"智能"全靠版面分析模块，而这个模块基于几何假设：

• 表格识别：检测横线/竖线坐标 → 定位单元格边界 → 填字符
• 段落聚类：按坐标距离、行间距、左缩进做聚类
• 标题识别：靠字号大小、字体粗细、位置特征分类

每套新版式都是一次重新调参。合并单元格、跨页表格、多栏排版、图文混排，任意一种都能让规则崩掉。规则的本质是假设 PDF 长什么样，而现实中的 PDF 总能打破你的假设。

传统路线总结：输出是字符 + 坐标 + 版面标签，追求的是确定性和逐字保真，代价是规则脆弱、维护成本随版式复杂度指数增长。

二、大模型时代的 PDF 解析：语义驱动

2023 年之后，大模型改变了文档解析的底层逻辑。核心转变是：不再把 PDF 当成几何对象去"抠"，而是当成视觉内容去"看懂"。

1. 多模态视觉模型（VLM）端到端理解

最直接的路线：把 PDF 页面渲染成图像，丢给多模态大模型（GPT-4V、Qwen-VL、InternVL 等），让它直接"看图输出"结构化结果。

这一步跳过了传统路线里"版面分析 → OCR → 结构重建"的整条链。模型看到一个表格，不需要先检测线框再拼单元格，而是直接理解"这是一个 5 列的采购清单"并输出结构化数据。

突破点：不再需要为每种版式写规则，模型在训练数据中见过足够多的版式后能泛化。

局限：存在幻觉风险（看错但自信），且不保证 100% 逐字保真。对于合规存档、出版级还原等场景，纯端到端还不够。

2. 深度学习版面模型 + 语义化 OCR

传统 OCR 的字符识别模块被深度学习替代：CRNN、Transformer 序列模型直接做"图像 → 文本序列"的端到端识别。版面检测也从线框规则变成了检测模型（LayoutLM、DocLayout-YOLO），在海量文档数据上训练后自动分类区域类型。表格结构识别用 Table Transformer 直接输出 HTML/网格结构，处理合并单元格远比线框检测靠谱。

3. LLM 语义后处理

这条路线最务实：先用传统或深度学习工具把文本粗提取出来，再丢给大语言模型做语义层加工。LLM 负责实体抽取（合同金额、日期、条款）、噪声过滤、版面重排、字段映射，输出结构化 JSON。

核心价值在于容错性——前面的解析再粗糙、顺序再乱，LLM 靠语义理解都能拼回来。

大模型时代路线总结：输出从"字符 + 坐标"升级为**"结构化语义"**，泛化能力大幅提升，但引入了幻觉风险和 token 成本。

三、我们的方案：Multi-Agent 协作 + 视觉闭环

传统方案的核心问题是规则脆弱——版式稍微变一下就崩。大模型端到端方案的核心问题是输出不可控——幻觉、丢字段、格式错位。我们在工程实践中尝试了一条介于两者之间的路线：保留传统方案的结构化中间表示，用多 Agent 协作替代单一流水线，用视觉模型做闭环质检。

下面拆开讲。

预处理：先做图像级修复

不管输入是扫描件还是标准 PDF，第一步统一走图像预处理——清晰化、去摩尔纹、倾斜校正。我们用 Image2Image 模型做这一步，而不是传统的几何变换。原因很简单：摩尔纹、模糊这类问题在传统几何层面很难处理，而生成模型能直接"修复"视觉质量。

Coordinator Agent：用 VLM 做任务调度

这是整个架构最关键的一层。我们没有用传统的"检测 → 分类 → 路由"硬编码流水线，而是训练了一个 Coordinator Agent 做视觉层面的任务调度：

1. 用 VLM 对页面做分层检测：区分修饰层（水印、页眉页脚、装饰线）和内容层
2. 用自研的目标检测模型做精准 BBox 定位 + 阅读顺序推断
3. 决策：页面上的每个区域应该交给哪个专业 SubAgent 处理

为什么不用传统规则？因为 Coordinator 需要做的是"理解"——"这个区域是页眉装饰还是正文内容？"——这种判断传统规则写不全，而 VLM 天然擅长。

四个专业 SubAgent：术业有专攻

Coordinator 把页面拆成不同区域后，路由给四个专职 Agent：

• Text Agent：处理段落、标题层级、字体样式（颜色、加粗）、Unicode 内容提取、Span 切分、公式语义。不只是提取文字，而是理解文本的层级关系和语义角色。

• Table Agent：先判定标准表格还是异型表格，然后做表格线分割、合并单元格识别，输出 HTML/OTSL 结构。对表格类型做判定的好处是：标准表格走高效解析路径，异型表格切到更重的重建逻辑，避免一刀切导致两类都做不好。

• Figure Agent：图形类型识别（流程图/坐标图/图章/二维码），BBox 截图，图片主体提取。图表类内容在传统方案里要么忽略、要么硬提取，我们选择单独处理。

• BG Agent：处理纯色/简单背景的补全、水印识别与去除、前景 Mask 提取。背景处理在传统方案里是预处理阶段的附属操作，我们把它升级为独立 Agent，因为背景干净与否直接影响后续所有 Agent 的输入质量。

统一中间表示：结构化页面数据

四个 Agent 的输出统一汇入一个结构化中间表示：Paragraph → Line → Span → Text。

这个设计借鉴了传统方案的思路——中间表示保证了数据的可检查性和可追溯性。每个 Span 都知道自己属于哪个 Line、哪个 Paragraph，都有坐标信息。这意味着在任何一步出问题，都能定位到具体的层级。

Quality Agent：视觉闭环迭代

这是整个方案最大的差异化点。

传统方案和大多数大模型方案都是"解析一次就输出"，质量好不好看运气。我们加了一个 Quality Agent 做迭代质检：

1. 用解析结果反向生成一个 Tagged PDF
2. 把生成的 PDF 渲染成图像
3. 用 VLM 做视觉 diff——对比原始 PDF 和重建 PDF 的差异
4. 根据 diff 结果调整参数，重新解析
5. 循环直到视觉 diff 可接受

本质上是用模型当自动化 QA：生成一个中间产物，自己审查，自己纠错。这个能力在传统方案里不可能实现——传统方案没有"看懂版面"的能力，自然做不了视觉对比。

传统方案是"解析一次碰运气"，我们是"解析 → 自检 → 迭代"。

多格式输出

最终输出支持三条路径：

• Tagged PDF：Span 级绘制 + 视觉 diff 保真，面向需要格式还原的场景
• Word/PPT/Excel：接入 PDF Convert 模块，面向日常办公文档转换
• OOXML 端到端：VLM 理解 → 直接生成 OOXML → 渲染为 Word，面向需要高保真 Word 输出的场景

四、几个设计决策的取舍

为什么是 Multi-Agent 而不是单一流水线？

MinerU、Marker 等开源方案是单一流水线——所有版面元素过同一条管道，每个模块串行处理。好处是简单可靠，坏处是改一个模块容易影响另一个。

Multi-Agent 的好处是每个 Agent 可以独立迭代。Table Agent 的表格识别算法升级了，不影响 Text Agent；BG Agent 的去水印逻辑调了，不需要重新跑整个流水线。代价是 Coordinator 的调度复杂度更高，以及 Agent 之间的数据传递有开销。

为什么用 VLM 做质检而不是纯指标评估？

传统方案用字符级匹配率（Precision/Recall/F1）评估解析质量。但这些指标反映不了版面还原度——字符全对了，但表格跑偏了、标题层级错了、图文位置反了，传统指标照样打高分。

VLM 视觉 diff 评估的是"看起来像不像"，虽然不精确，但更接近人类对文档质量的感知。

为什么要有中间表示而不是直接端到端输出？

纯 VLM 端到端方案（直接 PDF 图片 → 结构化 JSON）看起来最简洁，但问题是不可调试。出了错不知道是哪一步的问题。

中间表示（Paragraph → Line → Span → Text）保证了每个层级都有明确的数据结构，出了问题能精确定位：是 Span 切分错了？还是 Line 聚类错了？还是 Paragraph 识别错了？

五、写在最后

PDF 解析的技术演进，本质上是在"确定性"和"理解力"之间找平衡。

传统方案确定性高但理解力弱——能精确还原字符，但不懂版面语义。大模型方案理解力强但确定性低——能理解内容含义，但输出可能有幻觉。

我们目前的方案试图两头都拿：用结构化中间表示保确定性，用 Agent 协作 + VLM 闭环保理解力和质量。这不一定是最优解，但至少是在工程上走得通的一条路。

如果你在做类似的情况，或者遇到了相似的痛点，欢迎交流。联系方式：yinlonghan@wps.cn