文档提取 API：每个供应商都能在自家的演示中胜出

要点总结：

• 文档提取 API 可从 PDF、扫描件或电子邮件中为你提取已标记的字段、表格和明细行。OCR 只提供字符，含义需由你自行判断。
• 基于模板和 AI 驱动的提取是不同的产品。当供应商移动总计金额位置时，模板就会失效，而 AI 提取能阅读它从未见过的布局。
• 应该用你自己的文档，以字段级准确率来评判供应商。数据表上的数字是他们用自己的文档测出来的。
• Parseur 提供了开发者 API 和你的运营团队可以操作的 Web 应用，因此无需任何人来构建审核工具。
• Parseur 托管在欧盟境内，数据在欧盟处理和存储，且绝不会用于训练 AI 模型。

文档提取 API 是一种服务，它接收 PDF、扫描图像或电子邮件等文件，并返回 JSON 或 CSV 等结构化数据。不同于返回纯文本并让你自己寻找其中含义的原始 OCR，文档提取 API 能够识别并保留结构：关键值对、表格、明细行和标记字段。

有三个相似的工具经常与它混淆。公共数据 API 提供别人已经整理好的数据集。网页抓取 API 去抓取网页上的内容。OCR 引擎？只有字符，没有结构。文档提取 API 处理的是你的文档，即那些已经存在于收件箱中的文档，并将它们转化为系统可以处理的数据。有些供应商将同样的产品称为“文档理解 API”（document understanding API），或者作为“文档提取 SDK”（document extraction SDK）发布。标签不同，作用一样。如果你还在纠结自己面临的是哪个问题，我们将文档解析与网页抓取进行了详细对比。

据 Research and Markets 报道，包含文档提取 API 的智能文档处理市场规模约为 30.1 亿美元，预计复合年增长率（CAGR）将达到 31.7%。 这个数字本质上是对发票、账单和表单数量的统计，而每一份都需要被读取。在许多公司里，负责读取这些文件的“东西”，仍然是一个拥有第二台显示器和数字小键盘的真人。

常见示例：

• PDF 发票 → 包含抬头字段和明细行数组的 JSON
• 入职表单 → 标记的关键值对（姓名、地址、签名）
• 银行对账单 → 导出为 CSV 的交易表格

贴着相同标签的五类供应商

搜索“文档提取 API”，你会找到十几家供应商，除了同属一个类别外，他们几乎毫无共同点。他们之间并没有真正构成竞争，因为他们是为五种不同的工作而构建的。每一家都能在自家的演示中胜出，所以选择哪个阵营比听推销说辞更重要。在预约通话之前，先弄清楚你属于哪一类。

对于上表有两点说明。第一，界限可能是模糊的：一些供应商横跨两类。第二，Parseur 被放在第三类，因为这就是它构建的初衷——将电子邮件和运营文档转化为结构化 JSON，并配备一个让你的运营团队可以切实运行的应用程序。如果你处理的是工程图纸，第四类会比我们更合适，我们更愿意现在就告诉你，而不是在试用期间让你发现。

基于模板的提取 vs AI 驱动的提取（只有一种能规模化扩展）

基于模板的提取通过页面上的位置来寻找字段。AI 驱动的提取则通过其含义来寻找。 这就是全部的区别，它决定了你要承担多少工作量。

模板的逻辑是：发票号距离顶部 40 毫米，距离左侧 120 毫米。快速、确定、非常美好。这一切都能维持，直到某天早上供应商重新设计了他们的发票，此时它就会返回错误的值，或者什么都不返回，接着就会有人提交工单。200 个供应商，200 个模板，以及一个懂这些模板的工程师。

AI 驱动的提取像人一样阅读文档。它能找到总计金额，是因为它位于名为“应付金额”的行下方，在右下角，格式为货币，并且等于上方数值的总和。哪怕你移动它、改变样式，甚至把整张发票翻译成德语，它依然能找到。

Parseur 运行两个 AI 引擎且不使用模板：用于电子邮件和文本文档的文本 AI 引擎，以及用于 PDF、扫描件和图像的视觉 AI 引擎。你只需描述你想要的字段，提取过程就会根据每份文档自适应，而不是每种布局，所以只需花几分钟定义字段，而不用花几周去构建模板。

