从 OCR 到 Agentic Document AI

显示全部楼层

为什么“理解文档”，正在成为下一代企业 AI 的分水岭？

文档，一直是企业数字化中最被低估、却最核心的“非结构化资产”。

合同、发票、标书、工单、制度、报告、邮件、扫描件、PDF…… 在几乎所有企业系统中，真正承载业务含义的，并不是数据库字段，而是文档本身。

过去 20 年，企业对文档的处理路径高度一致：

OCR → 规则抽取 → 人工校验 → 入库

而今天，这条路径正在被彻底重写。

一、传统 Document AI 的三大“天花板”

在进入 Agentic Document AI 之前，我们必须先承认一个事实：

绝大多数“文档识别系统”，并不理解文档。

1️⃣ OCR ≠ 理解

OCR 解决的是“看清字”，不是“理解意思”。

即便识别率达到 99%，系统依然不知道：

这是一份合同，还是报价单？
“交付日期”指的是哪个条款？
哪一页才是最终版本？

2️⃣ 模板与规则不可扩展

传统 Document AI 的核心是：

固定模板
正则规则
字段位置假设

一旦遇到：

多版本合同
扫描质量差
表格结构变化
跨页语义

系统就会指数级崩溃。

3️⃣ 系统“只提取，不思考”

传统方案本质上是一个 ETL：

文档 → 字符 → 字段 → 表

它无法回答任何业务级问题：

这份合同是否存在风险？
是否违反公司制度？
与历史合同相比是否异常？

二、LandingAI ADE：不是“更强 OCR”，而是范式迁移

Andrew Ng 在 LandingAI ADE 中提出的，并不是一个“更准的识别模型”，而是一个全新的文档理解范式。

我们可以把 ADE 的核心理念总结为一句话：

文档不再是“输入数据”，而是 Agent 的工作对象。

ADE 背后的三个关键转变

转变一：从「字段提取」到「任务驱动理解」

传统系统问的是：

“我该从这份文档里提取哪些字段？”

Agentic Document AI 问的是：

“我现在要完成什么任务？这份文档对任务意味着什么？”

举例：

任务是合同风险审查
任务是费用合规判断
任务是工单归类与路由

文档只是 Agent 推理过程中的一个上下文证据源。

转变二：从「一次性推理」到「多轮思考」

ADE 的核心不在 OCR，而在Agent Loop：

读取文档
形成初步假设
定位关键段落
验证假设
若不确定 → 回到文档重新查证

这与人类阅读高度一致。

不是“抽字段”，而是“反复阅读、确认、推理”。

转变三：从「规则系统」到「可解释推理」

ADE 强调：

每一步推理可追溯
每个结论有证据
Agent 的“为什么”可被审计

这对企业系统极其关键。

三、Agentic Document AI 的标准架构拆解

如果你要在自己的工程体系中理解或复刻 ADE，本质上要掌握下面这套Agentic Document Pipeline。

1️⃣ 文档感知层（Document Perception）

这一层并不只是 OCR，而是：

OCR（文本）
Layout Parsing（版式）
Table Detection（表格）
图像区域理解
页级 / 段级结构建模

目标是构建：

“可被 Agent 操作的文档结构表示”

2️⃣ 语义分块与知识单元化

这是很多 RAG 系统失败的地方。

错误做法：

固定长度 chunk
无视语义边界

Agentic 系统应当：

按语义单元分块
保留层级结构（章节 / 条款 / 附录）
标注来源页码、上下文关系

这一步决定了后续 RAG 的“智商上限”。

3️⃣ Agent 推理与工具调用层

核心能力包括：

文档内搜索（非向量）
跨文档对比
多轮自问自答
不确定性检测
决策分支

Agent 不只是调用 LLM，而是：

在文档空间中“行动”

4️⃣ RAG 深度融合（不是外挂）

在 ADE 思路中，RAG 不是：

“我先查，再让模型回答”

而是：

RAG 是 Agent 推理过程中的一个工具

Agent 可以：

多次检索
动态调整 query
验证多个证据源
放弃不可靠结果

5️⃣ 输出层：结构化 + 可解释

最终输出必须满足：

可落库
可追溯
可复核
可审计

否则无法进入核心业务系统。

四、ADE 之外：同类 Agentic Document AI 产品全景

LandingAI 并不是孤例。全球范围内，Document AI 正在集体走向 Agent 化。

下面从“理念相近度”维度进行梳理。

1️⃣ Google Document AI + Gemini

特点：

强大的版式与表格理解
与 Gemini 深度集成
偏“平台能力”

局限：

Agent 行为可控性较弱
企业定制成本高

2️⃣ Azure Form Recognizer → Copilot Stack

特点：

强调与业务系统集成
强合规、强审计

局限：

Agent 能力偏弱
推理链可解释性有限

3️⃣ Amazon Textract + Bedrock Agents

特点：

可组合性强
适合工程化落地

局限：

架构复杂
需要较强云原生能力

4️⃣ Rossum / Hyperscience

特点：

财务与票据领域极强
强人机协同

局限：

场景相对垂直
Agent 通用性有限

5️⃣ 自建：LLM + LayoutLM + RAG + Agent

这是越来越多大厂正在走的路。

优势：

可控
可深度定制
可沉淀为平台能力

代价：

架构复杂
需要长期演进能力

五、给工程与架构负责人的关键建议

如果你真正想“学习 ADE 的产品理念”，而不是“用 ADE 这个工具”，我给你 5 条落地级建议。

建议一：别从 OCR 开始，从“任务”开始

先问清楚：

文档要支撑什么决策？
谁对结果负责？
错一次的成本是多少？

建议二：把文档当成“Agent 环境”

不是数据源，而是：

可探索
可回溯
可质疑

建议三：RAG 是基础设施，不是亮点

真正的护城河在：

Chunk 设计
检索策略
失败路径处理

建议四：必须有人类兜底机制

Agentic Document AI 的本质是：

人机协同，而不是全自动。

建议五：把“解释性”当一等公民

否则它永远进不了核心系统。

六、结语：谁先“理解文档”，谁就理解业务

我们正在经历的，并不是一次 OCR 升级，而是一次企业认知系统的升级。

当 Agent 能够阅读、理解、质疑文档，它才真正开始理解企业。

LandingAI ADE 的价值，不在于一个产品，而在于它清晰地告诉我们：

Document AI 的终点，不是字段，而是推理。