在微信AI背后，技術究竟如何讓一切發(fā)生？關注微信AI公眾號，我們將為你一一道來。今天我們將放送微信AI技術專題系列 “微信掃一掃的技術與藝術”的第三篇 ——《 微信掃一掃識物——離線系統(tǒng)篇 》。

導語

2019年12月，微信掃一掃“掃物”功能上線，用戶可以通過掃一掃“識物”查看被掃商品的價格、相關資訊、相關商品等信息。

什么是識物 

識物是以圖像或視頻作為輸入，用以挖掘微信生態(tài)下商品、物品等有價值等信息。這里我們基本覆蓋了微信生態(tài)里的電商類目小程序，涵蓋上億商品SKU，聚合了微信內的搜一搜、搜狗等資訊，最終聚合后呈現(xiàn)給用戶。

工程上，識物工作主要可以分為三塊，如圖1所示：

圖1

1. 算法模型

算法側主要是對檢測模型和多類目的檢索模型等持續(xù)煉丹，檢測模型需要返回圖片中物品的準確位置；檢索模型需要保證同款物品的特征表達越近越好。

2. 離線工程

識物是典型的“離線寫，在線讀”的業(yè)務，業(yè)務數(shù)據的存儲和檢索庫的構建都是在離線環(huán)節(jié)完成。我們收錄了小程序生態(tài)下的商品圖片，下載后進行檢測摳圖，提取檢索特征，最終構建成檢索庫交付到線上環(huán)境。 這篇文章將 主要介紹這一部分的工作 。

3.在線部署

算法模型和離線生成的檢索庫最終完成部署，對外服務。用戶識物時，檢索庫會召回一批相似物品，再經過一系列復雜的精排、過濾邏輯，最終返回用戶看到的結果。

挑戰(zhàn)

1. 數(shù)據版本

數(shù)據版本主要分為兩類，一是算法模型版本，我們有10+種業(yè)務模型，平均每周有2-3個模型迭代升級。二是檢索庫版本，在模型不迭代的情況下，每天有新數(shù)據的合并，即增量迭代 ；而每次算法模型變更，特征表達發(fā)生改變，需要根據新特征重新構建檢索庫，即全量迭代。

在高頻的版本變更場景下，如何兼顧靈活性與安全性。  

2. 數(shù)據處理性能

目前我們收錄的圖片數(shù)為10億左右，平均每天新增1500w。除了圖片數(shù)量多，任務的流程也很多，如圖片下載、目標檢測、特征提取等任務，每個任務每天都是千萬級的數(shù)據處理量。

如何高效的處理數(shù)據，提升業(yè)務的迭代效率。

3. 繁雜的流程

隨著業(yè)務的發(fā)展，簡單的業(yè)務流程已經不能滿足我們日益復雜的業(yè)務需求。為了提升業(yè)務指標，我們可能還需要圖片質量，文本語義，死鏈、下架商品的過濾等任務。

如何在流程日益變多的情況下，不導致整個系統(tǒng)的臃腫。

4. 數(shù)據質量

離線工程屬于重流程的業(yè)務，數(shù)據從產生和落地將經歷九九八十一環(huán)，任何一環(huán)出錯都會導致結果有問題。發(fā)現(xiàn)問題的時間越晚，修復的成本越高，對業(yè)務的影響越難以估計。

如何科學的監(jiān)控和管理數(shù)據質量，使系統(tǒng)有良好的可維護性。

數(shù)據版本

這里有多種維度的數(shù)據版本，例如模型版本，特征版本，檢索庫版本等，上游環(huán)節(jié)的版本變更將引發(fā)后續(xù)環(huán)節(jié)的變更，最終都將導致 檢索庫版本變更 。

圖2 數(shù)據流程簡圖

2.1 檢索庫

在我們的業(yè)務場景下，檢索庫的迭代是高頻操作，正常情況下每天會增量更新，而模型的變更又會引發(fā)檢索庫全量更新。數(shù)據量級上，我們的全量圖像是億級別的，按類目分庫后每個類目也是千萬級。

