OCR 和文档提取的区别——为什么有了字符还不算有数据

如果你曾经扫描过一摞发票，用 OCR 工具跑了一遍，然后发现自己_还是_得把数字一个个手动抄进表格——那你已经体会过这篇文章要讲的那道坎了。OCR 把活干完了——它把页面的图片变成了文本。但文本不等于数据。知道 1,250.00 这串字符出现在页面的某个地方，并不能告诉你它是应付总额，而不是小计、税额，或者上个月的余额。

这”最后一公里”——从”页面上有这些字”到”这是总额、这是供应商、这是每一条明细项，都打好了标签、可以直接拿来用”——就是文档提取。这篇文章会用大白话讲清楚两者的区别，告诉你各自适合什么场景，并帮你判断你的流程到底需要哪一个。

OCR 究竟做了什么

OCR——光学字符识别——只有一个任务：看一张文本的图片，输出里面的文字。喂给它一张扫描的收据，它会还给你一份转录稿——商家名称、明细项、总额、日期——以一串扁平的字符形式，大致按阅读顺序排列。

这对某些事情确实很有用：

• 让扫描版 PDF 可被搜索。 正是 OCR 让你能对一份拍照得来的文档按 Ctrl-F 查找。
• 无障碍访问。 屏幕阅读器需要 OCR 生成的那一层文本。
• 全文归档。 如果你只是想日后能凭内容_找到_一份文档，OCR 就够了。

OCR 做不到的，是理解这份文档。它不知道哪个数字是总额、哪个是税额。它不知道中间那三行是明细项，底下那一行是合计。它不知道”Acme Corp”是供应商，“Jane Smith”是联系人。它只是把字符交给你，意思留给你自己琢磨。

文档提取多做了什么

文档提取从 OCR 收尾的地方接着往下做。它接过页面的内容，返回有名称、有类型的字段——一个结构化对象，你可以直接丢进表格、数据库或别的系统：

{
  "invoice_number": "INV-2026-0412",
  "issue_date": "2026-05-30",
  "vendor": "Acme Corp",
  "total_due": 1250.00,
  "currency": "USD",
  "line_items": [
    { "description": "Design work", "quantity": 10, "unit_price": 100.00 },
    { "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
  ]
}

从 OCR 转录稿到这一步，有三样东西变了：

1. 值都带上了标签。 total_due 就是总额，而不是一个恰好出现在页面上的数字。你不用费心去分辨哪个是哪个——提取已经替你做了。
2. 结构被保留了下来。 明细项以一行行的列表形式返回，而不是被压成一团。只有一个的东西（发票号）和有很多个的东西（明细项）被分得清清楚楚。
3. 类型被规整了。 1250.00 是一个数字，而不是字符串 "$1,250.00"。2026-05-30 是一个可排序的日期，不管原文档印的是什么格式。你可以直接做计算和筛选，不用先清理一遍。

整个区别用一句话就能说清：OCR 给你的是字符，提取给你的是数据。

两者对照一看便知

	OCR	文档提取
输出	一串文本	有名称、有类型的字段（JSON / CSV / Excel）
理解文档吗？	不——只是转录	是——分得清总额、小计、税额
结构	扁平文本，按阅读顺序	保留列表、表格、嵌套
类型	一切都是字符串	数字、日期、布尔值都被规整
新版式	能用（它只是读）	能用，不需要为每个供应商建模板
适合做什么	搜索、归档、无障碍	把数据喂进工具和流程
还得重新敲一遍吗？	通常得	不用

对大多数团队来说，最关键的是最后一行。如果你的目标是拿这些数字_做点什么_——核对、求和、推进你的财务系统——那 OCR 之后，重新敲一遍这一步还原封不动地摆在你面前。提取则把它去掉了。

“可我已经有 OCR 了——这还不够吗？”

这是最常见的问题，而老实的答案是：完全取决于你下一步要干什么。

如果你只需要找到并读取文档，OCR 就够了——别给自己加一堆用不上的复杂度。但如果有人正在读 OCR 的输出，再把那些值敲到别的地方去，那敲字这一步，正是提取要替你解决的。判断方法很简单：你是不是在把数字从一个屏幕抄到另一个屏幕？ 如果是，那你正在用手做提取自动帮你做的事。

还有一个相关的坑，是在 OCR 之上用正则表达式自己搭一套提取——“找到以 TOTAL 开头的那一行，抓后面的数字”。它在第一个供应商身上能跑通，到第二个就崩了，因为下一张发票写的是”Amount Due”，或者把总额放在了别的位置，又或者表格跨了两页。每来一种新版式，就得加一条新规则。正是这台永远停不下来的跑步机，让基于模板和基于正则的做法，撑不过区区几种文档格式。

现代文档提取不一样在哪

老一代的提取工具需要每种版式配一套模板——你得在一份样本文档上画框，标明”发票号永远在这里，总额永远在那里”。这只有在每份文档长得都一样时才管用，而一旦你手上的供应商、银行或交易对手不止一个，这几乎从来不成立。

理解版面的抽取，会像人一样去读文档——靠理解字段_意味着什么_，而不是它们落在页面的哪个位置。一份全新的发票版式第一次就能跑通，不用预先搭任何模板。一份表格横跨 12 页的银行对账单会作为一份干净的列表返回。一份混着两种语言的报关文档，会让每个值都保留它原本的文字。同一套思路也覆盖收据、合同、证件、简历和化验报告——不同的文档，同一个道理：你描述你想要什么，引擎去找出来。

如果你想看”描述你想要什么”的实操版，我们专门写过一整篇：如何写出好用的提取结构（Schema）。

那怎么核对结果呢？

从原始 OCR 走到结构化字段，有一个合理的顾虑：当一个工具去_理解_文档、而不只是转录它时，你怎么确认它理解对了？

答案是出处可溯。Ztract 提取出的每一个值，都锚定在源页面上它确切的位置。在输出里点一下 total_due，原文档上对应的地方就会高亮——于是核对一个数字只是扫一眼，而不是大海捞针。你扫一遍那些看起来不对劲的字段，有问题的一键改掉（修正是免费的——只有提取会计入你的页数），就完成了。你既拿到了自动化的速度，又没有丢掉自己读源文件那种可审计性。

那你到底需要哪一个？

一份快速判断指南：

• 你需要搜索或归档扫描文档 → OCR 就够了。
• 你需要文档对屏幕阅读器无障碍 → OCR 就够了。
• 有人正在读文档，把里面的值敲进表格、ERP 或数据库 → 你需要文档提取。
• 你试过 OCR 加正则，版式一变就崩 → 你需要的是理解版面的抽取，而不是更多规则。
• 你需要每一个提取出来的值都能追溯回源文档 → 你需要带出处的提取，比如左右对照的查看方式。

大多数最后选择 Ztract 的团队，都是从 OCR 起步，撞上了重新敲一遍的那堵墙，然后意识到：缺的那块拼图不是更好的字符识别——而是把那些字符变成打好标签的数据。

用你自己的文档试试看这道坎

要最快地体会这道坎，就拿一份你日常真正会处理的文档跑一遍提取，看看那份结构化的输出——带标签的字段、真正的数字、一行行的明细项——而不是一堵文字墙。新账户可获得 30 页免费额度，无需信用卡，足够你拿几份最棘手的版式测一测。

如果你手上有个流程，拿不准 OCR 和提取哪个才是对的工具，来跟我们聊聊——比起把不对的工具卖给你，我们更愿意帮你挑对那一个。