AI technology for electricity suppliers is essential, but the AI is very high threshold of practice, especially for start-up companies. So how electricity supplier startups to build AI systems? How to use AI to solve practical problems?
Author: Summer Sword
AI technology for electricity suppliers is essential, but the AI is very high threshold of practice, especially for start-up companies. So how electricity supplier startups to build AI systems? How to use AI to solve practical problems?
November 30, 2018 - December 1, 2009, sponsored by the 51CTO WOT global Artificial Intelligence Technology Summit was held in Beijing, Guangdong Finance JW Marriott Hotel.
The summit with the theme of artificial intelligence, the head of the micro-Fu sword shop AI summer in the industry can share special "micro store AI practices" on the topic with guests.
On the following three aspects will share with you some practical aspects of micro shop in AI:
- Who is micro shop
- AI micro shop environment
- Explore the case of micro shop AI
Who is micro shop
And many other electronic business platform different, slightly more than the store is designed to give consumers a variety of style, both fun and tasty and easy to use all kinds of goods.
Therefore, our position is to create repeat customers have possession of a good shop, and sellers fully able to offer a variety of micro-shop on our platform via mobile phone.
Currently, these stores has more than seventy million and more than one billion items on the micro-shop platform. All along, we pass the "Network × platform" business model driving the company's growth.
Here "network" refers to the use of micro-channel networks to achieve subscriber growth; and "platform" refers to our platform by the club members to achieve revenue.
AI micro shop environment
Currently, a simple micro-store environment as shown in FIG AI. Here we take a look at its specific level:
- The bottom is the log collection (VLOG), database synchronization (VTS / VSS), and the external network reptiles (Spider), the middleware provides us with a wide variety of data sources.
- The intermediate layer is a message queue (Kafka) and micro store the message queue (VdianMQ), which provides real-time data. Correspondingly, the off-line data can be synchronized in the HDFS.
- Then a layer of data algorithm development platform and platform. Among them, data development platform primarily to serve the number of warehouses and BI, and algorithm platform is mainly through the provision of various algorithms, to develop a variety of real-time or off-line algorithm task.
- In the near-line or real-time environment, we mainly used the Spark Streaming, Storm, Flink and Python. Of course, we are planning to recent Storm of all relevant content moved on Flink. In the off-line calculations, we used the number of available warehouse and BI use Hive, Impala like query engine, and available Spark task to run the cluster. Currently, most of our Spark task is written by Scala, of course, there are some traditional MapReduce tasks.
- The top layer is the data table. Where: GDS micro shop unified storage systems, which encapsulates the open-source Key-Valuepair storage, HBase, and Redis (memory cache). ES provides data services. Taking into account the need to provide services to report VIO department, so we let LIGO simply encapsulates Impala query engine for data query offline or near-line.
AI explore micro-shop case
We do a lot of exploration work in the shop AI micro aspects, as shown above, roughly divided into the following areas:
- Business side. Including: understanding, relevance modeling, guess the user's intent recommended where you like, the creative concept of click-through rate, estimated conversion rate, as well as optimization of the advertising class.
- Image categories. Including: risk control, image search, and the ability to extract semantic tags provide services, recommendations, search and sort and so on. In addition, also it involves the ability to picture quality points and character recognition.
- User portrait. They include: analysis of mining the user's preferences, the crowd attributes, location-based services (LBS, that is, obtain location information of a mobile phone user), user-based commodity portraits, as well as user lifecycle management.
- Data mining. They include: category prediction, structured data, and the construction of (Standard Product Unit, a standard unit of product) of the SPU.
- Natural Language Processing (NLP). Comprising: a word, entity recognition, classification, and a vector word models.
Let me through a few simple cases to tell you about the exploration of micro shop in AI area.
Picture stream calculated
For streaming image is calculated, we experienced a series of iterative process.
- 在最初阶段，我们通过采用各种深度学习的框架，利用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测试，并迅速得到线上的效果。