我們調研了業(yè)界內主要用于圖像檢索的技術，如圖3所示。綜合考慮后，我們選取了靈活性更強、相對內存占用更小的的faiss-ivf作為我們的索引庫構建算法。

圖3 圖像檢索庫選型   

對于每天的增量數(shù)據，我們每天對每個類目(10+個類目)都會構造一個對應 當天數(shù)據檢索庫 。每個類目的全量檢索庫是由 N天的檢索庫合并生成 (faiss-ivf特性)，2000w的數(shù)據合并僅需要4分鐘?；谶@樣的設計，使得我們可以靈活的選取時間窗口的范圍，如圖3所示了窗口為2的合并方法。

這樣的好處是，如果某天數(shù)據發(fā)現(xiàn)有問題，只需要修復當天數(shù)據后再進行合并即可 ；如果需要丟棄某些數(shù)據，如舊數(shù)據，合并時不選取即可。

圖4 檢索庫生成

2.2 數(shù)據版本兼容

前面我們講到，模型變更最終都將引發(fā)檢索庫的全量迭代，這里的模型有 檢測模型和檢索特征模型 。新檢索庫上線時，本質上是新舊數(shù)據的過渡，一般實現(xiàn)新舊數(shù)據的切換都會設計復雜的系統(tǒng)來保證數(shù)據一致性。

2.2.1 檢測模型變更

這種場景下的檢索庫變更，嚴格上來講我們并沒有實現(xiàn)新舊數(shù)據的一致性，我們只是通過簡單的方法使得即使 新舊數(shù)據同時存在也不影響用戶的體驗 。

這里主要涉及到如何構建我們的映射關系，我們?yōu)槊看螜z測出的結果都賦予一個唯一的單調遞增id。替換模型后，同一張圖片的檢測結果會變化。可能摳圖的位置有變化、可能會扣取不同的物品、可能會扣取多個物品。

如圖5所示，檢索庫v1里只有上衣，對應檢索id為1；變更檢測模型后，檢索庫v2可以同時檢測出上衣和下衣，對應檢索id為2，3。這樣在線模塊可以逐步更新檢索庫，線上同時存在新舊檢索庫也沒有影響，如果請求落到舊庫返回1，落到新庫返回2，但最終都將返回正確的結果， 結果上是一致的 。

圖5 檢測模型變更

2.2.2 檢索特征模型變更

這種場景下的檢索庫變更則復雜許多，檢索庫存的特征來自于檢索特征模型。檢索模型變更后，同一個物品圖片的特征表達完全不同，維度甚至也發(fā)生了變化，如圖6所示。

我們需要同步變更 檢索特征模型服務和新檢索庫 ，通過雙buffer的方式實現(xiàn)新舊數(shù)據的共存，而且要實現(xiàn)嚴格的路由協(xié)議來保證同一個請求在 同版本 的特征檢索服務和檢索庫中完成。

圖6 檢索特征模型變更

2.3 數(shù)據版本管理系統(tǒng)

在開發(fā)過程中，算法需要交付各種模型給離線和在線，離線生成的檢索庫也需要交付給在線，數(shù)據版本的迭代也需要考慮版本的可回退性。為了解耦多方之間的依賴，且避免在同步過程中直接操作文件帶來的風險，設計了一套數(shù)據版本管理系統(tǒng)。

如圖7所示，資源發(fā)布者上傳資源到該系統(tǒng)，并附帶對應業(yè)務、版本號及md5。資源使用者只需要理解對應業(yè)務當前的版本號，版本管理系統(tǒng)會返回對應的資源文件。線上實際使用時，在線模塊會定期輪訓某業(yè)務對應數(shù)據版本文件的md5和本地文件md5是否一致，不一致則會拉取最新的文件，拉取完成后校驗md5是否一致，最終實現(xiàn)更新。

在業(yè)務模型或檢索庫需要回退時，只需修改配置文件，重啟服務即可。

