有道云笔记是如何使用TensorFlow Lite的?

近年来,有道技术团队在移动端实时 AI 能力的研究上,做了很多探索及应用的工作。2017 年 11 月 Google 发布 TensorFlow Lite (TFLlite) 后,有道技术团队第一时间跟进 TFLite 框架,并很快将其用在了有道云笔记产品中。本文将介绍我们是如何将 TFLite 运用在有道云笔记中的文档识别工作中的,以及 Tflite 都有些什么特性。

文档识别工作的介绍

1. 文档识别的定义
文档识别最初是开发有道云笔记的文档扫描功能时面对的一个问题。文档扫描功能希望能在用户拍摄的照片中,识别出文档所在的区域,进行拉伸 (比例还原),识别出其中的文字,最终得到一张干净的图片或是一篇带有格式的文字版笔记。实现这个功能需要以下这些步骤:

  1. 识别文档区域: 将文档从背景中找出来,确定文档的四个角;
  2. 拉伸文档区域,还原宽高比: 根据文档四个角的坐标,根据透视原理,计算出文档原始宽高比,并将文档区域拉伸还原成矩形;
  3. 色彩增强: 根据文档的类型,选择不同的色彩增强方法,将文档图片的色彩变得干净清洁;
  4. 布局识别: 理解文档图片的布局,找出文档的文字部分;
  5. OCR: 将图片形式的“文字”识别成可编码的文字;
  6. 生成笔记: 根据文档图片的布局,从 OCR 的结果中生成带有格式的笔记。

pic1

文档识别就是文档扫描功能的第一步,也是场景最复杂的一个部分

2. 文档识别在有道 AI 技术矩阵中的角色

有道近年来基于深度神经网络算法,在自然语言、图像、语音等媒体数据的处理和理解方面做了一系列工作,产出了基于神经网络的多语言翻译、OCR(光学字符识别)、语音识别等技术。在这些技术的合力之下,我们的产品有能力让用户以他们最自然最舒服的方式去记录内容,用技术去理解这些内容,并将其统一转化为文本以待下一步处理。从这个角度来看,我们的各种技术组成了以自然语言为中心,多种媒体形式相互转换的网络结构。

文档识别是从图像转化为文本的这条转换链上,不起眼却又不可缺少的一环。有了它的存在,我们可以在茫茫图海中,准确找到需要处理的文档,并将其抽取出来进行处理。

3. 文档识别的算法简介

我们的文档识别算法基于 FCNN (Fully Convolutional Neural Network) ,这是一种特别的 CNN(卷积神经网络),其特点是对于输入图片的每一个像素点,都对应着一个输出(相对的,普通的 CNN 网络则是每一张输入图片对应着一个输出)。因此,我们可以标记一批包含文档的图片,将图片中文档边缘附近的像素标注为正样本,其他部分标注为副样本。训练时,以图片作为 FCNN 的输入,将输出值与标注值作对比得到训练惩罚,从而进行训练。关于文档识别算法的更多细节,可以参见有道技术团队的《文档扫描:深度神经网络在移动端的实践》这篇文章。

由于算法的主体是 CNN,因此文档扫描算法中主要用到的算子(Operator)包括卷积层、Depthwise 卷积层、全连接层、池化层、Relu 层这些 CNN 中常用的算子。

4. 文档识别与 TensorFlow

能够训练和部署 CNN 模型的框架非常多。我们选择使用 TensorFlow 框架,是基于以下几方面的考虑的:

  1. TensorFlow 提供的算子全面且数量众多,自己创建新的算子也并不麻烦。在算法研发的初期会需要尝试各种不同的模型网络结构,用到各种奇奇怪怪的算子。此时一个提供全面算子的框架能够节省大量的精力;
  2. TensorFlow 能够较好的覆盖服务器端、Android 端、iOS 端等多个平台,并在各个平台上都有完整的算子支持;
  3. TensorFlow 是一个比较主流的选择,这意味着当遇到困难时,更容易在互联网上找到现成的解决办法。

