第十四期： 拥有7000多万店铺和10多亿件商品的微店如何打造AI系统？

AI技术对于电商至关重要，但AI的实践门槛很高，对于创业公司尤其如此。那么电商创业公司如何打造AI系统?如何利用AI解决实际问题?

作者：夏剑

 AI技术对于电商至关重要，但AI的实践门槛很高，对于创业公司尤其如此。那么电商创业公司如何打造AI系统?如何利用AI解决实际问题?

2018 年 11 月 30 日-12 月 1 日，由 51CTO 主办的 WOT 全球人工智能技术峰会在北京粤财 JW 万豪酒店隆重举行。

本次峰会以人工智能为主题，微店AI的负责人夏剑在行业赋能专场与来宾分享《微店AI实践》的主题演讲。

作者将从如下三个方面和大家分享微店在AI方面的一些实践：

• 微店是谁
• 微店AI环境
• 微店AI的探索案例

微店是谁

与其他众多电商平台不同，微店旨在给消费者带来多式多样的，既好玩又好吃且好用的各类商品。

因此，我们的定位是打造出拥有回头客的私藏好店，而且卖家完全能够通过手机在我们的平台上开设各种微店。

目前，微店平台上有着七千多万个店铺和十多亿件商品。一直以来，我们通过“网络×平台”的商业模式驱动着公司的成长。

此处“网络”是指利用微信网络来实现用户的增长;而“平台”是指我们通过会员俱乐部的平台，来实现营收。

微店AI环境

当前，微店的简单AI环境如上图所示。我们下面来看看它的具体层次：

• 最下方是日志收集(VLOG)、数据库同步(VTS/VSS)、以及外网爬虫(Spider)，这些中间件为我们提供了各式各样的数据来源。
• 中间层是消息队列(Kafka)和微店消息队列(VdianMQ)，它们提供实时的数据。相对应地，离线数据则可以被同步到HDFS里。
• 再上一层是数据开发平台和算法平台。其中，数据开发平台主要是服务于数仓和BI，而算法平台则主要是通过提供各种算法，去开发各种实时的、或离线的算法任务。
• 在近线或实时的环境中，我们主要用到了Spark Streaming、Storm、Flink和Python。当然，我们最近正计划着将Storm的相关内容全部迁到Flink上。在离线计算中，我们用到了可供数仓和BI使用的Hive、Impala之类的查询引擎，以及可供Spark任务运行的集群。目前，我们的Spark任务大部分是由Scala编写，当然也有一些传统的MapReduce任务。
• 最上层是数据中台。其中：GDS是微店的统一存储系统，它封装了开源的Key-Valuepair存储、HBase、以及Redis(内存缓存)。ES提供了数据服务。考虑到需要为部门提供VIO报表服务，因此我们让LIGO简单地封装了Impala查询引擎，以实现离线或近线的数据查询。

微店AI探索案例

我们在微店AI方面做了许多探索工作，如上图所示，大致分为如下几个领域：

• 业务侧。包括：对用户意图的理解，相关性建模，在推荐里的猜你喜欢，点击率、转化率的预估，以及广告优化之类的有关创意的概念。
• 图像大类。包括：为内容、推荐、搜索和排序等方面提供服务的，风险控制、图像搜索、以及语意标签的提取能力。另外，还涉及到了图片质量分和文字识别的能力。
• 用户画像。包括：分析用户的偏好，人群属性的挖掘，基于位置的服务(LBS，即获取用户手机的位置信息)，基于用户的商品画像，以及用户的生命周期管理。
• 数据挖掘。包括：类目预测，结构化数据，以及SPU(Standard Product Unit，标准产品单位)的建设。
• 自然语言处理(NLP)。包括：分词、实体识别、文本分类、以及词向量模型等。

下面让我通过几个简单的案例，来给大家介绍一下微店在AI方面的探索。

图像流式计算

针对图像的流式计算，我们经历了一系列的迭代过程。

