腾讯云文字识别 OCR 技术构建和应用

9 月 7 日，云+社区（腾讯云官方开发者社区）主办的技术沙龙——AI 技术原理与实践，在上海成功举行。现场的 5 位腾讯云技术专家，在现场与开发者们面对面交流，并深度讲解了腾讯云云智天枢人工智能服务平台、OCR、NLP、机器学习、智能对话平台等多个技术领域背后架构设计理念与实践方法。本文内容整理自腾讯云高级工程师彭碧发，给大家带来“腾讯云文字识别 OCR 技术构建和应用”的分享。

本文内容整体分为三部分：

第一，腾讯云 OCR 概况；

第二，产品介绍和接入。

第三，腾讯云 OCR 技术介绍。

腾讯云 OCR 概况

OCR（Optical Character Recognition）的定义是光学识别、字符识别，让计算机看图识字的技术。

有两个例子，身份证可以把姓名、性别、民族等具体信息都识别出来。通用 OCR 可以把文本识别出了 4 段文字。

产品定位是打造文字识别工具箱，目前聚焦在公有云上。打造文字识别工具箱要求我们做到够丰富、被集成、够灵活。我们自己也花了一部分时间在私有云上，但发现非常耗时间，性价比布告，所以目前主要聚焦在公有云上，等公有云规模复制之后再结合私有云。

中间白色部分是我们目前提供的产品能力，现在整体有 35 种接口，提供文字识别工具箱，所以接口一定要跟的上，目前有 35 种。往下是技术资源、计算存储、服务能力。不同的其他技术形成组合产品以及解决方案，最后服务于合作伙伴，目前合作伙伴类型比较多：泛互联网、金融保险、政府企业、交通物流、教育，目前泛互联网在公有云上运行量比较大一点。

产品优势：性能优异、场景丰富、接入方便。

性能优异是说准确率和召回率、识别速度等性能指标高于行业竞品。产品非常丰富，有 30 几种接口，覆盖了票据、身份证、火车票等非常多的细分场景。接入方便，有快速接入指南，基础的开发者可以通过 8 到 10 分钟左右的时间快速接入。

产品介绍和接入

下面展开讲一下 OCR 的具体产品，其中会重点介绍两个产品，也是目前比较多的产品。还会介绍客户以及客户如何快速接入。

先看一下小程序，文字识别在中间部分，除了文字识别现在还有一些其他的，包括人脸识别、车辆识别。目前分成五大类，旁边有二维码，大家可以扫描一下。服务列表，这也是前两周更新的，上一次是 24 项，现在已经变成 35 项了，大概分类是通用、卡证、票据、行业和汽车。目前接口 35 项已经处于行业前列，但后面有计划继续增加更多的接口，实现行业接口领先。

用的比较多的通用印刷体，准确率大概在 95%以上，可以识别非常多的语言，目前是 18 种语言以上。GPU 处理速度是 300 到 500ms，CPU 慢一点是 3 到 8s，会通过预处理、投视矫正、去模糊，增加识别的鲁棒性。

身份证识别没有受到客户挑战，通用 OCR 的产品太复杂了，会有挑战，但身份证没有受到客户挑战。我们准备在细分场景下继续进行优化。

可以看在 ICDAR 两项凭证中取得第一名，但这仅仅是测试，有一定的价值，但更多是在实际产品中的识别水平。因为识别产品场景更多，场景复杂一点。

这是前一段时间准确率和召回率的情况，识别率大概在 92%以上，竞品友商大概在 70%左右。这是客户给我们项目的反馈图。

我们有快速指引接入，里面会有自动咨询代码，这是自己在代码里扣出来的，只需要把“SecretId”和“SecretKey”替换一下就可以。

腾讯云 OCR 技术介绍

下面介绍一下产品。目前框架包括两部分：图像分析、OCR，我最早是参与图像分析的，后面接手了 OCR 应用，技术开始扩展成 OCR。大概分为五层：用户接入层、Web 接入层、业务逻辑层、引擎平台层、基础服务层。右边是运营能力，包括环境、评测。

用户接入层可以通过 API 和 SDK 两种方式接入，Web 接入层除了常见的域名解析和路由分发外还有一套标准的云 API 接口——云 3.0 接入。使用它的好处是 SDK 可以进行生成，产品进来之后文档生成会非常好。还可以生成一些配套的调试工具。