圖7 數(shù)據版本管理系統(tǒng)

2.4 docker化

目標檢測、檢索特征提取等是典型的圖像深度學習任務，業(yè)界內有caffe、pytorch、tensorflow、tensorRT等多種深度學習框架，有的框架不能保證向上兼容。而我們負責煉丹的同學第一要務是追求效果指標，在嘗試各種奇淫巧技時練出來的丹通常并不能和微信的線上環(huán)境很好的兼容。

簡而言之，在重算法的工程系統(tǒng)中，不僅有業(yè)務代碼的更新，還有工程環(huán)境的迭代。這非常適合使用docker來封裝和迭代業(yè)務環(huán)境。通過docker化部署，我們可以更方便的引入更多開源組件來支撐業(yè)務，也可以讓我們在一些框架選型上更加靈活。

就我們自己的業(yè)務場景而言，我們還可以利用微信深度學習任務平臺(yard)的計算資源，這部分屬于平臺內部的公用資源，需要搶占式使用。yard也是docker化去執(zhí)行任務。這為我們業(yè)務可以借助yard公用資源作為臨時擴容worker節(jié)點做了很好的鋪墊。

分布式計算

我們每天平均有1500w增量數(shù)據，全量為十億級別的數(shù)據。單機必然無法滿足處理的實效性，唯有分布式計算才能滿足要求。

3.1 數(shù)據拆分

正如mapreduce，map階段的工作我們需要對數(shù)據進行拆分。這里對拆分原則除了平均外，還考慮了拆分后到數(shù)據的運行時間。 如果拆分太細GPU的運行效率會降低，拆分太粗會導致錯誤修復的時間成本變大 。我們讓每個拆分后的任務都盡量控制在1小時內完成，最終拆分的粒度為每個包10w左右。

3.2 數(shù)據并行計算

拆分后的數(shù)據進行并行計算相當于reduce階段，這里的重點是如何將拆分后的數(shù)據分發(fā)到多臺機進行計算。此外，我們還希望 yard 公用資源空閑時可以非常靈活的進行擴容接入，提高并發(fā)處理能力。

我們結合zookeeper的分布式鎖特性，實現(xiàn)了一套可靠分布式任務隊列。worker采用拉模式拉取隊列的任務。這樣的優(yōu)點是伸縮性好，可以靈活的增加和減少yard的機器資源。如圖8，當新worker接入后，從隊列中拉到任務直接執(zhí)行，可以實現(xiàn)秒級的擴容。

圖8 伸縮性好

對于我們的場景，任務需要被可靠消費，這里的可靠包含來兩層含義。

第一是避免任務被重復消費，我們借助zookeeper的?；铈i，鎖通過心跳保持活性。如圖9中第1，2時刻，worker拿到隊列里的任務搶鎖成功才可執(zhí)行；如果出現(xiàn)機器宕機，如圖9第3時刻，鎖會自動釋放。

第二是完整消費，我們在task被完全消費結束后才刪掉隊列里的對應task，如時刻4的task2。時刻3由于機器宕機，task1并未被完整消費，因此依舊存在，后續(xù)可被繼續(xù)消費。

圖9 可靠消費

理論上講，我們的消費模式屬于至少一次消費(at least once)，極端情況下，如果worker執(zhí)行完任務還沒有回傳狀態(tài)時宕機，那任務仍處于未成功消費，仍可能被后續(xù)worker消費。這里需要保證任務的冪等性。

引入 yard 公用計算資源提升了我們的處理能力，但同時也給我們帶來了一些小問題。例如，公用集群的機器配置比我們自己集群要好很多，為了使不同集群都能發(fā)揮最大的GPU性能，我們支持不同集群使用不同的全局參數(shù)配置。而且公用集群和文件系統(tǒng)不在同一個idc，導致網絡IO時間過長，降低了GPU利用時間，我們在公用集群的同idc實現(xiàn)了一套文件預拉取系統(tǒng)，根據任務隊列中存在的任務，提前同步待消費文件到同idc的文件緩存系統(tǒng)。