这种权衡是真实存在的。AI 提取是基于概率的，而模板是确定性的，这就是为什么会有置信度分数，这也是为什么下面评估部分的重点更多放在异常处理上，而不是准确率的宣传上。

文档提取 API 的五阶段工作原理

尽管供应商在细节上有所不同，但文档提取管道在各处的基本形态是一致的。

为什么这已经不再是一个可选项：数据量。Dream Factory 引用了被广泛传播的预测，即全球数据量在 2025 年将达到 175 泽字节，而这个日期现在已经成为过去式，其中以文档而非数据库行形式到达的数据比例并未缩减。手动录入根本无法应对这种规模。大量的模板墙也不行。

步骤 1：接收

无论供应商怎么称呼它，这都是文档接收 API：通过 HTTP 上传、电子邮件转发或来自其他系统的 Webhook。电子邮件的作用比听起来更重要。很大一部分商业文档从未触及文件上传工具，它们是以附件的形式从一个从未听说过你们门户网站的供应商那里发送过来的。

步骤 2：AI OCR 及版面分析

AI OCR 将图像和扫描内容转换为机器可读的文本。然后，版面分析会计算出阅读顺序、文本块、行、单词以及每个元素在页面上的位置。这就是现代引擎与 2010 年代引擎的区别：它生成的是一张结构图，而不仅仅是字符。

步骤 3：解析处理

• 关键值对：将标签与数值匹配，如_“发票号：12345”_。
• 表格和明细行：重建行和单元格，包括合并的单元格、跨度以及跨页的表格。
• 分类：在决定寻找哪些字段之前，先确定文档类型。

步骤 4：后处理

日期、货币和供应商名称会被规范化为一致的格式。结果将根据 JSON Schema 或 Pydantic 模型进行验证，以确保格式错误的有效载荷永远不会到达你的 ERP 系统。

步骤 5：交付

API 对于小文件会同步返回结果，对于较大的文件则使用 Webhook 回调进行异步处理。重试机制和幂等性才是保证大批量交付可靠性的关键。在你签约之前就要问清楚这两点，而不是等到第一个无声无息崩溃的周五晚上之后。

给我看 JSON 数据

供应商页面总是大谈“结构化输出”，却从未展示过具体的样子。下面是一张供应商发票应该返回的数据结构，这也是值得要求每个供应商都去匹配的格式：

{
  "document_type": "invoice",
  "supplier": { "name": "", "tax_id": "", "supplier_id": "" },
  "invoice": {
    "invoice_number": "",
    "invoice_date": "",
    "due_date": "",
    "currency": "",
    "po_number": ""
  },
  "amounts": { "subtotal": 0, "tax": 0, "freight": 0, "total": 0 },
  "line_items": [
    {
      "description": "",
      "sku": "",
      "quantity": 0,
      "unit_price": 0,
      "line_total": 0
    }
  ],
  "confidence": { "invoice_number": 0.98, "total": 0.99, "line_items": 0.91 }
}

其中有两个地方发挥了主要作用。line_items 是一个数组，而不是一堆混乱的文本，这正是实现双向和三向匹配的基础。confidence 是针对每个字段的置信度，它能让你自动决定是否需要人工介入。

如何挑选文档提取 API（不被演示蒙蔽）

每个供应商都能在自家的演示中胜出，因为文件都是他们自己挑的。唯一能预测实际生产效果的评估，是用你自己的文档进行测试。

1. 在与任何人交谈前构建测试集

从你过去三个月的业务中抽取 200 到 500 份真实文档，并根据收件箱的实际情况进行权重分配：

• 约 70% 是常见的供应商格式
• 约 20% 是一个季度才见一次的长尾供应商
• 约 10% 是会导致系统崩溃的边缘情况：劣质扫描件、手写笔记、跨页表格、退款单、外币、一张发票上包含两个采购单号

让所有候选方案测试同一套文件集。永远不要让供应商来挑选样本。

2. 对字段评分，而不是对文档评分

文档级别的准确率会掩盖那些让你付出代价的错误。逐个字段进行评分，并根据出错造成的损失程度进行权重调整：

3. 需要追踪的指标是直通处理率

统计那些从收到到录入系统全程无需人工干预的文档数量。在一个月 5000 份文档的体量下，90% 和 96% 直通率之间的差距是 300 份需要人工打开处理的文档。这不是一个简单的指标，这对应着一个人的岗位职责。

