写点什么

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:583193

评论

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

Kafka原理——Kafka为何如此之快?

Kafka中文社区

【量化】量化交易入门系列3:经典的量化交易策略(中)

恒生LIGHT云社区

量化投资 量化交易 量化

C++ 动态内存分配的问题,你都懂了吗?

小梁编程汇

c++ 堆内存管理 内存分配 smart pointer

今天你的静态变量和静态代码块执行了吗?

华为云开发者联盟

Java 类加载 静态 静态变量 静态代码块

Hive on Spark和Spark sql on Hive,你能分的清楚么

华为云开发者联盟

sql 分布式计算 Sparksql hive on spark 数据源

科技驱动经济发展的时代全面到来

CECBC

【Golang】浅谈协程并发竞争资源问题

恒生LIGHT云社区

golang 后端 协程 并发 Go 语言

潘娟:Keep open,Stay tuned 开源为我打开的全新世界 | TiDB Hackathon 2021 评委访谈

PingCAP

Flink类型系统的根及相关接口

编程江湖

flink

网络安全好学吗?基础入门篇,NMAP高级使用技巧和漏洞扫描发现

学神来啦

网络安全 渗透测试 kali基础 nmap kali Linux

架构营模块八作业

GTiger

架构实战营

nodejs 异步I/O和事件驱动

编程江湖

nodejs

「自我检验」熬夜总结50个Vue知识点,全都会你就是神!!!

Sunshine_Lin

面试 Vue 前端 进阶 ES6

编写Spring MVC控制器的技巧

编程江湖

Spring MVC

EMQ 映云科技入围 Venture50 行业榜单,数字科技企业风向标!

EMQ映云科技

物联网 Venture50

书单 | 学习数据可视化?看这些书就够了!

博文视点Broadview

带你认识7种云化测试武器

华为云开发者联盟

测试 接口测试 华为云DevCloud 云化测试 Mock 服务

Go 通过 Map/Filter/ForEach 等流式 API 高效处理数据

万俊峰Kevin

微服务 stream go-zero Go 语言

数据库批量插入这么讲究的么?

秦怀杂货店

Java 数据库 批量插入

netty系列之:选byte还是选message?这是一个问题

程序那些事

Java Netty 程序那些事 UDT 1月月更

什么是Log4Shell?Log4j漏洞解读

龙智—DevSecOps解决方案

log4j Log4j 2 Log4Shell

前端开发Vue中的v-指令的使用

@零度

Vue 前端开发

10个问题让你快速避开java中的jdbc常见坑

华为云开发者联盟

Java 数据库 JDBC fetchSize Prepared Statement

作业4

施正威

一文整理区块链技术为企业带来的九大好处

CECBC

写时复制技术(COW)详解

小梁编程汇

性能优化 操作系统 CopyOnWrite;

面试官:为什么不同返回类型不算方法重载?

王磊

Java开发之测试框架知识分享

@零度

Java

ReactNative进阶(一):ReactNative 学习资料汇总

No Silver Bullet

React Native 1月月更

测试阻碍交付,如何破解这一难题?

SoFlu软件机器人

大数据开发之Hive SQL的优化分享

@零度

大数据 Hive SQL

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