智能文档清洗实战

很多人在处理合同、报告等文档时，习惯把OCR后的原始文本直接丢给大模型，期望一次性生成所有结果。这种做法看似省事，实际上工程稳定性极差。经过多个项目的实践复盘，我们意识到：真正靠谱的智能文档清洗流程，核心不在于“让模型看文档”，而在于先把输入清洗干净，再按不同目标拆分处理链路。

一、低质量文档的真实痛点

实际业务中，输入质量往往极不稳定。扫描件、拍照件、带水印PDF是常态，同一份文档里既有语义问题也有格式问题，输出还不能只是摘要，必须能生成可交付的结构化报告。如果跳过清洗环节直接处理，模型输出很容易混杂，后续展示和报告导出都难以稳定。

一个典型的场景是合同审查：法务团队上传的PDF可能来自手机拍照、传真件或多年扫描存档，页眉页脚夹杂无关标记，表格内容跨页断裂，甚至出现印章遮挡文字。这些“脏数据”一旦直接喂给大模型，轻则漏判关键条款，重则产生完全错误的解读。

二、智能文档清洗的核心目标

基于上述痛点，文档清洗需要明确以下几个目标：

• 去除HTML标签、特殊字符、冗余内容（如页眉页脚、页码）
• 统一编码与换行符，处理全角/半角符号混用
• 保留标题层级、列表结构与语义分段，确保文档骨架不丢失
• 对于扫描版PDF，必须接入OCR进行文字识别，否则无法提取有效内容

这些目标看似基础，但决定了后续所有分析环节的上限。清洗做得越扎实，模型的理解就越稳定。

三、解析层设计：统一中间层是关键

在实践过程中，我们建议把文档处理拆成四层架构：

1. 解析层：将低质量文档转为统一的文本结构（如 markdown + pages）
2. 审阅层：将不同类型的问题（语义风险、格式规范）分开处理
3. 汇总层：合并各维度的分析结果
4. 交付层：导出结构化报告（如 Word、PDF 或 API 数据）

其中，解析层是整个流水线的基石。一个可参考的解析接口参数配置如下：

python

params = {
    "parse_mode": "auto",
    "crop_dewarp": 1,       # 切边矫正，适合扫描件、拍照件
    "remove_watermark": 1,  # 去除水印
    "get_image": "both",    # 保留页面图像，便于证据定位
}

• crop_dewarp=1 专门针对扫描件和拍照件的倾斜、黑边问题进行矫正
• remove_watermark=1 对带水印的合同或报告尤其重要
• get_image=both 保留页面图像，后续可用于证据预览或原文对照

解析完成后，输出统一的 markdown + pages 结构：

• markdown 承载正文、标题、条款结构
• pages 承载分页信息，用于页面预览或原文定位

这样做的好处非常直接：无论原始文件是 PDF、DOC、DOCX 还是扫描图片，在进入审阅层之前都会收敛成同一种输入对象。整个系统后续只面向这个统一中间层，不再与原始文件类型耦合。

四、清洗策略的实战要点

文档清洗并非简单的文本替换或正则匹配。根据文档类型和业务场景，需要采用差异化的处理策略。

格式清理

• 使用正则表达式去除 HTML 标签、特殊字符、多余空格
• 移除页眉页脚页码（通常匹配 第X页 或 Page X 等模式）
• 过滤掉长度小于 10 字符的无效行（如孤立的制表符或分割线）

编码统一

• 将全角符号转为半角（中文标点除外）
• 统一换行符为 \n（处理 Windows \r\n 与 Linux \n 混用）
• 移除控制字符如 \x00，处理乱码并统一为 UTF-8 编码

表格处理

• 将表格转为 Markdown 格式或 JSON，保留行列关系
• 可使用 camelot 或 tabula 提取表格后再序列化为文本，避免行列错位

扫描件识别

• 对于文本型 PDF，直接使用 PyMuPDF 提取文本
• 对于扫描型 PDF，必须启用 OCR。判断依据包括：图像区域较大、每页平均文本长度接近零等特征

值得一提的是，启信慧眼在企业信息核查场景中，会对接大量的年报、审计报告、诉讼文书等 PDF 文件。这些文件往往混合了印刷体表格、手写注释和公章遮挡区域。通过上述清洗策略，可以将企业名称、统一社会信用代码、股东信息等关键字段从杂乱的版面中准确提取出来，为后续的合规分析提供可靠的数据基础。

五、为什么要拆成多条审阅链路

以合同审查为例，一份文档里至少存在两类完全不同性质的目标：

• 法律语义风险：如责任条款是否完整、违约责任是否明确、争议解决方式是否合理
• 文本规范与一致性问题：如错别字、前后术语不一致、编号格式错误

如果把这两类问题塞进同一个 Prompt，模型输出很容易混杂——既可能把错别字误判为法律风险，也可能遗漏真正关键的条款缺失。

更合理的做法是：同一份 markdown，两份不同 Prompt，两棵不同 JSON 树。

解析后的统一中间层可以并行执行两条审阅链路：

• 链路 A：条款风险审阅（输出 clause_review + parties）
• 链路 B：规范审阅（输出 norm_review）

最后汇总两份结果，导出结构化的审查报告。这种分路处理的架构有四个明显收益：

1. 每个 Prompt 职责单一，模型输出更稳定
2. 两条链路可以独立迭代优化，互不干扰
3. 后续扩展新的审阅维度（如合规性审查、行业特定条款检查）只需新增链路
4. 前端展示和报告导出可以直接消费固定 JSON，无需再做二次解析

六、总结

智能文档清洗看似只是预处理环节，实际上决定了整个系统的上限。我们通过多个项目的复盘得出的核心经验是：

• 不要跳过清洗环节直接让模型处理原始文档
• 尽早建立一个统一的中间层（如 markdown + pages），屏蔽原始文件格式差异
• 根据文档类型采用差异化的清洗策略（扫描件、表格、水印等各有不同处理方式）
• 将不同类型的分析目标拆分成独立的处理链路，而不是塞进同一个 Prompt

把解析和清洗做扎实，后续的审阅、汇总、交付才能真正稳定可控。反之，如果在这一步偷懒，后面所有环节都会被不稳定的输入所拖累。