半导体数据清洗：十种脏数据形态怎么识别

2026-07-29 发布 | 数据工程

半导体工厂数据海量但藏着大量脏数据：传感器漂移、通信平线、单位错乱、缺失重复、标签错配、异常跳变。脏数据直接喂给模型，结论就是错的，轻则白分析，重则把好工艺改坏。这篇拆开十种最常见的脏数据形态，讲清每种长什么样、怎么识别、怎么处置，并给出一套可落地的清洗纪律和规则库思路，都是一线踩坑踩出来的实战经验。

一、脏数据为什么是半导体分析的隐形炸弹

半导体工厂每天产生海量数据，机台参数、量测结果、良率、缺陷，每秒都在涌。但数据不是拿来就能用的，里面混着大量脏数据：传感器飘了、通信丢了、人为录错了、单位弄混了。这些脏数据如果不清，直接喂给分析模型，结论就是错的，轻则白分析，重则误导工艺调整，把好工艺改坏。我见过因为一组温度单位错标，把正常工艺判成异常，白折腾一周。

很多人重视模型和算法，轻视数据清洗，觉得清洗是体力活。其实在半导体数据分析里，清洗往往占七成工作量，模型只占三成。数据质量决定天花板，模型只是逼近这个天花板。脏数据进去，再好的模型也出不来好结果。这句我反复跟团队讲，但总有人忍不住跳过清洗直奔建模，然后被错误结论打脸。

更麻烦的是，半导体数据的脏有行业特色。它不是简单的空值缺失，而是各种奇形怪状：通信中断造成的长段平线、传感器漂移造成的缓慢偏移、单位混用造成的量级错乱、批次混线造成的标签错配。这些问题通用数据清洗教程很少讲，得结合半导体场景才认得出来。这篇就把十种最常见的脏数据形态拆开，帮你建立半导体专属的清洗直觉。

还有一点，清洗不是越干净越好，过度清洗会删掉真实信号。比如一批片因为工艺调整确实参数变了，如果你当成异常全清掉，就丢掉了工艺变更的信息。所以清洗要讲分寸，区分真异常和真变化。我吃过过度清洗的亏，把一次成功的工艺改进当成脏数据清了，后来复盘才发现删掉的是金子。分寸感是清洗的最高境界，需要业务理解。

最后说个现实：清洗没有银弹，得因地制宜。不同机台、不同参数、不同产线，脏的形态不一样，清洗规则不能一套通吃。我建议每条线建自己的清洗规则库，沉淀常见脏形态和处理办法，新人照着做，老人在此基础上调。这套规则库比任何通用工具都值钱，因为它装着这条线的经验和教训，是真正的数据资产。

二、形态一：传感器漂移与平线

传感器用久了会漂移，读数慢慢偏高或偏低，不是突然坏，是慢慢偏。这种脏数据最隐蔽，因为数值还在合理范围，只是系统性偏移，单看一个点发现不了，得看趋势才看出缓缓上移或下移。我遇到过一台温度传感器的读数每月偏高零点几度，半年后偏了三度，期间所有基于温度的分析都带了系统误差，良率异常查了很久才定位到传感器。

另一种是通信中断造成的长段平线。机台通信闪断，数据采集中断，系统用最后一个值填充，于是出现一长段完全相同的平线，看着像工艺特别稳，实际是没数据。这种平线一眼能认，但容易被当成正常稳态忽略。我的处理是检测连续相同值超过阈值就标记为缺失，而不是当真实值用，否则均值方差全被污染。

对策上，漂移用滑动窗口的偏差检测，比如本周读数和上周同工况比偏了多少，超阈值就预警校准。平线用连续相同值检测和相邻点跳变检测，发现长平线就置空。这两种都得结合工况，不能脱离上下文判。我建的规则库里，漂移和平线是最高频的两类，处理好了能挡掉一半的脏数据，所以放在最前面讲。

还有一个相关形态叫卡值，传感器卡在某个固定值不动，和平线类似但更极端，通常是传感器彻底坏了。卡值比漂移好认，因为完全不动，但危害一样大。我的经验是，任何参数如果出现连续完全相同的长段，先当卡值或平线处理，置空并报警，让设备工程师去查传感器，而不是当成真实稳态喂给模型，这是基本原则。

