文/ 阿里淘系 F(x) Team - 琻中
背景介绍
前端页面的设计与展示都离不开图片，在 imgcook 中，许多图片的 icon 更图片中非常重要的一环。icon 往往由简单的线条组成，并有鲜明的含义，因此它被广泛用于通用行动点的表述 —— 主页、搜索、设置、返回、用户，等等。除此以外，icon 既能化抽象为具象，解决文字表达的枯燥性；又能因为它高度规范化的设计获得较强的语义性。
在 imgcook 全链路中，我们统计到平均每个月都有约 6,156 个 icon 被检测出；平均每个新增模块都使用了约 2.67 个 icon。因此，了解设计稿中用了哪些 icon，某种程度上就知晓了此 icon 范围内的语义信息，由此可以帮助 imgcook 做更多的智能化判断。基于这一点，icon 语义化这一步骤就显得十分重要了。
问题分析
在以往的 imgcook 链路中，我们已经采用了 resnet 对约 80+ 的 icon 进行分类识别和语义信息的提取；我们也通过图片聚类的方式将相似的图片归为一组从而根据相似性推测 icon 的语义信息。不过，在线上验证后效果并不是特别可观：
首先，icon 的类别很多，数量也很庞大，使用模型直接训练的效果不会特别理想，因此需要一个科学的分类与样本管理方法从而提升分类与样本的质量。
其次，虽然绝大多数 icon 都遵循一定的设计原则（简单、直观），但 icon 设计依旧是个极富设计性的过程，所以 icon 的样式也在不断地升级。因此，我们需要我们的数据与模型能具备更强的覆盖面与泛化能力。
综上，icon 的识别与语义化是 imgcook 整个链路中不可或缺的一环，而对于 icon 识别的优化不仅仅优化模型，更要从数据源头和可迭代性入手，我们需要让模型具有自我迭代能力，所以对 icon 识别模型进行了从 L3 到 L4 的能力升级。
接下来，我会通过这篇文章讲述下 imgcook 是如何通过构建一个完整的 icon 模型闭环链路来解决数据与模型的优化问题。
技术方案
数据链路
说到 icon 识别模型闭环链路，最主要且贯穿始终的就是数据部分了。若数据不能自我更新、自我迭代，那这个链路充其量不过就是一个模型变更的实验，并称不上是工程化链路。在 imgcook 的闭环中，为了保证数据是最新的且可以自我补充，我们提供了两种数据收集方案：
- 手动新增数据
- imgcook 链路 icon 自动入库
如果手上已经整理了一个分类的数据，可以通过面板直接导入：
此外对于 imgcook 自动提取的 icon，会直接收录并执行自动标注：
这样，我们就保证了在后台数据集中，总是有源源不断地新设计、新分类的 icon 汇入，从而不断壮大 icon 数据集的覆盖面。
对于自动收集的 icon，系统会执行一次预测，如果预测成功，则会自动打上标签，如果预测失败，则会提醒人工手动打标。维护人员可以通过非常简单地点击为数据打标：
标注成功之后，即可一键将数据发送至 oss 保存，供之后的模型训练使用。
模型链路
由于训练数据在实时更新，模型训练层只需同步 oss 的数据和标签数据，即可非常便捷地生成训练样本，在经过数据同步、图片数据增强以后，即可直接将归档文件导入 pipcook 进行训练。训练结束之后，会将当前的模型与线上的模型做准确度对比，进入灰度阶段。灰度期过之后，新的模型就会取代旧模型，进入到 imgcook 主链路中。
落地效果
在部署了新的模型链路之后，icon 识别的整体质量也得到了提升。
数据效果
首先，由于流程中的 icon 都经过了严格的清洗、去重和归一化，样本的坏样率大大降低，自上线以来，新增训练集总数达到了 2729 个，平均每月回捞有效数据 909 个。分类也由 97 种提升至 105 种。
模型效果
模型几次的迭代过程与迭代结果如下，模型测试集的准确度达到了 83%。
| icon 数量 | 模型准确率 | |
|---|---|---|
| 8月第1次迭代 | 14,912 | 80.152% |
| 11月第5次迭代 | 17,540 | 83.035% |
运用在线上的识别效果（包括绑定类名的准确度）也有一定的提升：
未来展望
这套系统的核心思想是通过不断补充并确保数据的可靠性，来不断优化模型。数据链路是整个 icon 识别模型闭环链路的核心。但是，icon 识别的整个流程并不是只有数据层可以优化：使用更加智能的方式筛洗数据，挑选更合适的模型进行训练预测，这两个维度也非常值得后续继续深入研究。
