#图片、PDF 和 OCR 文档理解的方案阶梯

图片和文档理解常被误解成“让模型看一眼”。在真实系统里，模型看到的往往不是一张清晰图片，而是截图、扫描件、拍照票据、跨页 PDF、表格、手写备注、印章、低清水印和多版本附件。

这篇文章关注图片、PDF 和 OCR 文档理解的工程阶梯：什么时候可以直接上传，什么时候只需要预处理，什么时候必须建设可追溯的文档管线。

#场景

假设一个企业采购和财务系统要自动处理供应商资料。

供应商会上传营业执照、发票、报价单、合同 PDF、银行账户证明和产品资质截图。财务希望系统抽取发票代码、金额、税号和开票日期；采购希望比对报价条款；法务希望标出付款、违约、保密和自动续约条款；客服希望根据用户截图判断系统报错。

输出会被不同角色消费：

• 财务字段会进入报销和付款流程。
• 采购摘要会进入比价表。
• 法务风险会进入合同审查队列。
• 客服截图解释会变成回复草稿。

常见失败样本包括：

• 手机拍照发票有反光，金额和税号 OCR 错。
• 合同 PDF 是扫描件，页码和章节无法直接解析。
• 报价单表格跨页，表头在上一页，模型只看到数据行。
• 截图里有内部后台地址、客户姓名和手机号。
• 合同有两个版本，文件名相似，系统混用了旧版本。
• 模型总结“付款周期 30 天”，但无法指出页码和条款原文。

#问题类型

图片和文档理解可以拆成几个不同问题。

适合模型处理的是语义解释、字段候选、跨段归纳和风险说明。应该由程序处理的是文件可信度、OCR 坐标、页码、字段类型、金额日期格式、权限和版本。

必须人工确认的包括：付款金额、银行账号、合同风险结论、资质有效性、对外承诺和任何会触发财务或法务流程的字段。

#收益/成本判断

收益包括：

• 减少人工看图、读 PDF 和录字段的时间。
• 把文档内容转成可搜索、可统计、可审计的数据。
• 提高财务、采购、法务和客服流转速度。
• 用页码、坐标和原文证据降低误判争议。
• 让复杂文档进入 RAG、工作流和结构化系统。

成本包括：

• OCR、版面解析、表格抽取和索引维护。
• 文件存储、权限、脱敏和生命周期管理。
• 字段 schema、业务校验和人工复核界面。
• 不同文件模板、扫描质量和语言的长期适配。
• 评估集、回放和错误归因。

低风险截图解释、短文档摘要和人工参考场景，可以接受模型偶尔遗漏。财务、法务和自动化流程则必须把错误代价算进去：一个金额识别错、条款漏判或版本混淆，可能比人工慢一点更糟。

#何时简单上传足够

简单上传适合：

• 单张截图或照片清晰，用户只需要自然语言解释。
• PDF 页数少、文本可复制、版式简单。
• 输出只是草稿或参考，不进入数据库。
• 用户会逐字检查结果。
• 不要求页码、坐标、置信度和字段级审计。

例如客服上传一张报错截图，让模型解释“这个错误大概和权限有关，请检查当前账号是否有项目管理员权限”。如果客服会自己核对并编辑回复，直接上传就能起步。

#何时预处理足够

轻量预处理适合输入稍微混乱，但流程仍然低风险：

• 图片需要自动旋转、裁剪、压缩、去除空白边。
• OCR 只用于给模型提供可读文本，不直接入库。
• PDF 需要按页提取文本，但不需要复杂表格和引用。
• 文件里可能有手机号、邮箱、订单号，需要先遮挡或脱敏。

这时系统可以在上传后做基础检查和 OCR，把图片、文本和简短提示一起交给模型。重点是提升可读性和减少明显泄漏。

#何时需要工程管线

需要工程管线的信号包括：

• 批量处理票据、合同、资质和报表。
• 输出字段会入库、对账、付款、审批或触发工具。
• 文档长、跨页、模板多、表格多或扫描质量不稳定。
• 用户要求“指出第几页第几条”。
• 需要区分版本、合同主体、附件、修订痕迹和签署状态。
• 需要权限控制、审计、错误回放和人工复核。

工程管线要把文档变成可追踪对象，而不是一次性 prompt 输入。

#方案阶梯

#第一层：文件检查和输入治理