5. 为什么想在文档识别中用 TFLite

在 TFLite 发布之前,有道云笔记中的文档识别功能是基于移动端 TensorFlow 库 (TensorFlow Mobile) 的。当 TFLite 发布后,我们希望迁移到 TFLite 上。促使我们迁移的主要动力是链接库的体积。

经过压缩后,Android 上的 TensorFlow 动态库的体积大约是 4.5M 左右。如果希望满足 Android 平台下的多种处理器架构,可能需要打包 4 个左右的动态库,加起来体积达到 18M 左右;而 tflite 库的体积在 600K 左右,即便是打包 4 个平台下的链接库,也只需要占用 2.5M 左右的体积。这在寸土寸金的移动 App 上,价值是很大的。

TFLite 的介绍

1. TFLite 是什么
TFLite 是 Google I/O 2017 推出的面向移动端和嵌入式的神经网络计算框架,于2017年11月5日发布开发者预览版本 (developer preview)。相比与 TensorFlow,它有着这样一些优势:

  • 轻量级。如上所述,通过 TFLite 生成的链接库体积很小;
  • 没有太多依赖。TensorFlow Mobile 的编译依赖于 protobuf 等库,而 tflite 则不需要大的依赖库;
  • 可以用上移动端硬件加速。TFLite 可以通过 Android Neural Networks API (NNAPI) 进行硬件加速,只要加速芯片支持 NNAPI,就能够为 TFLite 加速。不过目前在大多数 Android 手机上,Tflite 还是运行在 CPU 上的。

2. TFLite 的代码结构

作为 TFLite 的使用者,我们也探索了一下 TFLite 的代码结构,这里分享一下。

目前,TFLite 的代码位于 TensorFlow 工程中 “tensorflow/contrib/lite” 文件夹下。文件夹下有若干头/源文件和一些子文件夹。

其中,一些比较重要的头文件有:

  • model.h: 和模型文件相关的一些类和方法。其中 FlatBufferModel 这个类是用来读取并存储模型内容的,InterpreterBuilder 则可以解析模型内容;
  • Interpreter.h: 提供了用以推断的类 Interpreter,这是我们最常打交道的类;
  • context.h: 提供了存储 Tensors 和一些状态的 struct TfLiteContext。实际使用时一般会被包装在 Interpreter 中;

此外,有一些比较重要的子文件夹:

  • kernels: 算子就是在这里被定义和实现的。其中 regester.cc 文件定义了哪些算子被支持,这个是可以自定义的。
  • downloads: 一些第三方的库,主要包括:
  • abseil: Google 对 c++ 标准库的扩展;
  • eigen: 一个矩阵运算库;
  • farmhash: 做 hash 的库;
  • flatbuffers: TFLite 所使用的 FlatBuffers 模型格式的库;
  • gemmlowp: Google 开源的一个低精度矩阵运算库;
  • neon_2_sse: 把 arm 上的 neon 指令映射到相对应的 sse 指令。
  • java: 主要是 Android 平台相关的一些代码;
  • nnapi: 提供了 nnapi 的调用接口。如果想自己实现 nnapi 可以看一看;
  • schema: TFLite 所使用的 FlatBuffers 模型格式的具体定义;
  • toco: protobuf 模型转换到 FlatBuffers 模型格式的相关代码。

我们是怎么用TFLite的?

1. TFLite 的编译

TFLite 可以运行在 Android 和 iOS 上,官方给出了不同的编译流程。

在 Android 上,我们可以使用 bazel 构建工具进行编译。bazel 工具的安装和配置就不再赘述了,有过TensorFlow 编译经验的同学应该都熟悉。依照官方文档,bazel 编译的 target 是 “//tensorflow/contrib/lite/java/demo/app/src/main:TfLiteCameraDemo”,这样得到的是一个 demo app。如果只想编译库文件,可以编译 “//tensorflow/contrib/lite/java:tensorflowlite” 这个 target,得到的是 libtensorflowlite_jni.so 库和相应的 java 层接口。

更多细节见官方文档:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/docs_src/mobile/tflite/demo_android.md

