文 / 卡狸

背景

以人工智能为代表的前沿技术正在推动传统产业的升级，并为社会创造出巨大的经济效益。文本将从 imgcook 对前端领域中“字段绑定”这个命题的解决方案着手，讲述我们对于 Ai 产品服务的理解。

现代前端工作核心工作之一是将数据库接口字段和视图关联起来，我们一般使用简洁的模板语法来声明式地将数据渲染进 DOM 或某些跨端框架里，比如 VUE 官方的例子。

<div id="app">
  {{ message }}
</div>

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

视图部分和 vm 中的 message 字段关联到了一起，所以最后呈现在页面里时元素会因 data 的不同而发生变化。

因为模板语法的诞生，web 才从静态网页升级到动态网页时代，这种网页编程技术，使得页面显示的内容可以随着时间、环境或者数据库操作的结果而发生改变。值得注意的是，动态网页并不意味着动效，无论是 vue、 react ，还是 php、asp、jsp ，只要基于数据库，使用了动态技术，就是动态网页。

越是稳定的业务域，其常见的业务逻辑越是固定。相信不少业务形态稳定的前端开发日常工作时都会和我们面临同样的问题：某个模块，内部图文和原来基本一致，只因为部分样式或布局的变化就要做一个新模块。

为此，我们的解决方案是 imgcook，基于 imgcook 通用化视觉还原能力和业务域定制的逻辑推测能力，做新模块的极速生成。

imgcook 能力

上图的 Logic 部分目前可以统一解决业务域独有的问题，比如样式规范、埋点规范、搭建系统逻辑等。

除此之外，文初提及的数据绑定推测也是我们 Logic 层解决的重要问题之一，因为稳定的业务下的数据模型也必然是稳定的。比如淘系业务下的数据模型最后都会趋同于商品、店铺、优惠券等常见电商实体模型。为此我们去年做了一套字段绑定推测方案，有兴趣的同学可以移步这里。掘金地址点此，知乎地址点此。

样本准备

我们调研了淘系业务所需绑定的字段，希望使用机器学习能准确分辨出各个需要绑定的内容类别。这些分类样本在容易获得的前提下还需要保证特征足够明显，从而保障最终算法模型的准确率。

文字样本产出思路

我们分析大量的设计稿文字特征，发现设计师有设计稿意图和真实意图两种文字表述形态，比如一个商品标题，可能写的是“产品名称八个字”这种抽象文字，可能写“海蓝之谜睡眠面膜”这种真实文字。前一种文字句式是可枚举的，我们提供了规则识别的方式来解决。后一种真实型文字则需要我们人为的从数据库中获取，这种数据类别不够多，仅能覆盖常见的几种设计稿文字，加以获取数据和制定分类的过程都需要人为操作，我们开始思考是否有更理想的自动分析字段的方法。

ODPS 数据库字段

灵感来源于我们对日常业务开发价值的思索，在探究日常业务价值过程中，敏锐的觉察到了前后端通信所传输的数据天然就是一个高度结构化的样本。以 web 前端和后端通信举例，通信的核心内容是一串 JSON 字符，其中用 JavaScript 的对象和数据约束了结构，其他的基本数据类型作为叶子挂载在结构之上。表是一个天然的数据实体，现代互联网的数据最后都会归结到数据库 DB 里的一张张表上。在我们的业务里，商品、店铺、品牌、内容，都可以溯源到这些实体上，很多后端业务代码做的就是将这些实体结构排列的胶水黏合的事，我们业务后端也不例外。

我们在前后端通信的研发代理插件里做了 hook，每一次前后端数据通信都会被抓取分析。分析过程很简单，舍弃了 json 中因胶水层业务代码而形成的复杂结构，只分析字段和其所属对象数组的关系，期望直接分析出形如 “数据表”和“表中字段”这种直白的关系。

“数据表 itemList”内的字段

事实证明，尽管从 DB 到前端的 http 请求经过了无数系统和业务代码，但是依然遵循着 “实体”与“实体属性”的明显从属关系。上图里，我们拿到了结构中所有属于 itemList 的字段，字段名和内容之间有明显的关联关系，比如 itemList[].shopName 对应的真实字段是各种旗舰店、itemList[].itemTitle 则是商品标题。我们还原出这个实体，认为在我们业务域下 itemList 应该长这样。（“[]”意思为数组对象，“{}”意为普通对象）

interface Item {
  type?: string,
  itemDesc?: string,
  itemUrl?: string,
  itemImage?: string,
  itemTitle?: string,
  shopName?: string,
  itemSubTitle?: string,
}
 
