【51CTO.com原創稿件】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測試，并迅速得到線上的效果。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】