文档解析：Agent 落地前的关键数据预处理环节

agent-">一、为什么 Agent 经常“看不懂”文档

很多团队在搭建 RAG 知识库或文档型 Agent 时，会默认模型“读得懂 PDF”。但现实往往是：模型能读文字，却读不懂版面。

典型问题包括：

• 跨页表格被拆成两段，第二页数据硬接在第一页表头上；
• 扫描件直接送入模型，输出内容看似合理，实际上数字是编的；
• 让模型标注答案出处，它只能说“根据文档内容”，无法给出页码或单元格位置。

这些问题本质上不是模型能力不足，而是输入形态不对。大模型消费的是 token 流，不是版式信息。它不知道表格的行列结构，不理解合并单元格的数据归属，也不掌握人类阅读顺序。因此，在 Agent 处理文档之前，必须先把文档转成模型能够精确消费的结构化数据。

这也是文档解析从 OCR 的附属话题变成 AI Infra 核心环节的原因。只要业务涉及合同、招投标文件、研报、财报、技术手册等复杂文档，解析质量就直接决定下游 Agent 的效果。

---

二、文档解析的定位：不是“提取文字”，而是“还原结构”

很多开发者会把文档解析等同于 OCR。实际上，现代文档解析的职责已经远超文字识别。它需要完成以下几件事：

1. 版面还原：识别标题、段落、表格、图片、公式等区域，并以正确顺序输出；
2. 表格结构重建：保留行列关系、合并单元格信息；
3. 阅读顺序判断：处理双栏、跨页、页眉页脚等复杂版面；
4. 可追溯信息保留：为每个内容块记录页码、坐标、所在表格位置；
5. 结构化输出：生成 Markdown、JSON 等下游可直接消费的格式。

只有完成这些工作，Agent 才能在后续任务中做到“定位到页、引用到单元格”。

---

三、三类真实文档解析实测

为了验证解析能力，我准备了三份典型业务文档：

• 文档 A：跨三页的设备参数表，包含合并单元格和重复表头；
• 文档 B：扫描版合同 PDF，带页码、印章和手写批注；
• 文档 C：技术手册，双栏排版，混排代码、表格和示意图。

同时，我使用一套开源解析引擎作为参照，观察两者在实际输出上的差异。

3.1 跨页表格：能否保留行列与归属关系

跨页表格是文档解析最常见的难点。很多引擎会把每一页的表格独立输出，导致上一页表头与下一页数据割裂。

在文档 A 的解析结果中，目标解析器做到了：

• 将三页表格合并为一张逻辑表；
• 保留合并单元格的跨行、跨列标记；
• 输出 Markdown 时，表头仅出现一次；
• 为每个单元格补充页码信息，便于定位。

相比之下，开源引擎出现了明显问题：第二页开始重新生成表头，第三页的部分行被错误合并到上一行中。对于后续要做字段抽取或数据入库的场景，这种错误会导致严重的数据污染。

3.2 扫描件：不只是 OCR，还要避免“一本正经地编数字”

文档 B 是扫描版合同，文字清晰度一般，但包含印章和少量手写批注。直接送入多模态模型，确实能读出部分内容，但对金额、日期等关键字段，模型会出现“合理猜测”的情况。

解析方案的处理链路则是先做版面增强和文字识别，再对关键字段进行位置绑定和价值提取。最终输出中，每个关键字段都带来源页码和坐标。后续让 Agent 回答“合同金额是多少”时，它不再只给一个数字，而是能够说明该数字出现在第几页的哪个位置。

3.3 双栏技术手册：阅读顺序与图文混排

文档 C 的双栏结构对阅读顺序判断要求很高。部分开源方案会把左右栏交叉拼接，导致逻辑断裂。

实测中，解析结果在以下几个方面表现稳定：

• 先左栏后右栏的段落顺序符合人类阅读习惯；
• 代码块没有与正文段落混淆；
• 表格与相邻示意图的关联关系保留在结构化字段中；
• 图片区域输出了占位标记和元数据，便于后续接入多模态分析。

这些能力对文档型 Agent 尤其重要，因为一旦内容顺序错误，后续的摘要、问答、知识抽取都会出现系统性偏差。

