電気の供給業者のためのAI技術が不可欠ですが、AIは、特に新興企業のために、練習の非常に高い閾値です。だから、AIシステムを構築する方法を電気サプライヤーベンチャー？どのように現実的な問題を解決するためのAIを使用するには？
著者：夏の剣
電気の供給業者のためのAI技術が不可欠ですが、AIは、特に新興企業のために、練習の非常に高い閾値です。だから、AIシステムを構築する方法を電気サプライヤーベンチャー？どのように現実的な問題を解決するためのAIを使用するには？
2018年11月30日 - 2009年12月1日、51CTO WOT世界的な人工知能技術サミット主催のは、広東省財政JWマリオットホテル北京で開催されました。
人工知能をテーマとしたサミットは、業界におけるマイクロフー剣ショップAI夏の頭部は、ゲストとのトピックに関する特別な「マイクロストアAIの実践」を共有することができます。
以下の三つの側面であなたとAIにおけるマイクロ店のいくつかの実用的な側面を共有します：
- マイクロショップは誰です
- AIマイクロショップ環境
- マイクロショップAIの場合を探索
マイクロショップは誰です
そして、店舗よりも若干、異なる他の多くの電子ビジネスプラットフォームは商品のすべての種類を使用するために、消費者のスタイルの多様性を与えるために楽しさとおいしいと簡単に両方に設計されています。
したがって、我々の立場は完全に携帯電話を経由して当社のプラットフォーム上のマイクロショップの様々な提供することができリピート顧客が良いお店の所有権を持って作成することです、と売り手。
現在、これらの店舗は、マイクロショップのプラットフォーム上で70の以上の百万以上の10億の項目があります。すべてに沿って、私たちは、会社の成長を駆動する「ネットワークプラットフォーム×」のビジネスモデルを渡します。
ここで、「ネットワーク」は、加入者の増加を達成するために、マイクロチャネルネットワークの使用を意味する;および「プラットフォーム」は、収益を達成するためにクラブ会員による当社のプラットフォームを指します。
AIマイクロショップ環境
現在、図AIに示すように、シンプルなマイクロ店舗環境。ここでは、その特定のレベルを見てみましょう：
- 底部はログ収集（VLOG）、データベース同期（VTS / VSS）、および外部ネットワーク爬虫類（スパイダー）で、ミドルウェアは、データソースの多種多様を提供してくれます。
- 中間層は、リアルタイムデータを提供するメッセージキュー（カフカ）及びマイクロストアメッセージキュー（VdianMQ）、です。これに対応し、オフラインデータはHDFSに同期させることができます。
- そして、データのアルゴリズムの開発プラットフォームとプラットフォームの層。このうち、データの開発プラットフォームは、主に倉庫やBIの数にサービスを提供するために、およびアルゴリズムのプラットフォームは、リアルタイムまたはオフラインアルゴリズムのタスクの様々な開発し、主に様々なアルゴリズムの提供を通じてです。
- ニアラインまたはリアルタイム環境では、我々は主にスパークストリーミング、嵐、FLINKとPythonを使用しました。もちろん、我々はFLINKに移動し、関連するすべてのコンテンツの最近の嵐に計画しています。オフラインの計算では、我々は可能な倉庫の数を使用し、BIは、クラスタを実行するために、クエリエンジン、および利用可能なスパーク作業のようハイブ、インパラを使用しています。現在、私たちのスパークタスクのほとんどはスカラで書かれている、もちろん、いくつかの伝統的なMapReduceのタスクがあります。
- トップ層は、データテーブルです。ここで、オープンソースのキーValuepairストレージをカプセル化するGDSマイクロショップユニファイド・ストレージ・システム、HBaseの、そしてRedisの（メモリキャッシュ）。ESは、データサービスを提供します。アカウントにVIO部門に報告するためのサービスを提供する必要性を取るので、我々はLIGOは、単にデータのクエリをオフラインまたはニアラインインパラクエリエンジンをカプセル化してみましょう。
AIマイクロショップのケースを探ります
おおよそ次のエリアに分け、上記のように我々は、ショップAIマイクロ面での探鉱作業の多くを実行します。
- ビジネス側。含む：理解、関連性のモデリング、あなたが好きなユーザの意図を推測推奨、クリックスルー率、推定コンバージョン率だけでなく、広告クラスの最適化の創造的な概念。
- 画像のカテゴリ。含む：ように、リスク管理、画像検索、およびセマンティックタグを抽出する能力のサービスを提供し、勧告、検索およびソートし。また、また、それが品質のポイントと文字認識を描く能力を必要とします。
- ユーザー肖像画。彼らを含める：ユーザーの好みをマイニングの分析は、群衆は、ロケーションベースのサービス（LBS、つまり、携帯電話の利用者の位置情報を取得）、ユーザーベースの商品の肖像画だけでなく、ユーザーのライフサイクル管理を属性。
- データマイニング。彼らを含める：SPUのカテゴリ予測、構造化データ、および（標準製品ユニット、製品の標準単位）の建設を。
- 自然言語処理（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测试，并迅速得到线上的效果。