在 iOS 上,则需要使用 Makefile 编译。在 mac 平台上运行 build_ios_universal_lib.sh,会编译生成 tensorflow/contrib/lite/gen/lib/libtensorflow-lite.a 这个库文件。这是个 fat library,打包了 x86_64, i386, armv7, armv7s, arm64 这些平台上的库。

更多细节见官方文档:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/docs_src/mobile/tflite/demo_ios.md

两个平台上 TFLite 库的调用接口也有所不同:Android 上提供了 Java 层的调用接口,而 iOS 上则是 c++ 层的调用接口。

当然,TFLite 的工程结构是比较简单的,如果你熟悉了 TFLite 的结构,也可以用自己熟悉的编译工具来编译 TFLite。

2. 模型转换

TFLite 不再使用旧的 protobuf 格式(可能是为了减少依赖库),而是改用 FlatBuffers 。因此需要把训练好的 protobuf 模型文件转换成 FlatBuffers 格式。

TensorFlow 官方给出了模型转化的指导。首先,由于 TFLite 支持的算子比较少,更不支持训练相关的算子,因此需要提前把不需要的算子从模型中移除,即 Freeze Graph ;接着就可以做模型格式转换了,使用的工具是 tensorflow toco。这两个工具也是通过 bazel 编译得到。

更多细节见官方文档:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/docs_src/mobile/tflite/devguide.md

3. 缺失的算子

TFLite 目前仅提供有限的算子,主要以 CNN 中使用到的算子为主,如卷积、池化等。我们的模型是全卷积神经网络,大部分算子 TFLite 都有提供,但 conv2d_transpose(反向卷积)算子并没有被提供。幸运的该算子出现在网络模型的末端,因此我们可以将反向卷积之前的计算结果取出,自己用 c++ 实现一个反向卷积,从而计算出最终的结果。由于反向卷积的运算量并不大,所以基本没有影响到运行速度。

如果不巧,你的模型需要但 TFLite 缺少的算子并非出现在网络的末端,该怎么办呢?你可以自定义一个 TFLite 算子,将其注册在 TFLite 的 kernels 列表中,这样编译得到的 TFLite 库就可以处理该算子了。同时,在模型转换时,还需要加上 –allow_custom_ops 选项,将 TFLite 默认不支持的算子也保留在模型中。

更多细节见官方文档:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/lite/g3doc/custom_operators.md

TFLite 优缺点

优点:在 库的大小、开发方便程度、跨平台性、性能之间达成一个平衡
作为对比,有道技术团队选取了一些其他的移动端深度学习框架,分别分析其在“开发方便程度、跨平台性、库的大小、性能”四个方面的表现:

  • TensorFlow Mobile,由于和 server 上的 TensorFlow 是同一套代码,所以可以直接使用 server 上训练得到的模型,开发非常方便;能支持 Android, iOS, 跨平台性没问题;如前所述,库的大小比较大;性能主流。
  • caffe2,可以比较方便的从 caffe 训练出的模型转换到 caffe2 ,但缺少一些算子, 开发方便程度一般;能支持 Android, iOS,跨平台性没问题;库编译出来比较大,但是是静态库可以压缩;性能主流。
  • Mental/Accelerate,这两个都是 iOS 上的框架。比较底层,需要模型转换&自己写 inference 代码,开发比较痛苦;仅支持 iOS;库是系统自带,不涉及库大小问题;速度很快。
  • CoreML,这个是 WWDC17 发布的 iOS 11 上的框架。有一些模型转换工具,只涉及通用算子时开发不算痛苦,涉及自定义算子时就很难办了;仅支持 iOS 11 以上;库是系统自带,不涉及库大小问题;速度很快。

最后是 TFLite:

  • TFLite,其模型可以由 TensorFlow 训练得到的模型转换而来,但缺少一些算子, 开发方便程度一般;能支持 Android, iOS,跨平台性没问题;库编译出来很小;就我们的实验来看,速度比TensorFlow 快一点。