為了提高GPU利用率，我們還做了大量的工程優(yōu)化，這里就不展開敘述了?；诜植际接嬎愕目蚣?，極大提升了我們的計算效率。拿計算效率最低的目標檢測任務舉例，目前我們集群的處理能力可達到5600w圖/天，如果加上公用計算資源，可以達到1.2億圖/天 (集群12臺P4雙卡，公用集群yard-g7a集群平均10個雙卡，深度學習框架使用的tensorRT)。

任務調度

雖然我們每天有1500w左右的原始圖片，但最終符合錄入檢索庫的商品僅有一半不到。因為為了確保檢索數(shù)據的質量，我們會在多個維度做數(shù)據過濾?，F(xiàn)在我們的圖片從下載到建庫一共會經歷30+種中間任務，圖10僅展示了主要的任務流程模型。

圖10 任務流

4.1 任務系統(tǒng)

隨著任務的增多，尤其是許多任務間存在著復雜的依賴關系，每個任務都不是一個獨立的個體，每個任務的成敗都將影響最終的結果。為了更好的管理每個任務的狀態(tài)，梳理任務間的依賴，使得工程的復雜度不隨任務變多而變大，我們自研了一套任務調度系統(tǒng)。

調度系統(tǒng)主要由以下幾個部分組成：

·  文件系統(tǒng)：文件系統(tǒng)這里使用了微信自研分布式文件存儲系統(tǒng)的WFS，我們所有中間數(shù)據和結果數(shù)據都存放在這里

·  存儲系統(tǒng)：主要有任務存儲和實例存儲，與一般實例存儲不同的是，為了分布式計算，我們在數(shù)據維度和類目維度做了拆分，一個實例包含一個或多個子實例

·  調度系統(tǒng)：主要負責收集、管理任務狀態(tài)，檢查任務依賴

·  觸發(fā)器：定時輪訓調度系統(tǒng)，找到滿足執(zhí)行條件的任務實例

·  任務隊列：存儲待執(zhí)行的任務實例，由worker獲取依次消費

圖11 任務調度系統(tǒng)

容災性上，調度系統(tǒng)相關的模塊均是多機多園區(qū)部署，只要不是某個模塊完全掛掉，整套任務調度都可以正常執(zhí)行。

4.2 在線服務合并部署

對于每天的例行任務，實效性并不敏感，早幾個小時或晚幾個小時對業(yè)務影響不大。但GPU資源是是十分寶貴的，我們將部分GPU機器和在線GPU服務合并部署。結合在線流量屏蔽策略，實現(xiàn)高峰時期資源借給在線服務，低峰時期運行離線任務。

如圖12所示，其為一臺參與離線任務閑時調度的在線模塊，我們擬定每天0點-7點的低峰時間為離線運行時間，7點-24點的高峰時間為在線模塊服務時間。最大限度的利用了寶貴的機器資源。

圖12 分時調度運行

數(shù)據質量

前面做的工作保證了我們以任務為粒度的工程可靠性，但任務的成功并不能保證業(yè)務數(shù)據是完整的，如數(shù)據丟失、代碼邏輯有問題等。為了監(jiān)控數(shù)據維度上的業(yè)務質量，我們基于ELK搭建了一套數(shù)據系統(tǒng)，主要用于收集重要的基礎數(shù)據、業(yè)務數(shù)據、運行結果等。

5.1 數(shù)據可視化

我們曾在幾次版本迭代過程中，發(fā)現(xiàn)數(shù)據出錯，但發(fā)現(xiàn)時已經付出了極高的時間代價。因此我們希望在任意時刻都能觀察離線系統(tǒng)的運作是否正常，數(shù)據的流轉是否符合預期。出現(xiàn)問題后可以及時干預修正，降低錯誤成本。

