苹果的机器学习开发日记：如何设计能在Apple Watch上实时运行的中文手写识别系统

雷锋网 AI 科技评论按：随着苹果机器学习日记（Apple ML Journal）的开放，苹果分享出的设计自己产品、运用机器学习解决问题的故事也越来越多。近日苹果在上面就放出了一篇关于识别手写中文的文章，介绍了自己对这个功能的思考和实现过程。虽然文章中没有什么全新的技术，但也不失为一篇有诚意的开发经验分享。雷锋网 (公众号：雷锋网) AI 科技评论把文章编译如下。

随着手机、平板电脑这样的移动设备，以及智能手表这样的可穿戴设备变得流行甚至不可或缺，手写识别也随之变得前所未有地重要。中文包含了一个很大的字符库，在这些移动设备上支持中文手写识别就带来了一组独特的挑战。这篇文章中，苹果介绍了他们是如何在 iPone、iPad 和 Watch（绘画模式中）上应对这些挑战、实现中文手写的实时识别的。苹果设计的基于深度学习的识别系统可以准确地处理高达3万个不同的字符。为了达到合理的准确度，苹果的开发人员们在数据收集模式、书写方式的代表性和训练方式方面专门花了心思处理。他们发现，只要使用恰当的方式，即便更大的字符库也可以解决得了。实验表明只要训练数据的质量足够高、数量足够大，随着字符库增大，识别准确率只会慢慢下降。

简介

手写识别可以增强移动设备的用户体验，尤其是中文的键盘输入还相对比较复杂。中文的手写识别也有独特的挑战性，因为中文背后的字符库非常大。其它基于字母的语言中，包含字符的数量级通常也就在100上下，而中文国标 GB18030-2005 中含有的汉字有27533个，在整个中国范围内还有许多图形式的字符仍然在使用着。

为了便于电脑处理，常见的做法是只关注其中的一部分字符，一般就是选出日常使用中最有代表性的字。根据这样的思路，中文国标字符集 GB2312-80 仅仅包含了 6763 个字符（其中一级字符3755个，二级字符3008个）。中国科学院自动化研究所也构建了一个严密对齐的字符集，运用在CASIA数据库中，包含了总共7356个字符。SCUT-COUCH数据库的容量也在同一个水平上。

这些字符集基本反映了全中国的作家们的常用字。然而在个人层面上，每个人之间的“最常用字”经常都会有所不同。许多人都至少有几十个自己的“不常用字”，因为这些字其实会在相关的事物名中出现，反倒不用一个个写出来了。这样，理想状况下的中文手写识别算法就至少要扩充到 GB18030-2005 中2万多个汉字的水平。

早期的识别算法主要依靠基于一笔一划分析的结构化方法，后来有了去除笔划顺序影响的需求，就引发了人们利用整体形状信息建立统计学方法的兴趣。然而文本类别的数量越多，清晰地把文本分入一个类别就越难，这些方法显然会大大提升大字符集下的识别难度。

对于MNIST之类的拉丁字符识别任务，卷积神经网络（CNN）很快就表现出了压倒性的优势。只要有足够的训练数据、适当补充一些需要的生成样本，CNN毫无疑问可以达到出顶尖的表现。不过，这些研究中的字符类别都相当的少。

之前，当苹果的研究人员们开始研究如何做大规模的中文字符识别时，似乎明摆着就应该选CNN。但是CNN的方法需要把网络拓展到包含接近3万个字符，同时还要保证在嵌入式设备上还有实时识别的性能。这篇文章的重点就是介绍如何解决延时、字符覆盖率、书写风格的鲁棒性等方面的问题，达到理想的性能表现。

系统配置

苹果的研究人员们在这项研究中采用了一个普遍的CNN架构，跟之前用在MNIST手写识别实验中的CNN类似。系统的总体架构如图

图1. 典型的CNN架构（带有连续的2组卷积+子采样）

系统输入是一张中等分辨率 48x48 的图像（为了更好的性能），其中包含着一个手写中文字符。然后把它送入几个包含卷积层和子采样层的特征提取层。最后一个特征提取层通过一个全连接层连接到输出。

在每个卷积层中，苹果的研究人员们都选择了能够从逐渐变得粗糙的粒度中尽量提取特征的卷积核和feature map数量。他们运用一个2x2的卷积核，通过一个最大池化层做子采样。最后一个特征层包含的小feature map数量级一般在1000上下。最后，输出层上给每一个类都有一个单独的节点，对于 GB2312-80 中级别1的汉字就有3755个节点，拓展到所有字符的时候就要接近30000。

