Model and Modality Playbooks2026年7月15日Big Y

OCR 模型路由:如何平衡文本提取成本、质量和回退检查

如果你正在规划 **OCR 模型路由**,难点并不在于找到一个能从图像或 PDF 中识别文本的模型。真正的难点在于:哪条路由负责纯文本 OCR,哪条路由负责表单

OCR 模型路由:如何平衡文本提取成本、质量和回退检查

如果您正在规划OCR 模型路由,难点并不在于找到一个能从图像或 PDF 中读取文本的模型。真正的难点在于决定哪条路由应处理纯文本 OCR,哪条路由应处理表单和表格,以及哪条路由在第一时间就有资格接触受监管文档。

这就是为什么OCR 模型路由应当从策略开始,而不是从供应商偏好开始。一个低成本的文本 OCR 端点,仍然可能不是发票的正确路由。一个高质量的结构化提取器,仍然可能不是批量归档任务的正确路由。而一条看起来很便宜的路由,如果其同步限制迫使重试或回退,也可能最终变得昂贵。

截至2026 年 7 月 14 日,Flatkey 的公开主页和定价页面将该产品定位为一个统一的 AI 网关,具备一个密钥、一个余额和路由控制。为本文草稿检查的公开定价流也展示了具备 OCR 能力或接近视觉 OCR 的模型,例如 qwen-vl-ocrdeepseek-ocrdeepseek-ocr-2。本文仍然是作为路由操作手册来撰写,而不是目录式保证:读者应在将生产 OCR 流量接入之前,先验证实时模型流和定价页面。

OCR 模型路由真正优化的是什么

好的OCR 模型路由并不是追逐一个赢家,而是把正确的文档工作负载分配给正确的路由。

在实践中,团队通常会平衡五个变量:

  1. 提取深度:纯文本 OCR、版面恢复、表格、表单、键值对提取以及签名,不应放在同一条默认路径上。
  2. 计费单位:有些服务按页对基础 OCR 计费,而当您要求结构化提取时,另一些服务的费用会大幅上升。
  3. 文档限制:同步页数上限、异步限制、文件大小上限以及每页查询上限,都会直接影响路由可靠性。
  4. 数据控制:保留策略、区域和合同边界,可能会在您比较质量之前就排除掉某些路由。
  5. 回退安全性:只有当回退能够处理相同的文件类别、页数和合规类别,并且不会静默降级时,回退才是有效的。

这才是OCR 模型路由的真正工作。它不是排行榜,而是工作负载策略引擎。

先通过统一单位来开始 AI OCR API 路由

AI OCR API 路由中的第一个失败模式,是比较看起来相似、但对应输出差异很大的价格。

在比较路由之前,先把每条路由统一到相同的单位:

  • 纯文本 OCR 的每页有效美元成本
  • 结构化提取的每页有效美元成本
  • 附加功能或更高价值处理器的每页有效美元成本
  • 每次同步请求的最大页数
  • 每个异步任务的最大页数

当前官方定价页面清楚地显示了这种不匹配:

提供商 截至 2026-07-14 检查的官方定价信号 路由要点
Google Document AI Enterprise Document OCR: $1.50 / 1,000 pages; OCR add-ons: $6 / 1,000 pages 很好地提醒了我们,OCR 基础价格和增强层是分开的
Azure Document Intelligence Read: $1.50 / 1,000 pages; prebuilt models: $10 / 1,000 pages; custom extraction: $30 / 1,000 pages 同一份文档会因输出要求不同而落入差异很大的成本层级
Amazon Textract Detect Document Text example: $0.0015 / page; tables: $0.015 / page; forms: $0.05 / page; tables + forms + queries example: $0.070 / page 结构化提取会将 OCR API 成本放大到远高于基础文本提取的水平

这里通常最容易误读的是 OCR API cost。团队只比较纯文本 OCR 的费率,然后把发票、税表和合同路由到他们从未预算过的功能层级。

在查看 OCR API cost 时,在上线之前先问三个问题:

  1. 这个报价是针对纯文本 OCR 还是结构化提取?
  2. 该路由是否会将表单、表格、查询或附加功能单独计价?
  3. 页数限制会不会迫使任务进入更昂贵的异步或回退路径?

如果你无法回答这三个问题,你的 OCR API cost 估算仍然不完整。

使用工作负载类别,而不是单一默认 OCR 路由

AI OCR API routing 中的下一个错误,是把所有文档都走同一条路由。

这通常会造成两头都不讨好:

  • 廉价的归档 OCR 被过度处理。
  • 表单提取工作负载的规格定义不够精确。
  • 回退会变得危险,因为备用路由无法复现相同的提取形态。

更好的做法是在一开始就定义路由类别:

工作负载 更优的路由行为 重要原因
纯文本 OCR 先走最低成本且已批准的文本路由 对成本敏感,而且通常能容忍更简单的输出
布局感知 OCR 路由到能保留段落、标题和表格的模型 下游分块、搜索或审阅界面都需要它
结构化表单/发票 只路由到支持 schema 或能可靠输出键值对的提取器 准确率必须按字段评估,而不是按原始文本评估
大批量 PDF 优先选择页数上限更高且队列行为可预测的异步路由 否则同步限制会破坏回退机制
受监管文档 只路由到已通过留存和区域规则审查的提供商 如果违反文档策略,最便宜的路径也没有意义