说一下 AI 视觉的产品情况，有图像分析、人脸分析，但最开始的时候全都放在代码库里，所以后面就分开了，互相解耦，互不影响。内部有不同引擎，每一种引擎的实现都不一样，所以进行了整体的适配。基础服务层是一些能力，像计费上报、计费之等。使用微服务可以把各个业务之间互相耦合，发布的时候可以做到影响范围最小。

下面重点介绍一下引擎平台层，就是引擎平台层让我们的接入效率提高很多。OCR 最终是要 15 项，其他加起来 AI 视觉要达到 170、180 项。

V1 版本是改造之前的版本，当时想用我 Facade 提供统一接入，通过 CommonAdapter 进行配置，但 CommonAdapter 配置不友好、不清晰，自己使用后也发现记不住。还有在简单适配层处理的逻辑真的非常简单，超过三层的逻辑处理都不行，还需要增加设备层，用三层会导致修改问题非常麻烦，是非常耗人力成本的。最开始改错误码就改了好几次，发现问题后就对它进行改造。

这是改了之后的情况，目前在引擎接入和引擎适配放在一个工程里。客户或者引擎评测图片进来之后通过它获取引擎，再进行分发调用插件，插件主要抽象成 HandleReq、HandleHeader、HandleRsp。并且会把错误码统一收集，这样逻辑会更加灵活，发布起来非常方便。并且各个显示接口出去后会非常标准，内部的其他使用也可以直接调用，不用关注后面的差异。最主要的是效率急剧提升，以前是需要 2.5 天，现在需要 0.5 天就能解决。

引擎平台层插件动态加载的介绍，目前使用的框架是 Tars 框架。Tars 框架会先通过命令 push，push 以后配置通过加载，加载以后在 VM.RUN 里就可以把场景加载出来。目前已经发放了接近 60 个配置，发完之后马上上线。

有一部分接口是老接口，OCR 文档页面上文字识别 2017 就是我们的老接口（2.0 接口），2.0 框架非常老，框架经常出了问题之后找不到人维护，所以我们非常急迫地对它进行改造。之前各个业务都在这里耦合，会互相影响，现在改在之后。本来客户是从 Nginx 到 Qzhttp 的，现在到 2.0 逻辑层和 3.0 逻辑层最后到引擎平台服务，维护起来比较简单一点，只需要维护一个平台服务就可以，比较方便。

接口改造也会碰到一些问题，这是我们接口改造完之后的情况，改造过程还挺顺利的。但改造之前发现了不少问题，比如说代码里有隐藏功能、架构师暴露文档没有的功能等情况，贸然改造的话会出现很多问题。所以不能用普通改造，普通改造是指根据文档写代码，这种情况非常危险。最后用的是旁路真实流量测试与验证方法。

客户的流量或来之后到 NGINX 接入层，在接入机上会有 GoReplay，通过 GoReplay 把数据保留下来，保留下来后可以通过复制发送到新接口。接下来会有比较工程，知道大概改造效果。

以行驶驾驶证为例，有一次测试发现有 1000 多个请求，其中 1400 个正常和老接口保持一致，有 300 多个不一致，300 多个不一致中是什么原因，有数据了就根据具体的情况一一进行修复。

每个接口上之前都会测试指标，不同的接口会有差异性。横坐标是阈值，蓝色的是召回率，橘色的是误判率。可以根据你要确定误判是多少，画一个阈值就可以知道召回值是多少。

评测方法确定之后后续做自动化，因为接口非常多所以必须自动化，这样东西才能沉淀下来。可以看到前面部分会有召回率、准确率、耗时 TP99、TP50 等，下图是标注和实际的用户接口之间的差别。

为了保证服务质量会有多层次多维度的接口告警，引擎层面会有业务层的告警以及维度给到 API、IP 接口，指标会有失败率、异常率等等。接口比较多，所以现在做了测试自动化，修改接口跑一下测试自动化的脚本，发布起来会比较方便一点。运维层用了 K8S，非关键节点是允许挂掉的，挂掉之后是服务可用，资源不够的时候会把一部分请求给流水掉，这样的话不至于引起“雪崩”。

作者介绍：

彭碧发，腾讯云大数据及 AI 人工智能中心高级工程师，研究生毕业于华中科技大学图像所，在腾讯云先后参与了图像分析、OCR，目前主要负责 OCR 技术上云。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/sd8dn3iCddXt2UMC8OL0jA