可以看到,TensorFlow Mobile 开发方便,通用性好,但链接库大,性能主流(其他 server 端神经网络框架的 mobile 版也都有类似的特点);Mental/Accelerate 这些比较底层的库速度很快,但不能跨平台,开发比较痛苦;caffe2、TFLite 这类有为移动端优化过的神经网络框架则比较平衡,虽然初时会有算子不全的问题,但只要背后的团队不断支持推进框架的开发,这个问题未来会得到解决。

优点:相对容易扩展

由于 TFLite 的代码(相对于 TensorFlow)比较简单,结构比较容易理清,所以可以相对容易的去扩展。如果你想增加一个 TFLite 上没有而 TensorFlow 上有的算子,你可以增加一个自定义的类;如果你想增加一个 TensorFlow 上也没有的算子,你也可以直接去修改 FlatBuffers 模型文件。

缺点:ops 不够全面

如前所述,TFLite 目前主要支持 CNN 相关的算子 ,对其他网络中的算子还没有很好的支持。因此,如果你想迁移 rnn 模型到移动端,TFLite 目前是不 OK 的。

不过根据最新的 Google TensorFlow 开发者峰会,Google 和 TensorFlow 社区正在努力增加 ops 的覆盖面,相信随着更多开发者的相似需求, 更多的模型会被很好的支持。这也是我们选择 TensorFlow 这样的主流社区的原因之一。

缺点:目前还不能支持各种运算芯片

虽然 TFLite 基于 NNAPI,理论上是可以利用上各种运算芯片的,但目前还没有很多运算芯片支持 NNAPI。期待未来 TFLite 能够支持更多的运算芯片,毕竟在 CPU 上优化神经网络运行速度是有上限的,用上定制芯片才是新世界的大门。

 总结

这一两年来,在移动端实现实时的人工智能似乎已经形成了一波潮流。有道技术团队在移动端 AI 算法的研究上,也做了诸多尝试,推出了离线神经网络翻译 (离线 NMT) 、离线文字识别 (离线 OCR) 以及离线文档扫描等移动端实时 AI 能力,并在有道词典、有道翻译官、有道云笔记中进行产品化应用。由于目前移动端 AI 尚处在蓬勃发展阶段,各种框架、计算平台等都尚不完善。 
 
阅读全文
NLPCC2018中文语法错误修正任务分享
本文主要是分享在NLPCC2018会议语法错误修正任务中有道AI团队的相关工作和方法,我们在该任务中取得了综合指标第一名的结果。该方法对应论文已被NLPCC会议收录,论文题目为:《Youdao’s Winning Solution to the NLPCC-2018 Task 2 Challenge: A Neural Machine Translation Approach to Chinese Grammatical Error Correction》

背景篇

NLPCC的全称为“CCF国际自然语言处理与中文计算会议”,英文为“Natural Language Processing and Chinese Computing”,是中国首个NLP领域的国际会议,由中国计算机学会(CCF)主办,至今已经举办了七届。在今年的竞赛单元中,首次增加了中文语法错误修正任务(Shared Task 2: Grammatical Error Correction)。该项任务的目标是:检测并修正由非中文母语者书写的中文句子中的语法错误[1]。可以认为该项任务的输入是一句可能含有语法错误的中文句子,输出是一句经过修正后的中文句子。作为一个比赛任务,这个工作更关注算法的效果,即结果的正确性,而不太考虑处理速度、资源占用等应用落地的问题。

数据篇