补充一个坑：漂移有时候和工艺真变化长得很像。比如工艺真调整了温度设定，读数和漂移都表现为缓慢变化。区分要靠变更记录，有变更单的就是真变化，没有的就是漂移。所以清洗一定要和变更管理系统打通，不能孤立看数据。我们吃过没打通的亏，把一次成功升温当成传感器漂移清了，后来工艺工程师追过来才知道错了，数据和分析的联动太重要。

三、形态二：单位与量级的错乱

单位混用是半导体数据里特别坑的一类。同一参数，不同机台、不同时期可能用不同单位，温度是摄氏度还是华氏度，压力是帕还是托，厚度是纳米还是微米。如果清洗时没统一，直接拼到一起，数值就差出量级，模型一看这参数方差巨大，要么报错要么学出歪理。我见过把华氏度和摄氏度混算，温度分布横跨负几十到正几百，分析全废。

量级错乱还有一种是小数位数错，比如本该是零点几的数值录成了几十，差了一百倍。这种通常是人为录入或接口转换时的小数点错误。检测办法是看该参数的历史分布，突然出现一个偏离主分布一百倍的点，八成是小数点错了。我的规则是对每个参数设合理范围，超范围就标记人工确认，不让它悄悄混进数据集。

对策上，最重要的是建单位字典，每个参数固定单位和量级，入库前统一转换。不同源的数据进来先过单位校验，不符就转换或报警。这步看着简单，但能挡掉大量低级错误。我们早期没做，数据乱得没法用，后来花了大力气建字典、写转换，数据才干净。这活儿前期累，后期省心，值得早点做，别等脏数据堆成山再收拾。

还有一个隐蔽的单位坑：同一参数不同版本的系统用了不同精度。比如老系统存整数，新系统存小数，拼数据时整数那批看着像量级小，其实是精度低。这种不是真错，但会影响分析。处理是统一精度，老数据补零或标注低精度，别和高质量数据混为一谈。细节决定数据能不能用，这类精度问题新手最容易忽略，导致模型对老数据不信任。

给团队的建议：单位字典要有人维护，新参数进来先定义单位再采数，别先采了再补。我们有过新机台上线，参数单位没定义清楚，采了三个月才发现一半单位错，回头改历史数据改到崩溃。所以单位管理要前置到数据采集设计阶段，而不是事后擦屁股。数据治理的功夫在事前，不在事后，这是用惨痛教训换来的认知。

四、形态三：缺失、重复与标签错配

缺失是最直观的脏数据，参数该有值却没有。缺失分两种，随机缺失和块状缺失。随机缺失可能是偶发采集失败，块状缺失往往是通信或存储故障，一长段都没了。处理上，随机缺失可以插值或标记，块状缺失超过一定比例整段作废更稳妥，插值补出来的假数据比缺失更危险，因为假数据会误导分析还不容易发现。

重复是另一类，同一批片的数据被采了两次，或者接口重发导致重复记录。重复会让统计偏向重复的那部分，均值方差都失真。检测靠主键或时间戳去重，同一批次同一时间戳只留一条。我见过接口抖动导致一批数据重复了五遍，良率算出来虚高，汇报上去被领导识破，场面很难看，从此我们把去重当成入库必检项。

标签错配最坑，数据本身没问题，但归属错了。比如批次号和机台对不上，或者良率标签贴错了片。这种脏数据单看数值正常，但关联分析时全错。检测靠交叉校验，比如批次号和该批次应有的产品类型、工艺路线对不上就报警。标签错配我遇到过一次，把A产品的良率算到B产品头上，误导了B产品的工艺调整，事后复盘才查清，代价不小。

这三类里，缺失和重复相对好处理，有成熟方法。标签错配最难，因为得靠业务规则交叉验证，没有规则就发现不了。我的做法是建一批交叉校验规则，比如批次存在性、机台-产品匹配、时间合理性，入库前逐条过。规则越全，标签错配抓得越干净。这套校验我们持续积累，现在能挡掉绝大多数错配，数据可信度上了一个台阶。

补充一个实战经验：块状缺失别急着补。有次一块区域通信断了八小时，数据全缺，接口恢复后自动补了插值，看着完整，实则八小时是假的。后来分析那段时间工艺，结论全错。从那以后，块状缺失超过阈值整段作废并标注，宁可数据少一段，也不要假一段。缺失是诚实的空，假数据是诚实的错，后者更毒，这条原则我要求团队牢记。

