为什么不能直接把整份 PDF 截图丢给多模态大模型解析？

复杂 PDF 往往包含多栏、表格、页眉页脚、脚注和扫描噪声。直接整页输入容易导致阅读顺序错乱、表格单元格错位、长页信息被压缩或遗漏。生产系统更适合先做版面切块，再按区域调用 OCR、文档解析器或视觉大模型。

多模态大模型能完全替代 OCR 和 Document AI 吗？

通常不建议完全替代。OCR 和 Document AI 更擅长稳定返回文字、坐标、表格和选择框等结构化证据；多模态大模型更适合处理跨区域理解、字段归并、异常解释和复杂版面兜底。

PDF 抽取结果如何做上线验收？

应按字段准确率、表格结构准确率、阅读顺序、置信度分布、人工复核命中率和失败样本回放来验收，而不是只看少量演示文档是否解析成功。

LLM 文档视觉抽取生产实战：用版面切块与置信度审计稳住 PDF 解析质量

背景问题

越来越多企业把多模态大模型接入合同审查、财报解析、保单录入、工单归档、发票核验和知识库构建。最早的做法通常很直接：把 PDF 转成图片，把图片和一个”请提取字段”的提示词一起发给模型，然后等待 JSON 结果。

这种方式在演示阶段可行，但在生产环境很容易失控。原因并不只是模型能力不够，而是文档本身具备很强的版面结构：多栏正文、表格、合并单元格、手写批注、页眉页脚、脚注、印章、复选框、横向表格、扫描倾斜和低清晰度都会影响抽取结果。一个字段被抽错，后续可能进入理赔、风控、财务、法务或客户运营流程，影响远大于普通问答错误。

从主流云厂商的实践来看：

厂商	产品 / 服务	关键能力侧重
OpenAI	Vision API（图片输入）	多图输入、Token 计费、通用视觉理解
Azure	Document Intelligence Layout 模型	文本、表格、选择标记、版面结构抽取
AWS	Textract AnalyzeDocument	TABLES、FORMS、QUERIES、SIGNATURES、LAYOUT
Google Cloud	Document AI Gemini Layout Parser	复杂表格、减少幻觉、layout-aware chunking

结论：生产级文档视觉抽取不是”让大模型看一眼”，而是要设计一条有版面证据、有置信度、有复核闭环的流水线。

核心原理：先保留版面证据，再让模型做语义归并

文档视觉抽取可以分成三层：

第一层：页面证据层

这一层负责保留页面、区域、坐标、文字、表格单元格、选择框、图片区域和置信度。它不急着解释业务含义，而是先回答”页面上实际有什么”。Azure Layout 模型会返回文本、表格、选择标记和结构；Textract 围绕表格、表单、签名、布局等特征输出分析结果；LayoutParser 等工具和论文也说明，文档图像分析的基础是先识别区域和结构，再做后续任务。

第二层：区域理解层

这一层把页面切成标题区、段落区、表格区、表单字段区、签名区、附件说明区等可处理单元。多模态大模型可以在这一层参与：它可以判断跨区域关系、补充标题与表格之间的上下文、解释异常格式，或者在传统 OCR 与表格识别失败时做兜底。但它的输出必须绑定原始证据，而不是直接成为最终事实。

第三层：业务字段层

这一层把页面证据归并成业务系统需要的结构，例如合同编号、甲乙方、保单号、金额、日期、责任条款、付款条件、审批意见。最终结果应包含字段值、来源页码、来源区域、置信度、抽取方法和复核状态。

一个可落地的字段结构通常类似下面这样：

{
  "field": "total_amount",
  "value": "128,500.00",
  "currency": "CNY",
  "source": {
    "page": 3,
    "block_id": "table_3_2",
    "cell": "row_8_col_5",
    "bbox": [0.62, 0.71, 0.91, 0.76]
  },
  "confidence": 0.87,
  "method": "layout_parser_plus_vlm_review",
  "review_status": "auto_accepted"
}

这里的重点不是 JSON 是否漂亮，而是字段值必须能追溯到页面证据。没有证据绑定的抽取结果，即使看起来准确，也很难审计、回放和纠错。

工程落地：一条稳定的文档视觉抽取流水线

1. 文档预处理

生产系统首先要处理输入格式。PDF 可能是原生文本 PDF，也可能是扫描图片 PDF，还可能混合文本层、图片层和手写批注。建议先做：

文档指纹与页数统计
文件大小检查
加密检查与损坏检查
图片清晰度评估

对于扫描件，需要做旋转校正、去噪、分辨率标准化和页面裁边。对于原生 PDF，应优先保留文本层和坐标信息，不要盲目转成整页图片后再 OCR。 原生文本、OCR、版面模型和视觉大模型应是互补关系，而不是互相替代。

2. 版面切块

版面切块是本文的关键点。切块粒度太大，模型会丢失细节；切块太小，又会丢失上下文。一个实用策略是按页面结构分层切块：

粒度	包含内容
页面级	页码、旋转角度、宽高、整体质量
区域级	标题、段落、表格、图、选择框、签名、页眉页脚
单元级	表格单元格、表单键值对、复选框状态、金额字段、日期字段

Google 的 layout-aware chunking 思路值得借鉴：切块不应该把段落和标题、表格和表头割裂开。对于合同条款、财报表格和技术手册，抽取块最好携带上级标题、表头、页码和周边说明，否则模型可能正确读取了文字，却误解了字段归属。

