第十四期: 拥有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面试题

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

前端小歌谣

放弃很容易 但是坚持一定很酷

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值