OCR 方案选型：自研封装还是调用第三方 API？

一、一个被低估的工程现实

在不少团队里，文字识别项目的启动方式惊人地相似：业务方提出需求，技术负责人评估后认为“调用一个现成接口就能解决”，于是项目迅速立项。然而，真正进入交付阶段后，问题才开始集中暴露。

笔者曾参与过三类典型的文字识别项目：票据信息提取、单据结构化识别、手写记录转录。它们的技术背景各不相同，但失败路径却高度重合：

• 离线测试准确率看似达到 95%，可一旦面对日均万级的真实请求，数百条错误结果足以让下游对账、审核环节疲于奔命；
• 用户上传的图片质量参差不齐，倾斜、暗光、反光、遮挡几乎无法避免，识别结果随机性极强；
• 即使字段被识别出来，业务语义仍然模糊——哪个数字是单号、哪个是金额、哪个是日期，系统无法自动对应；
• 大尺寸图片单次识别耗时可达数秒，接口超时后客户端反复重试，最终把自身服务压垮。

这些现象指向一个结论：识别引擎本身的精度往往不是项目失败的主因，真正拖垮项目的是引擎之外的工程链路。

二、自研封装与第三方 API 的本质差异

讨论“自研封装还是调用第三方 API”，不能只比较识别准确率。两者在工程属性上存在根本区别。

2.1 调用第三方 API：快，但边界由别人定义

第三方 API 的核心优势是启动成本低。开通服务、获取密钥、发送请求、解析响应，整个链路可以在几小时内跑通。对于验证性项目或低频场景，这是最高效的选择。

但它的限制同样明显：

• 可控性弱：请求频率、并发上限、超时阈值、返回字段格式均由服务方决定，业务侧只能被动适配；
• 成本随量线性增长：调用量越大，费用越高，且难以通过架构优化显著摊薄；
• 数据链路外部化：图片需要上传至外部服务，对数据敏感型业务而言，合规评估成本不容忽视；
• 定制能力有限：当业务需要特定字段的后处理逻辑时，API 通常只提供通用识别结果，深度定制空间小。

2.2 自研封装：慢，但每一步都可控

自研封装并不意味着从零训练模型。更常见的做法是：基于开源引擎或自建模型服务，封装一层面向业务的识别网关。这层网关负责预处理、调度、后处理、监控等环节。

它的优势在于：

• 全链路可控：从图片接入、预处理、识别调度到结果结构化，每个环节都可以按业务需求调整；
• 边际成本递减：一旦基础设施建成，新增识别类型的边际成本主要是配置和调优，而非按次付费；
• 数据闭环：识别结果可以反哺模型优化，形成“识别—校验—纠正—再训练”的正向循环；
• 深度定制：可以针对票据版式、字段规则、业务校验逻辑做专门设计。

代价也很直接：需要投入人力建设预处理、调度、监控、容错等模块，初期周期长，对团队工程能力要求高。

三、真正决定项目成败的四个工程环节

无论选择哪条路线，以下四个环节都是文字识别项目无法绕开的。

3.1 图像预处理：识别质量的第一道闸门

用户上传的图片极少是理想状态。预处理的目标不是“让图片好看”，而是“让识别引擎稳定”。

常见预处理步骤包括：

• 自动旋转与倾斜校正；
• 对比度增强与去噪；
• 边缘检测与版面分割；
• 感兴趣区域裁剪。

这些步骤可以显著降低识别结果的方差。一个实用的做法是：在预处理阶段输出质量评分，对低质量图片提前拦截或提示用户重拍，而不是把压力全部留给识别引擎。

3.2 字段结构化：从“识别出文字”到“理解业务”

识别引擎返回的通常是文本块及其位置信息。业务需要的却是结构化字段，例如：

{
  "invoice_no": "12345678",
  "amount": "¥1,200.00",
  "date": "2024-01-15"
}

实现这一步需要版式分析与规则引擎。常见策略包括：

• 基于关键字的锚点定位；
• 基于坐标关系的字段绑定；
• 基于正则与校验规则的字段清洗；
• 基于业务逻辑的交叉验证。

只有完成结构化，识别结果才能真正进入业务系统。

3.3 性能与稳定性：别让重试打垮自己

大图识别耗时高是常态。如果客户端在超时后立即重试，而服务端没有限流与熔断机制，很容易形成雪崩。

建议的设计包括：

• 异步任务队列：将识别请求排队处理，客户端轮询或回调获取结果；
• 分级超时：根据图片尺寸和识别类型设置不同超时阈值；
• 幂等设计：同一张图片的重复请求返回同一任务结果；
• 限流与降级：在压力过大时优先保障核心业务。

3.4 监控与反馈：没有度量就没有优化

文字识别项目上线后，必须持续监控：

• 识别成功率与字段准确率；
• 各环节耗时分布；
• 低质量图片占比；
• 人工纠正频率与纠正内容。

这些数据既是优化依据，也是判断“是否需要自研”的关键指标。

四、混合架构：一种更务实的落地路径

对于多数团队而言，非此即彼的选择并不现实。更可行的方式是分层设计：

1. 接入层：统一接收识别请求，完成鉴权、限流、日志记录；
2. 预处理层：执行图像校正、质量评估、区域裁剪；
3. 识别调度层：根据业务类型、图片质量、成本预算，选择调用第三方 API 或本地识别服务；
4. 后处理层：执行字段结构化、规则校验、结果缓存；
5. 反馈层：收集人工纠正结果，用于规则迭代或模型优化。

这种架构的好处是：初期可以快速接入第三方 API 验证业务价值，同时保留切换或补充自研识别能力的空间。当调用量增长到一定规模，或数据敏感性要求提高时，可以逐步将核心场景迁移到自研服务。

五、决策框架：什么时候该自研，什么时候用 API

可以用以下问题帮助判断：

• 调用量级：日均请求是否达到需要认真核算成本的规模？
• 数据敏感性：图片是否包含不宜外传的信息？
• 定制深度：业务是否需要特定版式、特定字段的深度后处理？
• 团队能力：是否有足够的工程人力维护预处理、调度、监控链路？
• 迭代预期：识别需求是否会持续变化，需要快速调整？

如果多数答案偏向“是”，自研封装的长期收益更明显；如果业务尚在验证期、调用量低、团队资源有限，第三方 API 是更理性的起点。

六、结语

文字识别项目的难点，从来不只是“调一个接口”。识别引擎之外，图像预处理、字段结构化、性能保障、监控反馈，每一个环节都可能成为项目瓶颈。

自研封装与第三方 API 不是对错之分，而是阶段性与可控性的权衡。真正专业的做法，是先理解业务链路，再选择匹配当前阶段的技术方案，并为未来的演进留出空间。