写点什么

95% 只是开始,贝壳的 OCR 识别率提升之道

  • 2020-03-19
  • 本文字数:6284 字

    阅读完需:约 21 分钟

95%只是开始,贝壳的OCR识别率提升之道


图像处理技术是目前人工智能发展最为迅猛的领域。居住服务平台贝壳找房积累和沉淀了大量的交易数据,依托着丰富的场景 + 数据 + 算法,贝壳交易智能围绕以房产证识别为核心的 OCR 技术架构也在落地实践中逐步建立起来。今年 6 月的 QCon 全球软件开发大会(北京站)2020 中,贝壳找房交易智能技术负责人郭流芳将分享贝壳找房 OCR 识别率提升实战经验,近日,我们对他做了采访。

OCR 技术初探

InfoQ:请简单介绍下自己,包括学习和工作经历。


郭流芳:大家好,我叫郭流芳,贝壳找房交易智能技术负责人。硕士毕业于中国矿业大学(北京),研究领域为图像处理,从事人工智能工作 6 年。从零到优构建了贝壳找房交易 OCR 技术体系,抽象总结了票据卡证类的 Uni-iMatch 解决方案和 ASLS 自学习系统,实现了行业内高水平备件识别精度。团队著有《深度学习 PyTorch 实战——图像技术在 OCR 上的应用》一书,将于今年面世。


InfoQ:能否讲讲你眼中的 OCR 技术?


郭流芳:OCR 的英文全称是 Optical Character Recognition,中文叫做光学字符识别,表示对数字化设备拍摄图像中的文字部分进行检测识别的技术。文字是信息的载体,但有相当大的一部分信息存在于视频(可以认为是时序图像)或者图片中。据思科白皮书的一项统计,到 2021 年左右互联网中 85% 以上的信息都是视频或者图片,这其中就包括数量不在少数,且有重大应用场景的文字图像。OCR 技术使这些图像中的文字信息得以利用成为可能。


在行业中,OCR,几乎成为图像文字识别技术的代名词。在 2012 年之前,这类任务是一个典型的模式识别问题,其流程主要包括预处理、特征提取、分类器等几个步骤。在 2012 年之后,深度学习席卷计算机各个领域,OCR 也变得简单起来,但仅仅是入门简单了。当前,OCR 仍然面临不少挑战。


OCR 文字检测方面,文字方向的多变性,有上下结构,有左右结构,还有混合结构,交叠结构。形状的不规则性,文字排列并不总是按行排列。多尺度问题,就是图片中的文字区域大小尺度相差很大。还有一些标注歧义性,检测完整性,不一而足。技术也从最初的矩形框回归,发展到多边形,到目前的任意形状检测。这些技术该如何和具体的业务问题结合起来解决实际问题呢?


OCR 文字识别方面,对于形变、光照、曲线、弧面、景深、形近字、噪音遮挡、文字交叠、长文本等依然存在巨大的优化空间。


还有在 OCR 领域经常被忽略的,那就是检测识别结果的结构化。把文字检测识别出来只是开始,如何返回结构化的结果,其难度不亚于检测和识别。例如,对于简历这种,有语义上明显的键值结构,但是又是模板不能完全覆盖的,因为你无法穷尽所有的情况。这种我们到底该如何做结构化呢?


总体而言,OCR 技术已经取得了长足的进步,但具体场景下仍有不少挑战需要攻克。

贝壳找房交易 OCR 技术体系

InfoQ:贝壳找房有哪些 OCR 应用场景?


郭流芳:贝壳找房的 OCR 能力建设是按照图像数据特征来划分的。具体分为视频图像 OCR,文档类 OCR,自然场景 OCR。


其中,文档类又细分为三大块。分别是:第一,票据卡证类,主要是贝壳找房平台上的各类备件,比如:房本、身份证、户口本、工作居住证等等。第二,通用表格类,主要涉及平台线上线下的各种表单数据,比如:报税单、征信报告、放款单等等。第三,通用文档类,泛指文档文字密集型,但又无明显结构化分割边界的图片,比如:交易中的合同、各种确认单、贝壳找房 IM 中的小图片等等。


自然场景 OCR,泛指背景主体是自然街景但其中含有文字信息的一类图像处理任务。具体应用在,为保证真房源而进行的图片实勘作业,涉及楼盘(小区名字)、楼栋(识别楼栋号牌)、单元门(单元号)、房屋(房屋号)、楼层识别(电梯间按键拍照识别)等等。


