当前位置：首页 > Python 工业工具 > 正文内容

[公开] Python实现帕累托分析：80/20法则落地

【摘要】帕累托分析人人会画，但在Fab里做出能指导决策的帕累托图并不容易：口径不统一、权重选错、分层缺失，都会把改善资源引向错误方向。本文给出一套可复用的Python帕累托分析模块，涵盖数据字典规范、损失金额加权、分层下钻与置信区间判定，并附完整代码与一次真实良率攻关的应用记录。

分类：数据工具 | 发布日期：2026-08-15 | 栏目：半导体智能制造实战

一、背景故事：一张画错的帕累托图，让半年的改善资源打了水漂

这件事发生在我入行第三年。当时部门要定下一年度的良率改善重点，数据组用一周时间把全年的缺陷记录拉出来，做了一张很漂亮的帕累托图。排在第一位的是"光阻残留"，缺陷片数遥遥领先，第二位是"颗粒污染"。会上很快就定了方向：集中兵力打光阻残留，成立专项组，配了三个人和一台专用的量测机时。

半年后复盘，光阻残留的缺陷片数确实从每季两千一百片降到了八百片，按项目目标算完成得漂亮，专项组还拿了季度改善奖。但让所有人尴尬的是，工厂整体的良率损失金额几乎没有变化，财务那边给出的数字甚至略有恶化。这个结果当时没人能解释，直到一位从别的厂调过来的资深工程师看了原始数据，问了一句：你们这张图，是按片数排的还是按钱排的？

答案是按片数。而光阻残留这类缺陷绝大多数发生在低阶产品上，单个裸片价值低，而且大部分可以通过返工挽救，真实损失金额并不高。与此同时，排在后面的"套刻偏移"虽然发生频次不高，但集中出现在两款高价值的新产品上，一旦出问题整批无法返工，单批损失是光阻残留的十几倍。把这批数据按金额重新加权之后，排序完全变了，第一名换成了套刻偏移。

这件事给我的教训很深：帕累托分析的技术门槛几乎为零，几行代码就能画出来，但它的工程价值完全取决于输入口径是否正确、权重是否反映真实优先级、以及有没有做必要的分层。本文要写的不是怎么画这张图，而是怎么把它做成一个能真正指导资源分配的工程化模块。

二、技术原理：帕累托原则的统计基础与适用边界

帕累托原则来源于经济学家帕累托对财富分布的观察，其数学形式是幂律分布。在制造业质量领域，Juran把它总结为"关键的少数与次要的多数"，意思是少数几类原因贡献了大部分损失。需要强调的是，八十二十只是一个经验性的近似，真实数据中可能是七十三十，也可能是九十五十，关键不是比例本身，而是分布是否足够陡峭到值得做集中投入。

判断分布陡峭程度有一个实用的量化方法，就是计算基尼系数或者直接看累计曲线的形状。如果前百分之二十的类别贡献了超过百分之六十的损失，集中投入的策略是划算的；如果最大的一项也只占百分之十五，说明问题分散，此时更适合做系统性的通用改善（比如提升整体洁净度或者加严来料管控），而不是逐个攻关。我们在做季度规划时会先算这个指标，再决定用哪种策略，避免盲目套用帕累托。

第二个原理层面的要点是权重选择。帕累托图的纵轴可以是频次、影响片数、损失金额、停机时长或者客诉数量，不同的权重会给出不同的排序。正确的做法是让权重与决策目标一致：如果目标是降低成本，就用金额；如果目标是提升准时交付率，就用停机时长或者延误批次数；如果目标是降低客诉，就用逃逸到客户端的缺陷数。一张图只服务一个决策目标，不要指望用一张图回答所有问题。

第三个要点是分层。未经分层的帕累托图只能告诉你"哪一类问题大"，不能告诉你"从哪里下手"。同样是颗粒污染，如果集中在两台机台上，解法是设备维护；如果均匀分布在所有机台上，解法可能是厂务的洁净度或者来料。实践中我们的规矩是：任何进入Top3的问题，必须至少沿机台、班次、产品、时间四个维度各做一次下钻，找到集中度最高的那个切面，才允许立项。

最后一个容易被忽视的原理是统计显著性。当某个类别的样本量很小时，它在图上的位置有很大的随机性。我们的做法是给每个类别计算一个基于泊松分布的置信区间，如果第一名和第二名的区间重叠严重，就说明这两项在统计上无法区分，此时应该并列处理而不是强行排序，或者继续收集数据再做判断。

三、现状分析：Fab里帕累托分析的四种典型错误用法