比赛方要求参赛者主要使用主办方提供的数据进行模型算法的训练和调试,在比赛截止前一周发布测试集原文,参赛者使用算法生成指定格式的自动批改结果以后提交结果。 主办方给出的训练数据来源于一个语言学习网站,该网站提供了一个开放平台让对应语言的母语者可以自由地对平台上语言学习者写的作文进行语法修正。训练数据共有71万条记录,每一条记录包含一个可能含有语法错误的句子和零到多句对应句子修正结果。如果是零句修正结果,则可以认为这句话是不需要修正的;如果是多句修正结果,可以认为有多种修改方法。 在一个传统的自然语言处理任务中,训练数据的收集和清洗往往会占到整个策略工作的50%甚至70%的时间,数据预处理的策略也会对后续算法的选择和效果有非常大的影响。通过对训练语料的分析,我们最终使用的策略是:将训练语料中每条记录拆成多个错误到正确的语句对,如果某条记录没有修正结果,则生成一个正确到正确的语句对。经过上述处理后,我们最终获得了122万条训练语料,并且将其中的3000句预留作为调试用的开发集,不参与到训练当中。原始训练数据的对应修正结果分布及样例分别如图表 1和图表 2所示。

阅读全文
文档扫描:深度神经网络在移动端的实践
鲜于海舒(有道高级研发工程师)
随着深度学习算法在图像领域中的成功运用,学术界的目光重新回到神经网络上;而随着 AlphaGo 在围棋领域制造的大新闻,全科技界的目光都聚焦在“深度学习”、“神经网络”这些关键词上。与大众的印象不完全一致的是,神经网络算法并不算是十分高深晦涩的算法;相对于机器学习中某一些数学味很强的算法来说,神经网络算法甚至可以算得上是“简单粗暴”。只是,在神经网络的训练过程中,以及算法的实际运用中,存在着许多困难,和一些经验,这些经验是比较有技巧性的。
有道云笔记不久前更新的文档扫描功能中使用了神经网络算法。本文试图以文档扫描算法中所运用的神经网络算法为线索,聊一聊神经网络算法的原理,以及其在工程中的应用。
阅读全文
Avazu Click-Through Rate Prediction比赛分享

                                                                                                              燕鹏、周骁聪

Avazu Click-Through Rate Prediction是移动广告dsp公司avazu在kaggle上举办的广告点击率预测的比赛,全球共有1604支队伍参加,我和周骁聪组队参加了比赛,最终我们获得了第三名。下面是我们比赛的方法分享。

Avazu CTR Prediction

整个比赛历时两个多月,在这个过程中我们和众多数据挖掘高手交流切磋,对于广告点击率预测问题也有了更深的理解。点击率预测算法在经历了多年的研究和发展之后,如今再要有一个大的提升已经是一个比较困难的事情了。当前点击率预测算法的主要收益大都是来自于线性模型的改进+特征工程,最近几年工业界已经开始尝试用非线性模型去解决点击率预测的问题,也取得了一些不错的结果。通过这次比赛,我们也相信非线性模型的使用以及多模型的融合会带来点击率预测算法的下一次飞跃。

阅读全文
Scrum——在变化中求进化

贾儒(高级开发工程师)

移动互联网当道的今天,变化已经是大家习以为常的事情了。也许昨天还在街边苦等久久不来的出租车,今天已经可以在手机上点点预约车辆准时到达门口。优秀的产品带来了生活习惯、甚至生活方式的变化,这是从前无法想象的。在这背后则是互联网产品服务的变化,在这个大潮中,“进化”的周期变得越来越短,大家也许还记得当年各大杀毒软件厂商,每年才会发布一个新的功能版本,而如今几乎每一天大家的手机上都会收到各种各样的软件更新。而在这种快速更新的软件背后,需要一种能够很好适应并响应变化的团队组织方式——已经为大家所熟知的敏捷开发方法Scrum。

阅读全文
局域网内针对自制证书网站的SSL中间人攻击

孔祥欣(高级开发工程师)

对于网络上通信的两个人,我们如何窃取他们的通信信息而又不被他们发现呢?一种通用的做法就是中间人攻击。所谓的中间人攻击就是通过某种技术手段将攻击者放置在通信的两个人之间,拦截并分析他们的通信流量,然后在将流量转发给对方。

如下图所示,Alice和Bob以为他们是通过虚线通信的,实际上是通过实线由Malicious转发的,这里Malicious就是一个中间人,他可以看到Alice和Bob之间的全部通信信息。

kongxx 图1

为了防止中间人攻击,Alice和Bob决定使用SSL协议。

阅读全文