AI技術對於電商至關重要，但AI的實踐門檻很高，對於創業公司尤其如此。那麼電商創業公司如何打造AI系統?如何利用AI解決實際問題?
AI技術對於電商至關重要，但AI的實踐門檻很高，對於創業公司尤其如此。那麼電商創業公司如何打造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測試，並迅速得到線上的效果。
閱讀更多 中國雲計算 的文章
