出品 | 智東西公開課講師 | 劉思偉 織點智慧AI研究室負責人
導讀：
6月1日晚，織點智慧AI研究室負責人劉思偉在智東西公開課進行了AI零售合輯第二講的直播講解，主題為《商品識別演算法在收銀結算場景的應用與落地》。
在本次講解中，劉思偉老師首先分析AI 零售存在的業態，然後針對結算收銀場景中商品識別的難點，從商品識別落地中的模型選擇、資料挑選與標註、前端和雲端部署、模型改進等方面，進行了深入講解。
本文為此次專場主講環節的圖文整理：
正文：
大家好，我是劉思偉，來自廣州織點智慧AI研究室，負責零售場景相關的AI產品的落地。今天分享的主題為《商品識別演算法在收銀結算場景的應用與落地》，主要分以下4個部分:
1、AI 零售2、CVPOS自助收銀的應用和商品識別的難點3、商品識別演算法落地的一般方法4、商品識別演算法工程落地步驟和應用實踐
AI 零售
首先，AI 零售定義為以人工智慧為核心技術，為零售行業降本增效，增強使用者的體驗。也就是人工智慧在傳統行業裡，是為了提升它的效率、降成本、整合資源並增強體驗。但在實踐中發現，AI的能力並沒有我們期待的那麼美好，所以在落地的過程中，更需要腳踏實地的抓緊節省成本的關鍵指標。
近幾年，接觸到AI 零售的概念，大概是從16或17年的無人店開始，它確實是風靡一時，但是到後面主要是往自助結算、人臉支付、智慧營銷及門店管理的方向發展。形態變得越來越沉穩，看到大家在風口前面慢慢冷靜下來，迴歸到務實和理性，這是行業健康發展非常樂於看見的情況。為什麼無人店不能夠堅持下去，或者說現在越來越少？一個原因可能是人的誠信問題；另一個是管理、維護成本還很高，而體驗卻沒達到非常極致的效果，所以大家也不再往這個方面去考慮。
目前AI 零售會有哪些業態呢？我們總結了4大產品業態。第一是自助結算，第二是無感購物，第三是新型支付，第四是智慧營銷。
自助結算是在收銀環節節省成本，從整個零售行來考慮，結算是在所有消費行為的末端，也是最容易想到並且場景最容易控制的，所以大家都願意在這方面進行研發。自助收銀產品主要是自助結算臺，包括RFID的和視覺的，另外還有一些掃碼裝置，購物車以及冰箱等。實踐證明，這些裝置做的越簡單，越易用，節省成本的效果就越顯著。
第二是無感購物，拿了就走，這是最接近無人店的一種產品。他沒有固定的結算的流程，挑完商品之後，出門就完成自動結算。它大概經歷了兩代，第一個是RFID的模式，第二個是完全基於視覺的模式。RFID相對比較簡單，而且比較容易實現，只要在商品上加入特定的標籤，出門時透過感應完成商品的檢測，從而生成訂單。RFID實際上完成了一種成本轉移，把末端的結算的成本轉移到中間用來貼標籤、管理商品的成本。而視覺方案確實是解決了成本轉移的問題，但是它本身造價比較高，要求的運算能力、感測器的精度、規模都非常的大，而且並非真的無人，還需要按照一定規則進行運營，所以真正達到無人落地還需要很長的一段時間，它涉及到成本、技術和客戶顧客的習慣的問題。為什麼還繼續堅持做這樣的產品？或許這是人類對未來的生活方式的期許和信仰。
第三是支付，自從誕生了掃碼支付以後，我們攜帶現金的機會大大降低，這方面確實改變了我們的生活。下一步肯定會向無感支付的方向發展，它的第一階段是人臉支付，我們在17年時藉助微信的免密支付，率先推出了人臉支付 手勢識別的模式，實現零接觸的支付方式。隨著人們對支付安全性的信心越來越強，人臉支付在未來必定成一個比較流行的趨勢。
第四是智慧營銷方面，可以透過一些會員識別的方式，對會員做精準的推薦，向商戶提供合適的營銷策略。門店可以藉助佈置的感測系統，比如用於人臉支付的人臉識別機，識別會員，然後透過室內的監控攝像頭進行客流統計，並且獲取一些購買行為的情況，做大資料的處理，就可以向門店提供供應鏈管理、門店運營、營銷推薦等服務，讓門店的經營更加省時省力。
這四個的產品模式都是圍繞在提高效率，這也沒有違背剛剛提到的人工智慧就是為了節省成本這一點。下面從收銀環節來介紹人工智慧落地的應用情況。
CVPOS自助收銀的應用和商品識別的難點
我們講到的自助收銀裝置叫做CVPOS，從名稱看出它是藉助視覺的技術的POS機。首先從它的基本的需求開始介紹，作為一個自助裝置，它的基本功能是要自己操作，輸出訂單並完成結算，而不需要其他人員參與，這是產品最頂層的需求。再往下探一些需求，相比於掃碼支付而言，怎樣提升體驗呢？它可以一次識別多個，並且解決掃碼不能解決的非標品問題。根據這兩級的需求，產品的模式是嘗試用攝像機拍攝結算臺上的所有的商品，用視覺模型進行識別。當然也可以用別的感測器，但是視覺是最準確的。如果大家瞭解這個行業，可能會出現用重力感測器去識別，但是它的限制會高很多。
在現實的場景中CVPOS是會面臨哪些困難呢？這個領域我們用到的是目標檢測深度學習的模型。在深度學習中，作為有監督的演算法，資料的一致性是相當重要的，而環境會對模型的輸入資料產生一定的影響。我們必須保持訓練資料和測試資料的分佈要一致，這一點要求不需太過苛刻，儘可能保持環境的一致性，，不要是光太強或者太弱的環境，或者一些很極端的情形，剩下的環境因素交給模型自己去學習適應。
那為什麼不要把環境給封起來，做一些隔絕？這樣產品就會太複雜，完全違背產品設計的初衷，因為比較開放的環境會讓顧客更加容易接受產品。所以，顧客的體驗是第二個重要因素，除了剛剛所說的讓顧客感覺舒服外，另一個涉及到顧客體驗的是產品是否容易學習，怎麼樣去做結算，怎樣擺放商品，而不容易遮擋。當然最極致的一種體驗，是可以隨意擺放，都能夠識別這種商品。但是用視覺的方式，遮擋其實是不能完全解決的。所以後續產品的設計上是要儘量降低遮擋的機率。
第三是維護成本，在沒有做任何最佳化之前，成本是相當高的。首先，商品有可能外觀會很相似，外觀相似對於視覺是一個非常高的風險因素。另外，在零售行業的更新迭代速度非常快，我們的運維以及模型訓練的速度必須得跟上它們的運營效率，才能保證能夠正常的使用這個裝置。如果這三方面任意一點做的不好的話，都可能會出現顧客在買單時不能成功，造成後面有一堆人排隊，這樣的效果就非常差，導致顧客對產品的認同感以及複用的可能性降低。
上圖是在應用過程中發現的一些問題。從順時針開始，第一張，我們有個習慣就是喜歡用塑膠袋，但是視覺上這種塑膠袋實際上給物體帶來很大的噪聲，甚至改變了物體的外觀，，讓模型失效，第二張圖是商品的外觀極其相似，第三張出現了嚴重遮擋的問題，第四張是識別整體作為一個商品，還是識別單個商品。因為在真實的零售場景裡，有很多情況是你意想不到的，都是需要親身去經歷才能發現。後面都是圍繞在這些方面去進行改進和升級。
商品識別演算法落地的一般方法
在介紹經驗教訓之前，先介紹下演算法的一般落地方法。
現在優秀的開源演算法已經很多了，如何讓他們真正的助力自己的行業，成為產品的一部分，是需要方法論的。上圖是經過實踐總結出來的一些經驗，首先要明確任務的目標，到底是一個CV的任務，還是一個NLP的任務？這比較明顯，我們是一個CV的任務，但更重要的是要明確它的輸出結果是一個絕對的決策，還是一個推薦的決策。絕對的決策要求他的精度是零容忍的，它的準確率絕對影響最終產品的效能，而推薦的決策只需要給出一個分數，讓使用者自己參考做決策。
顯然CVPOS不是推薦式的決策，它對精度要求非常高，所以在第二步選擇模型演算法的步驟上，首先要根據精度的要求，再結合其他一些資源去挑選演算法到底是用目標檢測還是分割、分類，或是多種組合，用什麼主幹，選用什麼網路架構，這些選擇都需根據現場的需求決定。
第三步是資料準備，資料集剛開始可以用公開資料集，有助於去挑選合適的候選方案，隨著業務場景成熟，不斷引入業務資料，形成資料閉環，有助於快速提升模型精度。
對於標註，要選擇是手工標註、全自動標註還是半自動標註？顯然半自動標註是最符合真實的工程應用的。最後還有一些資料生成的問題，因為總會想不可能獲得更多的資料，總希望模擬出更多的資料分佈去擬合模型。但模擬方法從效果來講，這種資料增強不及業務資料閉環來得顯著。
資料挑選和資料集準備完之後，就是訓練調優步的方面，用什麼樣的網路？有沒有預訓練的模型？最佳化的策略是怎樣？訓練是用開源框架，還是要自己搭建一個訓練平臺。因為到了後期真正接近產品時，其實是需要固化一些引數，這時開發一個相對自動化的平臺工具進行模型的訓練和輸出，而不需要更多的調參，減少人工參與，是必要的。對於預訓練模型，可以根據商品的特定形態選擇訓練模型。比如說像烘焙，他的外觀極其相似的，我們可以專門做一個預訓練模型，為後續的訓練提速做準備。
透過調參訓練，再回到真實場景的業務資料迴圈中，不斷最佳化模型，當它的效能達到一定要求時，可以選擇上線部署，部署根據具體需求，選擇在雲端還是前端部署，最後一定要關心在應用上線之後的整個運營的狀況，在運營過程中搜索更多的真實問題，再把新需求回饋到整個模型開發的流程當中，對模型進行更好的迭代。
上圖是前端部署所需的一些工具以及模型，對於框架，基本上都是一些成熟的框架，而且他們的公開資源會比較多，方便大家去做實驗研究。對於模型，我們以目標檢測為例，會有一些帶錨框的模型，還有不帶錨框的模型，要根據真實場景去做決定。因為這是一個前端部署，我們儘量選用一些小的backbone，再配合一些模型壓縮技術。在前端部署方面，有類似於TFLite、Ncnn的前端的架構。現在選用的主要是國內大廠的開源的架構，因為它們會對國內經常使用的晶片，有一些定製化的處理，而且工具鏈也比較完善。
上圖是雲端部署的羅列，框架是一致的，因為要充分利用模型的效能，就少一點考慮模型的小型化，可以用一些更深、更寬、準度更高的網路，也不是不做最佳化，因為在雲端部署大部分使用的GPU是英偉達GPU，可以用TensoeRT去做最佳化，在正常情況下可以達到三倍左右的效能增益。API的部署可能會用到一些框架下自帶的Serving功能，或自己開發一些API的介面。
上圖是一個分類模型下的backbone的效能比較，開始可以透過這張表選擇一個性價比較高的模型進行候選實驗。由上圖可以看到在ResNet50左右區間，價效比最高，所以可以考慮在這附近選用一些backbone。
下一種是目標檢測的模型選擇，把Anchor-Free和Anchor的一步或兩步模型都做了驗證，是在自建的資料集上進行的測試，發現在backbone上效能會低一點，YOLOv3的價效比較高，是否用YOLOv3，還是要根據當前的真實環境和驗證實驗而定。
商品識別演算法工程落地步驟和應用實踐
– 需求分析
下面進入商品識別落地的經驗介紹，首先介紹下它的基本的需求。第一，它是一個自助的裝置，自助完成完成訂單並結算；第二，它的準確性的要求很高，結算是不能夠有誤的；第三，顧客要容易學習，使用方便。根據這三點基本的需求，我們確定產品的模式，是透過攝像機拍攝所有待識別的商品，利用CV進行檢測，完成生成賬單並結算。
根據場景需求，要考慮它的結構以及外觀是否可以完全輔助我們的演算法。第一點是結算臺的區域設計，這關係到整個產品的大小，以及一次性檢測商品的容量，根據我們所服務的便利店以及餐飲的模式，平均每人每單商品的數量大概是在4件左右，結算臺的大小是按照這種標準去設計的，大概五六件商品，而且在擺放的過程中是留有充足的空間，不會擠在一起，從而去降低物品遮擋的可能性。對於我們應用場景，大小已經適合了，若面積更大，可一次性識別東西更多，根據購物習慣，更容易造成堆疊。
第二點是攝像頭的選型，因為攝像頭的位置是固定的，我們推薦是選擇一個定焦的攝像頭，因為變焦的攝像頭很難去固定環境，這影響資料的穩定。另外要儘量用一些寬動態的模組消除對強光的影響。下一個選擇是用2D還是3D的攝像頭，3D有一個距離的資訊，對於不在同一個面的物品，它的分割效果是可以的，但是也不能完全解決遮擋的問題，若被完全遮擋，3D也是搞不定的。從綜合成本上考慮，最終選擇2D攝像頭。
第三點是攝像頭該如何佈置？首先，多個攝像頭可以提高在遮擋情況下的準確率，但是透過融合兩個攝像頭的結果來看，提升的效果並不多，因為系統不知道應該相信哪個攝像頭多一點。這裡用到一個整合演算法的思路，但這種思路，最好是用在異構的演算法或異構的資料訊號上，也就是這些演算法或訊號具備的能力完全不同，這樣效果會更明顯一些。所以，還是先用一個攝像頭進行設計。
對於角度問題，如果商品的特徵集中在頂部，可直接採用一個垂直向下的角度，而且這種角度，遮擋的可能基本消除。但在便利店的場景中，需要識別很多瓶子類的商品，它的特徵集中在側面，就須架起一定的角度。以我們的經驗，大概是用到70-80度的角度，既能夠看到側面，又不會增加太多的前後遮擋。
– 模型需求
下面進入模型選擇的問題，選擇模型首先要制定一個客觀的指標，一般用常規的mAP、召回率、準確率，要客觀的去評價待測的模型，幫助快速篩選出候選的模型，模型的選擇可以遵循以下四個提示：
第一，預訓練模型是否能夠搞定，如果能搞定，就不需要再做多餘的訓練，其他的業務或場景是可以參考的，但顯然在CVPOS上面是不可以的，我們需要更多的業務資料；第二，不能忽視傳統的方法；第三，是要用多模型的組合，還是用一個端到端的模型；第四，是模型是否容易訓練和部署。
第二到第四點其實是在做一種選擇，我們是要選擇一個端到端的模式，還是用多種方法組合的模式，端到端在研究領域上比較受歡迎，但是在工程上，端到端並不順利，因為它的耦合性太強，兼顧到的功能會比較多，所以訓練起來有點困難。但是在工程上追求的是靈活，所以很多時候問題是需要分開處理。比如可以將整個目標檢測模型分成檢測和分類兩個模型，由於平常在工程上出問題，可能只會出現在其中一個模型上面，我們去最佳化去改進，就只需要關心那個模型就可以。這樣可以大大簡便後續的一些維護工作。所以，我們的模型是要用一個雙模型的方式，即目標檢測模型 分類或商品檢索的模型，雙模型組合。
– 資料需求
對於資料上的需求，可以先選用公開資料集或網上的資料，對模型進行訓練和對比，評判模型的可行性。在瞭解產品具體的場景後，將自己的業務資料迴流，去迭代自身的模型，形成一個自制的資料集。自制資料集還有另一種方式是自己生成組合的資料集，但實踐上這兩個其實都有效的，但是資料閉環的方式是短期內提升精度最有效的方法。對於資料增強，有一部分是憑藉自己的猜測，所以不能完全模擬真實的資料的分佈，它的效率並沒有資料閉環高。第四點是標註的成本，分成三種，人工、全自動和半自動，人工和全自動顯然是不可以的。若為全自動，就證明你的模型是正確的，就不需要再訓練。
折中選擇半監督的標註方法，用比較好的預訓練模型去做預標註，然後透過人工把置信度比較低的標籤修正過來。資料標註成本的另一方面考量是，它會直接影響到最終模型的選擇。由於現在選定的是一個目標檢測，為什麼不選分割任務？因為分割的標籤非常難打，而目標檢測只需要一個框，所以優先要考慮用目標檢測的模型。選擇打框標籤也發現另一個問題，因為在同一張圖上可能會出現多個類別，這樣打起標也非常麻煩。所以，雙模型的方式可以很好的解決這個問題，打標籤的時候只需要關注框的位置，而並不需要再去選擇到底是哪一個分類。
下面介紹下我們的經驗，一開始選用經驗效能比較好的模型，然後在公開資料加上一點實驗室資料，而實驗室資料的產生如上圖所示。左邊兩幅圖是曠視在19年釋出的一個商品的資料集-RPC，而我們的採集方式跟它類似，也是用各個攝像頭的角度去拍攝商品，然後透過旋轉的轉盤把各個角度的資訊錄入，最後透過語義分割或例項分割，把他的掩膜mask給取出來之後，再進行商品的組合。
右圖是在17年時做的一個組合，雖然沒有RPC的陰影效果，但對於最終訓練的作用是差不多的。最根本還是真實場景的問題。透過資料的訓練，在實驗室跑的成績非常高，但放到了現場，下降30%是很正常的，從而證明了訓練和測試的資料分佈是不一致的。
– 落地的困難
落地的困難有以下3點，第一，與benchmark相距甚遠；第二，商品種類繁多，在不同商戶之間利用率是非常低，標註困難等；第三，維護的頻率非常高，需要有相當高的及時性。那針對上面的這三個要求做了一些改進。
– 改進
首先，當然是資料閉環的問題，我們對環境做了一定的要求，限制場景，並開發採集工具及結果的錯誤檢查工具，可以讓現場的資料快速回流到模型的基礎訓練集裡面，及時地更新學習。資料採集方面，直接放棄了實驗室環境，直接開放給店員採集，用現場的資料。在採集的過程中，對於相同的商品，可以透過不同角度、方位，按照一定規則進行採集。如果有多家門店有相同的上新需求，可以把採集任務分配到各個門店，平均每一個門店的採集任務就降到比較低，基本沒有增加額外的成本。對於標註，採用半監督檢測標註，用一個比較好的預訓練模型去做預標註，在透過人工的篩選，把置信度低的樣本給調整過來。
第二個是多模型組合，上圖有兩個模型，一個是檢測模型，另一個是分類模型，除了可以解耦合，讓標註更簡單，對資料模型更容易的管理以外，還可以解決目標檢測上樣本不平衡的狀態，我們只需維護一組專門用來擬合檢測模型的訓練資料，其他的平衡的問題交給分類模型進行處理。
另外一個問題是樣本需要時間的管理，假設在同一年裡有三段時間，它的外形是不一樣的，這時需要商品的時間管理，利用時間的管理進行樣本的平衡，可以針對不同時間加不同的權重，比如近期的資料會多一點，遠期的資料少一點，生成一個適應較長時間段的訓練集。
第三是建立一個商品的預訓練模型，可以根據不同種類建立不同的預訓練模型，這可以加快fine-tuning的速度。第二個是困難樣本的反饋訓練，這是一個閉環的fine-tuning過程，及時將這種出錯的樣本回收到訓練集裡面，透過這種fine-tuning的方式，把這一部分沒見過的資料擬合過去。最後，要開發一個管理工具去管理訓練任務，做好任務的排序以及資源上的排程。
– 落地的其他事
第一點是部署，開始是從雲端開始部署，然後慢慢就變成前端，因為前端可以節省成本；第二點是模型的壓縮，可以利用一些比較成熟的框架，比如飛槳，進行模型的壓縮，可以發現在精度沒有下降的情況下，收益都非常可觀；第三點是檢測和分類模型上的最佳化，檢測方面發現一些Anchor-Free的效果比在Faster-RCNN的效果要好，所以嘗試用一些Anchor-Free的模型驗證自己的資料集，在分類方面，主要是用損失函式去加大分類之間的margin，可以參考一些人臉識別相關的損失，這些都可以加大類間的距離；第四點是習慣的培養，習慣培養反而是最困難的，因為習慣比較難培養，這也是在很多地方沒推廣起來的一個原因。
我們有兩點比較實用的建議，第一，可以提示一個擺放的位置，雖然不高階，但一次成功識別率應該是會大大提高。第二，不去培養顧客，專門培養店員，讓店員使用這個產品，尤其是對烘焙、餐飲這種非標品，店員就不需要專門的手工錄入資訊。從這個層面來講，它確實也是可以提升最後的結算效率。
對於產品的魯棒性問題，因為一些客觀原因，識別率做不到100%，所以必須要有一些輔助工具去保證模型的更新速度，包括採集、標註、訓練、驗證部署等，都要透過工具去管理，透過工具讓我們發現錯誤。另外還有一個恢復機制的問題，第一種恢復機制是機器上的恢復，可以用一些校驗的手段，比如加重力感測器去校驗識別結果，或者用多個攝像頭的整合思路去投票等，置信度較低時，可以提示下客戶去重新擺放。另一個是要有一個人工快速介入的管理機制，不要讓使用失敗的顧客等。所以收銀機不只是一個產品或是一個演算法，它需要整個運營系統相互配合。
– 總結
總結主要分為以下幾點：首先，大目標減成本是不變的，所有產品的設計都要圍繞著總成本不變的目標，然後我們依據這個目標以及一些資源需求選擇合適的模型，第3到第5點，是演算法維護而產生的一些新功能需求，也就是在產品的設計中要保留資料閉環的機制，也要有相應的開發效率的工具，查錯的工具，能夠快速訓練迭代等，另外產品要有自校驗、自恢復的機制，不管是機器自己完成還是人工干預，我們的整個運營模式裡必須包含這一塊才能保證整個產品有序的運作下去。最後是產品是易用的、習慣可培養的。