从文档中"提取数据"，
我们到底在做什么？

"可读"与"可用"之间的鸿沟

一份文档可以是人类可读的（你看一眼就能理解），也可以是机器可读的（计算机能提取其中的字符），还可以是机器可用的（数据以结构化格式存储，程序可以直接查询、排序和分析）。这是三种截然不同的状态——而大多数工具只能把你带到第二种。

当OCR处理一张扫描发票时，文档从"机器不可读"变成了"机器可读"。这一步是真实的进展。但机器可读的文字和机器可用的数据之间，还隔着一道很大的鸿沟。机器可用的数据知道自己是什么：这个单元格是"发票合计"，这个是"供应商名称"，这个是"开票日期"。机器可读的文字只是字符——一串平铺的流，没有任何关于它代表什么的概念。

这两种状态之间的差距，正是手工劳动仍然存在的地方，也是大多数工具悄悄停下脚步的地方。

从文档到数据的五个步骤

"从文档中提取数据"实际上是一条五步流水线。大多数人只想到第一步——因为那是工具在宣传的那步。

第1步已经被充分解决。OCR正是为此而生，现代OCR可以可靠地完成它。第2步到第5步才是真正的工作所在——而这些步骤恰恰是大多数工具留给你自己处理的部分。

OCR停在哪里

OCR被设计用来解决第1步，它把这步做得很好。在清晰的印刷文字上，字符识别准确率通常超过99%。对于那个特定任务——将图片中的字符转换为文本字符串——这是一项成熟可靠的技术。

但输出的是一串文本流。把一张供应商发票送进OCR，你会得到类似这样的内容：

ACME Supplies Ltd
123 Commerce Street, Chicago IL 60601
INVOICE
Invoice No: INV-2024-0892    Date: March 15, 2024
Bill To: Greenfield Corp     Due: April 14, 2024
Description        Qty    Unit Price    Amount
Office chairs       4       $285.00    $1,140.00
Desk lamps         10        $45.00      $450.00
                                 Total: $1,590.00

文字都在。但你又回到了同样的问题面前：哪个数字是发票合计？哪个日期是开票日期，哪个是到期日？如果你要处理来自二十家供应商的三十张发票，每家把这些字段放在不同位置，使用不同标签，格式也各有差异。每种版面变化都是一个新的解析难题。

基于模板的OCR通过让你预先定义每种版面的像素坐标来解决这个问题："发票编号总是在这个边框位置。"这确实管用——直到某家供应商更新了发票样式，或者你新增了一家供应商。每种新版面都需要一套新模板，维护成本随文档种类线性增长。

OCR的根本局限不在于准确率。在于OCR在字符层面运作，对一个字段在文档语境中的含义毫无感知。

图片转文字工具停在哪里

简单的图片转文字工具通常不过是界面更好的OCR。有些略进一步——以"图片转表格"或"照片转表格"为卖点的工具可以检测网格线，推断表格结构，保留源文档中可见表格的行列关系。对于有清晰边框列的银行流水，这看起来像是完整的解决方案。

局限在那个窄小场景之外很快就会暴露：

• 依赖版面：如果你的文档采用表单布局（标签：值的配对形式）、双栏设计，或任何没有可见网格线的结构，就没有表格可供检测，工具会退回到纯文字输出。
• 没有语义字段识别：即使保留了表格结构，工具也不知道哪一列是"金额"，哪一列是"描述"。把你的目标列（"提取供应商、发票编号、合计"）与工具找到的列对应起来，仍然需要手工操作。
• 无法跨文件汇总：每份文档产生一个独立的输出文件。把三十个碎片合并成一张完整的汇总表——并确保所有列的对齐关系保持一致——是你自己的问题。

实际效果是：在顺利的情况下，对单份结构清晰的文档，你能省去一些复制粘贴的工作。一旦有多份文档、版面各异，或数据以表单形式呈现，你又回到了手工完成第2步到第5步的状态。

大多数工具跳过的那步：知道哪段文字是哪个字段

语义字段识别——无论位置或标签如何，都能理解某个值在文档中扮演什么角色——是文档数据提取中最难的部分，也是大多数工具根本不去尝试的部分。

一张供应商发票可能把合计标注为"合计金额"、"应付金额"、"实付总额"或"结欠余额"。来自不同地区的供应商可能用略有差异的格式书写相同含义。对于理解发票的人类来说，这完全不是问题。但对于任何依赖位置映射或固定字符串匹配的工具而言，这是无法解决的难题。

AI视觉模型以不同的方式处理这个问题。在数百万份文档上训练过的模型理解发票词汇、银行流水结构和医疗记录惯例。当你要求它提取"发票合计"时，它不是在搜索字面字符串匹配——而是识别出在语义上就是发票合计的那个值，无论这家供应商使用了什么标签。"总金额"、"合计"、"应付款"和"价税合计"都会被解析到同一个字段。当一份文档包含五个不同日期时，"开票日期"返回的是文档创建日期，而不是付款到期日或交货日期——因为模型理解这些概念在语境中的语义区别。

这个语义层正是第2步和第3步真正需要的东西。没有它，字段识别就只能靠手工完成。

完整的工作流究竟是什么样的

当五个步骤全部由一个工具处理时，整个工作流程缩减为三个动作：上传文档、指定想要的列名、收到结构化的Excel文件。没有中间解析环节，没有手动列映射，没有拼合多份输出的操作。

使用简录AI的实际流程：

1. 上传文件——PDF、JPG、PNG、截图或任意格式混合
2. 输入你想要的列名：供应商名称、发票编号、开票日期、合计金额
3. 下载一份Excel文件，每行是一份文档，每列正好是你要求的字段

工具负责字符识别、语义字段识别、格式标准化、跨文件汇总和导出。你指定的列名就是最终表格的标题——由于字段识别是基于语义而非位置，同一套列名可以跨所有供应商的版面使用，无需逐家配置。

在任何真实工作量下，效率差距都相当显著。人工录入平均每页约需3分钟；AI提取处理一页只需5-10秒——效率相差约18倍。对于三十张发票，这意味着从90分钟缩短到5分钟。更重要的是，输出结果高度一致：无论批次中有多少家供应商或多少种版面，每一行的字段名称、日期格式和数字格式都完全相同。

常见问题