企业官网建设流程全解析

1. 工业AI质检的冷启动困局：为什么“没有不良品样本”是常态而非意外

但凡在制造业产线上摸爬滚打过几年的人，大概率都听过或者亲身经历过这样一个场景：老板或者项目负责人拍板要上AI质检，目标很明确——用视觉算法替代人工目检，提升检出率、降低人力成本。项目启动会开得热火朝天，等到真正要动手训练模型的时候，问题来了：翻遍产线几个月的存图，良品图片几十万张，不良品图片可能连一百张都凑不齐，有些缺陷类型甚至一张都没有。

这不是个别现象，而是工业质检领域最普遍的冷启动难题。很多人第一反应是“那就多收集一些不良品图片呗”，但实际产线上的情况是：第一，有些缺陷本身就是小概率事件，良品率99.5%意味着每1000个产品里才5个不良品，你要攒够训练模型所需的最低样本量，可能要等几个月甚至半年；第二，有些缺陷一旦出现，产线会立刻停机调整，等你反应过来去拍照，不良品已经被处理掉了；第三，新产品导入阶段，连良品长什么样都还在摸索，更别提不良品了。

所以“没有不良品样本，怎么做AI质检”这个问题，本质上不是一个技术问题，而是一个工程策略问题。它考验的不是你会不会调参、会不会选backbone，而是你能不能在数据极度匮乏的条件下，用一套组合拳把模型从零到一地搭起来，并且让它真正在产线上跑起来、稳下来。

这篇文章面向的是正在或者即将面对这个问题的算法工程师、机器视觉从业者、制造业数字化转型的推动者，以及对这个领域感兴趣的技术管理者。我会从整体思路、核心技术方案、实操落地步骤、常见坑与排查技巧几个维度，把这件事掰开揉碎了讲清楚。不敢说看完就能直接上手干，但至少能让你少走几个月的弯路。

2. 整体方案设计：没有坏样本时，模型到底在学什么

2.1 核心思路转换：从“认识坏”到“认识好”

传统监督式分类或检测模型的逻辑是：给模型看大量良品和不良品的标注样本，让它学会区分两者的边界。这条路在没有不良品样本时显然走不通。但如果我们换一个角度想——模型不一定非要“认识坏”，它只需要“认识好”，然后对任何不像好的东西发出警报就行了。

这就是异常检测（Anomaly Detection）的核心思想。在工业质检场景下，我们把它叫做“缺陷检测的无监督范式”。模型在训练阶段只接触良品样本，学习良品的数据分布。推理阶段，任何偏离这个分布的输入都会被判定为异常。这个思路的好处非常直接：你不需要收集不良品样本，只需要足够多的良品样本就能启动。

但这里有一个关键前提需要说清楚：无监督异常检测假设“良品是高度一致的，不良品是偏离良品的”。如果你的产线本身波动就很大——光照不稳定、产品位置偏移、来料批次差异明显——那模型学到的“良品分布”会非常宽泛，导致真正的缺陷也被当成正常波动放过。所以选择这条路之前，先评估一下你的产线稳定性。

2.2 方案选型对比：三条路各自的适用边界

在实际项目中，面对“没有不良品样本”的约束，通常有三条技术路线可选，它们并不是互斥的，很多时候是组合使用。

我个人的经验是：优先走无监督异常检测路线做冷启动，同时并行推进合成缺陷增强，等产线跑一段时间积累了一定真实不良品样本后，再逐步过渡到半监督或少样本微调。这个渐进式策略的好处是，你不需要等数据齐了才开工，而是边跑边迭代。

2.3 为什么不能直接上大模型或者通用视觉API

有些朋友可能会想：现在多模态大模型这么强，直接拿通用视觉能力去判断产品好坏不就行了？这个想法在demo阶段可能看起来可行，但落到产线上基本行不通。原因有三：第一，通用模型没有见过你的产品，它不知道什么是“这个产品的正常状态”；第二，产线节拍要求推理时间通常在几十毫秒级别，大模型的推理成本根本扛不住；第三，工业场景对误报率和漏报率有严格的量化要求，通用模型无法给出可控的置信度阈值。

所以工业质检的AI方案，最终一定要落到针对具体产品、具体工位定制的轻量级模型上。无监督异常检测恰好满足这个需求：模型小、推理快、只需要良品数据就能训练。