还有,就是视频图像 OCR,在视频讲房领域进行合规性审核,比如:审核视频中的水印 logo、审核视频的画面中是否存在不当承诺的文字等等。


当然,作为交易智能图像团队,有 OCR 能力,但不限于 OCR,会根据平台当前或者潜在需求,丰富技术栈,追求挑战,让交易不再难,服务于更美好的居住而不断前进。


InfoQ:请介绍一下贝壳的 OCR 技术体系,包括你们是什么时候开始打造 OCR 技术体系的,到现在经过了哪些阶段,有哪些重要时间节点。


郭流芳:贝壳的 OCR 技术体系,走过了大多数后进者都走过的路子,先用,再模仿,最后智造。


第一阶段:调研试用,时间大概是 2018 年。这一阶段,还是处于试用阶段,主要是调研尝试,试图给人力密集的备件审核业务,提效赋能。当时,调研试用了市面上兄弟团队的各类技术和接口,因为这些接口都是面向通用文字识别的,当年的测评结果其实并不理想。而且,随着调研试用的深入,审核人员预期的提高,希望迭代升级接口,提高准确率和降低接口响应时间。但这些需求,通用接口,通通不能满足,更重要的是,可能涉及信息安全问题。所以,痛定思痛,决定自主开发。


第二阶段:自主开发,时间截止到 2019 年年中。刚有讲到,随着深度学习的普及,这个门槛其实变得很低。随着第一阶段的结束,对于 OCR 产品和技术的未来,有了一个方向性的基本判断。接下来要做的就是要聚焦!聚焦!!在聚焦!!!我们给自己定下,千张平均字段识别率 95% 的目标。当时,市面上最好的接口也未达到这个准确率。我们调研开源技术,翻阅不少论文,排除了 character 级别的检测识别方案,确定了行检测行识别的初步方案。之所以,排除 character 单字的检测识别是因为成本高而效果差。初期进行数据合成,控制成本,搭建 serving,使用容器技术,提高可用性和响应速度。最终,成功达到目标。当然,这一切没有这么顺利,欲知详情,QCon 等你


第三阶段:开始了技术栈 2.0 的升级。因为为了第二阶段的目标达成,我们需要跑的快,跑的准,所以,很多技术细节被暂时定义为非主要矛盾,暂时压制,并未去深入研究。随着各种备件识别业务的上线铺开,和识别精度的稳定攀升,原来的非主要矛盾,逐渐突出,成为主要矛盾。比如,最初的后处理(也就是结构化),越做越繁琐,越做越繁杂,且在工程上无法统一调配。比如:检测中遇到的一些弯曲(水平或垂直或景深)、印章、交叠、长短文本兼顾等等问题。比如:识别中的形近字、人名地名中的生僻字、CTC 和 attention 到底怎么使用。再比如:工程上如何构建闭环,如何解决商业化部署中的新增模板问题。针对这些痛点。我们踏上了技术栈 2.0 的升级之路。


InfoQ:贝壳的 OCR 技术有哪些优势?


郭流芳:我个人觉得,贝壳找房 OCR 的技术优势初期和后期都在于【场景】和【数据】。有位先哲曾经说过:“社会一旦有技术上的需要,这种需要就会比十所大学更能把科学推向前进”,这就是我对贝壳找房【场景】的理解。它既是我们技术的起点和落脚点,更是我们技术源源不断进步的驱动力。当然,贝壳找房平台积累的海量数据,是技术得以展开的一个基础。上文有提到 2019 年进行了技术 2.0 的升级,其中很重要的一个环节就是从不同角度 state of art。认知要跟最前沿的技术对齐,业务要落实最前沿的技术,自研技术要不断迭代,不断努力,以便最终成为最前沿的技术。有了这些方面,技术在场景和数据的驱动下,不断迭代,引领着准确率的上升。