这就是文档 AI 模型路由比通用 OCR 基准测试更有用的地方。文档 AI 模型路由让你在生产环境中成本和回退失控之前,将“读取页面”和“提取业务字段”分离开来。

在回退之前设置质量门槛

大多数团队都说自己重视 OCR 质量,但他们只衡量字符准确率。对于真正的文档 AI 模型路由来说,这还远远不够深入。

你的路由策略应按工作负载评估质量:

  • 纯文本 OCR:文本完整性、阅读顺序、多语言支持、手写容忍度
  • 版面 OCR:表格边界、标题层级、段落分组
  • 字段提取:键值对精度、规范化稳定性、错误可见性
  • 运维:同步/异步一致性、文件支持、页数上限、查询限制

Amazon Textract 自身的定价和配额文档说明了这一点的重要性。OCR 包含在 Analyze Document 输出中,但同步 PDF 和 TIFF 请求仅限 1 页,而异步 PDF 和 TIFF 作业可处理最多 3,000 页。Azure 的 service-limits 文档将页数统计和吞吐量直接关联到计费和限流行为。Google Document AI 按处理器类型公布每分钟页数和每分钟请求数的配额。

这正是许多OCR 模型路由指南中缺失的部分:回退不仅仅是“哪个提供商在线”。回退是“哪个提供商可以接收同一类文档,而不会破坏输出结构、页数限制或成本策略”。

围绕文档限制构建回退类别

最稳妥的AI OCR API 路由设计,是使用明确的回退类别,而不是宽泛的供应商故障切换。

下面是一个实用示例:

  • A 类:用于截图、身份证或简单扫描件的单页同步 OCR
  • B 类:用于大型 PDF 的多页异步 OCR
  • C 类:用于发票、表单和合同的结构化提取
  • D 类:受监管文档,仅允许有限的提供商集合

然后仅在同一类别内定义回退:

  • A 类路由可故障切换到另一条同步 OCR 路由。
  • B 类路由应只切换到另一条能够承载相同页数的异步路由。
  • C 类路由应只切换到能够保留字段结构的路由,而不仅仅是原始文本。
  • D 类路由应只在相同合规边界内进行回退。

这就是可靠的文档 AI 模型路由在实践中的样子。

OCR 模型路由的实用决策树

flowchart TD
    A[新文档任务] --> B{需要结构化字段吗?}
    B -->|否| C{单页或小型同步文件?}
    B -->|是| D{发票/表单/合同工作流?}
    C -->|是| E[使用最低成本、已批准的纯文本 OCR 路由]
    C -->|否| F[使用带页数上限余量的异步 OCR 路由]
    D -->|是| G[使用已批准的结构化提取路由]
    D -->|否| H[使用感知版式的 OCR 路由]
    E --> I{主路由失败?}
    F --> I
    G --> J{等效回退是否保留输出模式?}
    H --> I
    I -->|是| K[仅在相同文件大小和页数限制类别内回退]
    I -->|否| L[返回结果]
    J -->|是| M[回退到预先批准的结构化路由]
    J -->|否| N[升级为人工审核或重新路由到批处理队列]
    K --> L
    M --> L
    N --> L

这个决策树是 OCR 模型路由 的核心。先把它搭建好,然后将路由映射到这棵树中,而不是每当出现一个新的 OCR 模型或合同时都重写业务逻辑。

Flatkey 的定位在这里的作用

Flatkey 的公开定位在这里很重要,因为 OCR 路由的痛点很少只是一次模型调用。问题更多出在调用周边:多个提供商、混杂的计费单位、不清晰的回退机制,以及薄弱的支出可见性。

2026 年 7 月 14 日 检查的 Flatkey 实时定价源中,能看到具备 OCR 能力或与 OCR 相邻的条目,包括 qwen-vl-ocrdeepseek-ocrdeepseek-ocr-2,以及更广泛的图像和视觉模型。这并不能消除对输出质量或当前可用性进行验证的需求。但它确实让控制平面的叙事对通过单一网关而不是分散的供应商账户来比较 AI OCR API 路由 选项的团队更具相关性。

换句话说:只有当工程、财务和安全团队都能审视同样的路由、同样的定价逻辑以及同样的失败类别时,OCR 模型路由 才真正有价值。这正是统一网关流程应当解决的问题。

上线前的四点检查清单

在将 OCR 模型路由 投产之前,请确认以下四项:

  1. 按单位归一化的定价:你能按路由说明真实的 OCR API 成本,而不只是按供应商的宣传口径说明。
  2. 工作负载分类:纯文本 OCR、版式 OCR、结构化提取以及受监管文档不应共用一条默认路径。
  3. 质量门槛:每条路由都要针对工作负载所需的精确输出形状进行测试。
  4. 回退限制:故障转移必须停留在相同的页数上限、文件类型和合规类别内。

如果你跳过其中任何一项,OCR 模型路由 就会变成重试和异常处理,而不是一个可持续的系统。

结论

最好的 OCR 模型路由 策略通常是在正确意义上保持“平淡”。它让 OCR API 成本 可以比较,让简单 OCR 保持低成本,把结构化提取路由到合适的层级,并且拒绝回退到一个无法安全处理同一文档的路由。

这才是值得追求的标准。先验证你今天实际可以买到的实时目录和定价,然后将 文档 AI 模型路由 围绕页数单位、功能层级和回退类别一起设计,而不是一次只考虑一个方面。

如果你想在接入新的 OCR 路由之前先查看 Flatkey 的公开目录和定价情况,请先查看定价页面。