第一种错误是口径漂移。同一个缺陷代码，不同工序、不同系统的定义可能不一致。我们遇到过一个真实案例：光刻工序把"套刻超规"记为缺陷，而后段的电测工序把同一批次的失效记为"电性开路"，同一个物理问题在数据库里被记了两次，帕累托图上两个条形柱其实是同一件事。解决办法是建立缺陷代码字典并强制入库校验，这也是表1那份数据字典存在的原因。

第二种错误是用错聚合层级。有的分析把整片晶圆当作最小单位，一片上有一个坏点和有五百个坏点被记为同样的一次。在良率语境下正确的单位应该是受影响裸片数，否则会系统性低估那些集中爆发型的缺陷。我们改用裸片级统计之后，颗粒污染的排位上升了两位。

第三种错误是时间窗口选择随意。有人拿一个月的数据做年度规划，有人拿两年的数据做本月决策。窗口太短会被偶发事件主导，窗口太长则会把已经解决的老问题混进来。我们现在的规则是：季度规划用最近两个季度的数据并对最近一个季度加权一点五倍，月度攻关用最近八周滚动数据，两者分开维护，不互相借用。

第四种错误是画完就结束。很多团队把帕累托图做成了报告里的一页配图，看完就归档，没有后续的分层、立项、跟踪和复盘闭环。一张没有关联到具体行动项和责任人的帕累托图，价值等于零。我们后来在模块里直接输出一份"待立项清单"，包含问题项、分层结论、建议责任部门和预估收益，把分析和行动强制绑在一起。

四、瓶颈问题：从"能画图"到"能决策"之间的三道坎

第一道坎是数据质量。绝大多数Fab的缺陷数据都存在缺失、重复和标签错误，直接拉出来跑分析，结果不可信。我们的处理流程是先做三项校验：主键唯一性校验（同一批次同一工序同一缺陷代码不允许重复记录）、数值合理性校验（受影响裸片数不得超过该产品单片总die数）、以及字典完整性校验（缺陷代码必须存在于字典表中）。这三项校验在我们厂平均会拦下百分之四到百分之七的记录，这些记录不是删除而是进入待处理队列由品质工程师人工确认。

第二道坎是成本口径。把缺陷折算成金额需要单die成本，而这个数字财务每季度更新一次，且分产品、分阶段（在制品成本与成品成本不同）。如果分析脚本里写死一个常数，跨季度对比时就会出现假信号。我们的做法是把成本表做成一张独立的维度表，按产品与生效日期做区间关联，任何一条缺陷记录都按其检出时间匹配当时有效的成本版本，这样历史分析结果可以复现，不会因为成本更新而变化。

第三道坎是组织接受度。帕累托图会明确指出"哪个部门的问题最大"，这天然带有一定的对抗性。第一次把按金额加权的图放到联席会上时，光刻组的反应相当强烈，认为统计方式对他们不公平。后来我们做了两个调整：一是在图上同时标注问题的可控性评级（分为完全可控、部分可控、依赖外部三档），二是把责任分派改成"主责加协办"的形式而不是单一归属。这两个调整让数据从"问责工具"变成了"资源分配工具"，阻力小了很多。

五、解决方案：一个可复用的Python帕累托分析模块

模块的设计目标是：输入一张规范化的缺陷记录表，输出帕累托图、分层下钻结果和待立项清单三样东西，并且所有参数（权重字段、时间窗口、分层维度、置信水平）都可配置。一切的前提是输入表的字段口径必须统一，下面这份数据字典是我们厂实际执行的版本，任何接入这个模块的数据源都必须先满足它。

表1：帕累托分析输入数据字典规范（本厂良率系统实际执行版）

数据字典落地之后，下面给出核心实现，代码经过脱敏但结构与我们生产环境使用的版本一致。

import pandas as pd

import numpy as np

from scipy import stats

REQUIRED_COLS = ["lot_id", "defect_code", "affected_die",

"loss_amount", "stage", "detect_time"]

def validate(df, die_per_wafer_map, code_dict):

"""三项入口校验：返回清洗后数据与被拦截记录"""

miss = [c for c in REQUIRED_COLS if c not in df.columns]

if miss:

raise ValueError("缺少必需字段: %s" % miss)

rejected = []

# 校验一：主键唯一性

key = ["lot_id", "stage", "defect_code"]

dup = df.duplicated(subset=key, keep=False)

rejected.append(df[dup].assign(reject_reason="主键重复"))

# 校验二：数值合理性

cap = df["lot_id"].map(die_per_wafer_map).fillna(np.inf)

bad = df["affected_die"] > cap

rejected.append(df[bad].assign(reject_reason="受影响die超过总die数"))

# 校验三：字典完整性

unknown = ~df["defect_code"].isin(code_dict)

rejected.append(df[unknown].assign(reject_reason="缺陷代码不在字典"))

mask = ~(dup | bad | unknown)

return df[mask].copy(), pd.concat(rejected).drop_duplicates()