在纯技术层面上,我觉得贝壳找房 OCR 技术的优势概括起来为 ------“灵活、深入”。具体表现为,在架构上,致力于打造各项追求极致的原子能力(比如:弯曲文本检测识别、交叠文本检测识别)等,使得各个原子能力跟其他能力项解耦,可以”控制变量法“的独立迭代发展,虽然这么做增加了工程的复杂度,但是,也同时给予工程以原子组合的灵活性。这使得这些单项技术可以走的深,可以走的远。目前,我们的架构设计可以随心所欲的根据图像(或者任务)的自身特点,进行组合,提供用户无感知的高品质服务。这点(打造迭代原子能力)在后续业务铺开,多样性和复杂度上来后,显的尤为重要,是能不能继续高速发展的关键因素。

OCR 难点与识别率提升

InfoQ:在前面你提到的应用场景中,从简单到复杂,请为它们排个序,并简述理由。


郭流芳:我觉得其实没有简单和复杂的区分,要做到极致,在技术的世界里,没有简单二字。但通常来说,我们认为票据卡证类的相对简单,其次是通用文档和自然场景,最后就是通用表格类。理由是,票据卡证类的图像相对来说各项约束更多,或者说问题空间更小,比如:身份证,性别只有两种可能性,“男”或者“女”。而版面上,目前以二代身份证为主,版式单一,字体确定。相对来说快速起步还是比较容易。但它也有自己的难点,比如,识别这块的人名、地名,还有一个最大的风险那就是用户隐私,数据合规性的问题,为此,你需要数据合成。但如何合成对模型有效的数据呢?数据合成不好,不升反降,适得其反。通用文档它的难点在于如何很好的结构化。还是上文中的例子:简历识别。想象各种各样的版式,但是键值对几乎是可以枚举的。完全给你纯文本版的简历,利用 nlp 做好各类样式适配的结构化都应该不太简单,更何况是非文字版的呢!自然场景的难点在于,背景的复杂多样、字体五花八门、遮挡、光照、多尺度以及如何大批量快速训练,而现在的自然场景,还有一个特点就是目标文字区域附近会有噪音(比如:楼牌附近都是广告),使得目标信息解析结构化也是痛点难点。之所以把表格排在最后是因为,表格自身标注的难度,以及表格之间风格的高度相似和单元格推理的极度易错(对于多行密集型,基本上一行出错,全表完蛋),更不提无边框的表格推理识别。


综上所述,各有各的特点。把每种技术任务的边界勘定好,利用约束聚焦解决问题,是我们实践中的一个很重要的思路。


InfoQ:以最复杂的场景为例,简述一下它的 OCR 识别过程,每个过程中有哪些坑点。


郭流芳:嗯,那我谈一下贝壳找房最有特色的房本识别吧。其可以作为 OCR 识别的一个典型代表。整个流程大概分为,图片摆正、图片分类、文字检测、文字识别、识别结果结构化。图片摆正是后续流程处理的前提,因为所有的标注和训练都是基于人的视角摆正的图片进行的。如果图片摆正失败,那么后续流程就会倒戈。目前我们的兜底是,采取方向类别信息的 top-2 进行摆正尝试。但是,要训练一个好的摆正模型难点在于,泛化。你没有办法预知所有的类别。在我们的实践中如果想做一个统一摆正模型的话,是要覆盖所有的备件,目前已知备件种类 691 种,但是每种备件又有自己的版本细分。做一个四分类的方向分类模型,几乎需要覆盖到多达 T 级的数据。那么,如何提高泛化能力呢?能不能先做一个预处理把方向特征明确化,让卷积直接学习图片的方向特征呢?这是我们摆正的坑。


正常来说,一个接口处理一个特定的备件类型,但实际情况,会有很多其他的备件进行请求,比如:比如在房本任务中,就会有房屋登记表、前后封皮、确认书等等非房本图像对接口进行请求。这些请求是没有走完全流程的必要性的。所以,我们增加了图片分类,只对目标图像放行,减少对后半程模型的请求次数。对于非目标数据接口在分类这里提前返回。图片分类,在保障一定分类准确率的前提下,需要保证高召回:宁可误判,不可漏判。对于这类分类任务如何解决?虽然是个二分类或者稀疏类别分类问题,但是,依然存在数据样本的极度不平衡的情况,非目标多种多样,如何既保证快速判断又保证分类的准确性呢?


检测是各种问题的高发环节,套打偏移(文本交叠检测)、曲面弧面的任意形状检测(还有一种方案是先做文档矫正?)、老房本中的单个汉字,单个数字检测(漏检率高)。这些问题该如何解决?方案怎么选?还有是否要在一个模型里解决所有问题呢?