作为基准线，苹果的研究人员们在CASIA benchmark任务中评估了这个CNN模型。虽然这个任务只涵盖了汉字中级别1的字符，但是在以往文献中有丰富的识别测试准确率结果。他们使用了同样的基于 CASIA-OLHWDB、DB1.0-1.2，分为训练集和测试集，训练样本的数量大约为100万个。

值得注意的是，苹果这项研究的关注点是面向产品的，所以他们的目标并不是在 CASIA 中取得尽可能高的准确率，更为关注的是模型大小、推理速度和用户体验。所以，他们的优化目标是一个紧凑的、能够实时计算结果的系统，它要能够对付多种不同的书写风格，对于非标准的笔划顺序也需要有较高的鲁棒性。这样下来，即便把在线的数据库也加入了评估中，他们还是选用了基于图像特征的识别方法。他们也把实际观察到的笔划变化、外型改变也考虑了进来。

表1展示了前文图1中的CNN模型的测试结果，其中“Hz-1”代表了级别1的汉字库（3755个字符），“CR(n)”代表了模型的前n位识别结果中含有正确字符的准确率。除了常用的首选准确率（n=1）和前10位识别准确率（n=10）之外，表格中还加入了一项前4位准确率（n=4），因为苹果的用户界面中就是显示4个候选字符，前4位准确率是一个重要的衡量用户体验的标志。

表1：CASIA在线数据库中3755个中文字符的测试结果。标准训练，关联模型大小1MB

之前有研究中首选准确率达到93%，前10位准确率达到98%。相比之下，虽然苹果自己的前10位准确率和其它研究中的在同一水平上，但第一位准确率要稍低。在苹果看来，这是为了达到更高的前4位准确率作出的平衡；而且可能更重要的是，这个模型的大小（1MB）比之前任何类似的系统都要小。

表1中的系统仅仅用了CASIA中的数据进行了训练，没有用到其它的训练数据。苹果的研究人员们也很感兴趣，如果额外加入自家的iOS设备上实际采集到的手写数据用来训练系统会达到怎样的效果。这些数据中涵盖的书写风格更为多样，每个字符也有更多对应的训练样本。如下表2就是训练结果，对应的是同一个3755字符的字符库。

表2：CASIA在线数据库中3755个中文字符的测试结果。增强训练，关联模型大小15MB

虽然这个系统的体积有大幅度的增加（达到了15MB），准确率却只提升了一点点（前4位准确率的绝对值提升了2%）。这表明，测试集中的多数书写风格都已经在CASIA的训练集中有了相当的覆盖。不过这也说明增加更多的训练数据并没有什么坏处：新增加的书写风格并不会对模型的原有表现带来负面的影响。

拓展到3万个字符

前文有说过，每个人理想状况的下的“常写的字”都不一样，用户数目大的时候需要的字库大小也就远远不止3755个。准确挑出需要的字库也不是一件那么简单直接的事情。GB2312-80 定义的简体中文字符，以及 Big5、Big5E、CNS 11643-92 中定义的繁体中文字符覆盖的范围也各有不同（从3755到48027个汉字）。近期一些的还有新增了4568个字符的 HKSCS-2008，GB18030-2000中的甚至更多。

苹果想要保证用户们的日常用语都能写得出来，不管是简体还是繁体中文、是名字还是诗歌，还有其它常用的标记、视觉符号和emoji表情，他们也希望能让用户无需转译就写出偶尔会在产品或者品牌名中出现的拉丁字符。苹果遵循了国际主流的 Unicode 字符集作为字符编码标准，因为其中几乎囊括了上面提到的所有字符标准（值得一提的是，Unicode 7.0在B-D拓展中可以区分7万个字符，而且还在考虑增加更多）。所以苹果的字符识别系统就选择了关注 GB18030-2005, HKSCS-2008, Big5E 中的汉字部分，以及 ASCII 的核心字符集和一组视觉符号和emoji表情，总数大约3万个字符。这对于大多数中国用户来说已经是最佳的取舍了。

在选出了模型内在的字符库之后，下一个关键的点就是对用户真正使用的书写风格进行采样。虽然不同的书写风格之间有一些正式的规则可以用来帮助鉴别，但此外还会有一些区域性的书写变化，比如 U+2EBF （艹）的几种写法，或者U+56DB（四）的写得潦草的时候和U+306E（の）之间的类似性。

屏幕上显示的字符也会带来迷惑性，因为有些用户会希望某些字符以特定的样式显示。写得快的时候也会让风格变得潦草，这会增加字符的模糊性，比如 U+738B（王）和U+4E94（五）。

