ARTICLE · 1081216
多模态文档:从 OCR 到真正读懂 PDF
多模态文档智能，不只是把图片里的字识别出来，而是让 AI 理解文档的结构、表格、字段、章节、图表、签名和版面关系。
企业文档不是纯文本，真正难的是“读懂格式背后的业务含义”。
OCR 和文档智能有什么区别
OCR 主要做：
图片或扫描件 -> 文字文档智能要做：
图片/PDF/表格/扫描件 -> 结构化信息 + 位置 + 关系 + 业务字段比如一张发票，OCR 能识别文字：
金额 1280.00
税号 913...
日期 2026-07-01文档智能要知道：
• 哪个是发票金额。 • 哪个是税额。 • 哪个是购买方。 • 哪个是销售方。 • 表格行列怎么对应。 • 章和签名是否存在。
为什么企业文档难
企业文档经常很复杂：
• PDF。 • 扫描件。 • 手写文字。 • 表格跨页。 • 合同条款。 • 发票票据。 • 身份证件。 • 图表和图片。 • 多栏排版。 • 印章、签名、二维码。
这些不是普通文本模型能直接处理好的。
主流工具在做什么
Azure 官方介绍中提到，Document Intelligence 可以从 PDF、图片和表单中提取文本、键值对、表格和文档结构。AWS Textract 文档也强调可以分析表格、表单、选择元素和签名。
从模板抽取到生成式抽取
传统文档抽取常依赖模板：
这个字段在左上角
那个字段在第 3 行第 2 列模板适合固定格式，比如标准发票。
但很多文档格式不固定：
• 不同供应商合同。 • 不同银行流水。 • 不同地区表格。 • 不同扫描质量。
生成式抽取的方向是：让模型根据语义和版面理解字段，而不是只靠固定坐标。
Azure 文档里也提到 custom generative extraction，面向非结构化和模板变化的文档。
文档智能能用在哪
它的核心价值是把非结构化文档变成结构化数据。
文档智能的输出应该长什么样
不要只输出一段摘要。
更好的输出是结构化 JSON：
{
"invoice_number": {
"value": "FP20260701001",
"confidence": 0.98,
"page": 1,
"bbox": [120, 80, 260, 110]
},
"total_amount": {
"value": "1280.00",
"confidence": 0.96,
"page": 1,
"bbox": [420, 680, 520, 710]
}
}位置和置信度很重要。它们让人能回到原文核查。
测试文档智能要看什么
文档智能测试不能只用干净样本。真实扫描件很乱。
一个测试用例示例
case_id: doc_ai_001
document: "扫描版发票 PDF"
expected_fields:
- "发票号码"
- "购买方名称"
- "销售方名称"
- "金额"
- "税额"
- "开票日期"
expected_behavior:
- "字段值正确"
- "返回字段所在页码和位置"
- "低置信度字段标记人工复核"
forbidden_behavior:
- "把税额当总金额"
- "没有识别到字段却编造"
- "输出完整身份证号到普通日志"和 RAG 的关系
很多 RAG 失败，不是检索问题，而是文档解析问题。
比如 PDF 表格被解析乱了，后面向量检索再强也没用。
文档智能可以作为 RAG 前处理：
PDF -> 解析结构 -> 生成 Markdown/JSON -> 切分 -> 入库 -> 检索问答解析质量决定知识库质量。
常见坑
第一个坑：只测 OCR 字符准确率。
业务关心的是字段和关系，不只是字。
第二个坑：没有人工复核机制。
低置信度字段不能直接进高风险流程。
第三个坑：忽略表格。
很多关键数据在表格里，表格结构错了，结果就错。
第四个坑：日志泄露文档内容。
文档常含隐私和合同信息，日志要脱敏。
实践清单
• 收集真实文档样本，包括模糊、歪斜、跨页、手写。 • 为关键字段建立标注集。 • 不只评估文字，还评估字段、表格和位置。 • 对低置信度结果设置人工复核。 • 输出结构化 JSON，并保留来源页码和位置。 • 检查日志和 trace 是否泄露敏感字段。 • 将文档解析质量纳入 RAG 评测链路。
小结
多模态文档智能让 AI 从“读文字”进化到“读懂文档”。企业大量知识都藏在 PDF、扫描件、表格和票据里，这些内容要先被正确解析，才能进入 AI 系统。
对测试工程师来说，文档智能的核心不是 OCR 分数，而是字段是否准、结构是否对、来源是否可查、风险是否可控。