let itemList: Array<Item> = [
  {
    type: '8',
    itemDesc: 'Nike',
    itemUrl: '//pages.tmail.com/..............',
    itemImage: '//img.alicdn.com/.............',
    itemTitle: '现代简约胡桃木实木床',
    shopName: 'ONLY 官方旗舰店',
    itemSubTitle: '流行元素|圆领设计衬托温婉气质'
  }
]

熟悉香农信息论的同学知道，信息论基础理念之一就是剥除“信息的意义”，也就是说 “title” 本身只是一个无意义单词，是一个指代，只有当他位于不同的实体中才会有不同的意义。

“字段 title”在不同的“实体”内意义不同

可以看到，item[] 内的 title 是一个商品的标题，而互动（interaction）下的 title 则是店铺关注信息。实体 + 字段的划分方式下，最终字段有明显的类别特征。基于内嵌于研发流程的字段分析方案，我们不用依赖数据库就可以做到字段样本的收集，甚至可以实现前端业务的局部自定义。

图片样本产出思路

涉及到图片分类时，上述样本获取方式又不适合了。

图片特征不离散，比起文字更复杂，分析起来也更耗时。我们从目的出发，将图片划分成业务标、icon、头像、店铺标、场景图、白底图、氛围图、高斯模糊背景等特征明显的几个分类。

图像按功能进行分类

不同类别图片样本收集方式不一样，场景图白底图等动态图片可从数据库中获取，氛围高斯模糊图等使用 canvas 绘制制造。

以氛围图为例，参考设计师背景图设计规范，底色采用一个具有光感的微渐变，在此之上叠加一个纹理，再补上基础的几何图形，通过透明度和位置的变化进行叠加。几何图片支持常见的矩形、圆、三角、菱形等基础图形，随机透明度、大小与位置到比较理想的参数即可。

氛围图自动产出策略

模型训练

文本模型选择

我们文本单个分类的样本不多，且相同分类的文本中一些关键字频繁出现，对此我们选择分词算法 + 朴素贝叶斯作为分类模型。该模型核心为如下公式：

朴素贝叶斯

有基础的概率论知识就看得懂这个公式，翻译成大白话意思就是，如果 A 分类中 B 特征出现的概率很大，那么我们遇到一个未知分类，完全可以根据 B 特征出现概率来推算他是不是 A。至于分词，就是把文本切分为一个个单词，这些单词就是各文本分类的特征依据。

文本分类算法流程

图片模型选择

回到图片分类问题上，看起来图片比文本难下手，其实不然。现在业界机器学习发展最迅速的方向就是 cv ，业界也有很多基于 ImageNet 等数据集进行大量训练得到的模型，比如 VGG、ResNet 等。所以我们决定从现在已成体系的图片神经网络中借用模型预训练，这样可以大大节省训练成本。

正巧我们当时受限于计算资源，需要选择一种训练方式来尽可能适应数据量少和计算资源少的问题，所以一拍即合，决定基于 mobileNet 基础上进行迁移学习，基本步骤如下：

图片分类算法流程

虽然本文描述顺序上先收集样本再调研模型，但我们实际工作时其实模型选择在先，样本制造在后。因为算法工作最重要的其实还是样本准备，这个工作从前至后贯穿整个工作周期并最终决定模型质量。而模型的选择需要视情况而定，随时根据效果和策略的好坏进行变更。所以流程倒置倒无伤大雅，能解决问题即可。

算法通用解题思路

Ai 产品服务

现在，我们拥有了两个可以根据我们业务文字内容和图片内容进行分类的模型，当我们设计稿还原时识别了可以被模型识别出的分类就为其做自动字段绑定，比如我们设计稿中有“海蓝之谜XXX”，那么还原之后，我们看到 “海蓝之谜XXX”的 innerText 属性就自动绑定上了 item.itemTitle。

imgcook 自然不会止步于此，我们在探索过程中，运用智能化思维，总结出了如下几个 Ai 产品特点，以此为指导思想完善了我们的平台能力，使其从一个研发工具型产品升级为一个研发平台产品。

平台能力泛化

算法模型需要有一定的泛化能力，同理，Ai 服务平台也需要有泛化能力。

我们思考如何将这种“智能绑定”的能力开放出去造福其他业务团队，让每个团队使用我们的平台都可以构建一套自己体系下的预测服务，实现平台级别的能力泛化。

imgcook 通用服务与定制服务

产品链路中和业务特性无关的部分下沉为通用服务，那些需要基于业务定制的部分则完全开放。