最后，增大国际化的程度有时候也会带来没有预料到的冲突，比如U+4E8C（二），写成连笔的时候就会和拉丁字符“2”和“Z”产生冲突。

苹果的设计准则是给用户提供全部的输入可能性，不管是像印刷字体一样，还是潦草的、不受约束的写法。为了囊括尽可能多的字体变形，苹果的研究人员们从全中国不同区域的作家们手中收集数据。让他们很惊讶的是，有不少不常用的字，大多数的用户连见都没有见过。由于对不常用字的不熟悉，用户在书写的时候可能会犹豫、写错笔划顺序，以及造成其它的一些错误，都需要纳入考虑中。

苹果的研究人员们雇了许多不同年龄段、性别、教育程度的普通中国人，让他们写字，收集数据；最终得到的手写数据也有许多别的数据库不具有的特点：包含了多大几千名用户的数据，在iOS设备上用手指书写（而不是手写笔），数据也是有许多小批的。其中还有一个好处是iOS设备的采样会形成非常清晰的手写笔迹。

苹果的研究人员们发现了非常多样的书写方式。如下图2到图4是其中一些U+82B1（花）的写法，有的接近打印，有的很潦草，有的变化很大。

实际上，日常生活中用户们经常写得很快、变化很大，潦草、变形的笔迹看起来会有很大的区别。比如U+7684（的）和U+4EE5（以）。

反过来说，有时候不同的字也会看起来很相似，造成迷惑。以下U+738（王）、U+4E94（五）的数据就是明显的例子。值得注意的是，要能够区分潦草的变化就一定需要足够的训练数据。

根据前面讨论的设计准则，苹果采集了上千万个手写的汉字实例用作训练数据。下面表3中的结果就是把可识别的字符数量从前面的3755个字符拓展到接近3万之后得到的。仍然是前文的同一个 CASIA 在线测试。

表3：CASIA在线数据库中30K个字符的测试结果

这里保持了同样的模型大小。前文表2中的系统只是限制在级别1汉字范围，其它都与表3中的系统相同。准确率有略微下降，这倒比较符合研究人员们的期待，因为大幅度增长的覆盖范围会带来额外的混淆，比如前面提到过的“二”和“Z”。

把表1到表3的结果进行对比，可以看到把字符覆盖范围扩大10倍并不会把错误率也扩大10倍，或者把模型大小变大10倍。实际上，对于更大的模型，错误率升高得要慢得多。所以，构建一个覆盖了3万个字符（而不是仅仅3755）、同时还有高准确率的中文手写字符识别系统，不仅是可能的，还是可行的。

为了说明系统在这所有3万个字符中的表现如何，苹果的研究人员们也用一系列不同的测试集进行了测试，其中包含了所有支持的字符、用了各种的书写风格。表4是结果的平均值。

表4：包含了所有书写风格的3万个字符的测试集的多个苹果内部测试的平均结果

当然，表3和表4的结果是不能够直接进行对比的，因为它们是用不同的测试集得到的。不过，它们的第一位准确率和前四位准确率对于整个字符库都是在同一水平的。这样的结果是通过较为均衡的训练模式达到的。

讨论

在表意文字工作组 IRG 不断从不同的来源收集文字、提出新的增加建议下，目前大小约为75000的Unicode字符集中含有的中日韩文表义文字未来还可能继续增加。坦诚地讲，之后新增加的字符都会是非常罕见的字符（比如历史上出现过的名字或者诗歌中的）。不过，对于名字里刚好有一些罕见字的人来说，这些工作还是很有意义的。

那么，苹果未来打算如何应对更大的字符库呢？这篇文章中的实验展示了不同数量的训练数据下的训练和测试错误率状况。这样就可以做近似的推断，预测有更多训练数据、更多字符需要识别的时候准确率表现如何。

比如，从表1到表3可以看到，对于增大了十倍的字符库和模型相关资源的大小，准确率仅仅下降了（不到）2%。那么就有理由猜测，对于数目达到十万个的字符库和同倍增加的训练数据，完全有可能仍然达到84%左右的首选准确率和97%的前10位准确率（对于同样的网络架构）。

总结来说，构造一个覆盖了多达3万个中文字符的高准确率手写识别系统，即便对于嵌入式设备也是可以实现的。进一步地，随着字符库大小增加，识别准确率下降得非常慢，只要有足够数量的高质量训练数据。这对未来可能的基于更大的字符库的手写识别来说是一个好消息。

via  Apple ML Journal ，雷锋网 AI 科技评论编译

相关文章：

苹果机器学习博客姗姗来迟，不过第一篇文章就给紧缺训练数据的研究者们发糖

雷锋网版权文章，未经授权禁止转载。详情见。