3. 核心技术方案拆解：从良品数据到可用模型的完整链路

3.1 数据采集：良品样本的“质”比“量”更重要

很多人以为无监督方法对数据要求低，就随便拍几百张良品图丢进去训练。我踩过这个坑，结果就是模型在验证集上表现还行，一到产线上就疯狂误报。后来复盘发现，问题出在数据采集环节。

良品样本的采集有几个硬性要求。第一，覆盖所有正常波动。你的产线在一天之内可能经历光照变化（早晚光线不同）、产品位置微移、来料批次差异，这些“正常的变化”都必须出现在训练数据里，否则模型会把它们当成异常。第二，排除隐性缺陷。有些产品表面看起来是良品，但实际上存在微小的瑕疵，如果这些图片被当作良品训练，模型会学到错误的分布。建议采集时由经验丰富的质检员复核一遍。第三，数量不是越多越好。对于无监督异常检测，500到1000张高质量良品图通常就足够了，关键是多样性而非绝对数量。

实操中我通常这样操作：在产线稳定运行的一个完整班次内，每隔一段时间采集一批图片，覆盖早中晚不同时段、不同批次来料。采集完成后做一次去重和筛选，把明显模糊、过曝、欠曝的图片剔除。

3.2 图像预处理：让模型只关注“产品本身”

原始产线图片里包含大量与缺陷无关的信息：背景、夹具、传送带、光照不均。如果直接拿这些图去训练，模型会学到一堆无关特征。预处理的目标就是把这些干扰因素去掉，让模型聚焦在产品区域。

标准流程是这样的：首先做ROI裁剪，根据产品在图像中的固定位置，裁出只包含产品表面的区域。如果产品位置有偏移，可以用模板匹配或者简单的目标检测模型先定位产品。然后做光照归一化，常用的方法包括直方图均衡化、自适应直方图均衡化（CLAHE），或者更简单粗暴的——在采集阶段就把光照环境固定死。最后做尺寸统一，把所有图片缩放到模型输入尺寸，比如256x256或512x512。

注意：预处理阶段做的任何变换，在推理阶段必须完全一致地执行。我见过不止一个项目，训练时用了CLAHE，推理时忘了加，结果模型表现断崖式下降。

3.3 模型选择：PatchCore、PaDiM还是FastFlow

无监督异常检测领域这几年发展很快，工业场景下常用的模型有PatchCore、PaDiM、FastFlow、STPM等。它们各有特点，选择哪个取决于你的具体需求。

PatchCore的核心思路是用预训练CNN提取良品图片的特征，构建一个特征记忆库，推理时计算测试图片特征与记忆库的最近邻距离，距离超过阈值就判为异常。它的优势是不需要训练，直接拿预训练模型提特征就行，部署极快。缺点是推理时需要遍历记忆库，速度受记忆库大小影响。PaDiM则是用高斯分布建模每个位置的特征分布，推理时计算马氏距离。它比PatchCore快，但对齐要求更高。FastFlow用归一化流做密度估计，训练和推理都比较快，适合产线节拍要求高的场景。

我的建议是：如果项目周期紧、产线节拍要求不苛刻，优先用PatchCore快速验证可行性。如果验证通过但速度不够，再考虑换成FastFlow或者对PatchCore做记忆库压缩。

3.4 阈值设定：没有不良品样本，怎么定判定边界

这是无监督异常检测落地时最棘手的问题之一。模型输出的是一个异常分数，你需要定一个阈值来决定多少分以上算不良。没有不良品样本，就没法用传统的ROC曲线来选阈值。实践中我通常用以下几种方法组合确定：

第一种是统计法。假设良品图片的异常分数服从某种分布（通常是高斯分布或Gamma分布），取良品分数的99.5%分位数作为初始阈值。这意味着在良品上误报率大约0.5%。第二种是人工复核法。用初始阈值跑一批产线图片，把被判为异常的图片拿出来人工看，如果大部分确实是误报，就适当提高阈值；如果发现有些确实是缺陷但没被判出来，就降低阈值。第三种是合成缺陷验证法。在良品图上人工合成一些缺陷，看模型给这些合成缺陷打多少分，以此校准阈值的下限。