先限制文件类型、大小、页数、分辨率和来源。对图片做方向检测、压缩和清晰度检查；对 PDF 区分文本 PDF、扫描 PDF 和混合 PDF；对敏感截图做 PII 和水印检测。

这一层的收益是防止明显坏输入进入后续流程。成本主要是上传规则、错误提示和文件元数据记录。

#第二层：OCR 和版面解析

OCR 不只是得到一串文本。生产系统更需要：

• 文本内容。
• 页码和坐标。
• 置信度。
• 区块类型：标题、段落、表格、页眉、页脚、印章、签名。
• 图片和表格与正文的关系。

坐标和页码是后续复核的基础。没有它们，模型即使答对，也很难让用户相信。

#第三层：结构化字段抽取

字段抽取需要 schema 和业务校验。

{
  "invoiceNumber": "string",
  "sellerTaxId": "string",
  "buyerName": "string",
  "totalAmount": "number",
  "issuedAt": "YYYY-MM-DD",
  "evidence": [
    {
      "page": 1,
      "bbox": [120, 340, 520, 390],
      "text": "价税合计..."
    }
  ],
  "confidence": "high | medium | low"
}

模型可以抽候选字段，但程序要校验金额格式、税号长度、日期范围、币种、主体一致性和重复文件。

#第四层：长文档切分和检索

合同、报告和说明书不能简单整份塞进模型。需要按标题、条款、表格和附件切分，并保留 metadata：

• 文档 ID、版本、上传人和权限。
• 页码、章节、条款号和附件名。
• 文档类型、主体、日期和有效状态。
• OCR 置信度和解析来源。

检索结果要带原文证据。用户问“是否自动续约”，系统应该回答结论，同时引用具体条款和页码。

#第五层：工作流、复核和评估

当输出进入业务流程，要补齐状态机：

• 待解析、解析失败、待抽取、待复核、已确认、已入库、已驳回。
• 低置信字段进入人工队列。
• 人工修改要反写样本集。
• 每次 OCR、模型、prompt、schema 更新都要回归评估。

#方案选型表

#反模式

第一种反模式：只保存模型答案，不保存证据。

文档理解必须能回到原文。没有页码、坐标、原文片段和文件版本，线上争议无法复盘。

第二种反模式：把 OCR 文本当成真实数据。

OCR 会把 0 和 O、1 和 I、金额小数点、日期分隔符识别错。入库前必须做格式、范围和业务一致性校验。

第三种反模式：跨页表格按页独立处理。

很多报价单和报告的表头、单位、币种在上一页。按页切开会让模型失去上下文。

第四种反模式：所有 PDF 用同一种策略。

文本 PDF、扫描 PDF、图片型合同和复杂报表需要不同解析方式。统一塞进模型会浪费成本，也降低质量。

第五种反模式：把低置信字段静默填默认值。

未知、缺失、解析失败和业务默认值必须区分。否则后续流程会把系统失败当成真实字段。

第六种反模式：忽略上传图片里的隐私和内部信息。

截图和照片常包含手机号、后台 URL、订单号、员工姓名和水印。预处理阶段就要识别和遮挡。

#工程清单

• 场景边界：截图解释、字段抽取、长文档问答还是业务审批是否明确。
• 文件治理：类型、大小、页数、分辨率、版本和权限是否记录。
• 预处理：旋转、裁剪、去噪、OCR、表格抽取和元数据清理是否可回放。
• 证据定位：页码、坐标、原文片段、条款号和时间版本是否保留。
• 结构化输出：字段 schema、枚举、空值策略、置信度和证据数组是否定义。
• 业务校验：金额、日期、税号、主体、币种、重复文件和权限是否校验。
• 人工确认：高风险字段和低置信样本是否进入复核队列。
• 可观测性：OCR 置信度、解析失败率、字段错误率、重试次数和人工修改是否记录。
• 评估体系：是否覆盖清晰图、低清图、扫描 PDF、表格、跨页和多版本样本。
• 成本延迟：OCR、视觉模型、长文档检索、缓存和超时策略是否明确。

#小结

图片和 PDF 理解的关键不是“模型能不能读”，而是输入质量、证据定位和输出契约。

低风险、短输入、人工参考时，直接上传或轻量预处理足够。只要字段要入库、文档要审计、结论要被业务使用，就需要 OCR、版面解析、结构化校验、检索引用、人工复核和评估闭环。