识别这块,我们遇到了形近字(人也经常看错的)、生僻字(训练和测试数据都难以获取,但确实存在)、对于长文本的地址(序列太长,其中还夹杂生僻字),如何解决这些问题呢?还有字典达到一定量级后,精度如何进一步提升(精度长尾问题如何解决)?都是我们遇到的坑。


最后说下结构化,从相对位置信息加规则的 hardcode 到模板匹配再到命名实体语义分类,结构化的各个场景和具体技术到底该如何适配?NLP 加 OCR 去做结构化到底香不香?


InfoQ:我们都知道,识别率是衡量 OCR 识别是否精准的重要标准,你们是如何将识别率从 95% 提升到 99% 的?


郭流芳:我觉得概括起来可以归纳为面向 badcase,分析主要矛盾,然后,从【数据】【模型】【结构化】三个方向具体入手,逐个击破,逐步提高。


为了做好准确率提升,首先,需要把问题定义清楚,这至关重要,最重要的是把问题的边界和约束明确出来;其次,需要确定 Evaltion 和 Metric。我们这边奉行测试先行的原则,再探索或者新建任何一个任务前,第一优先级的是要确保至少 100 张的测试数据。对于存量模型我们建立了滑动测试集。测试集的大小为 1000。分成三部分,第一是:QA 组建的边缘测试集(目标是测全)。第二个是:离线训练中的未识别部分和线上回流的 badcase(目的是暴露问题)。第三部分是:线上数据随机抽样(目的是展示真实效果,为了测准)。利用滑动测试集,得到 badcase,统计 badcase 的数量分布,以此确定当前模型精度提升的主要阻碍。


整个深度学习是数据驱动的,对遇到的问题,优先使用【数据】解决。但是数据是宝贵稀缺的资源,有时不可多得,例如:为了扩大生僻字的字典大小,我们不得不设计完整的数据合成试验。因为生僻字之所以叫生僻字,就是因为很难遇到数据。


对于特定字段,进行专项后处理,在【结构化】环节上的进行优化。例如:在房本地址字段的长文本中,就引入了 NLP 的语言模型。因为,地址通常是头尾好识别,而中间难以识别。我们通过大量标注预料,利用头尾来预测中间。进行结果的交叉验证。


随着字典的增加,我们需要更大的网络【模型】提取特征,需要更有区分度【损失函数】,这些都需要根据自己数据的实际情况,进行分析决策。会看到我把【模型】这个角度放到了最后,是因为【数据是模型的上限,模型只是在无限逼近数据】,所以,只有数据被榨干后,才回到优化模型的部分。如果你数据都不够,那就先补充数据吧。


总之,只有一个点一个点的钻研才能获得精度滴滴点点的提升。


InfoQ:目前是否存在一些瓶颈?未来还将做哪些事情去提高识别率?


郭流芳:“各种计划都不可能达到绝对的完美,这意味着一切事物的改良可以无止境的进行。我深知这一点,所以我经常会找一些更好的方法。我不会问自己:我能不能做的更好?我知道我一定办得到,所以我会问:我要怎么才能做得更好?”


我引用上面的话,是我们团队的一个信仰。目前,我们面临的问题是如何低成本地去永无止境的优化。简而言之,如何平衡投入产出比的问题,在 99% 的时候,其实已经高于人工作业准确率的情况下,是否还要去优化?如果需要优化,该怎么优化?该怎么低成本的优化?这是我们面临的一个难题。为此,在房本领域,我们开发了 ASLS (Auto Self-Learning System)系统和 Uni-iMatch (Unified intelligent Matching)来解决精度长尾问题和新增模板问题。其思路(闭环意识和抽象归纳)是可以借鉴到其他识别领域的。

嘉宾介绍

郭流芳,贝壳找房交易智能技术负责人。硕士毕业于中国矿业大学(北京),研究领域为图像处理,从事人工智能工作 5 年。现为贝壳找房交易智能技术负责人。从零到优构建了贝壳找房交易 OCR 技术体系,抽象总结了票据卡证类的 Uni-iMatch 解决方案和 ASLS 自学习系统,备件识别精度处于行业领先水平。团队著有《深度学习 PyTorch 实战——图像技术在 OCR 上的应用》一书,将于今年面世。


