3. 缺陷数据分类与编码体系

在KLA检测数据分析中，缺陷分类与编码体系是连接“原始检测信号”与“制程异常诊断”的桥梁。KLA设备输出的缺陷记录通常包含坐标、尺寸、灰度、极性、层号等原始属性，但这些属性本身并不能直接回答“这是什么缺陷、由哪道工序引入、是否影响良率”。只有建立统一的分类标准、稳定的代码映射关系，并把属性提取为可计算的数据标签，后续的统计、聚类、根因分析和良率关联才有可靠基础。

一、KLA缺陷分类标准的三层结构

KLA检测系统（如Surfscan、SP系列、8系列等）在缺陷分类上通常遵循“检测类别—缺陷类型—缺陷子类”的三层结构。第一层是检测类别，描述缺陷被检出的物理机制，例如散射光异常、反射率变化、图形对比度差异、表面形貌突变等；第二层是缺陷类型，描述缺陷的形态与成因倾向，如颗粒、划伤、凹坑、凸起、残留、针孔、桥连、断线、膜层异常等；第三层是缺陷子类，用于进一步区分尺寸区间、极性、位置特征或工艺来源，例如“小尺寸颗粒”“边缘划伤”“金属层残留”等。

需要特别注意的是，KLA设备自带的分类结果（如Defect Class、Defect Code、Bin Code）是设备算法基于信号特征给出的“机器分类”，它并不等同于制程工程师最终使用的“工程分类”。机器分类偏向信号形态，工程分类偏向工艺成因。因此，在建立编码体系时，必须明确区分这两类标签，并保留映射关系，否则后续分析会出现“设备说这是颗粒，工艺说这是残留”的冲突。

二、缺陷代码映射：从设备码到工程码

缺陷代码映射的核心任务是建立一张可维护的映射表，把设备输出的原始代码（Raw Code）转换为工程分析使用的标准代码（Engineering Code）。映射表通常包含以下字段：设备型号、检测程式（Recipe）、原始代码、原始描述、工程代码、工程名称、所属类别、默认严重度、是否计入良率、备注。映射关系可以是一对一、一对多或多对一。例如，不同Recipe下的“Code 12”可能分别对应“表面颗粒”和“膜内颗粒”，此时必须结合Recipe和层号做联合映射。

在实际操作中，建议采用“版本化映射表”管理。每次Recipe变更、设备升级或新增缺陷类型时，不直接修改原表，而是新增版本号并记录生效日期。这样在回溯历史数据时，可以准确还原当时的分类口径，避免因映射表变更导致趋势图出现虚假跳变。

三、缺陷属性提取：把“描述”变成“字段”

属性提取的目标是把非结构化的缺陷描述转化为结构化字段。KLA数据中常见的可提取属性包括：缺陷尺寸（等效球径或长宽）、灰度对比度、极性（亮缺陷/暗缺陷）、所在层号、晶圆内坐标（极坐标或直角坐标）、距边缘距离、缺陷密度、聚集程度等。这些属性中，尺寸和位置是最具分析价值的两个维度。

尺寸分箱是属性提取的典型操作。例如，可按等效球径将颗粒分为“<0.1μm”“0.1–0.2μm”“0.2–0.5μm”“>0.5μm”四档。分箱边界应结合工艺节点的关键尺寸和良率敏感度确定，而不是随意划分。位置属性则通常转换为“中心区/边缘区/环状区/扇区”等空间标签，便于后续判断缺陷是随机分布还是与特定工艺位置相关。

极性判定同样重要。亮缺陷通常对应颗粒、凸起或残留，暗缺陷通常对应凹坑、针孔或缺失。但极性会受检测模式和基底材料影响，因此极性标签必须与Recipe绑定，不能跨Recipe直接比较。

四、数据标签化实战：从CSV到可分析表

假设我们拿到一份KLA Surfscan输出的缺陷CSV，字段包括：DefectID、X、Y、Size、Gray、Polarity、RawCode、Layer、Recipe、Lot、Wafer。目标是生成一张带工程标签的分析表。操作流程如下：

1. 加载与清洗：剔除坐标越界、Size为负、RawCode为空的记录；统一坐标单位（如将mm转为μm）。
2. 代码映射：按Recipe+Layer+RawCode三键关联映射表，生成EngCode和EngName。未命中映射的记录标记为“Unmapped”，单独统计。
3. 尺寸分箱：根据Size字段生成SizeBin标签，如“S1(<0.1)”“S2(0.1-0.2)”等。
4. 空间标签：计算缺陷到晶圆中心的归一化距离r/R，按阈值划分中心区（r/R<0.3）、中间区（0.3–0.7）、边缘区（>0.7）。
5. 严重度赋值：结合EngCode和SizeBin，按预设规则赋予Severity（Critical/Major/Minor）和KillFlag（是否计入良率）。
6. 输出：生成包含原始字段+工程标签的宽表，写入数据库或Parquet文件，供后续分析使用。

下面给出一个映射表与标签规则的示例片段，便于直接参考：

RawCode,Recipe,Layer,EngCode,EngName,Category,Severity,KillFlag
12,SCAN_A,1,PART_S,Particle_Small,Particle,Minor,N
12,SCAN_B,1,PART_F,Particle_Film,Particle,Major,Y
07,SCAN_A,2,SCR_E,Scratch_Edge,Scratch,Critical,Y
23,SCAN_A,3,REST_M,Residue_Metal,Residue,Major,Y
41,SCAN_B,2,PIN_H,Pinhole,Pinhole,Critical,Y

标签规则示例：若EngCode为SCR_E且Size>0.3μm，则Severity=Critical、KillFlag=Y；若EngCode为PART_S且Size<0.1μm，则Severity=Minor、KillFlag=N。规则应集中配置在规则表中，而不是散落在代码里，便于工艺工程师评审和调整。

五、常见问题与判断依据

在实际项目中，缺陷分类与编码体系最容易出现三类问题。第一类是“同码异义”，即同一个RawCode在不同Recipe下代表不同缺陷，若映射时未联合Recipe，会导致分类错误。第二类是“同义异码”，即同一类缺陷因设备灵敏度调整被拆成多个RawCode，若未做归并，会导致趋势图出现虚假波动。第三类是“标签漂移”，即映射表更新后未做版本记录，历史数据与当前数据口径不一致。

判断编码体系是否健康，可以观察三个指标：Unmapped比例是否稳定在低位、同一EngCode的尺寸分布是否合理、KillFlag为Y的缺陷是否与良率损失有统计相关性。若KillFlag为Y的缺陷数量与良率损失趋势明显背离，说明严重度规则需要重新校准。

缺陷分类与编码体系不是一次性建成的静态表，而是随工艺演进持续维护的数据资产。只有把分类标准、代码映射、属性提取和标签规则统一到可版本化、可审计的数据管道中，KLA检测数据才能真正支撑制程异常诊断，而不是停留在“看缺陷图”的层面。