本文由騰訊WXG應用研究員breezecheng原創發表於公衆號「騰訊技術工程」,原題「微信「掃一掃識物」 的背後技術揭祕」。php
如今市面上主流的移動端IM應用於都有「掃一掃」功能,看起來好像也就能掃一掃加好友、加羣,但實際上做爲一個IM產品的重要信息入口,「掃一掃」功能也能夠很強大。html
▲ 幾款主流IM裏的「掃一掃」功能ios
以國民應用微信爲例,微信的「掃一掃」(即掃碼功能)已經深刻人心。程序員
微信的「掃一掃識物」功能2019年12月23日已在iOS版本中正式上線,從識別特定編碼形態的圖片(二維碼/小程序碼/條形碼/掃翻譯),到精準識別天然場景中商品圖片(鞋子/箱包/美妝/服裝/家電/玩具/圖書/食品/珠寶/傢俱/其餘商品),掃碼識物以圖片(視頻)做爲媒介,聚合微信內部有價值的生態內容如電商、百科、資訊進行展現,有哪些技術難點須要去克服? 本文將詳細爲你解密微信「掃一掃識物」功能背後的技術祕密。算法
(本文同步發佈於:http://www.52im.net/thread-2887-1-1.html)spring
掃一掃識物是指以圖片或者視頻(商品圖:鞋子/箱包/美妝/服裝/家電/玩具/圖書/食品/珠寶/傢俱/其餘商品)做爲輸入媒介來挖掘微信內容生態中有價值的信息(電商+百科+資訊,如圖 1 所示),並展現給用戶。這裏咱們基本覆蓋了微信全量優質小程序電商涵蓋上億商品 SKU,能夠支持用戶貨比 N 家並直接下單購買,百科和資訊則是聚合了微信內的搜一搜、搜狗、百度等頭部媒體,向用戶展現和分享與該拍攝商品相關的資訊內容。數據庫
▲ 圖1. 掃一掃識物功能示意圖編程
百聞不如一試,歡迎你們更新 ios 新版本微信 → 掃一掃 → 識物 自行體驗,也歡迎你們經過識物界面中的反饋按鍵向咱們提交體驗反饋。圖 2 即爲掃物實拍展現。小程序
(視頻地址點此查看)微信小程序
▲ 圖 2. 掃一掃識物實拍展現
掃一掃識物的目的是開闢一個用戶直達微信內部生態內容的一個新窗口,該窗口以用戶掃圖片的形式做爲輸入,以微信生態內容中的百科、資訊、電商做爲展現頁提供給用戶。除了用戶很是熟悉的掃操做,後續咱們會進一步拓展長按識圖操做,將掃一掃識物打形成用戶更加觸手可及的運用。
掃一掃識物的落地場景以下圖所示,主要涵蓋 3 大部分:
a. 科普知識:用戶經過掃物體既能夠得到微信生態中關於該物體相關的百科、資訊等小常識或者趣聞,幫助用戶更好的瞭解該物體;
b. 購物場景:同款搜索功能支持用戶對於見到的喜好商品當即檢索到微信小程序電商中的同款商品,支持用戶掃即購;
c. 廣告場景:掃一掃識物能夠輔助公衆號文章、視頻更好的理解裏面嵌入的圖片信息,從而更好的投放匹配的廣告,提高點擊率。
對於掃一掃,你們耳熟能詳的應該是掃二維碼、掃小程序碼,掃條形碼,掃翻譯。不管是各類形態的碼仍是文本字符,均可以將其認爲是一種特定編碼形態的圖片,而識物則是識別天然場景圖片,對於掃一掃家族來講是一個質的飛躍,咱們但願從識物開始,進一步拓展掃一掃對天然場景圖片的理解能力,好比掃酒,掃車,掃植物,掃人臉等等服務,以下圖 3 所示。
▲ 圖3. 掃一掃家族
下面咱們爲你們重點介紹掃一掃識物的完整技術實現方案,圖 4 展現的是掃一掃的總體框架示意圖。
該框架主要包含 4 大部分:
1)用戶請求環節;
2)商檢離線入庫環節;
3)同款檢索+資訊百科獲取環節;
4)模型訓練部署環節。
四大環節抽取核心技術模塊能夠總結爲三個,即爲數據構建、算法研發、平臺建設,咱們將一一道來。
▲ 圖4. 掃一掃識物總體框架
數據構建:
AI 時代數據爲王,數據構建的目的就是爲了更好的服務於 AI 算法,好比對於用戶請求圖、商家入庫圖都須要進行主體檢測、類目預測、特徵提取,都須要有高質量的訓練數據來支撐檢測模型、分類模型以及檢索模型。一言以蔽之,數據決定了整個掃一掃識物性能上限。
算法研發:
算法研發是爲了充分的利用已有的數據,爲識物的每個環節如檢測、類目預測,檢索特徵提取都在精度、速度上到達最優的折中,從而實現用戶任意商品請求都能得到精準的同款召回,以及更加相關的資訊展現。算法研發的好壞決定了掃一掃識物的性能下限。
平臺建設:
不管是數據建設,算法研發,模型上線都離不開一個好的平臺支持,咱們爲掃一掃識物從數據清洗、模型訓練、部署,上線打造了一個完整的平臺。能夠說,平臺建設關乎研發效率,決定了掃一掃識物可否實現上線。
掃一掃識物數據構建分爲兩大塊,一大塊是用於模型訓練的訓練數據建設,另外一大塊則是支撐用戶任意商品檢索請求的線上檢索庫構建。
模型訓練數據庫構建 訓練數據庫主要是支援模型訓練,如同款檢索中須要的物體檢測模型,類目預測模型以及同款檢索模型等,在百科資訊搜索中則須要訓練商品標題文本分類模型,命名實體識別模型等。本篇文章咱們重點關注視覺語義這一塊的算法策略,對於百科資訊用到 NLP 算法咱們在下一篇文章中詳細闡述。3.3 章節中咱們將闡述數據構建中用到的圖片去重,檢測數據庫標註用到的半監督學習算法,以及檢索數據構建提出的半自動同款去噪+合併算法。
▲ 圖5. 訓練數據構建(視覺模塊)
在線檢索數據庫構建 在線檢索數據庫的覆蓋範圍相當重要,決定了可否支持用戶的任意商品搜索請求。咱們採用定向導入、長尾加爬、訪問重放、主動發現四種策略不斷擴展咱們的商家圖規模,目前已覆蓋 95%+常見商品。這一數字還在不斷上漲中,咱們但願後續對用戶的任意商品請求都可以精確召回同款商品。
6.一、圖片去重
不管是檢測數據庫仍是檢索數據庫,第一步都是清理掉重複圖片,這樣既能夠下降存儲壓力,也可以下降模型訓練壓力。
經常使用的圖片去重算法有以下 2 種:
1)MD5 去重,去除徹底相同的圖片;
2)哈希去重,除徹底重複圖外,還能去除在原圖上進行了些簡單加工的圖片。
如改變原圖的亮度、尺度、對比度、邊沿銳化、模糊、色度以及旋轉角度,這些圖片保留意義也不大,由於在模型訓練中採用數據加強策略能夠覆蓋到。經常使用的哈希去重主要有 aHash,dHash,pHash 等,詳細理解能夠參閱相關文章[1,2],咱們重點對比各個去重算法的速度和魯棒性,以下圖 6 所示。
▲ 圖6. 經常使用去重算法速度和魯棒性對比
對比圖 6 中的數字可知,dHash 的去重速度最快,由於只須要計算臨近像素的亮度差別,很是簡單易處理,並且對於圖片簡單的 ps 操做具備較好的容忍程度,除圖片旋轉外,諸如亮度、尺度、對比度、邊沿銳化、模糊、色度等較小改變都具備很好的抗干擾能力,有助於咱們清理更多的無效圖片。最終咱們也是採用 dHash 對咱們訓練庫進行去重操做,11 類全量爬蟲商品庫中,大概清理掉了 30%的重複圖片,累計有 300w 左右。
6.二、檢測數據庫構建
從圖 4 展現的總體框架可知,掃一掃識物的首要步驟就是主體檢測,即先定位用戶感興趣的區域,去除掉背景對後續環節的干擾。主體檢測基本是大部分以圖搜圖產品的公認首要操做,以下圖 7 所示的阿里的拍立淘,百度的拍照識圖,以及微軟的識花小程序。固然主體檢測的算法各有差別,如拍立淘採用的是物體檢測算法,百度識圖採用的是顯著性區域預測,微軟識花須要用戶配合定位。爲了解放用戶,咱們但願算法可以自動定位商品區域,考慮到顯著性區域預測很難處理多個商品出如今視野的狀況,相似拍立淘,咱們採用更加精確的物體檢測算法來定位商品位置,並選擇置信度最高的商品進行後續的商品檢索以及資訊百科展現。
▲ 圖7. 經常使用以圖搜圖產品的主體檢測操做示意圖
固然物體檢測模型離不開檢測數據庫的支撐,這裏咱們對比三種標註物體 boundbox 位置和類別的方法,即人工檢測標註,弱監督檢測標註以及半監督學習檢測標註。
人工檢測標註:經常使用的人工檢測標註工具 labelimg 以下圖所示,咱們須要標註爬蟲的商品庫中 11 類商品出現的位置以及對應的類別標籤。考慮到人工標註的時間和金錢成本都很是巨大,咱們只採用該策略標註少許的樣本,更多的採用後續的算法進行自動檢測框標註。
▲ 圖8. 經常使用人工檢測標註工具labelimg
弱監督檢測標註:該算法的核心思想是標註圖片中所含物體的類別相比標註框+類別的時間成本要低不少,如何只利用全圖類別信息來自動推斷物體的位置信息,從而完成自動檢測標註呢?學術界和工業界有大量的研究者對這一方向進行了研究和探索,主要思路都是挖掘圖片中的局部顯著性區域,用其來表徵全圖的類別語義信息,如圖 9 列舉了幾篇表明性文章。圖 9 左下角算法重點闡述下,它是業內第一篇用深度學習來作弱監督檢測的文章,實驗室師兄研發,咱們還基於該算法參加過 ImageNet14 的競賽,拿了一個小分支的冠軍。儘管願景很美好,弱監督檢測算法有個嚴重的缺陷,就是很容易擬合到局部區域,好比從大量貓的圖片中擬合到的位置是貓臉區域,而很難定位到完整的貓的位置,這對於咱們同款商品檢索來講是難於接受的,咱們須要精確召回同一款商品(細粒度檢索),全部信息量都很是重要,於是該算法基本被咱們 pass 掉了。
▲ 圖9. 經常使用弱監督檢測算法[3,4,5,6]
半監督檢測標註:相比弱監督檢測算法,半監督檢測算法更加貼近任務自己:基於少許的人工標註檢測框+檢測開源數據庫初始化檢測模型,而後用該模型去自動標註剩下的商品數據庫,並用增長的標註來從新更新檢測模型,以後迭代進行模型更新和自動標註。固然爲了控制上述環節持續正向激勵,咱們爲對置信度較低的標註樣本進行人工校訂,算法示意圖以下所示。基於該算法,咱們完成了整個商品檢測數據庫的標註,11 類全量商品庫標註了上百萬個檢測框,其中人工啓動標註只有十幾萬,其餘的基本都是基於算法自動標註,大大節省了標註的時間和金錢成本。
▲ 圖10. 半監督檢測算法流程示意圖
6.三、檢索數據庫構建
完成了圖片去重和主體檢測以後,你們一個天然的想法就是,可否直接用這批摳圖後的商品圖結合 SKU 貨號進行檢索模型的訓練,答案是否認的。
摳圖以後的商品圖還存在兩大問題:
1)同款噪聲問題,即同一個 SKU 下面存在非同款的圖片,這多是因爲用戶上傳錯誤圖片、商家展現的是局部細節圖、檢測摳圖錯誤等因素致使;
2)同款合併問題,不一樣的 SKU 可能對應的是同一個款式商品,不加以合併,會致使分類類別數目急劇膨脹,並且模型難於收斂。
所以,在訓練檢索模型以前,咱們須要完成同款去噪和同款合併兩個環節,咱們提出了基於自動聚類的同款去噪算法和基於混淆分類矩陣的同款合併算法,以下圖 11 所示。後續咱們將分別對這個算法進行解析。
▲ 圖11. 同款去噪+同款合併算法示意圖
6.3.1 同款去噪
咱們採用聚類算法來自動去除每一個商品 SKU 中存在的噪聲圖片。咱們研究了經常使用的聚類算法,以下圖 12 所示,
▲ 圖12. 經常使用聚類算法聚類效果展現及速度對比
關於這些算法的理論及實現流程,你們感興趣能夠參閱[7]。咱們在圖 13 中對上述聚類算法在常見指標上進行了對比分析,考慮到商品 SKU 聚類的特性,咱們更加關注聚類算法的抗噪聲能力,對不一樣 SKU 特徵分佈的適應性以及處理速度,綜合分析實踐後,咱們選擇了 DBSCAN 做爲咱們的聚類算法,並對其進行改造來更加適配商品的聚類去噪,咱們稱其爲層次法 DBSCAN。
▲ 圖13. 經常使用聚類算法各類指標對比
層次法 DBSCAN 主要分爲兩個環節,分別爲 step1.尋找距離最緊緻的最大類簇,以及 step2.重訪噪聲樣本, 撈回同款困難樣本,增長多樣性。下面我簡要介紹這兩個步驟。
層次法 DBSCAN 步驟 1 該步驟的目的是挑選 SKU 中距離最緊緻的最大類簇,由於 SKU 中的同款樣本相對噪聲樣本分佈更有規律,數目也通常會更多。算法示意圖以下圖 14 所示,咱們鄰域內最小樣本數目設置爲 2,將全部的核心點聯通後,假設有多個類簇,咱們選擇數目最多的類簇做爲咱們挑選的商品圖片,剩下的樣本做爲噪聲樣本。
▲ 圖14. 層次法DBSCAN步驟一過程示意圖
圖 15 展現了某個實際 SKU 的步驟一聚類效果,從中咱們能夠發現最大聚類因爲控制的閾值很嚴格,樣本分佈很單一化,而在噪聲中實際有一些誤爲噪聲的困難正樣本(用紅圈示意)。這些困難的正樣本對於提高檢索模型的魯棒性和泛化能力很是重要,於是咱們須要把噪聲中的困難正樣本撈回到左邊的最大類簇中來,即爲步驟 2 完成的事情。
▲ 圖15. 某個SKU的步驟一實際聚類效果展現圖
層次法 DBSCAN 步驟 2 爲了將噪聲樣本中的困難正樣本撈回,提高訓練樣本的豐富性,咱們須要重訪噪聲樣本,計算噪聲樣本和最大類簇的距離,並將知足閾值條件的近距離噪聲樣本從新分配給最大類簇,以下圖 16 所示。
▲ 圖16. 層次法DBSCAN步驟二過程示意圖
6.3.2 同款合併
同款合併的目的是爲了將不一樣 SKU 可是同一款式的商品進行合併,從而獲得實際有效的款式類目。咱們採用分類混淆矩陣來完整自動同款合併。基於合併前的數據咱們能夠訓練初始分類模型,並計算任意兩個 SKU 之間的混淆機率。混淆機率定義爲 p_ij=c_ij/n_i,其中 p_ij 爲第 i 類預測爲第 j 類的混淆機率,c_ij 爲模型將第 i 類預測爲第 j 類的樣本個數,n_i 爲第 i 類樣本的實際個數。某個 SKU 的混淆機率矩陣以下所示,可知,當兩個 SKU 實際爲同一個款式時,如圖 17 左中類目 1 和 3,那麼他們之間很難區分,混淆的機率就會偏大。經過設定合併同款的分數閾值,咱們可以將同款 SKU 進行合併。實際操做過程當中,咱們採用下圖右邊的迭代步驟進行,即先採用高的閾值合併置信度最高的同款,而後更新優化分類模型,並下降閾值合併更多的同款 SKU,上述步驟迭代進行,直到沒有同款 SKU 須要合併。
▲ 圖17. 左:商品SKU之間的混淆機率示意圖,右:迭代合併流程示意圖
合併完同款以後,咱們獲得的訓練檢索數據庫的規模以下圖所示,總共爲 7w+多類目,1kw+訓練樣本,相比目前主流的開源數據庫如 ImageNet(1000 類,130w+)和 OpenImage(6000 類,900w+),在類別和數目上都要更加豐富。
6.3.3 成本收益
這裏咱們對採用算法進行同款去噪+同款合併,和採用純人工清理進行對比在時間和金錢上都有巨大的收益提高,加快了整個項目的迭代速度。
兵馬未動,糧草先行,上一章節咱們已經講述瞭如何備好糧草(清洗高質量的訓練數據),那麼這一章節天然而然就是亮兵器了(高效利用現有訓練數據的算法模型)。按照掃一掃識物總體框架,咱們重點介紹視覺同款搜索涉及到的三大模塊,即爲物體檢測、類目預測和同款檢索。
7.一、物體檢測
物體檢測是掃一掃識物的第一個環節,咱們須要有效的定位用戶拍攝圖片中的商品位置,剔除掉背景對後續同款檢索的干擾。
學術界和工業界對物體檢測展開了大量的研究,以下圖 18 所示:
1)研究者從不一樣角度對檢測算法進行優化,如從速度考慮分爲 one-stage 和 two-stage 檢測;
2)從 anchor 出發分爲 anchor-based、anchor-free、guided anchors,近期 anchor 又開始崛起,在性能上匹配 two-stage,速度上匹配 one-stage;
3)還有從類別不平衡出發,不一樣尺度物體檢測等等出發。
▲ 圖18. 物體檢測經常使用深度學習算法
考慮商品檢測中,主要重視三個問題:
1)速度問題;
2)檢測標註類別不平衡;
3)物體尺度變化差別大。
綜合這三個問題,咱們選擇圖 19 中的 retinanet [8]做爲咱們的檢測器。衆所周知,retinanet 屬於 one-stage 檢測器,從原圖出發直接回歸物體的位置和類別,於是速度快,其次它採用金字塔架構,有效的適配多尺度物體檢測,最後,retinanet 提出了 focal loss 能夠有效的適應類別不平衡問題,以及樣本難易問題。後續咱們會採用 anchor-free 的策略進一步優化 retinanet 的 head 部分,進一步加速模型的檢測速度,這裏不展開介紹。
▲ 圖19. retinanet算法架構示意圖
咱們將 retinanet-resnet50fpn 和經典的單階段檢測器 yolov3,和兩階段檢測器 faster-rcnn-resnet50-fpn 進行對比,以下表格 20 所示。評測數據採用的是外包採集的 7k 張圖片,涵蓋了 11 大類,對比表格結果可知,retinanet 在速度和精度上達到了很好的折中效果。後續咱們會經過 tensorRT 進一步優化 retinanet 的前向速度,劇透下最快能夠達到 80FPS。
▲ 圖20. retinanet算法架構示意圖
7.二、類目預測
類目預測是爲了肯定檢測摳圖中物體的類別,從而方便後續用指定類目的模型進行特徵提取和同款索引。你們可能會有所疑慮,由於前面檢測器已經識別出了商品的位置和類目,爲什麼不直接用檢測器的類目,而是要從新來過一次類目預測呢?緣由以下圖 21 所示:訓練檢測器的數據有限,而用戶上傳的圖片可能千奇百怪,那麼訓練庫未出現的子類很容易形成檢測器分類錯誤,其次是類間混淆性也會帶來分類錯誤。
▲ 圖21. 直接採用檢測器的類目存在的問題
那麼該如何提高類目識別的精度呢?這裏咱們利用海量的線上檢索庫來提高類目預測的精度。即爲咱們將用戶 query 在檢索庫中進行一次檢索,查詢最近鄰的 top-20 所屬的類目,結合檢測器的預測類目,來從新加權投票獲得物體的最終類目。最終,經過檢測+檢索,咱們能極大提高類目預測的精度,將近 6 個點的提高。
7.三、同款檢索
同款檢索是掃一掃識物的靈魂。不一樣於通常的以圖搜圖,只須要找出類似的圖片便可,同款檢索屬於細粒度檢索,須要檢索出 query 的精確同款,好比華爲 watch GT2 須要搜出來的就是該款手錶,不能是其餘牌子的手錶,這就致使同款檢索的挑戰很是大。
下圖 22 列出了同款檢索的難點與挑戰:
1)類間混淆性問題,即如何區分類似款和同款;
2)同款召回問題,即同款自己存在較大差別,如何有效的檢索出同款。
考慮到這些難點,咱們提出了 9 大方向來優化咱們的同款檢索模型。下面一一解釋。
▲ 圖22. 同款檢索的難點與挑戰
7.3.1 同款檢索之分類模型
這是咱們的 baseline 模型。咱們使用的分類模型以下圖 23 左側所示。衆所周知,分類模型採用 softmax 將邏輯值映射爲類目的機率值,下圖右上角表格所示,softmax 能很好的放大邏輯值的差別,將正確類目的機率逼近 1,有利於模型快速收斂。下圖中咱們還展現了 softmax 分類模型的決策邊界,以及在 mnist-10 類目上學習獲得的特徵分佈[9,10]。
觀察可知,softmax 分類器學習到的特徵空間有 3 大特徵:
1)特徵空間呈現扇形分佈,於是用餘弦距離檢索會優於歐式距離,後面咱們會固定採用餘弦距離進行同款檢索;
2)不一樣類目分佈不均衡。事實上咱們但願同等重視各個類目,他們能均勻的分割整個特徵空間,有利於模型泛化能力;
3)邊界樣本檢索不許確,從特徵圖可知,邊界樣本距離臨近類的餘弦距離極可能小於該樣本到同類之間的距離,形成檢索錯誤。
下面,咱們重點修整分類模型的所存在的問題。
▲ 圖23. 分類模型的重要特性分析
7.3.2 同款檢索之分類模型改進 1 歸一化操做
歸一化包括兩種,對圖 23 中的分類權重 W 進行歸一化,以及對特徵 x 進行歸一化。那麼歸一化的做用是什麼呢?先來講說權重 W 的模長和特徵空間分佈不均衡的關係。有研究者[10]代表,訓練數據庫中樣本多的類目對應的 W 的模長也會越長,表徵模型越重視該類的分類正確程度,而忽視了其餘樣本數目少的類目,如圖 24 所示,MNIST 和 WebFace 兩個數據庫都驗證了上述的映射關係。而實際上咱們但願的是每一類都能被平等的重視,特徵空間中每一類可以均衡的劃分整個空間。
於是咱們須要對 W 進行歸一化,讓全部類別的權重一致,即:
▲ 圖24. 每一類的樣本數目和分類權重W的映射關係
特徵歸一化的操做相似,即爲:
回顧 softmax 分類的決策邊界:
咱們將 W 和 x 都進行歸一化,於是決策邊界只取決於角度,迫使模型訓練收斂後特徵分佈更加扇形化,有利於餘弦檢索。可是二者同時歸一化,會形成模型難於收斂,你們能夠思考一番爲什麼?參考圖 23 中的 softmax 特性,因爲權重和特徵都進行了歸一化,分類邏輯值最大爲 1,最小爲-1,一樣的三類分類學習中 gt 類目對應的 softmax 機率最大隻到 0.78,遠小於 1,致使模型仍有較大 loss,很差收斂。解決方法比價簡單,對邏輯值乘以一個尺度值 s 便可,擴大差別化,有利於模型收斂。
7.3.3 同款檢索之分類模型改進 2 角度 Margin
增長角度 Margin 的核心目的是讓 softmax 分類的扇形分佈更加有利於檢索:即爲同類更加彙集,不一樣類更加遠離。常見的 3 種增長角度 margin 的策略入下圖 25 所示:乘性 margin[10,11],加性餘弦 margin[12],加性角度 margin[13]。
▲ 圖25. 常見softmax和margin softmax對比
增長 margin 後,softmax 分類模型獲得的類內特徵更加緊湊,以下圖 26 所示。這裏多說幾句,相比乘性 margin,加性 margin 更加容易訓練,這是由於乘性 margin 將餘弦的單調區間從[0,π]縮小爲[0,π/m],梯度更新區間變小了,而加性 margin 單調區間不變,有利於模型收斂。
▲ 圖26. 常見softmax和margin softmax特徵分佈對比
7.3.4 同款檢索之分類模型改進 3 排序損失
分類模型的學習目的是類別可區分,和檢索任務仍是有必定區別,引入排序損失的目的就是顯示的去優化檢索任務,即爲歐式空間中同類樣本的距離要小於不一樣類。通常排序損失和分類損失疊加使用效果要更好,咱們設計的模型結構以下圖 27 所示:
▲ 圖27. 分類模型+排序損失模型架構
圖 27 中右邊展現的是經常使用的排序損失函數,如 contrastive loss, triplet loss, lifted structure loss 等。圖中重點展現了三元組損失函數以及優化的可視化目標,即同類距離要比不一樣類距離小於一個 margin。
7.3.5 同款檢索之分類模型及其改進後性能對比
此處咱們對分類模型和其改進版本在商品檢索任務上進行性能對比。
評測集合是咱們收集的 11 大類商品庫,其中用戶評論圖做爲查詢樣本,檢索樣本爲同款商家圖和非該款式的噪聲集合組成,能夠較好的模擬線上檢索庫。
圖 28 展現了分類模型及其改進版本在珠寶類目上的性能對比,可知:
1)增長歸一化和角度加性 margin 後,即爲 ArcFace[13],檢索性能要優於經常使用 softmax 分類模型;
2)在分類模型基礎上增長排序損失,如 Hard Triplet Loss,檢索性能優於經常使用 softmax 分類模型;
3)分類+歸一化+角度 margin+排序,如最後兩行所示,性能進一步提高,可是提高幅度不是特別大。
▲ 圖28. 分類模型及其改進版性能對比
7.3.6 同款檢索之多任務模型
爲了進一步提高檢索模型的特徵表達能力,咱們探索讓檢索特徵捕捉更加豐富的商品特性,如在款式的類別上,加上視角、品牌等商品屬性,以下圖 29 所示。
▲ 圖29. 檢索特徵嵌入多種商品屬性
爲了適應多屬性標註標註的學習,咱們設計以下圖 30 的多任務協同窗習模型。多任務協同窗習模型的好處很是明顯,能夠更好的利用屬性之間的相關性,有利於網絡的優化收斂,以及提高模型的泛化能力,這樣獲得的檢索特徵更加有利於商品同款檢索。這裏有個問題,不一樣任務權重如何設計?
固然咱們能夠手工設置每一個任務的權重,但這須要對各個任務理解較爲深刻加上大量調參獲得,另外的策略是自動獲得各個任務的權重,有許多研究者對此進行了研究,這裏咱們採用驗證集趨勢算法[14]來自動計算獲得各個任務的權重,以下圖 31 所示。該算法思想比較直接,即爲人工設置高權重用於主任務,如款式分類,其餘任務基於其優化難易程度來獲得權重,如難優化(損失波動大且絕對值高)的任務權重大,易優化的權重小。使用多任務協同窗習後,模
▲ 圖30. 多任務學習網絡來利用多屬性標註
▲ 圖31. 基於驗證集趨勢算法的多任務協同窗習模型
型的檢索性能相比單任務模型有較大的提高,以下圖 32 所示。
▲ 圖32. 多任務模型相比單任務模型檢索性能對比
7.3.7 同款檢索之注意力模型
在圖 22 中咱們講述了同款檢索的一個巨大的挑戰即爲類似款對同款檢索的混淆。爲了更好的區分同款和類似款,咱們但願更加關注一些顯著的區域,以下圖 33 中手錶的 logo,刻寫的文字,鞋子的 logo,花紋等。經常使用的注意力模型分爲三種[15],有特特徵空間注意力,特徵通道注意力,以及 2 種注意力相結合。經過實驗對比可知,增長特徵空間注意力後,模型檢索性能提高,可是增長特徵通道注意力,檢索性能反而降低,以下圖 34 所示。咱們認爲空間注意力有利於強化模型重視顯著空間區域,而特徵通道注意力可能形成了模型過擬合,性能反而有所降低。
▲ 圖33. 注意力模型
▲ 圖34. 三種注意力模型檢索性能對比
7.3.8 同款檢索之層級困難感知模型
一樣針對同款檢索的兩大難點和挑戰,即類間混淆性和類內差別性,咱們採用層級困難感知模型來充分重視這兩大難題,以下圖 35 所示的包包。儘管是同款,其類似程度可能有很大差別,如該款式包包因爲拍攝視角、遮擋等形成的變化,對於非同款的負樣本,也有很是類似的其餘款式包包,和差別比較大的其餘商品入酒類、口紅等。
▲ 圖35. 商品檢索中同款類內差別性和類間混淆性的層級分佈特性
層級困難感知模型模型[16]結構以下圖 36 所示,其排序損失按層級分佈,第一層級針對全部的正負樣本進行排序學習,第二層負責較爲困難的正負樣本對,而第三層則負責更加困難的正負樣本對,而且對於越困難的樣本對,模型網絡設計的越深。
▲ 圖36. 層級困難感知模型
層級困難感知模型經過層級設計,匹配正負樣本對的層級分佈特性,可以有效的提高模型的同款檢索性能,以下圖 37 的實驗所示。
▲ 圖37. 層級困難感知模型同款減速性能
7.3.9 同款檢索之互學習模型
衆所周知,通常競賽中你們都會融合多個模型的結果來提高精度。可是在實際的項目落地,咱們須要同時考慮部署模型的精度和速度,融合多個模型會佔用更多計算資源,下降前向速度。那麼怎麼既然融合多個模型結構的優點,又不增長計算資源呢?這就是互學習模型的核心思想,以下圖所示,互學習模型經過 KL 散度 loss 來吸取其餘模型的結構優點,部署的時候只須要部署一個模型便可,不增長計算資源。
▲ 圖38. 互學習模型
實驗中,咱們利用 resnet152 和 inceptionv4 進行互學習,實際部署採用 resnet152 進行檢索,其性能以下圖 39 所示。互學習除了增長模型訓練時間,對模型上線不增長任何負擔,可是精度可以較爲顯著的增長。
▲ 圖39. 互學習模型同款檢索精度
7.3.10 同款檢索之局部顯著性擦除
經過上述全部策略來提高模型的同款檢索性能後,咱們發現仍然存在一個問題,就是深度學習模型會過度關注圖像的紋理區域,而忽視物體的形狀。好比在行旅箱的同款檢索中,返回的是印有相同圖案的書包,錢包等,而非行旅箱。如何讓模型在關注
▲ 圖40. 經常使用CNN模型都會過度關注圖像紋理,而忽略形狀
紋理的同時,也關注下物體的形狀信息呢?咱們採用局部顯著性擦除技術來破壞原圖的紋理,迫使模型來關注物體的形狀。常見的局部顯著性擦除有 3 種,以下圖 41 所示,分別爲隨機擦除,伯努利擦除,對抗擦除。這裏咱們重點對比了前二者,對抗擦除後
▲ 圖41. 局部顯著性擦除
續有時間再補上其性能,實驗結果以下圖 42 所示,局部顯著性擦除可以極大的提高模型的同款檢索精度。
▲ 圖42. 局部顯著性擦除同款檢索性能
7.3.11 同款檢索之互 k 近鄰編碼重排序
前面咱們講述的都是優化檢索模型,這裏咱們講述的是如何進一步優化檢索模型的檢索結果,即重排序。
在重排序裏面,我我的很是欣賞互 k 近鄰算法[17],很是簡單高效。互 k 學習算法最先被提出來用於行人再檢索,以下圖 43 所示,其核心發現是,對於 query 樣本,其檢索的 top-10 樣本中,正樣本(和 query 爲同一人)換作查詢樣本時,其 k 近鄰中有原始的 query 樣本,而負樣本(和 query 非同一我的),其 k 近鄰中沒有原始 query 樣本,基於該發現,做者在馬氏距離的基礎上,增長了基於互 k 近鄰的距離度量,如圖中下方所示,基於該度量能夠有效的對原排序進行重排序,將正樣本挪前,將負樣本挪後。
▲ 圖43. 行人再識別中的互k學習算法
可是實際上,咱們沒法直接利用該算法用於商品同款檢索,緣由在於咱們的 query 是用戶評論圖,而檢索圖是商家圖,他們存在很大的差別,形成互 k 近鄰會失效,後續咱們重點是如何優化特徵度量空間,讓模型的域差別減少,而後再利用互 k 近鄰來進行重排序。
7.3.12 競品對比
最後,咱們基於用戶上傳的 7k 張圖片進行 11 類檢測準確度評測, 運行環境 NVIDIA GPU P4,來對比不一樣競品的精度差別。對比試驗可知,咱們的算法要優於京東,接近拍立淘。
正所謂磨刀不誤砍柴工,平臺建設對於咱們的數據構建,模型學習,模型部署都是相當重要。下面咱們一一介紹。
8.一、數據清理平臺
爲了加快人工校驗以及人工標註的速度,咱們開發了一系列工具來輔助標註和檢驗模型精度,這裏不作過多解釋。
8.二、模型訓練平臺
這幾年,機器學習平臺發展迅猛,不少公司擁有本身的深度學習平臺,咱們人少錢少,主要是基於開源的深度學習平臺來開發符合商品同款檢索的特有平臺。咱們主要是開發了 caffe 和 pytorch 兩套同款檢索平臺,後續重點介紹。
▲ 圖44. 機器學習平臺發展史[18]
8.2.1 caffe
咱們開發的第一個模型訓練平臺是 caffe。caffe 平臺的核心架構以下圖 45 所示,caffe 平臺如今主要是工業界用的多,如今學術界用的少些。
咱們開發的 caffe 同款檢索平臺,具備以下特色:
1)支持豐富的數據增廣策略;
2)支持多類型數據加載;
3)支持蒸餾學習/互學習算法;
4)支持困難感知模型算法;
5)支持排序模型算法;
6)支持 batchsize 擴充。
caffe 的優缺點很是明顯,其優勢有:
1)訓練快,結果穩定;
2)基於 prototxt 快速試驗各類多模型/多標籤/多數據源任意組合。
其缺點有:
1)新算法開發慢;
2)調試不靈活;
3)顯存優化很差;
4)學術前沿方法更新少。
第 4 個缺點是較爲致命的,咱們沒法快速跟進學術前言,於是咱們後續決定開發 pytorch 檢索平臺。
▲ 圖45. caffe平臺核心架構
8.2.2 pytorch
咱們開發的 pytorch 檢索架構以下圖 46 所示,基本支持 caffe 檢索平臺的全部特色:
1)支持豐富的數據增廣策略;
2)支持多類型數據加載;
3)支持蒸餾學習/互學習算法;
4)支持排序模型算法;
5)支持更多主流網絡 EfficientNet;
6)支持數據去噪/合併同款/檢索;
7)支持混合精度訓練。
pytorch 優缺點也很是明顯,其優勢:
1)自動求導,算法開發效率高;
2)動態圖,Python 編程,簡單易用;
3)Tensorboard 可視化方便;
4)Github 資源多,緊跟前沿;
5)Pytorch1.3 支持移動端部署。
固然 pytorch 也不是天衣無縫的,相比 caffe 有其缺點:
在多任務自由組合不如 caffeprototxt 方便。
▲ 圖46. pytorch同款檢索平臺構建
8.2.3 模型部署平臺
模型訓練咱們能夠不在意模型運行時間代價,可是在模型部署時候咱們得要充分重視模型的資源佔用狀況,儘可能提高模型的併發能力,如 GPU 部署時候優化顯存,適配硬件,加快速度。這裏咱們重點介紹後臺 GPU 部署使用的 tensorRT 和手機端部署使用的 ncnn。
▲ 圖47.模型訓練到部署
8.2.3.1)模型部署平臺:tensorRT
tensorRT 是英偉達開發的部署平臺,可以有效的下降模型顯存,加速模型前向速度。這裏咱們不展開細節,你們能夠關注下面的檢測模型和檢索模型,經過 tensorRT 量化加速後,顯存和速度都有了巨大的飛躍。
▲ 圖48.tensorRT部署加速
8.2.3.2)模型部署平臺:ncnn
移動端部署,咱們用騰訊本身開發的 ncnn 架構,其優勢以下圖 49 左圖所示,demo 如右圖所示。
▲ 圖49.手機移動端ncnn部署
8.三、任務調度系統平臺
任務調動平臺由咱們的後臺大神們開發,主要用於各個任務的有效調用,考慮到咱們的檢索庫是上億的數據庫,須要保證平臺具備較好的容錯、容災,以及魯棒機制。以下圖 50 所示,固然這裏展現的只是冰山一角,後面等後臺大神們在 KM 裏給你們詳細解釋。
▲ 圖50. 億級檢索任務調度平臺
最後,咱們對咱們的掃一掃識物進行將來展望,仍是那句話,咱們期待掃一掃識物成爲你們的一個生活習慣:掃一掃,知你所看;掃一掃,新生活,新姿式。
▲ 圖51. 掃一掃識物將來展望
[1] 公司內部文檔
[2] https://blog.csdn.net/Notzuonotdied/article/details/95727107
[3] Learning Deep Features for Discriminative Localization,CVPR16
[4] Weakly Supervised Object Localization with Latent Category Learning, ECCV14
[5] Weakly Supervised Deep Detection Networks, arXiv16
[6] Seed, Expand and Constrain: Three Principles for Weakly-Supervised Image Segmentation, arXiv16
[7] https://scikit-learn.org/stable/modules/clustering.html
[8] Focal Loss for Dense Object Detection, arXiv18
[9] https://zhuanlan.zhihu.com/p/76391405
[10] SphereFace: Deep Hypersphere Embedding for Face Recognition,arXiv18
[11] Large-Margin Softmax Loss for Convolutional Neural Networks, arXiv17
[12] CosFace: Large Margin Cosine Loss for Deep Face Recognition, arXiv18
[13] ArcFace: Additive Angular Margin Loss for Deep Face Recognition, arXiv18
[14] A Multi-task Deep Network for Person Re-identification, MM17
[15] Concurrent Spatial and Channel ‘Squeeze & Excitation’ in Fully Convolutional Networks, arXiv18
[16] Hard-Aware Deeply Cascaded Embedding, ICCV17
[17] Re-ranking Person Re-identification with k-reciprocal Encoding, CVPR17
[18] 公司內部文檔
[1] QQ、微信團隊原創技術文章彙總:
《騰訊技術分享:騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享:騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《騰訊技術分享:Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享:iOS版微信是如何防止特殊字符致使的炸羣、APP崩潰的?》
《騰訊技術分享:Android手Q的線程死鎖監控系統技術實踐》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊團隊分享 :一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享:微信Android版小視頻編碼填過的那些坑》
《微信團隊披露:微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談:如何着手客戶端性能監控和優化》
《微信團隊原創分享:Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一):如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)》
《騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)》
《如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫:單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案:基於TLS1.3的MMTLS詳解》
《微信團隊原創分享:Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享:Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享:Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐:8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道:3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享:Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具:AndResGuard [有源碼]》
《移動端IM實踐:Android版微信如何大幅提高交互性能(一)》
《移動端IM實踐:Android版微信如何大幅提高交互性能(二)》
《移動端IM實踐:WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)》
《信鴿團隊原創:一塊兒走過 iOS10 上消息推送(APNS)的坑》
《騰訊TEG團隊原創:基於MySQL的分佈式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等》
《瞭解iOS消息推送一文就夠:史上最全iOS Push技術詳解》
《騰訊資深架構師乾貨總結:一文讀懂大型分佈式系統設計的方方面面》
《騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅做技術研究學習)》
《微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)》
《騰訊技術分享:GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享:Kotlin漸被承認,Android版微信的技術嚐鮮之旅》
《社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三):微信搖一搖紅包雨背後的技術細節》
《社交軟件紅包技術解密(四):微信紅包系統是如何應對高併發的》
《社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等》
《QQ設計團隊分享:新版 QQ 8.0 語音消息改版背後的功能設計思路》
《微信團隊分享:極致優化,iOS版微信編譯速度3倍提高的實踐總結》
《IM「掃一掃」功能很好作?看看微信「掃一掃識物」的完整技術實現》
>> 更多同類文章 ……
[2] 更多IM開發熱門技術方面的文章彙總:
《移動端IM開發者必讀(一):通俗易懂,理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結》
《現代移動端網絡短鏈接的優化手段總結:請求速度、弱網適應、安全保障》
《小白必讀:閒話HTTP短鏈接中的Session和Token》
《IM開發基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理》
《IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞》
《開源IM工程「蘑菇街TeamTalk」的現狀:一場虎頭蛇尾的開源秀》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊原創分享(一):如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(上篇)》
《騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(下篇)》
《如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的?》
《騰訊技術分享:騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享:騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》
《子彈短信光鮮的背後:網易雲信首席架構師分享億級IM平臺的技術實踐》
《IM開發基礎知識補課(五):通俗易懂,正確理解並用好MQ消息隊列》
《微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《自已開發IM有那麼難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)》
《IM開發基礎知識補課(六):數據庫用NoSQL仍是SQL?讀這篇就夠了!》
《適合新手:從零開發一個IM服務端(基於Netty,有完整源碼)》
《IM裏「附近的人」功能實現原理是什麼?如何高效率地實現它?》
《IM開發基礎知識補課(七):主流移動端帳號登陸方式的原理及設計思路》
《IM開發基礎知識補課(八):史上最通俗,完全搞懂字符亂碼問題的本質》
《IM「掃一掃」功能很好作?看看微信「掃一掃識物」的完整技術實現》
>> 更多同類文章 ……
(本文同步發佈於:http://www.52im.net/thread-2887-1-1.html)