在 QCon 北京 2020 的演讲中,郭流芳老师将重点介绍 OCR 技术的一般流程、各个环节遇到的实际问题以及整个技术架构的变迁,贝壳交易智能是如何通过一个一个技术点的突破,使识别率从无到有,从 95% 到 99% 的。还将介绍下基于业务演进打造的 Uni-iMatch 和 ASLS 系统。点击了解详情。


2020-03-19 10:583246

评论

发布
暂无评论
发现更多内容

企业全球化出海技术体系建设实录【专题合集】

阿里技术

技术专题合集 全球化技术能力

如何从5万设备中找出频繁掉线设备,长期不在线的设备?——设备管理运维类

阿里云AIoT

Axure9和Axure10哪款好?有什么区别呢?

Rose

原型设计 Axure RP

小程序无需编程,体验IoT物联网平台-物模型开发——设备接入类

阿里云AIoT

物联网

共建区块链生态,旺链科技获颁2022年度FISCO BCOS产业应用合作伙伴

旺链科技

区块链 区块链+

React Hooks源码深度解析

京东科技开发者

函数 React Hooks 企业号 3 月 PK 榜

详解数仓中sequence的应用场景及优化

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 3 月 PK 榜

天池 DeepRec CTR 模型性能优化大赛 - 夺冠技术分享

阿里云大数据AI技术

人工智能 深度学习

高效学 C++|组合类的构造函数

TiAmo

组合 C++

IoT物联网时代,如何优化你的网络- DNS域名解析服务——设备接入类

阿里云AIoT

缓存 网络协议 物联网 域名解析 调度

DAPP质押挖矿项目技术开发功能丨DeFI质押挖矿系统开发详细方案

I8O28578624

【活动报名】数据存储降本增效应用实践 PolarDB × ScaleFlux 线下 Meetup 来袭!(杭州站)

阿里云数据库开源

数据库 postgresql 阿里云 开源 polarDB

软件测试/测试开发 | Spring Boot 集成 Swagger

测试人

软件测试 springboot 测试发开

Cloud Kernel SIG月度动态:发布 ANCK 新版本及 Plugsched v1.2.0

OpenAnolis小助手

内核 龙蜥社区 sig anck CVE修复

JavaScript 对象管家 Proxy

devpoint

JavaScript Proxy ECMAScript 6

IoT物联网平台-规则引擎SQL数据格式详解——设备管理运维类

阿里云AIoT

sql 物联网 数据格式

苹果M1/M2电脑安装Lightroom Classic 2022(LRC2022) 后打开闪退怎么办?

理理

m1 LRC2022 闪退 M2 苹果软件

Go 闯进 Top 10、C++ 再次被 Java 反超,TIOBE 3 月榜单发布

博文视点Broadview

贴合运维业务场景的告警聚合实现——以Zabbix为例

观纵科技

zabbix 运维监控 IT运维

Matlab实现图像分割

timerring

图像分割

Jasper狂飙:AIGC现象级应用的增长秘笈

OneFlow

人工智能 深度学习 ChatGPT

如何基于 Skywalking 来快速搭建一套应用性能监控平台

观纵科技

APM 全链路监控 Skywalking

mac office 365 商业专业版附升级工具

Rose

Office 365

精准医疗迎数字化新机遇,百奥利盟携手阿里云为创新生物药提速上市

云布道师

阿里云

GreptimeDB v0.1 发布|原生支持 Python, PromQL 和对象存储

Greptime 格睿科技

云原生 时序数据库 PromQL

如何规避近年频发的数据安全事故?

Zilliz

云原生 云服务 数据安全

BetterSnapTool for Mac 帮你整理窗口,提升效率

理理

BetterSnapTool 苹果电脑 窗口布局

ArchKeeper(开篇):架构守护平台的问题与理念

京东科技开发者

架构 敏捷 系统架构 腐化治理 企业号 3 月 PK 榜

还在curd吗?封装属于自己的Spring-Boot-Starter

做梦都在改BUG

Java spring Spring Boot Starter

15 英寸 MacBook Air 和黄色 iPhone 14 在路上吗?

Rose

apple

苹果软件Noir:为所有网站应用深色模式

理理

Safari 扩展 Noir – Dark Mode 暗模式

95%只是开始,贝壳的OCR识别率提升之道_QCon_邓艳琴_InfoQ精选文章