我們對涉及數(shù)據流轉的核心任務都做了數(shù)據結果上報，這樣子我們可以通過數(shù)據漏斗發(fā)現(xiàn)是否出現(xiàn)問題。這個問題在 全量數(shù)據重跑的時候尤其重要 。圖13展示了項目中核心任務的數(shù)據情況。

圖13 數(shù)據漏斗可視化

上圖看上去是每天任務級的數(shù)據監(jiān)控，但實際上我們我們的設計是擴展到了 每次任務級（這里定義為planid） ，既可以是每天，也可以是每次覆蓋多天的重跑。我們按圖14的字段上報業(yè)務的運行結果，前4個字段組成聯(lián)合唯一索引，planid作為區(qū)分每次運行的邏輯字段。這樣即使同一個任務在不同時期運行結果是不同的，我們也能區(qū)分每一次運行后，真實的數(shù)據結果。這個設計在保證每次大版本數(shù)據迭代時，對于把控數(shù)據整體運行質量十分重要也十分有效。

圖14 上報字段

5.2 一致性檢查 

數(shù)據可視化方便了我們檢查問題，但是還不利于我們發(fā)現(xiàn)問題。我們還需要在數(shù)據出問題時，能及時告警、迅速修復。這最最重要的就是數(shù)據一致性，這里的一致性主要是一些核心任務的數(shù)據漏斗，輸入和輸出應該是一致的。圖15中展示了一些存在關聯(lián)的任務，帶顏色線段代表數(shù)據存在關聯(lián)性。

為了滿足各種維度的統(tǒng)計、校驗，同時又能快速支持新任務的檢查。我們封裝了核心的統(tǒng)計和校驗邏輯，配置化告警任務，確保層層流程運轉后的結果準確無誤。

圖15 一致性檢查

5.3 評測系統(tǒng)

我們在對我們的檢索庫做比較大的版本迭代，或是線上策略有比較大調整時，直接灰度上線再觀察曲線有時并不能及時發(fā)現(xiàn)問題，存在很大的隱患?；谶@種情況，我們開發(fā)了自動化測試系統(tǒng)。我們提前收集和整理了部分帶標簽的數(shù)據樣本，每次更新都需要在測試環(huán)境自動化評測一次，如圖16所示。我們在結合具體指標分析此次迭代是否可以安全上線。

圖16 評測系統(tǒng)

5.4 數(shù)據淘汰

我們平均每天流入數(shù)據超過千萬，數(shù)據膨脹的速度非?？?，這給我們帶來了極大的存儲成本和迭代成本。但回顧業(yè)務本身，其實許多商品數(shù)據在隨著時間的推進，將變成 過期、死鏈、下架 數(shù)據。最簡單的做法就是使用窗口期來維護我們的數(shù)據，窗口外的數(shù)據自動淘汰，我們在faiss檢索庫選型時也是這樣考慮的。

但是我們也想到，直接暴力的淘汰舊數(shù)據也會有個致命問題。對于我們的業(yè)務而言，什么數(shù)據對我們是重要的，常見的熱門商品固然重要，但是相對冷門長尾商品同樣重要，后者決定來商品庫長尾的多樣性。如果刪掉某個商品，檢索庫可能就沒有這個商品了，這是十分糟糕的。

因此我們在做數(shù)據淘汰的時候，需要考慮對有價值的長尾商品做保留。圖17展示了我們數(shù)據淘汰的方式，通過這種方式，我們窗口期內的數(shù)據質量將變得越來越高，全量數(shù)據的增長也相對可控。

圖17 窗口期為K的數(shù)據淘汰

總結

以上我們大致介紹了“掃一掃識物”的離線系統(tǒng)中的所涉及的一些關鍵點，部分模塊仍在持續(xù)優(yōu)化中。未來掃一掃識物將引入更多場景的識別，拓展更多維度的物品，追求“萬物皆可掃”的目標。

    相關閱讀 ：

微信掃一掃識物技術的從0到1

即掃即識，微信“掃一掃”識物為什么可以這么快？