注意：本文从我的一个PPT整理而来，行文可能比较随意，很多细节没有写清楚，后续有时间会持续修改。

  主要内容还是围绕着场景分析与数据理解、方法论与算法设计、工具链与部署落地等方面做展开。着重关注的还是顶层设计，因此涉及到的很多具体的细节没有说太多，仁者见仁智者见智吧。在平时工作中和思考问题上，我喜欢用简单粗暴的手段去分析，比如：本质上，和某某没有区别，说白了就这等语气。目的是透过现象看本质，抓住主要矛盾。

  本文大致的脉络是按照场景、数据分析，方法论算法设计，工具链与部署等进行展开。行文中一些较为重要点的，会单独开篇幅进行展开。包含以下论点：

  我认为缺陷检验测试没有啥难的，大多数都可以做。那为啥槽点还那么多？我认为很大一部分是AI的槽点，因为目前使用AI来做是主流，或者说只传统方法搞不定的，没办法，只有上AI的方法。AI的槽点有很多，例如：

  当然，学术界和工业界也有一条巨大的鸿沟。学术界在于新，有创新点，在开源数据上各种尝试。工业界强调的是精度、成本、落地。再者场景过于分散，没办法达成一致的共识，场景、数据、需求等均是如此。

  单单从工业界来看，在“缺陷检验测试”这一个细分的场景（其实也不是啥细分场景，所有找异常的都可以叫缺陷检验测试）。也有很多的槽点或者坑点，我认为原因如下：

  ：例如迭代中涉及多个环节，管理容易混乱，或没意识到baseline数据集的重要性，敏捷开发变成扯皮甩锅。

  ：业务场景分散，没有现成的可以直接展示。方案涉及光学硬件，做demo耗时耗力，关键的是最后不一定可以拿下。

  ：光学+标注+训练+部署一条龙，对工具链的使用者真实的体验要求非常高。有时别提用户体验了，甚至一个项目现做一套也不夸张。

  ：人工一个小小的动作，自动化执行超级复杂。尴尬的是面对的产品价值可能很低，比如几毛钱的一个塑料制品。

  ：AI信不过，传统来兜底。结果超参过多，运维困难。单纯AI有时也会存在模型过多的情况。

  自然场景一般是强语义信息，缺陷检验测试一般为弱语义信息。近期利用轻量级语义分割训练缺陷检验测试不好使有感而发。缺陷检验测试不需要非常大的感受野，一般为纹路上的缺陷，局部区域就可以判别。

  ，对标一下“人脸”，甚至“OCR”等领域，缺陷检验测试场景依旧很分散的，难以归纳。

  ，有比较的大人工干预空间。例如可通过一些光学、机械结构等设计降低场景的复杂，使得我们面临的场景更纯粹。

  ，这个目标缺陷的形态、颜色等有关。有时还会有一些例如黑色纹理上的黑色缺陷，强烈吃视角的缺陷等；

  ，很多时候做不到非黑即白的“一刀切。其实仔细思考，并不是客户给不粗明确的需求，而是场景和数据本身的固有属性，需求在执行的时候很难做到一致性，这点下面的数据分析会细说。

  ，动辄100%还是比较夸张的。不过以我个人的经验，100%需求的地方，还是比较好做的。一般1个点的漏检，2到3个点的误检也算比较理想的结果了。不过有一点值得说明的是，很明显的漏检和误检就是低级错误，要不得的。

  需求非常多，有时甚至来不及打光验证。因此我有一套简单粗暴的可行性分析办法。主要是针对业务场景来说。当然这只是粗糙的可行性分析，只能建立大致的、初步的印象。具体能不能做，还要从光学、结构复杂度、成本、运维、打开市场、推广等多重维度进行评估。

  基本上满足以上两点，就可以认为该case是可行的，基本能做的。不过实际的情况是很复杂的。仅仅靠“明显”和“明确”会把很多机会拦截在外。这种定义无可厚非，但是不够深入，给算法设限。缺陷检验测试，很难做到这两点的理想情况。且看下一小结数据的详细分析。

  直接后果就是标准难定，学术一点来说就是正负样本类间差距较小，不是非黑既白的一刀切能够搞定的，很难有一个一致性的标注将正负样本分开。也就是需求标准难定，即便是人工也很难保证。标准可能还比较好定，但是执行起来较为困难。

  这个放到第一点，因为它是场景和数据的固有属性，人工很难改变，这也是大家吐槽缺陷检验测试难做的根本原因。不管用任何手段去描述缺陷，都不能够做到明显可分。比如按照面积、灰度值等绘制其直方图，中间过渡区域永远存在一定量的样本，处于灰色地带，模棱两可。不管你是多人标注也好，不管你是做量化指标也好，总很难有好的办法改变这一现状。

  有人可能会说，直接给阈值进行一刀切或两刀切，阈值交给客户来定。不过我们自己本身要想明白这个事情：不管是AI，还是人工，都会检出灰色地带。该场景存在这样的一种情况，那么说明其需求本应该可接受灰色地带的数据分错。

  标注测试集就很难做，例如甲方合同明确要给出准确率。该问题的存在，很难达到理想的指标。所以如果面临该场景，建议在统计指标上，给出明显漏、明显误等。不然会陷入“清洗数据”、“更改需求”、“重复试验”的死循环，无法解脱。

  能否给出对应的量化指标，也非常大的问题，比如明显的缺陷判分很低，微弱的缺陷置信度又很高。降低客户的期望也好，让客户理解AI判定过程也好，总之就是既然想让AI代替人工，我是可以做到。

  针对该场景，我们要做的是：易分样本（也就是明显缺陷和明显不是缺陷）不能出错，然后在漏检和误检的tradeoff寻求一个平衡。一般客户会有“直通率”这个概念，可以多次磨合，多次迭代，趋向用户期待。

  这点表现为类内差异过大。比如同样是划痕，表现形式各种各样，有的发白，有的发黑，有的吃视角，有的发生在边缘地带等等，出现在不同位置，表现形式都不一样。因此导致一个问题：你很难收集到全部形态的缺陷样本，所以在测试集上很难有一个不错的表现。也就是你的训练集和测试集存在的明显影响性能的偏差，这里的偏差不是标注导致的，而是数据本身导致的。这种情况是比较高频率能够遇到，比如和客户聊一个需求的时候，对于某一种缺陷，他会说比较大概率发生在A处，但是不能排除发生在另外的地方的概率。问题是目前很难收集到样本，即便收集到样本，也很难覆盖所有的情况。

  一般我们做一个任务，会有一份标准测试集，方便我们的方案、算法进行迭代。没有测试集，精度指标无从谈起。由于缺陷表现的多样性问题，我们的标准测试集可能就没那么的“标准”。实际数据集构建的过程中，尽量保证较大的覆盖率。多样性图片拿不到，但是“缺陷描述”还是能拿得到的。因此就需要结合一些正常样本学习和数据生成的方法来降低“多样性不够”带来的影响。

  ，是不平衡的，大量的都是正常样本，NG样本占比较小；每天会收集海量的图，有缺陷的比较少。

  ，缺陷占整体较小，例如500w相机拍摄图片，2500*2000pix尺度上，缺陷尺度可能小到10*10pix的水平。缺陷过小会带来一个严重问题。没办法进行resize（当然使用高分辨率的相机本意也是更精准的检测尺度小的缺陷）。导致的问题是：测试的时候，1是耗时，2是比较难控制误检的。例如siliding window检测，即便每一个patch预测准确率是99.9%，综合起来，性能直线下降的非常厉害。

  ，会存在某一类占比较大，有些缺陷占比较小。实践证明：只要有足够多的样本，即便是非常微弱的缺陷（这里的定义是肉眼可判别），网络也可以识别。应对方法很多，无外乎是数据生成、数据增强、过采样、loss上设计、训练策略上等等。

  数据脏就是标注的时候把标注类别搞错。搞错大家一般会认为是数据难分的原因，其实不然，数据难分，也就是标准难定或没办法清晰给出，因此这部分导致的原因不能单纯归纳为数据脏。但是这里为便于分析，我们区别对待。脏数据会对网络训练带来不利的影响，强行训练会有过拟合的风险。因为网络提取通用特征，拟合不到缺陷只能去拟合其他噪声了。不过也有说法是，脏数据作为噪声，也能给网络带来好的收益，让网络搜索参数的时候增加扰动，避免陷入局部最优，却能防止网络过拟合。不过一般任务：数据还是越干净越好。

  那就是数据清洗，例如交叉验证。学术上也有一些噪声样本学习的方案。数据脏还比较好办，归根到底是数据标注的问题。随着训练迭代以及人工清洗，能很好的改善这一情况。

  虽然是工业场景，数据会源源不断过来。但是上文提到数据的几大问题，例如样本不平衡等，所以有时我们会需要生成一部分的数据。还有一种情况，在项目初期，我们往往“打样”。所谓demo阶段，是拿不到足够多的数据的。另外，数据肯定是多多益善，如果我们有生成数据的巧妙方法，训练从中受益的话，也非常大程度上降低了数据收集、标注、清洗的成本。

  数据生成有传统方法和深度学习方法两种可用。传统办法能够进行一些图像融合，例如直接将缺陷裁剪下来到处贴，为了保证生成的逼真一点，还是需要一些融合的手段，例如泊松融合和边缘融合等。当然，有些场景，直接修改图片局部的灰度值也可以生成逼真的缺陷。我就单单利用修改图片的灰度和对比度就生成了很多以假乱真的图片。深度学习方法一般用GAN和VAE等生成模型可用，利用GAN可以直接从噪声生成数据，不过产生新的对网络训练有受益的信息比较有限。可以利用类似pix2pix的方案进行图片编辑。传统方法中的图片融合也可以利用GAN来做。

  前面主要说了场景和数据的一些东西，这里对比再看一下。场景是客观的，固有属性，你做与不做，它都在那里。

  数据是有主观的成分在里面：从其光学设计、标准执行等上来说，有很大人为因素。也是上文说的可控。具有很大的操作和设计空间。

  但是有时还要思考：值不值得做？可能是时间、成本、性价比、大规模推广等方面的原因。当然，大部分场景还是很容易做的，因为在工业领域，至少是受限的和可控的场景。关键要分清主要矛盾和次要矛盾。

  缺陷检测是整个系统工程，每个阶段都有不同的人参与，而算法工程师几乎要从头打到尾。

  这里重要要建设四种意识，要进行全员建设。从产品经理、光学工程、结构工程师、算法工程师、应用工程师、运维工程师，当然也包括决策者：

  如上图所示，我们能用到的深度学习算法积木很多，首先是分类、分割、检测三大任务，这是我们的主菜。当然还有一些别的方法，例如分类算法中有细粒度分类，可以更加精准的提取微弱的特征，细粒度算法一般会用到打乱和注意力机制，对纹理上的缺陷识别会更优一点。另外，应用语义分割任务做缺陷检测，其实缺陷检测并不局限语义分割，它更像提取一张高斯热图，有缺陷的地方概率高，背景区域概率低。因此有一些热图回归的做法也可以应用。除了监督方案，在应对缺陷样本少的场景，我们还可以选择无监督学习方案。

  当然，上面也说了，数据场景复杂，一致性问题难以保证。而且面临的数据量比较大，因此你还可以使用一些半监督、弱监督的手段来降低标注的工作量。

  任务拆分，可以降低算法的难度。多个结果进行分摊任务难度，另外不同阶段对数据的依赖不一样，多个阶段拆分更容易控制，尤其是在样本平衡方面。多个阶段对标的是端到端，可以做到精度方面的提升。

  语义分割容易扩展，可以输出最精准的逐像素特征，依赖样本更少（当然标注量比较大），非常适合来做缺陷检测任务。下面给出一些经常叫魔改也好，定制也好的特性。

  过采样：进行正负样本平衡，非常基础和常用的手段，经常使用crop的手段。

  动态平衡dataset：其实和过采样有异曲同工之妙，不过该方法是随着训练过程动态调整的，可以理解为作用在数据层面的难样本挖掘。

  标签平滑：语义分割标注是有偏差的，主要体现在边界上，所以能够直接进行标签平滑策略。

  众所周知，diceloss是语义分割，尤其是应对正负样本不平衡的一把利器。但是它也有一些槽点，因此必须整明白。下面提出diceloss十问，暂时不给出答案。之前也写过一个diceloss的深度解析，可以参考一下：

  分类是最简单的任务，当然缺陷检验测试可能会对它提出了更高的要求。例如下面这个方法

  很多技巧性的东西，都是通用的目标检测技巧，例如：尺度问题、形变问题等等；本文不再叙述。

  传统方法：（场景受限，需要调参数，可用于防呆，明显缺陷没问题，微弱缺陷效果不行）

  难点：整合散乱的工具，甚至完全交给用户。市面是有很多做自动训练软件的，例如比较知名的VIDI，国内也有AIDI、Alpha等。可能大家选择的模型不是非常先进，但是从标注到训练，再到模型导出，用户体验和跨平台做的比较好。工业场景，特定场景特定算法，工具做好，不必追求SOTA模型，SOTA模型只是提高了自然场景精度的上限，而我们需要把握模型的下限。

  所以缺陷检验测试不单单是一个算法模型的问题，而是整个系统工程。可能不需要非常前言的算法，但是需要成熟的工具链。即便是基础的算法、看似容易的场景，也能形成技术壁垒。如果想复刻，也没那么轻松。很多时候，不是不能做，而是值不值得做？