本文已授權@極市平臺，未經允許不得二次轉載，如有需要請私信作者
註意：本文從我的一個PPT整理而來，行文可能比較隨意，很多細節沒有寫清楚，後續有時間會持續修改。
上次說到，要寫一個系列，最後整理才發現，還是合成一篇比較好一點。
主要內容還是圍繞著場景分析與數據理解、方法論與算法設計、工具鏈與部署落地等方面進行展開。重點關註的還是頂層設計，因此涉及到的很多具體的細節沒有說太多，仁者見仁智者見智吧。在平時工作中和思考問題上，我喜歡用簡單粗暴的手段去分析，比如：本質上，和某某沒有區別，說白瞭就這等語氣。目的就是透過現象看本質，抓住主要矛盾。
內容提要
本文大致的脈絡是按照場景、數據分析，方法論算法設計，工具鏈與部署等進行展開。行文中一些比較重要點的，會單獨開篇幅進行展開。包含以下論點：
- 主要難點
- 場景分析
- 缺陷歸納
- 簡單粗暴的可行性分析
- 數據的四大難點
- 數據生成
- 場景VS數據
- 方法論
- 算法積木
- 任務拆分
- 定制分類模型
- 定制語義分割模型
- 語義分割利器dice loss
- 定制目標檢測模型
- 正常樣本建模
- 工具鏈
- 技術壁壘
- 總結
（一） 主要難點
我認為缺陷檢測沒有啥難的，基本上都可以做。那為啥槽點還那麼多？我認為很大一部分是AI的槽點，因為目前使用AI來做是主流，或者說隻傳統方法搞不定的，沒辦法，隻有上AI的方法。AI的槽點有很多，例如：
- 多少人工就有多少智能，太依賴於標註的數據；
- 過擬合嚴重，泛化能力差；
- 容易被攻擊到，沒有提取到真正的特征；
- 提取特征太多抽象，可解釋性差，大傢都是“黑盒子”玩傢；
- 經驗學、嘗試學，沒有建立起方法論，trick太多，很多都是馬後炮強行解釋；
- “內卷”嚴重，nlp領域的sota 拿到CV，各種模改就work瞭？甚至都使用mlp進行返租現象，讓我們一時半會摸不到方向。
當然，學術界和工業界也有一條巨大的鴻溝。學術界在於新，有創新點，在開源數據上各種嘗試。工業界強調的是精度、成本、落地。再者場景過於分散，沒辦法達成一致的共識，場景、數據、需求等均是如此。
單單從工業界來看，在“缺陷檢測”這一個細分的場景（其實也不是啥細分場景，所有找異常的都可以叫缺陷檢測）。也有很多的槽點或者坑點，我認為原因如下：
- 方法論沒做好：例如迭代中涉及多個環節，管理容易混亂，或沒有意識到baseline數據集的重要性，敏捷開發變成扯皮甩鍋。
- demo難做：業務場景分散，沒有現成的可以直接展示。方案涉及光學硬件，做demo耗時耗力，關鍵的是最後不一定能拿下。
- 更換型號難做：光學+標註+訓練+部署一條龍，對工具鏈的用戶體驗要求非常高。有時別提用戶體驗瞭，甚至一個項目現做一套也不誇張。
- 高度定制：還是那句話，業務場景分散，推廣困難，復制基本等於重做。
- 精度需求：用戶期待高，動輒要求100%？超過人類？
- 檢測時間：人工一個小小的動作，自動化執行超級復雜。尷尬的是面對的產品價值可能很低，比如幾毛錢的一個塑料制品。
- AI+傳統：AI信不過，傳統來兜底。結果超參過多，運維困難。單純AI有時也會存在模型過多的情況。
從業務、工具、管理上來說，有三大難點：
- 業務難點：場景分散，更換型號困難，大規模標註困難，理解數據需要一個過程。
- 工具難點: 工具都有，但是整合困難。
- 管理難點：更新迭代，敏捷開發，需要需求、光學、標註、算法、運維等多方人員協同完成。
（二）場景分析
本文討論的是工業場景，那就先和自然場景比一比吧！如下：
當然有一個非常重要的特性沒有說：
自然場景一般是強語義信息，缺陷檢測一般為弱語義信息。近期利用輕量級語義分割訓練缺陷檢測不好使有感而發。缺陷檢測不需要特別大的感受野，一般為紋路上的缺陷，局部區域就可以判別。
貌似難度比自然場景少不少，再仔細分析一下，工業場景其實有以下幾個特點：
- 業務場景過於分散 ，對標一下“人臉”，甚至“OCR”等領域，缺陷檢測場景還是非常分散的，難以歸納。
- 受限、可控 ，有比較的大人工幹預空間。例如可以利用一些光學、機械結構等設計降低場景的復雜，使得我們面臨的場景更加純粹。
- 一般面臨目標比較微弱 ，這個目標缺陷的形態、顏色等有關。有時還會有一些例如黑色紋理上的黑色缺陷，強烈吃視角的缺陷等；
- 需求不太明確，很多時候做不到非黑即白的“一刀切。其實仔細思考，並不是客戶給不粗明確的需求，而是場景和數據本身的固有屬性，需求在執行的時候很難做到一致性，這點下面的數據分析會細說。
- 精度指標要求比較高，動輒100%還是比較誇張的。不過以我個人的經驗，100%需求的地方，還是比較好做的。一般1個點的漏檢，2到3個點的誤檢也算比較理想的結果瞭。不過有一點值得說明的是，非常明顯的漏檢和誤檢就是低級錯誤，要不得的。
以上是工業缺陷檢測場景的固有屬性。針對該場景，主要有以下三點需求：
- 撿出NG和GOOD，這個是最基礎的任務，不然不能稱之為缺陷檢測；
- 定位缺陷的位置，方便歸因分析、指標統計、設備升級、維修等；
- 給出缺陷的量化指標，例如面積、長度、對比度；一般對應的上層任務有缺陷分級、需求定制或變更。
（三）缺陷歸納
做好缺陷的歸類，才容易下手。這裡給出三種歸納方法：
歸納一：
- 紋理缺陷：替代原始樣本紋路表現，位置、大小、形態不固定；劃痕、臟污等；
- 結構缺陷：與目標結構有關，其位置、形態較固定，可能不存在量化的概念（錯漏反）；
- 其他缺陷：例如醫學圖像、一些紅外熱成像、超聲波成像等，可能無法靠肉眼建立精準的對應關系
- 綜合以上
歸納二（站在正常樣本建模的角度）：
- 紋理（一般指重復的結構，可能存在顆粒比較大的紋理）
- 非紋理對齊：與結構相關，但是可以做到對齊
- 非紋理無法對齊：與結構無關，但是很難對齊
- 綜合以上
歸納三（形態上）：
- 加法：臟污、異物、附著、
- 減法：殘缺、劃痕、破損
- 替換：混色、異色、雜質、混淆
- 變形：扭曲、尺寸、褶皺
（四）簡單粗暴的可行性分析
需求非常多，有時甚至來不及打光驗證。因此我有一套簡單粗暴的可行性分析辦法。主要針對業務場景來說。當然這隻是粗糙的可行性分析，隻能建立大致的、初步的印象。具體能不能做，還要從光學、結構復雜度、成本、運維、打開市場、推廣等多個維度進行評估。
簡單粗暴包括以下兩個點：
- 明顯：缺陷清晰可見，肉眼容易辨別，同時也是對光學成像提出要求；
- 明確：缺陷標準定義明確，沒有爭議，是對需求進行篩選；
基本上滿足以上兩點，就可以認為該case是可行的，基本可以做的。不過實際的情況是比較復雜的。僅僅靠“明顯”和“明確”會把很多機會攔截在外。這種定義無可厚非，但是不夠深入，給算法設限。缺陷檢測，很難做到這兩點的理想情況。且看下一小結數據的詳細分析。
（五）數據的四大難點
難分、多樣性、不平衡、數據臟。把握難點，針對舉措。
5.1 數據難分
直接後果就是標準難定，學術一點來說就是正負樣本類間差距較小，不是非黑既白的一刀切能夠搞定的，很難有一個一致性的標註將正負樣本分開。也就是需求標準難定，即便是人工也很難保證。標準可能還比較好定，但是執行起來較為困難。
這個放到第一點，因為它是場景和數據的固有屬性，人工很難改變，這也是大傢吐槽缺陷檢測難做的主要原因。不管用任何手段去描述缺陷，都不能做到明顯可分。比如按照面積、灰度值等繪制其直方圖，中間過渡區域永遠存在一定量的樣本，處於灰色地帶，模棱兩可。不管你是多人標註也好，不管你是做量化指標也好，總很難有好的辦法改變這一現狀。
有人可能會說，直接給閾值進行一刀切或兩刀切，閾值交給客戶來定。不過我們自己本身要想明白這個事情：不管是AI，還是人工，都會檢出灰色地帶。該場景存在這種情況，那麼說明其需求本應該能夠接受灰色地帶的數據分錯。
標註測試集就很難做，例如甲方合同明確要給出準確率。該問題的存在，很難達到理想的指標。所以如果面臨該場景，建議在統計指標上，給出明顯漏、明顯誤等。不然會陷入“清洗數據”、“更改需求”、“重復試驗”的死循環，無法解脫。
能否給出對應的量化指標，也是很大的問題，比如明顯的缺陷判分很低，微弱的缺陷置信度又很高。降低客戶的期望也好，讓客戶理解AI判定過程也好，總之就是既然想讓AI代替人工，我是可以做到。
針對該場景，我們要做的是：易分樣本（也就是明顯缺陷和明顯不是缺陷）不能出錯，然後在漏檢和誤檢的tradeoff尋求一個平衡。一般客戶會有“直通率”這個概念，可以多次磨合，多次迭代，趨向用戶期待。
5.2 多樣性不夠
這點表現為類內差異過大。比如同樣是劃痕，表現形式各種各樣，有的發白，有的發黑，有的吃視角，有的發生在邊緣地帶等等，出現在不同位置，表現形式都不一樣。因此導致一個問題：你很難收集到全部形態的缺陷樣本，所以在測試集上很難有一個不錯的表現。也就是你的訓練集和測試集存在的明顯影響性能的偏差，這裡的偏差不是標註導致的，而是數據本身導致的。這種情況還是比較高頻率能夠遇到，比如和客戶聊一個需求的時候，對於某一種缺陷，他會說比較大概率發生在A處，但是不能排除發生在其他地方的概率。問題就是目前很難收集到樣本，即便收集到樣本，也很難覆蓋所有的情況。
一般我們做一個任務，會有一份標準測試集，方便我們的方案、算法進行迭代。沒有測試集，精度指標無從談起。由於缺陷表現的多樣性問題，我們的標準測試集可能就沒有那麼的“標準”。實際數據集構建的過程中，盡量保證較大的覆蓋率。多樣性圖片拿不到，但是“缺陷描述”還是可以拿得到的。因此需要結合一些正常樣本學習和數據生成的方法來降低“多樣性不夠”帶來的影響。
5.3 樣本不平衡
表現在3個方面：
- 從樣本級別來看，是不平衡的，大量的都是正常樣本，NG樣本占比較小；每天會收集海量的圖，有缺陷的比較少。
- 從缺陷實例級別來看，缺陷占整體較小，例如500w相機拍攝圖片，2500*2000pix尺度上，缺陷尺度可能小到10*10pix的水平。缺陷過小會帶來一個嚴重問題。沒辦法進行resize（當然使用高分辨率的相機本意也是更精準的檢測尺度小的缺陷）。導致的問題是：測試的時候，1是耗時，2是比較難控制誤檢的。例如siliding window檢測，即便每一個patch預測準確率是99.9%，綜合起來，性能下降的非常厲害。
- 從類別上來看是不平衡的，會存在某一類占比較大，有些缺陷占比較小。實踐證明：隻要有足夠多的樣本，即便是非常微弱的缺陷（這裡的定義是肉眼可判別），網絡也可以識別。應對方法很多，無外乎是數據生成、數據增強、過采樣、loss上設計、訓練策略上等等。
5.4 數據臟
工程上的問題，必須考慮數據臟的情況。
數據臟就是標註的時候把標註類別搞錯。搞錯大傢一般會認為是數據難分的原因，其實不然，數據難分，也就是標準難定或者無法清晰給出，因此這部分導致的原因不能單純歸納為數據臟。但是這裡為瞭便於分析，我們區別對待。臟數據會對網絡訓練帶來不利的影響，強行訓練會有過擬合的風險。因為網絡提取通用特征，擬合不到缺陷隻能去擬合其他噪聲瞭。不過也有說法是，臟數據作為噪聲，也能給網絡帶來好的收益，讓網絡搜索參數的時候增加擾動，避免陷入局部最優，卻能防止網絡過擬合。不過一般任務：數據還是越幹凈越好。
那就是數據清洗，例如交叉驗證。學術上也有一些噪聲樣本學習的方案。數據臟還比較好辦，歸根到底是數據標註的問題。隨著訓練迭代以及人工清洗，可以很好的改善這一情況。
（六）數據生成
雖然是工業場景，數據會源源不斷過來。但是上文提到數據的幾大問題，例如樣本不平衡等，所以有時我們會需要生成一部分的數據。還有一種情況，在項目初期，我們往往“打樣”。所謂demo階段，是拿不到足夠多的數據的。另外，數據肯定是多多益善，如果我們有生成數據的巧妙方法，訓練從中受益的話，也很大程度上降低瞭數據收集、標註、清洗的成本。
數據生成有傳統方法和深度學習方法兩種可用。傳統方法可以進行一些圖像融合，例如直接將缺陷裁剪下來到處貼，為瞭保證生成的逼真一點，還是需要一些融合的手段，例如泊松融合和邊緣融合等。當然，有些場景，直接修改圖片局部的灰度值也可以生成逼真的缺陷。我就單單利用修改圖片的灰度和對比度就生成瞭很多以假亂真的圖片。深度學習方法一般用GAN和VAE等生成模型可用，利用GAN可以直接從噪聲生成數據，不過產生新的對網絡訓練有受益的信息比較有限。可以利用類似pix2pix的方案進行圖片編輯。傳統方法中的圖片融合也可以利用GAN來做。
（七）場景VS數據
前面主要說瞭場景和數據的一些東西，這裡對比再看一下。場景是客觀的，固有屬性，你做與不做，它都在那裡。
數據是有主觀的成分在裡面：從其光學設計、標準執行等上來說，有很大人為因素。也是上文說的可控。具有很大的操作和設計空間。
但是有時還要思考：值不值得做？可能是時間、成本、性價比、大規模推廣等方面的原因。當然，大部分場景還是很容易做的，因為在工業領域，至少是受限的和可控的場景。關鍵要分清主要矛盾和次要矛盾。
（八）方法論
缺陷檢測是整個系統工程，每個階段都有不同的人參與，而算法工程師幾乎要從頭打到尾。
這裡重要要建設四種意識，要進行全員建設。從產品經理、光學工程、結構工程師、算法工程師、應用工程師、運維工程師，當然也包括決策者：
- 版本管理意識：不光代碼有版本管理，算法、數據、環境甚至硬件都要有版本管理的概念。
- baseline意識：baseline也就是我們版本管理的起點，不斷優化的基石。
- 閉環意識：既然用AI，數據驅動的工程，那麼請問能夠一次性給到我完美的數據集？如果不能，請具備閉環意識，做好更新迭代、持續優化的工作。
- tradeoff意識：精度和時間是tradeoff，準確率和召回率是tradeoff，虛檢和漏檢是tradeoff。tradeoff的意思就是要綜合考慮。
在進行需求挖掘和可行性分析的時候，有一些一些值得思考點
- 用戶理解上，建立一致性的期望。全員更加理性認識AI方案。
- 用戶可能給不出明確的需求，要共同發掘一致性的需求。
- 需求、光學確定以後，建立標準測試集。
- 對於算法難以界定的灰色地帶，接不接受人工二次復檢？
- 是否涉及更換型號？
- 什麼是絕對不能容忍的錯誤，算法的下限在哪裡？
- 對時間上的要求？
- 標準確認上，采用多人標註，便於評估數據的一致性。
（九）算法積木
如上圖所示，我們能用到的深度學習算法積木很多，首先是分類、分割、檢測三大任務，這是我們的主菜。當然還有一些別的方法，例如分類算法中有細粒度分類，可以更加精準的提取微弱的特征，細粒度算法一般會用到打亂和註意力機制，對紋理上的缺陷識別會更優一點。另外，應用語義分割任務做缺陷檢測，其實缺陷檢測並不局限語義分割，它更像提取一張高斯熱圖，有缺陷的地方概率高，背景區域概率低。因此有一些熱圖回歸的做法也可以應用。除瞭監督方案，在應對缺陷樣本少的場景，我們還可以選擇無監督學習方案。
當然，上面也說瞭，數據場景復雜，一致性問題難以保證。而且面臨的數據量比較大，因此你還可以使用一些半監督、弱監督的手段來降低標註的工作量。
（十）任務拆分
任務拆分，可以降低算法的難度。多個結果進行分攤任務難度，另外不同階段對數據的依賴不一樣，多個階段拆分更容易控制，尤其是在樣本平衡方面。多個階段對標的是端到端，可以做到精度方面的提升。
（十一）定制語義分割模型
語義分割容易擴展，可以輸出最精準的逐像素特征，依賴樣本更少（當然標註量比較大），非常適合來做缺陷檢測任務。下面給出一些經常叫魔改也好，定制也好的特性。
定制特性：
- 多通道輸入：適配多個光源的復雜場景
- 骨架任意切換：resnet、effecientnet
- 多個head：多任務，處理互斥類別
- attention輔助head: aspp、danet、senet、non_local
- 中繼監督： 增強梯度信息
- refine module（Cascaded）：結果精修，過濾虛檢
- 不對等輸出：256*256 > 8*8等，加速，犧牲定位精度，降低擬合難度
- attention機制：通道、空間、nonlocal，提升全局感知能力
- 通道剪枝：手動，network-slimming
當然再配合一些訓練tricks，可以達到事半功倍的效果：
- 過采樣：進行正負樣本平衡，非常基礎和常用的手段，經常使用crop的手段。
- 動態平衡dataset：其實和過采樣有異曲同工之妙，不過該方法是隨著訓練過程動態調整的，可以理解為作用在數據層面的難樣本挖掘。
- 標簽平滑：語義分割標註是有偏差的，主要體現在邊界上，所以可以進行標簽平滑策略。
- diceloss：樣本不平衡神器，必須好好利用；
- 難樣本挖掘：
- loss截斷：同樣應對標註偏差的情況
- 對抗訓練：預防對抗攻擊
（十二）dice loss 10 問
眾所周知，diceloss是語義分割，尤其是應對正負樣本不平衡的一把利器。但是它也有一些槽點，因此必須整明白。下面提出diceloss十問，暫時不給出答案。之前也寫過一個diceloss的深度解析，可以參考一下：
- 和ce的區別?
- label為0的像素區域有無監督?
- 正常樣本有無作用?
- 正負樣本比例的影響、怎麼設置?
- epsilon的影響?
- 有無梯度消失或飽和的現象?
- 能否不使用sigmoid激活函數？
- 能否通過權重初始化改善梯度消失?
- 震蕩的本質原因?
- 預測邊緣更銳利?
（十三）定制分類
分類是最簡單的任務，當然缺陷檢測可能會對它提出瞭更高的要求。例如下面這個方法
分類任務有時會結合交叉驗證、多模型boosting、弱監督語義分割。
（十四）定制目標檢測
很多技巧性的東西，都是通用的目標檢測技巧，例如：尺度問題、形變問題等等；本文不再敘述。
（十五）正常樣本建模
傳統方法：（場景受限，需要調參數，可用於防呆，明顯缺陷沒問題，微弱缺陷效果不行）
- 對齊+對減
- 對齊+GMM
深度學習：
- 基於特征統計
- 基於GAN
- 基於樣本生成
對場景進行篩選，從簡單、對齊入手。註意：可以利用監督學習尋找算法的上限
（十六）工具鏈
如上圖，缺陷檢測落地需要非常多的工具支撐：
- 圖像采集：相機、運動設備、光學控制；
- 數據托管：服務器、數據庫、版本管理、數據積累；
- 數據處理：圖像分析、定位、裁剪；
- 數據標註：適配各種任務、半自動標註；
- 數據清洗：半自動、交叉驗證、一致性分析；
- 缺陷生成：傳統方法、融合、GAN；
- 訓練框架：分類、分割、檢測、熱圖回歸等；
- 測試框架：多模型測試、指標統計、可視化；
- 部署平臺：模型融合、模型加速、平臺移植；
- 前端框架：GUI、數據持續收集、用戶體驗；
難點：整合散亂的工具，甚至完全交給用戶。市面是有很多做自動訓練軟件的，例如比較知名的VIDI，國內也有AIDI、Alpha等。可能大傢選擇的模型不是非常先進，但是從標註到訓練，再到模型導出，用戶體驗和跨平臺做的比較好。工業場景，特定場景特定算法，工具做好，不必追求SOTA模型，SOTA模型隻是提高瞭自然場景精度的上限，而我們需要把握模型的下限。
（十七）部署
部署沒啥可說的，可其他任務沒有太大區別，這裡列舉一些總結的點吧！
部署兩大任務：
- 平臺移植
- 模型加速
模型加速：
- 模型輕量化：mobilenet, EfficientNet
- 量化：INT8、INT16、2BIT
- 剪枝：network-slimming
- 蒸餾：Knowledge Distillation
部署的兩種方式：
- 服務端：服務器、雲端(微信小程序)、工控機
- 邊緣設備：jetson, NPU，rk, arm
常用推理庫：
- c、c++原生態：darknet
- pytorch原生態：libtorch、torch.jit
- 中間轉換：onnxruntime
- GPU: tensorRT、onnxruntime-GPU、TVM
- CPU: openvino、onnxruntime-CPU
- ARM: ncnn TNN MNN等
（十八）技術壁壘
- 系統工程：硬件、光學、算法、部署，穩定、可靠
- 數據積累：用戶理解、場景理解、數據理解，在專用領域形成數據積累
- 工具鏈：可以支撐項目快速落地
- 成本控制：開發周期、硬件成本、運維成本
所以缺陷檢測不單單是一個算法模型的問題，而是整個系統工程。可能不需要非常前言的算法，但是需要成熟的工具鏈。即便是基礎的算法、看似容易的場景，也可以形成技術壁壘。如果想復刻，也沒有那麼輕松。很多時候，不是不能做，而是值不值得做？
Nothing is impossible, what you want is simply expensive
（十九）總結
- 場景分散，硬件結構、光學強相關，復刻難度大，高度定制、推廣成本高。任務可行性分析，系統工程層面（整套方案、數據）形成技術壁壘；
- 數據一致性問題：難分、類內差異大、樣本不平衡、數據臟等，難以在一個標註測試集上輸出比較好的指標。需求理解、數據理解、數據管理；
- 不需要特別前沿的算法；
- 問題模型定制、訓練技巧、任務拆分；
- 工具鏈完善；