2019年9月7日，腾讯云开发者社区（腾讯云官方开发者社区）主办的技术沙龙——AI技术原理与实践，在上海成功举行。现场的5位腾讯云技术专家，在现场与开发者们面对面交流，并深度讲解了腾讯云云智天枢人工智能服务平台、OCR、NLP、机器学习、智能对话平台等多个技术领域背后架构设计理念与实践方法。
以下内容整理自腾讯云高级工程师彭碧发，给大家带来“腾讯云文字识别 OCR 技术构建和应用”的分享内容。
我的演讲题目是“OCR应用和技术构建”，大概会发30分钟左右的时间。主要讲解的是OCR技术上云过程中碰到的问题以及产品介绍。
先进行一下自我介绍，我叫彭碧发，是腾讯云大数据及AI人工智能中心的高级工程师，研究生是在华中科技大学图像所毕业的，在腾讯云先后参与了图像分析、OCR，目前主要负责OCR技术上云。
今天PPT的目录大概分三部分：
第一，腾讯云OCR概况；
第二，产品介绍和接入。
第三，腾讯云OCR技术介绍。
前两部分会主要讲产品定位、产品优势，以及分开介绍具体的产品和怎么快速接入。第三部分是PPT的主要重点，主要讲一下在上云过程中的接入速度的问题。
OCR（Optical Character Recognition）的定义是光学识别、字符识别，让计算机看图识字的技术。
有两个例子，身份证可以把姓名、性别、民族等具体信息都识别出来。通用OCR可以把文本识别出了4段文字。
产品定位是打造文字识别工具箱，目前聚焦在公有云上。打造文字识别工具箱要求我们做到够丰富、被集成、够灵活。我们自己也花了一部分时间在私有云上，但发现非常耗时间，性价比布告，所以目前主要聚焦在公有云上，等公有云规模复制之后再结合私有云。
中间白色部分是我们目前提供的产品能力，现在整体有35种接口，提供文字识别工具箱，所以接口一定要跟的上，目前有35种。往下是技术资源、计算存储、服务能力。不同的其他技术形成组合产品以及解决方案，最后服务于合作伙伴，目前合作伙伴类型比较多：泛互联网、金融保险、政府企业、交通物流、教育，目前泛互联网在公有云上运行量比较大一点。
产品优势：性能优异、场景丰富、接入方便。性能优异是说准确率和召回率、识别速度等性能指标高于行业竞品。产品非常丰富，有30几种接口，覆盖了票据、身份证、火车票等非常多的细分场景。接入方便，有快速接入指南，基础的开发者可以通过8到10分钟左右的时间快速接入。
刚才讲的是OCR的概况，讲了产品的定义和优势。
下面展开讲一下OCR的具体产品，其中会重点介绍两个产品，也是目前比较多的产品。还会介绍客户以及客户如何快速接入。
先看一下小程序，文字识别在中间部分，除了文字识别现在还有一些其他的，包括人脸识别、车辆识别。目前分成五大类，旁边有二维码，大家可以扫描一下。服务列表，这也是前两周更新的，上一次是24项，现在已经变成35项了，大概分类是通用、卡证、票据、行业和汽车。目前接口35项已经处于行业前列，但后面有计划继续增加更多的接口，实现行业接口领先。
用的比较多的通用印刷体，准确率大概在95%以上，可以识别非常多的语言，目前是18种语言以上。GPU处理速度是300到500ms，CPU慢一点是3到8s，会通过预处理、投视矫正、去模糊，增加识别的鲁棒性。
身份证识别没有受到客户挑战，通用OCR的产品太复杂了，会有挑战，但身份证没有受到客户挑战。我们准备在细分场景下继续进行优化。
可以看在ICDAR两项凭证中取得第一名，但这仅仅是测试，有一定的价值，但更多是在实际产品中的识别水平。因为识别产品场景更多，场景复杂一点。
这是前一段时间准确率和召回率的情况，识别率大概在92%以上，竞品友商大概在70%左右。这是客户给我们项目的反馈图。
我们有快速指引接入，里面会有自动咨询代码，这是自己在代码里扣出来的，只需要把“SecretId”和“SecretKey”替换一下就可以。
下面介绍一下产品。目前框架包括两部分：图像分析、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，非关键节点是允许挂掉的，挂掉之后是服务可用，资源不够的时候会把一部分请求给流水掉，这样的话不至于引起“雪崩”。