实际操作中，我会先用统计法给出一个初始值，然后产线试运行一周，每天收集误报和漏报情况，逐步微调。这个过程通常需要一到两周才能稳定下来。

4. 实操落地全流程：从零搭建一个可用的质检原型

4.1 环境搭建与依赖安装

先说一下我常用的技术栈：Python 3.9+、PyTorch 1.13+、OpenCV、scikit-learn、FAISS（用于PatchCore的最近邻搜索）。如果你用Anomalib这个开源库，很多模型已经封装好了，省去不少重复劳动。

# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate # 安装核心依赖 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install opencv-python scikit-learn faiss-cpu pip install anomalib # 可选，封装了多种异常检测模型

提示：如果你的产线工控机没有GPU，用CPU推理PatchCore也是可以的，只是速度会慢一些。512x512输入下，CPU单张推理大约200-500ms，看具体CPU性能。

4.2 数据准备与目录结构

Anomalib对数据目录有固定要求，我一般按下面的结构组织：

dataset/ ├── train/ │ └── good/ │ ├── 001.png │ ├── 002.png │ └── ... ├── validation/ │ └── good/ │ └── ... └── test/ ├── good/ │ └── ... └── defect/ └── ... # 如果有的话

训练集只放良品图，验证集也放良品图（用于确定阈值），测试集如果有不良品图就放进去评估，没有的话就只放良品图看误报率。

4.3 模型训练与阈值确定

以PatchCore为例，用Anomalib训练的核心代码如下：

from anomalib.data import Folder from anomalib.models import Patchcore from anomalib.engine import Engine # 数据模块 datamodule = Folder( root="dataset/", normal_dir="train/good", normal_test_dir="test/good", task="classification", image_size=(256, 256), ) # 模型 model = Patchcore( backbone="wide_resnet50_2", layers=["layer2", "layer3"], coreset_sampling_ratio=0.1, # 记忆库压缩比例 ) # 训练 engine = Engine(max_epochs=1) engine.fit(model=model, datamodule=datamodule) engine.test(model=model, datamodule=datamodule)

PatchCore的“训练”实际上只是构建特征记忆库，所以epoch设为1就够了。coreset_sampling_ratio控制记忆库的压缩比例，0.1表示保留10%的特征点，既能保证精度又能控制推理速度。这个参数需要根据你的数据量和精度要求调，我一般从0.1开始试，如果精度不够就提高到0.2或0.3。

训练完成后，用验证集上的良品图片计算异常分数分布，取99.5%分位数作为初始阈值：

import numpy as np # 假设 scores 是验证集所有良品图片的异常分数 threshold = np.percentile(scores, 99.5) print(f"初始阈值: {threshold:.4f}")

4.4 产线部署与推理服务

模型训练好之后，部署到产线上通常有两种方式：一种是直接集成到现有的视觉系统里，用Python调用模型做推理；另一种是封装成HTTP服务，产线PLC通过接口调用。我倾向于后者，因为解耦之后维护和更新都更方便。

from fastapi import FastAPI, UploadFile import cv2 import numpy as np app = FastAPI() @app.post("/predict") async def predict(file: UploadFile): img = cv2.imdecode(np.frombuffer(await file.read(), np.uint8), cv2.IMREAD_COLOR) # 预处理 img = preprocess(img) # 推理 score = model.predict(img) # 判定 is_defect = score > threshold return {"score": float(score), "is_defect": bool(is_defect)}

推理服务的响应时间要控制在产线节拍以内。如果单张推理超过节拍时间，可以考虑批量推理或者模型量化加速。

4.5 合成缺陷增强：让模型“见过”缺陷

虽然无监督方法不需要不良品样本，但如果你能合成一些缺陷图片，对模型调优和阈值校准都有帮助。合成缺陷的方法有很多，简单一点的可以用OpenCV在良品图上画随机形状、加噪声、做局部亮度变化；复杂一点的可以用GAN或者扩散模型生成更逼真的缺陷。