校验通过之后进入聚合与加权环节。这里的关键是把权重字段做成参数，而不是写死成金额或者片数，这样同一个模块可以同时服务成本、交期、客诉三类决策目标。同时输出累计占比和基于泊松分布的置信区间，供后续判断排序是否稳健。

def pareto(df, value_col="loss_amount", group_col="defect_code",

conf=0.95, recent_weight=None):

"""核心帕累托聚合，支持近期加权与置信区间"""

d = df.copy()

if recent_weight:

cut, factor = recent_weight # 如 ("2026-04-01", 1.5)

w = np.where(d["detect_time"] >= pd.Timestamp(cut), factor, 1.0)

d["_w"] = d[value_col] * w

else:

d["_w"] = d[value_col]

g = d.groupby(group_col)["_w"].agg(["sum", "count"])

g = g.sort_values("sum", ascending=False)

g["ratio"] = g["sum"] / g["sum"].sum() * 100

g["cum_ratio"] = g["ratio"].cumsum()

# 泊松置信区间，用于判断相邻排名是否可区分

lo, hi = [], []

for n in g["count"]:

a = stats.chi2.ppf((1 - conf) / 2, 2 * n) / 2 if n > 0 else 0

b = stats.chi2.ppf(1 - (1 - conf) / 2, 2 * n + 2) / 2

lo.append(a); hi.append(b)

g["ci_low"], g["ci_high"] = lo, hi

g["vital_few"] = g["cum_ratio"] <= 80

return g.reset_index()

第三部分是分层下钻。对进入关键少数的每一个问题项，沿指定的多个维度分别计算集中度，用赫芬达尔指数衡量分布是否集中。指数越接近一说明越集中在少数几个切面上，越接近零说明分布均匀。我们把阈值定在零点三，超过这个值就认为该维度是有效的下钻方向。

def drill_down(df, top_codes, dims=("tool_id", "shift", "product", "week"),

value_col="loss_amount", hhi_threshold=0.30):

"""对Top问题逐维度下钻，输出集中度最高的切面"""

out = []

for code in top_codes:

sub = df[df["defect_code"] == code]

for dim in dims:

if dim not in sub.columns:

continue

s = sub.groupby(dim)[value_col].sum()

share = s / s.sum()

hhi = float((share ** 2).sum())

top_key = share.idxmax()

out.append({

"defect_code": code, "dim": dim, "hhi": round(hhi, 3),

"top_slice": top_key,

"top_share": round(float(share.max()) * 100, 1),

"actionable": hhi >= hhi_threshold,

})

res = pd.DataFrame(out)

return res.sort_values(["defect_code", "hhi"], ascending=[True, False])

最后一步是输出待立项清单。这一步没有复杂算法，但它是整个模块最有价值的部分：它把"分析结果"翻译成"谁在什么时间之前要做什么、怎么验证"。我们要求清单里的每一行都必须有可量化的验证方式，不接受"加强管理"、"提高重视"这类无法验证的表述，这条规矩是从前面提到的那次失败教训里总结出来的。

六、实战案例：用这套模块重做一次季度良率规划

我们用这个模块重做了2026年第一季度的良率规划。输入是全季度共一万四千余条缺陷记录，经过三项校验拦下了六百三十七条（占百分之四点五），其中主键重复三百一十二条，主要来自重工批次的重复记录；受影响die数异常九十八条，追查后发现是一台缺陷检查机台的坐标映射配置错误；缺陷代码不在字典两百二十七条，是新工艺引入后品质部门未及时更新字典。仅仅是这一步数据校验，就暴露了两个此前完全不知道的系统性问题。

图1：金额加权的帕累托图。前三项累计占比约百分之七十四，是本季度改善资源投放的主战场；注意这个排序与按缺陷片数排序的结果并不相同，后文会详细说明差异原因。

按金额加权跑出来的结果就是本文图1。前三位是颗粒污染、套刻偏移和膜厚超规，累计占比百分之七十四。对比按片数排序的结果（图2），光阻残留从第三位掉到第六位，套刻偏移从第五位升到第二位，这个差异如果不做金额加权是完全看不到的，而它直接决定了三个人半年的工作方向。

图2：同一批数据在两种口径下的排序对比。光阻残留按片数排第三，按金额只排第六；套刻偏移则相反。用错口径会直接导致改善资源投向价值较低的问题。

接着对Top3做四维下钻，结果整理成表2。颗粒污染在机台维度的赫芬达尔指数达到零点四七，集中在Etch-05和Etch-09两台上，这两台的共同点是都在去年做过腔体大修；在班次维度指数为零点三三，夜班占比偏高，进一步查发现夜班的PM后首件确认是单人操作。套刻偏移在产品维度指数零点五二，集中在两款新产品上；在时间维度呈现明显的锯齿形态，每次机台校正后前八小时偏移量偏大，这个发现完全来自下钻，在总图上看不出任何端倪。