• 在最初阶段，我们通过采用各种深度学习的框架，利用Python和C++语言，仅在单机的GPU上运行了一些图像的相关计算。
• 接着我们改进为在GPU上，利用Hadoop集群，批量进行计算。
• 而在经过进一步研究之后，我们升级成为基于两个大数据组件的近实时计算方案，即：通过Kafka将各个任务串联起来，同时将结果或是图片存放在Hbase里。具体过程是：在收到图片处理请求后，我们会在Hbase中进行各种比对、或是进行简单的URL与Hash去重。一旦认定需要处理，则会下载图片，并将图片加入Kafka的队列之中，进而由算法模型做出预测。当然，这实际上是一个多阶段反复的过程，前一步的结果在被加入某一个Kafka队列，并被消退之后，会经由计算，再被加入另一个Kafka队列进行相似的过程，最终系统会把计算的结果存储到Hbase中。可见，这是一个较为实用的架构。

在如今的移动电商时代，图片呈现的效果对于消费者的购物决策影响巨大。同时，我们对于图片本身性质的管控也非常严格，不可出现任何违禁内容。因此，我们在此方面进行了如下探索。

图片质量分

如前所述，我们支持卖家通过手机来开设微店。这样在降低了开店门槛的同时，方便了用户通过随便拍摄照片并上传的方式，创建某个商品。

不过，由此也带来了如下方面的挑战：

• 照片数据量庞大。我们的系统中已有十几亿件商品，而且每天都在以几百万、乃至上千万的数量级增长。
• 图片质量参差不齐。由于手机拍照的限制，各种照片的质量远不及淘宝、京东之类的强运营电商平台。

因此，鉴于上述较强的主观因素，我们很难手工设计出图片的质量特征。因此，我们参考了业界的普遍做法：让众人打分，取平均值。

传统的Ranking SVM算法，主要被用于对搜索的结果进行排序，进而排定文本的优劣程度。因此，我们将该思路借鉴到了自己的模型侧，进而判断两个图片在质量上的优劣。

我们的设计方案是：在前端先使用一个连体卷积网络(Siamese CNN)，来训练出高度抽象的特征，然后将该特征“喂给(feed)”Ranking SVM，进而得到打分。

此处的连体CNN由参数相同的两路构成，它会将照片的优劣问题变成0/1的分类问题。

就效果而言，此处列举的是各种公共基准数据集在LIVE In the Wild Image Quality Challenge Database上的表现结果。可见，我们WeidianIQA的评分最高。

当然，此处LIVE In the Wild的数据集只有上千的量级规模。最近，Google针对几十万的数据提出了新的用来解决分类的方法。我们也在持续关注和研究着。

另一方面，在流式计算中，特别是违禁品图片中，存在着正负样本极度不平衡，以及效费比不佳的情况。

因此，为了兼顾高准确率和高召回，我们在算法模型侧采用了级联式的模型组合。具体方案是：

• 首先，我们让所有的图片经过一个轻量级的粗筛模型，由它筛查出几乎所有的违禁图片，或者是那些我们需要寻找的特征。当然，粗筛模型的准确率会比较低。
• 然后，我们将前面的结果“喂给”后面的高精度模型，以保证准确率。

值得一提的是，为了保障效费比，上述模型应当是轻量级的。如果“重”的话，就只可能作用到10%左右的图片上了。

商品类目预测

对于服务于PC端的综合性电商平台来说，商品的类目预测是结构化信息的基础，因此是非常重要和关键的。

这些类目在结构层次上各不相同，如服饰类商品可能会有五至六层的子类目，而手机类商品的SKU则会非常有限。因此，这就直接导致了商品数量分布严重不均衡。

同理，对于我们移动端的微店来说，也会出现商品标题杂乱无章的现象。

针对上述情况，我们先后进行了三次算法上的迭代：

• 版本一：规则+朴素贝叶斯统计
• 版本二：采用了传统的机器学习模型，即，最大熵模型
• 版本三：BiLSTM-Attention模型，是我们当前的版本