import cv2 import numpy as np def synthesize_defect(img, num_defects=3): """在良品图上合成随机缺陷""" h, w = img.shape[:2] result = img.copy() for _ in range(num_defects): # 随机位置 x = np.random.randint(0, w - 30) y = np.random.randint(0, h - 30) # 随机大小 rw = np.random.randint(10, 30) rh = np.random.randint(10, 30) # 随机颜色（模拟划痕、污点等） color = tuple(np.random.randint(0, 100, 3).tolist()) cv2.rectangle(result, (x, y), (x + rw, y + rh), color, -1) return result

合成缺陷的用途主要是：验证模型对缺陷的敏感度、辅助确定阈值下限、在缺少真实不良品时做初步的模型评估。但要注意，合成缺陷和真实缺陷之间存在域差距，不能完全依赖合成数据来评估模型性能。

5. 常见问题与排查技巧实录

5.1 误报率居高不下怎么办

这是无监督异常检测落地时最常见的抱怨。产线跑了一天，模型报了上百个异常，结果人工复核发现全是误报。遇到这种情况，按下面的顺序排查：

先看训练数据是否覆盖了所有正常波动。如果训练集只有白天的图片，晚上的光照变化就会被当成异常。解决办法是补充不同时段、不同批次的良品图片重新训练。再看预处理是否一致。训练和推理的预处理流程必须完全一致，任何差异都会导致误报。最后看阈值是否偏低。适当提高阈值可以降低误报，但要注意别把真正的缺陷也放过了。

5.2 漏报：模型对某些缺陷不敏感

漏报比误报更危险，因为不良品流出去了。如果发现模型对某类缺陷不敏感，首先确认这类缺陷在异常分数上是否确实偏低。如果是，说明模型学到的良品分布太宽泛，把这类缺陷也覆盖进去了。解决办法包括：收紧良品数据的采集标准（排除隐性缺陷）、增加合成缺陷样本做微调、或者针对这类缺陷单独训练一个检测模型。

5.3 产线环境变化导致模型失效

产线不是实验室，光照、温度、设备状态都在变化。我遇到过换了一批来料之后，模型误报率突然飙升的情况。排查后发现是新来料的表面纹理和之前有细微差异，模型把它当成了异常。这种问题的根本解法是建立模型持续迭代的机制：定期用新的良品数据更新记忆库，或者用产线积累的真实数据做增量训练。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是过度依赖合成缺陷。早期项目里我用合成缺陷做了大量调优，结果模型对合成缺陷很敏感，对真实缺陷反而反应迟钝。后来才明白，合成缺陷和真实缺陷的纹理、边缘、对比度都有差异，不能混为一谈。

第二个坑是忽略推理时的图像质量。训练时用的都是高清工业相机拍的图，推理时换了一个便宜相机，图像噪声大、对比度低，模型表现直接崩了。所以训练和推理的硬件条件要尽量一致。

第三个坑是阈值设完就不管了。产线运行一段时间后，设备磨损、来料变化都会导致数据分布漂移，固定阈值慢慢就不适用了。后来我加了一个自动监控机制，每周统计一次误报率和漏报率，超过阈值就触发告警，提醒更新模型。

6. 从冷启动到持续迭代：一条务实的落地路径

如果你现在正面对“没有不良品样本”的困境，我建议的落地路径是这样的：第一周，采集500-1000张高质量良品图，做好预处理，用PatchCore快速搭一个原型，确定初始阈值。第二到四周，产线试运行，每天收集误报和漏报案例，人工复核后微调阈值和预处理参数。第二个月开始，如果积累了少量真实不良品样本，用它们做少样本微调，或者训练一个专门的缺陷分类器做二级判定。第三个月之后，建立定期更新机制，每月用新数据更新一次记忆库或做增量训练。

这条路走下来，你会发现最大的挑战不是算法本身，而是数据工程和产线配合。算法方案是成熟的，开源工具是现成的，真正花时间的是跟产线沟通采集数据、跟质检员确认判定标准、跟设备工程师协调相机和光照。这些事没有捷径，只能一步一步来。

最后分享一个小技巧：如果你实在连良品样本都很少，可以考虑用预训练模型的特征提取能力做零样本异常检测。比如用CLIP这类视觉语言模型，通过文本描述“正常产品”和“缺陷产品”来做分类。这个方法精度不如专门训练的模型，但在项目极早期用来验证可行性是够用的。等验证通过再投入资源采集数据、训练专用模型，风险会小很多。