表2：分层下钻结果与改善责任分派（本季度Top3问题）

基于下钻结果生成了六条立项建议，全部分配了主责部门和验证方式。其中"校正后增加预热片流程"这一条实施成本极低，只需要在校正程序后追加两片测试片，当月就见到了效果，套刻偏移造成的损失下降了约三成。这种低成本高回报的机会，往往就藏在下钻的细节里，在汇总层面是发现不了的。

七、实施效果：从工具到方法的沉淀

这套模块在我们厂运行了三个季度。可量化的效果有三项：一是季度良率规划的准备时间从原来的两周缩短到三天，其中数据清洗与校验部分完全自动化；二是立项后的目标达成率从百分之五十二提升到百分之八十一，主要得益于下钻让改善方向更精准；三是季度良率损失金额连续三个季度下降，累计降幅百分之二十七。

除此之外还有几点经验值得记录。第一，数据校验环节的价值被严重低估了，它不仅提升了分析质量，还反过来暴露了缺陷检查机台配置错误、字典更新滞后这类平时没人管的基础问题，我们现在把每月的校验拦截报告固定发给品质与IT部门。

第二，帕累托分析必须与置信区间一起看。我们有一次遇到第一名和第二名的置信区间高度重叠，按点估计排序会得出明确结论，但统计上其实无法区分。那次我们选择了并列立项，事后证明两项确实都是重要问题，如果只做第一名就会漏掉另一半的收益。

第三，也是最重要的一点：工具解决不了口径与组织的问题。这套代码本身两百行不到，任何一个会pandas的工程师半天就能写出来，真正花时间的是把数据字典建起来、把成本口径与财务对齐、把责任分派机制谈拢。我们大约用了百分之二十的时间写代码，百分之八十的时间在做这些看起来不那么技术的事。如果你打算在自己的厂里推这套东西，建议把时间预算也按这个比例来分配，否则很容易出现代码写完了但没人用的局面。

附录A：落地实施的四阶段排期与人力投入

很多团队看完方法论后最关心的问题是「要投多少人、多长时间」。以我们推进帕累托分析工程化模块的实际记录为例，整个过程分为四个阶段。第一阶段是现状盘点与基线固化，耗时2周，投入良率工程师与数据工程师1人天70%、数据工程师0.5人力，产出物是基线数据集与口径说明书，关键动作是把改善资源投入产出比与Top问题命中率的历史数据拉齐到同一口径，并明确采样频率、剔除规则和缺失值处理方式。这一步看似枯燥，但如果基线不准，后面所有的改善量化都会被质疑。

第二阶段是方案设计与小范围验证，耗时3周，投入良率工程师与数据工程师1人全职，工艺工程、设备工程与品质部门配合评审。验证范围限定在1到2台设备或1条产品线，目的是用最小代价确认金额加权帕累托加分层下钻在本厂数据上确实有效。验证阶段必须设定明确的通过标准，例如误报率、命中率、响应时长这类可量化指标，避免最后陷入「感觉还不错」的模糊结论。

第三阶段是全面推广与系统集成，耗时4到6周，需要IT或MES团队投入约15人天完成接口开发、权限配置和上线部署。推广阶段的最大风险不是技术，而是使用习惯：如果一线工程师觉得新流程增加了工作量，就会绕过它。我们的做法是把可复用的Python帕累托分析模块直接嵌入现有的日常工作界面，让使用者不需要额外打开新系统。

第四阶段是效果确认与固化，耗时4周，主要工作是持续跟踪指标、修订SOP、组织培训并把成果写入部门知识库。这一阶段容易被忽略，但决定了改善能否长期保持。我们要求每个项目在关闭前必须完成三件事：SOP更新并发布、责任人指定到具体岗位、监控看板上线并设置告警阈值，三者缺一不可。

八、配套资料与实战工具包

本文的帕累托分析模块完整代码、数据字典模板、分层下钻配置文件与待立项清单模板已打包整理，代码基于pandas与scipy，可直接对接MES或良率系统导出的CSV，按本厂字段名调整映射即可运行。

点击上方「VIP资源」下载区，免费获取以下配套资料（持续更新MES/SPC/良率/AI实战资料）：

帕累托分析Python模块完整源码（含校验、加权、下钻、置信区间四部分）

缺陷数据字典模板与入库校验规则表（Excel版）

成本维度表设计说明与按生效日期区间关联的SQL示例

分层下钻配置文件模板与赫芬达尔指数判读速查表

待立项清单模板与本文六条立项建议完整示例

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你在自己的产线上遇到过类似情况吗？是怎么处理的？欢迎在评论区留下你的做法和数据，一起把这套方法打磨得更实用。