4. 明细行是最容易出问题的地方

表头字段很容易。候选名单上的每个引擎都能找到发票号。在你相信任何数字之前，先用跨页表格、重复表头、换行描述、运费和折扣行、按行计税、负数抵扣金额和混合单位来测试它。

5. 询问谁来清理异常情况

文件大小限制、异步处理、Webhook 重试、幂等性、速率限制、SDK 覆盖范围，以及遇到低置信度字段时会发生什么。然后问问谁来审核这些异常。如果答案是“你的工程师，在你们自己构建的工具里处理”，那么数据表上的价格就不是真正的价格。Parseur 对此的回答就写在API 文档中，而对最后一个问题的回答是：使用我们的 Web 应用程序，而不是浪费你们团队的冲刺周期。

文档提取 API 的真实成本

定价模式的差异比营销宣传要大得多，而且定价模式比具体的单价更重要。

• 按页收费：处理短文档时最便宜，但处理长文档时会极其昂贵。同样是提取一组字段，处理一份 40 页的合同要比处理一张单页收据贵 40 倍。
• 按文档收费：单文件成本可预测，但自定义模型、手写识别或基于查询的提取等高级功能通常需额外付费。
• 按体量固定订阅收费：每月固定费用包含一定的文档额度，与页数无关。

Parseur 采用第三种模式。长篇 PDF 和简短邮件的成本是一样的，当你的文档组合多变时，账单依然可控。当前的计费层级可在定价页面查看。

没人会主动报价的是围绕 API 进行开发的成本：后处理逻辑、审核界面、重试处理、提取漂移监控等。这笔账单通常比 API 账单本身还要大，而 Parseur 的 Web 应用正是为了省去这笔费用而存在的。

使用 Parseur API 将 PDF 解析为 JSON

完整的 PDF 提取 API 路径，从上传到 Webhook，只需五步。

基础 URL： https://api.parseur.com/

1. 认证

在你的 Parseur 账户的 API 部分找到你的 API 密钥，并在每个请求的 Authorization 头中发送它：

Authorization: <YOUR_API_KEY>

详细信息请参阅认证指南。

2. 查找或创建邮箱（Mailbox）

邮箱（Mailbox）是一个容器，用于存放你的文档以及你想要提取的字段。可以在应用界面中创建一个，然后列出你的邮箱以获取 ID：

curl -X GET "https://api.parseur.com/parser" \
  -H "Authorization: <YOUR_API_KEY>" \
  --compressed

邮箱 ID 也会显示在应用程序的邮箱 URL 中，以及创建邮箱响应的 id 字段中。

3. 上传文档

cURL:

curl -X POST "https://api.parseur.com/parser/<MAILBOX_ID>/upload" \
  -H "Authorization: <YOUR_API_KEY>" \
  -F "file=@./invoice.pdf" \
  --compressed

Python:

import requests

url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
headers = {"Authorization": "<YOUR_API_KEY>"}
files = {"file": open("invoice.pdf", "rb")}

response = requests.post(url, headers=headers, files=files)
print(response.json())

Node.js:

import fetch from "node-fetch"
import fs from "fs"

const url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
const headers = { Authorization: "<YOUR_API_KEY>" }

const formData = new FormData()
formData.append("file", fs.createReadStream("./invoice.pdf"))

const response = await fetch(url, { method: "POST", headers, body: formData })
console.log(await response.json())

文档也可以通过电子邮件转发的方式到达，而不仅限于 API 上传。这两种路径请参阅 上传电子邮件和文档。

4. 获取你的数据

在邮箱上配置 Webhook，解析完成的 JSON 会在第一时间推送到你的端点。在生产环境中，这是最正确的默认设置：无需轮询，无需设置 cron 任务，也不会在两次检查之间丢失文档。

当无法使用 Webhook 时的替代方案：

• 自动化平台：Zapier、Make、n8n 或 Power Automate。
• 轮询：通过 GET /document/{id} 获取解析后的 JSON。
• 导出：从邮箱下载 CSV、JSON 或 Excel。

5. 验证与优化

Parseur 仪表板会显示文档和 Webhook 日志，让你可以确切地看到提取了什么内容以及交付了什么内容。当某个字段返回错误时，直接在那里修复，而不是在你的代码库中打补丁。