3. 多引擎抽取与兜底

不要把所有页面都交给同一种模型。生产系统可以根据区域类型做路由：

普通正文：优先使用文本层或 OCR。
表格：优先使用表格结构识别，必要时让 VLM 检查表头、合并单元格和脚注。
复选框与签名：使用 Document AI / OCR 的选择标记、签名检测能力，再让模型做业务解释。
异常区域：低置信度、倾斜、模糊、跨页表格、密集小字区域进入 VLM 或人工复核。

这类路由不是为了炫技，而是为了降低成本和错误率。OpenAI 视觉输入会计入 Token；整页高保真输入很贵，也未必比专门的版面解析器更稳定。应把视觉大模型放在最需要语义理解的位置，而不是让它承担所有 OCR 工作。

4. 置信度审计

置信度不能只看模型返回的一个分数。更稳妥的做法是组合多个信号：

OCR 置信度
区域类型
字段规则校验（正则、格式、取值范围）
跨页一致性
数值格式（千分位、小数位、币种）
业务规则（表格合计关系、日期时序）
模型自检结果
历史错误样本相似度

例如金额字段可以检查千分位、小数位、币种、表格合计关系；日期字段可以检查格式、时序关系和合同有效期；身份证、保单号、发票号等可以检查正则和校验位。

低置信度并不一定代表错误，但它必须改变后续动作：自动接受、进入抽样复核、强制人工复核、退回重新扫描，应该有明确阈值。

5. 人工复核闭环

文档抽取系统上线后，人工复核不是临时补丁，而是训练质量体系的一部分。复核界面至少要展示：

字段值
来源页面与来源区域
高亮证据
模型解释
置信度
历史版本

复核人员修改字段后，系统应记录修改前后值、修改原因、文档类型、模型版本和提示词版本。这些数据后续可用于构建回归集。每次更换 OCR、文档解析器、多模态模型或提示词，都应在同一批高风险文档上回放，比较字段准确率、人工复核率和误通过率。

适用场景

最适合采用这套方案的场景通常有三个特征：文档格式复杂、字段结果进入业务流程、错误成本高。

场景	典型挑战
合同抽取	同一金额出现在正文、附件、付款计划表和签章页，需判断哪个是最终有效字段
财报解析	复杂表格、跨页表格、合并单元格和脚注显著影响结果
保险 / 金融 / 政务表单	复选框、手写补充、印章和附件经常影响业务判断

不适合的场景也很明确。如果只是一次性阅读少量清晰 PDF，人工查看或简单 OCR 可能更便宜。如果文档模板高度固定，传统模板抽取和规则引擎可能比通用多模态模型更稳定。

常见误区

误区一：认为 VLM 看图就能保证结构正确

视觉大模型能理解页面，但不等于它天然知道每个业务字段的法律或财务含义。尤其是表格、脚注、跨页内容和多版本附件，模型可能生成看似合理但没有证据支撑的字段。因此，抽取结果必须绑定页码、区域和证据。

误区二：只保存最终 JSON，不保存中间证据

只保存最终 JSON 会让排障非常困难。一旦业务方质疑某个字段，系统无法说明它来自哪一页、哪个表格、哪个单元格，也无法复现当时的模型输入。生产系统应保存原始文件指纹、页面图、版面块、OCR 文本、模型输入、模型输出和字段归并结果。

误区三：把所有低置信度样本都交给人工

人工复核资源有限。更好的方式是分级：

高风险字段、业务规则冲突字段、历史易错模板字段：优先复核
低价值字段：抽样复核
明显质量不合格的扫描件：直接退回重传

误区四：只用少量 Demo 文件验收

文档抽取系统最容易在长尾文件上失败。验收集应覆盖：清晰 PDF、扫描 PDF、多栏文档、复杂表格、横向页面、手写批注、低清晰度图片、跨页表格、页眉页脚干扰和不同模板版本。

上线检查清单

文档入口

限制文件类型、大小、页数和加密状态
记录文件哈希，避免重复处理
对低质量扫描件提前给出失败原因

版面解析

保存页面坐标系、区域类型、阅读顺序、表格结构、选择标记和置信度
对页眉页脚、页码、印章、签名等区域进行显式标记

模型调用

区分普通 OCR、Document AI、VLM 兜底和人工复核，不要把所有页面都送入最高成本模型
请求中应带上区域上下文和明确字段契约

结果治理

保存字段证据、模型版本、提示词版本、解析器版本、置信度、复核状态和回放结果
关键字段必须支持人工更正和审计

评估

按文档类型维护黄金样本集
指标不只包括字段准确率，还应包括表格结构准确率、阅读顺序错误率、低置信度命中率、人工复核率、退回率和单文档成本

参考资料

OpenAI — Images and vision: https://developers.openai.com/api/docs/guides/images-vision
Microsoft Azure — Document Intelligence Layout model: https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout?view=doc-intel-4.0.0
AWS — Amazon Textract AnalyzeDocument API: https://docs.aws.amazon.com/textract/latest/APIReference/API_AnalyzeDocument.html
Google Cloud — Process documents with Gemini layout parser: https://docs.cloud.google.com/document-ai/docs/layout-parse-chunk
LayoutParser: A Unified Toolkit for Deep Learning Based Document Image Analysis: https://arxiv.org/abs/2103.15348
DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis: https://arxiv.org/abs/2206.01062