1. 误检漏检治理的工程认知

在MVTec HALCON视觉项目中，检测系统上线后最常被产线投诉的问题往往不是“算法跑不起来”，而是“判得不对”。判得不对又分为两个方向：把好品判成坏品，把坏品判成好品。前者影响产能与成本，后者影响客户与品牌。要治理这两类问题，第一步不是调算子、改参数，而是把概念边界划清楚，否则团队会在“到底算不算误检”的争论中消耗掉大量时间。

一、四个核心概念的定义边界

在工业视觉语境下，通常用四个词描述判定结果与真实状态的偏差：误检、漏检、过杀、欠杀。它们并非同义词，而是从两个不同维度切分出来的。

• 误检（False Positive，FP）：真实为良品（OK），系统判为不良（NG）。这是从“系统输出”角度定义的错误。
• 漏检（False Negative，FN）：真实为不良（NG），系统判为良品（OK）。这是最危险的一类错误，不良品会流向客户。
• 过杀（Overkill）：站在产线良率角度，指系统把本可接受的工件判为NG，导致良品被丢弃或返工。过杀在数值上通常与误检高度重叠，但过杀更强调“业务后果”——良率损失。
• 欠杀（Underkill）：指系统对明显缺陷未做出NG判定，缺陷品被放行。欠杀与漏检在多数场景下等价，但欠杀更强调“质量门失守”的严重性。

需要特别说明的是：误检与过杀、漏检与欠杀，在混淆矩阵的计数上往往一致，但它们的治理视角不同。误检/漏检是算法指标视角，过杀/欠杀是产线业务视角。同一个FP，对算法工程师是“误检率”，对生产主管是“过杀率”，对质量经理是“良率损失”。治理时必须先统一口径，否则会出现“算法说误检率2%，产线说过杀率5%”的扯皮。

二、业务代价与质量指标

两类错误的代价并不对称。漏检/欠杀的代价通常是外部失效成本：客户退货、索赔、停线、品牌受损，甚至安全事故。误检/过杀的代价是内部效率成本：良品报废、返工工时、复检人力、产能下降。在多数项目中，漏检的代价远高于误检，因此治理优先级通常是“先压漏检，再控误检”。

但也不能一概而论。例如在3C外观件检测中，若过杀率过高导致每天报废上千件良品，其成本可能超过偶发的漏检。因此需要引入量化指标：

其中C_FP和C_FN是单件代价权重。这个加权代价公式是治理优先级的量化依据：当C_FN远大于C_FP时，阈值应偏向保守（宁可过杀）；当C_FP代价更高时，阈值可适当放宽。HALCON中通过set_threshold、set_grayval或分类器得分阈值调整，本质上就是在移动这个权衡点。

三、治理优先级与工程判断

治理不是“把两个指标都降到零”，而是在可接受的代价下找到平衡点。工程上通常按以下顺序推进：

1. 先保安全底线：确保漏检率低于客户或行业强制要求（如汽车件常要求FNR<0.1%）。
2. 再压过杀成本：在漏检达标的前提下，逐步放宽阈值或优化特征，降低过杀。
3. 最后做稳定性：关注批次波动、光照漂移、物料差异带来的指标漂移，避免“今天达标、明天超标”。

这里有一个容易被忽视的点：误检和漏检往往此消彼长。降低阈值会让更多可疑区域被判NG，漏检下降但过杀上升；提高阈值则相反。因此治理的本质是在ROC曲线上选工作点，而不是单方面追求某一指标最优。HALCON提供的classify_image_class_mlp、classify_image_class_svm等分类器，以及threshold、dyn_threshold等分割算子，其参数调整都会改变工作点位置。

四、从概念到治理动作

把上述认知落到HALCON工程实践中，治理动作可以归纳为三步。第一步是建立可复现的评估集：收集至少包含数百张良品与不良品的图像，标注真实标签，用read_image批量读入，用count_obj统计数量，确保评估集覆盖不同批次、光照和物料。第二步是量化当前工作点：用classify_image_class_mlp或threshold得到判定结果，与真实标签比对，计算FP、FN、TP、TN，进而得到FPR、FNR、过杀率、欠杀率。第三步是按代价调参：若漏检超标，降低判定阈值或增强特征；若过杀超标，提高阈值或引入更精细的ROI。

最后需要强调：误检漏检治理不是一次性任务，而是伴随产线生命周期的持续过程。物料更换、光源老化、相机偏移都会让原本达标的工作点漂移。因此建议在HALCON程序中加入定期自检逻辑，例如每班次用标准件跑一遍，记录判定结果，一旦FPR或FNR超出阈值就触发报警。这样，治理才从“救火”变成“预防”。