上图也表示了三个版本的准确率。在此，我们参照的是在100%召回的情况下所达到的效果。如今，深度学习在自然语言处理方面得到了突飞猛进的进展，我们正在研究BERT模型，希望能进一步提高准确率。

上图便是我们有关预测的流程图，这是传统的SVM模型。系统首先判断输入是否为图书。如果不是图书则进入一级类目分类器，就是上面提到的BiLSTM-Attention模型。

虽然我们手头已经有了一千万个训练语料，但是这远远不够，因此我们使用了一些乱排、以及随机丢弃的方法，来进一步增加训练语料。

在完成了一级类目的判定之后，我们目前仍使用传统的分类器--最大熵模型，来判定相对应的叶子类目。

除了上述在类目预测方面的尝试之外，我们也引入了Tensorflow。通过对其上层的API进行简单包装，我们的深度学习框架能够有效地支持算法工程师，去实现他们新的算法，并进行快速的迭代。另外，此处也涉及到了查询的扩展、以及各种预估。

用户画像

为了更加准确地提取用户特征并给出用户画像，我们在各种维度对卖家和买家进行了信息分类。除了用户属性的基本和静态特征之外，此处还涉及到了：

• 用户生命周期的管理
• 人群偏好属性(例如：是否追星族、是否喜爱潮牌、是否吃货)
• 地理位置(例如：常用地址、行政区划、农村/城市)
• 购物属性(例如：购买周期、是否海外购)
• 社交关系
• 社会身份等方面

我们希望通过网络，特别是微信，来实现用户的增长，进而了解他们的社交圈子等特征信息。

相较于前面的AI环境架构，上图所展示的用户画像的架构则较为简单，我们使用Scala开发了相关代码。

其具体层次如下：

• 计算层。在离线方面，我们主要写了一些Spark的任务;而在实时方面，我们则写了一些Flink的任务;当然我们也用到了GraphX和MLlib。为了保证实时与离线任务的逻辑尽量简单且易于维护，我们采用Scala编写了一个通用库，以实现离线和实时的统一。
• 存储层。我们使用了GDS作为微店的统一存储系统，它既可以使用ES来对外提供服务，又可以“落”到持久化的存储里，并放到Hive表中以供运营或BI侧使用。
• 查询中间层。主要是用来封装查询的需求。

上图展示的是部分计算的逻辑。为了统一用户的基本属性信息及其行为偏好，我们通过一次性解析，来得到用户标识的映射。

值得注意的是：不同于那些带有用户相关信息的单独App，对于从微信环境登录过来的用户而言，我们只能拿到静默登录的ID;而对于浏览类型的用户来说，他们的信息甚至都是匿名的。因此我们需要考虑做好标识性的设计，对各种登陆状态的切换行为予以映射。

另一方面，比上述类目预测简单的是预测用户的商品。我们会通过计算他们的浏览、点击、加入购物车、以及购买等训练数据，以得出他们的商品偏好模型，进而去预测他们的购买行为。

算法数据层统一

如今业界有一个趋势：统一本公司包括推荐框架、搜索框架、广告框架在内的所有框架，以通用并支持不同的业务场景。

如上图所示，各种请求在进入排序模块之后，RankPlugin服务器会识别不同的业务逻辑，进而区分出不同的推荐、搜索、以及广告需求。

相对应地，我们也配备有统一的算法数据层，并由GPS实现了统一的数据存储。可见，对于那些人手不够的创业公司来说，统一的架构能够方便系统快速地进行迭代。

无论是在召回层、排序层、还是策略层，一旦算法工程师有了新的想法，他们就能够通过统一的结果去实现AB测试，并迅速得到线上的效果。

阅读目录（置顶)(长期更新计算机领域知识）

阅读目录（置顶)(长期更新计算机领域知识）

阅读目录（置顶)(长期科技领域知识）

歌谣带你看java面试题