Parseur 能提取什么，以及还有什么不能提取

Parseur 是一款围绕一个核心理念构建的文档提取 API：软件在读取文档之前，不应需要对其进行任何前置准备。自 2016 年以来，它已处理了超过 1 亿份文档。

• 关键值对和表单：将姓名、地址、总计、发票号和参考 ID 提取到标记的字段中。
• 表格和明细行：发票明细、银行对账单交易、运输清单，包括跨越多页的表格。AI 表格提取涵盖了其工作原理。
• 扫描件和照片：视觉 AI（Vision AI）引擎可直接读取扫描和拍摄的文档，不仅限于电子 PDF。
• 电子邮件及其附件：这是 Parseur 的专长。电子邮件本身是一份文档，其携带的所有附件也是。
• 布局元素：当你需要时，提取标题、段落和选框标记。

它仍然难以处理的地方：密集的草书手写体和签名。这些是整个行业都尚未解决的难题，如果有任何供应商声称可以做到，请向他们索要基准测试数据。

大多数文档提取软件只提供 API，剩下的事全抛给你。Parseur 则提供了完整的两半：提供给你这一端的 API，以及一个让运营团队定义字段、审核文档和纠正结果的 Web 应用程序，无需提交工单或等待开发排期。

典型应用场景

• 应付账款 —— 将发票、收据和采购单转为结构化 JSON，然后直接录入 ERP 系统。
• 财务运营 —— 将银行对账单和交易报告转换为 CSV 或 JSON 以用于对账。
• 运营与物流 —— 提取装箱单、提单和交货单信息。
• 邮件自动化 —— 接收邮件及其附件，提取数据，然后通过 Webhook 交付。

安全性、GDPR 与欧盟数据驻留

Parseur 托管在欧盟境内：客户数据在欧盟境内处理和存储，托管数据中心通过了 ISO 27001 认证。 这是一项数据驻留承诺，它与单纯的 GDPR 合规徽章有着本质的区别，且要求更为严格。

Parseur 遵守欧盟 GDPR、英国 GDPR、加州 CCPA/CPRA 以及新加坡 PDPA 法规。客户文档绝不会被重新用于训练 Parseur 的 AI 模型，也绝不会被出售。保留期限是可配置的，你可以设置文档在指定时间窗口后自动删除。SOC 2 Type II 和 HIPAA 合规计划正在推进中（这意味着目前尚未获得相关认证）。

如果数据驻留是硬性要求，永远不要在未弄清以下四个特定环节在哪发生的情况下就接受“托管在欧盟”的说法：推理过程、临时缓存、备份，以及包含文档内容的日志。位于美国推理端点前面的欧盟数据库不等于欧盟数据驻留，而且这是一种很常见的架构。我们的 12 个问题验证无训练声明 针对模型训练开展了同样的测试。

文档提取 API 与大语言模型（LLM）：永远不要交出原始 PDF

语言模型在推理方面表现卓越，但在阅读 PDF 时却并不可靠。把扫描版发票扔给它，它很可能会极其淡定地返回一个根本不存在于页面上的总计金额。文档提取 API 生成的是真实可靠的基础数据，模型应该在此基础上运行。

行之有效的分工是：API 拉取发票号、日期、总计金额和明细行，并附带置信度分数；然后模型做它擅长的事情，比如把“01/03/25”变成 2025-03-01，标记文档类型，或将字段映射到你的内部词汇表中。Schema（架构）验证在底层发挥作用，拦截这两者单独都没注意到的错误。

AI 代理同样需要遵守这一规则。它的表现完全取决于传递给它的数据质量，一条凭空捏造的明细行，很容易变成一张伴随真实付款的采购单。想要了解更全面的信息，数据提取 API 终极指南 是本文所属的基石页面。

现在，去对供应商进行极限测试吧

最好的文档提取 API，不是功能列表最长的那个，而是能够在无需人工干预的情况下，挺过你最糟糕的 10% 文档考验的那个。构建测试集，针对出错会让你损失金钱的字段进行评分，并统计到底有多少文档能全程无需人工干预顺利产出。也来对我们进行测试吧，顺序随你挑。

其他的一切，不过是数据表上的空头宣传罢了。

最后更新于 2026年8月13日