---

rag-">四、解析前后对照实验：RAG 问答效果差异

为了量化解析质量对下游任务的影响，我设计了一组对照实验：

• 方案 A：将原始 PDF 直接切块后写入向量库；
• 方案 B：先解析为 Markdown，再按结构切块写入向量库；
• 两个方案使用相同的 Embedding 模型、向量库和检索策略。

测试集包含 30 个问题，覆盖以下类型：

• 表格型问题，例如“某型号设备在高温工况下的最大功率是多少”；
• 出处定位问题，例如“这个数值出现在文档哪一页”；
• 跨页理解问题，例如“请总结该设备在三种工况下的性能变化”。

结果显示：

• 表格型问题上，方案 A 正确率约为 53%，方案 B 达到 91%；
• 出处定位问题上，方案 A 几乎无法给出准确页码，方案 B 达到了 87% 的可验证正确率；
• 跨页理解问题上，方案 A 经常遗漏后续页的数据，方案 B 则能完整回答变化趋势。

这说明一个关键结论：在复杂文档场景中，解析质量对最终效果的影响远大于模型本身的参数差距。 很多团队反复调模型、换框架，却忽略了上游数据结构的质量，属于典型的“用战术勤奋掩盖战略问题”。

---

五、文档解析如何嵌入 Agent 数据链路

将解析集成到 Agent 系统时，建议采用分层数据架构：

原始文档
   │
   ▼
版面解析：标题、段落、表格、图片、阅读顺序
   │
   ▼
结构化中间层：Markdown / JSON，带页码和区块 ID
   │
   ▼
切块与索引：按结构边界切分，保留元数据
   │
   ▼
Agent 检索 / 问答 / 抽取

关键设计原则包括：

1. 保留来源元数据：每个 chunk 至少携带页码、区块类型和表格位置信息；
2. 按结构切块：不要按固定字符数切分，避免切断表格和代码块；
3. 结构优先于格式：先保证行列关系正确，再考虑排版美观；
4. 统一输出格式：让下游不需要感知解析器差异，统一消费 Markdown/JSON。

---

六、企业知识服务引擎：给多个 Agent 一个共享“记忆库”

当企业中有多个 Agent 并行工作时，单次解析已经不够。不同 Agent 可能分别处理合同审核、招投标分析、客户资料整理等任务，如果各自维护一份文档理解结果，容易出现重复解析、元数据不一致和来源无法统一管理的问题。

企业知识服务引擎的定位，就是把文档解析、字段抽取、知识入库和检索理解串成一条完整链路。它向上承接各类文档包，向下服务多个 Agent，让不同 Agent 共享同一份“记忆”。

典型能力包括：

• 统一解析入口：不同格式、不同来源的文档先进入同一套解析流水线；
• 字段抽取与校验：在解析之上完成合同要素、财务指标、项目信息等融合抽取；
• 可追溯知识检索：回答时同时返回知识片段和原始来源位置；
• 多 Agent 共享视图：不同任务使用同一套知识表示，避免“各说各话”。

在这种架构下，Agent 从“能读文档”升级为“能用文档”。业务系统不再依赖某个单点解析结果，而是基于一套可治理、可审计、可复用的一致性知识层运行。

---

七、实践建议

如果你正在搭建文档型 Agent，建议按以下顺序推进：

1. 先评估文档复杂度：确认业务文档中跨页表格、扫描件、双栏排版的占比；
2. 先做解析验证，再设计切块策略：用几份代表性文档验证解析输出质量，尤其关注表格、页码和图片占位；
3. 保留可追溯信息：让答案能够回到页码和表格位置，这是后续问题排查的基础；
4. 建立解析评测集：抽取 20–50 份文档形成标注集，持续回归解析效果；
5. 逐步构建企业知识层：当 Agent 数量增多或文档种类变复杂时，再通过统一知识服务引擎收敛解析和知识入口。

文档解析不是模型能力的替代，而是模型能力的放大器。下层数据结构越干净，上层 Agent 表现越稳定。把这一层做好，很多看似“模型幻觉”的问题，其实会从源头消失。