这样，每个业务下都有自己的业务样本集，并准确的将算法分类结果映射到对应业务配置好的字段上。基于这种思考，我们在字段绑定服务的基础上实现了规模更大的“业务逻辑库”，不仅是字段绑定能力，还可以定制业务规则、设计稿规则、搭建系统规则。基于核心的几个通用服务，比如组件识别模型、布局识别、函数虚拟执行引擎，每个业务都能定制自己的“逻辑框架”。

渐进增强

我们需要认识到，任何一个 Ai 算法目前都没有百分百准确率，imgcook 作为淘系内部业务研发平台，产出的代码会直接发布上线，所以对准确率的要求必须是 100%。所以在我们 imgcook 平台建造的过程中，渐进增强的思想尤为重要。

从终局上看，imgcook 是不应有可视化编辑器的，我们希望用 Ai 技术解决全部业务问题。但是从真实的平台研发历程来看，我们还是构建了一个“可视化干预平台”，再对这个可视化平台的操作抽象化，进行 Ai 算法能力赋能。可视化干预平台用来辅助解决 Ai 现阶段无法做到的事，比如本文所提及的字段绑定能力的手动操作方式。

字段绑定实际效果分析

基于模型识别的智能绑定预测准确率远不及前端手写的代码。实际应用中准确度如此之低，也因为我们低估了这件事的难易程度。且不论预测是否准确，就是正确的情况下表达式复杂程度也是我们始料未及的。下面列出一些例子作为上图的补充，看下所谓的“已经收敛的闭域”下的字段绑定问题还有多少复杂度：

// 支持的比较好的例子：
content.userNick // “某达人”的字段绑定：
data.contents // 节点循环的字段绑定：
item.iconImg // 图片链接的字段绑定：
'¥' + item.itemActPrice // “¥588”的字段绑定：

// 支持的比较好的例子：
6期：item.interestFreePeriod+'期' // “6期”的字段绑定
data.contents && data.contents.length > 0 // 容器展示与否的字段绑定：
!(data.$attr && data.$attr.isFenqi) ? '6px' : '0px' // 图片上外边距的字段绑定：
item.bookedNum && item.bookedNum > 50 ? '已定' + item.bookedNum + '件' : '火爆预定中' // “已定1000件”的字段绑定：

支持好的都是可以通过模型识别出来的简单绑定，涉及表达式和业务逻辑的立马被爆的体无完肤。那么这部分逻辑是否可以找寻规律，用非算法方式解决呢？

自我迭代

机器学习本质是一种自动拟合的高级版数据分析，因为引入了自我分析、自我迭代的机制，所以可以利用规律对未知数据进行预测。在反思平台自我迭代机制的过程中，我们发现了前文问题的求解方式。

和开篇文字样本产出思路一样，我们对用户手动执行的数据绑定信息进行了收集分析。经由 imgcook 可视化干预平台，我们收集了用户发布上线的正式模块，去除测试模块和低质量模块得到了样本模块，经过对样本模块结构进行分析得到用户一条条的“字段映射结构样本”，基于这些结构样本，我们建立了一个样本映射规则集合并最终反哺到智能化识别的链路里。当然，这个过程是无需人工干预的，每日凌晨准时启动全量模块的分析。理想情况下，用户 imgcook 用的越多，我们基于用户编写习惯就会学得越多的规则，字段推测效果就越好。

imgcook 自我迭代方案

基于上述自迭代方案，我们还衍生出了很多额外功能，比如“推断一个文字是否无需绑定”：我们分析字段绑定时会顺带打标，未关联数据的文字会打上“静态”标记，否则就是“动态”标记，则某文字无需绑定的概率就是其出现次数中被标为“静态”次数的比率。

字段静态化推测例子

结语

D2C 总结出的 Ai 产品特点

总的来说，我们认为一款优秀的 Ai 产品服务会和机器学习这个技术本身一样，学会自我迭代、渐进增强和定制泛化。如果说机器和数据进行自主互动，在互动的过程中用长远的收益来指导当下的决策，并不断调整决策至最优。那么 Ai 产品服务就应该是和用户进行自主互动，学习用户的输入，指导自己的沟通策略。从这一点来看，imgcook 希望和市面上的哪些可教学的 Ai 语音机器人一样，越用越灵活。

从一年前的关于字段绑定的一个设想开始到如今的 Ai 服务思路初见端倪，其中探索历程大致如此。我们有理由相信，随着人工智能的快速应用及普及，深度学习及强化学习等算法不断优化，人工智能将会从更多应用场景中得到价值的最大化、甚至催生出新业态、新模式，甚至是给传统领域带来创新和发展。若对我们平台有想法，希望一起来构建一个智能会学习的，帮前端解决问题的 Ai 平台可以加我微信 Ahkari-ifly 一起交流~

从字段预测看“Ai 产品服务”

背景