五、形态四：异常跳变与量测噪声

异常跳变是参数突然从一个值跳到另一个值，然后又回来，像尖刺。成因可能是通信干扰、瞬时干扰、或者量测设备偶发故障。单看跳变点像真异常，但前后都正常，大概率不是工艺真跳。处理上用相邻点差分检测，跳变超过阈值就标记，结合前后趋势判断是干扰还是真异常，真异常保留并报警，干扰就平滑或置空。

量测噪声是另一种，数据在正常值附近小幅乱抖，不是大跳，是持续的细抖。这种不致命但会掩盖真实趋势，尤其做微小工艺偏移分析时，噪声会盖过信号。处理用滑动平均或滤波，但滤波会丢细节，得权衡。我一般对噪声大的参数做轻度滤波，保留趋势去掉毛刺，关键参数保留原始值另存，分析时按需取用，不轻易覆盖原始数据。

这两种的处理关键是别误杀真信号。工艺调整时参数本来就会跳，那是真跳不是干扰。区分靠变更记录和上下文：有变更单的跳变是计划内，没有的才疑似干扰。我要求清洗规则和变更管理系统联动，看到跳变先查有没有变更，有就保留，没有再当干扰处理。脱离业务上下文的清洗都是瞎清，要么误杀要么漏网，这是最核心的原则。

还有一个相关形态叫离群点，数值明显偏离群体但不一定是错。比如一批片里有一颗特别差，是真差不是脏。这种不能一刀切删，要区分离群是因为数据错误还是真异常。我的做法是离群点保留并单独标记，交给分析环节判断是否纳入，清洗阶段只标记不删，删的权限留给业务判断。清洗的边界是修错误，不是替业务做决策，这条界线要守住。

给新人的建议：跳变和噪声处理要保守，宁可少清不要错清。我见过新手为了数据好看，把一堆跳变全平滑掉，结果把一次真实的设备异常也抹了，漏报了故障。清洗的目标是修数据错误，不是美化数据。任何处理都要可回溯，原始数据留底，处理步骤留痕，出了问题能复盘。保守、可回溯，是清洗的两大纪律，比技巧更重要。

六、落地清单与避坑总结

十种形态我拆成了四类讲：漂移平线、单位量级、缺失重复标签、跳变噪声。实际工作里，我建议建一张清洗规则库，每类对应几条检测规则和处置动作，新数据进来逐类过。规则库要持续积累，每遇到新脏形态就补一条，半年下来就是一条线最值钱的经验资产。别指望一次写全，边做边补才是正道，这也是数据治理的常态。

避坑第一条：清洗要结合业务上下文，脱离上下文的通用清洗会误杀真信号。第二条：保守处理，能标记的不删，删的权限留给业务。第三条：原始数据留底，处理可回溯。第四条：单位字典前置到采集设计。第五条：清洗规则和变更管理、标签系统联动。这五条是我踩遍坑总结的，照着做能避开八成清洗事故，建议你抄下来贴在工位。

最后说个心法：数据清洗是数据分析的地基，地基不牢，上面再漂亮的分析也站不住。我带团队有个铁律，任何分析结论交付前，必须先过清洗审查，说明数据怎么清的、清了什么、为什么。说不清清洗过程的结论，一律不采信。这条铁律帮我们挡掉无数错误结论，也倒逼大家重视清洗。把清洗当正经工程，而不是体力活，你的分析才立得住。

关于工具，没必要一上来就上复杂平台。我早期用脚本加规则库就解决了大部分问题，关键不是工具多先进，是规则库有没有积累。等数据量和复杂度上来了，再上专业的数据质量平台。工具是放大器，规则库是内核，内核空了工具再好也白搭。所以新人别迷信工具，先把常见脏形态和处置办法装在脑子里、写进规则库，这才是真本事。

收个尾：半导体数据的脏有行业特色，通用教程教不会，得在一线踩了坑才长记性。这篇把十种形态拆开，是希望你少踩几个。但纸上得来终觉浅，真正的能力是你在自己产线上把这套用起来、把规则库建起来。下次数据出问题，别急着跑模型，先问一句：这数据干净吗？这一问，能救你无数个加班的夜晚。

写在最后

你们产线最常被哪种脏数据坑过？清洗时踩过最离谱的坑是什么？评论区聊聊，我整理一份半导体数据清洗避坑清单。