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

[公开] GPT做根因分析(RCA)：结构化5Why的自动化尝试

【摘要】本文分享我们团队用GPT辅助做根因分析（RCA）的一次完整实践。核心思路是把丰田的5Why方法结构化成可执行的框架，再借助大语言模型的推理与结构化输出能力，把"人肉5Why"变成"GPT生成初稿加工程师证据校验"的半自动化流程。文章包含完整的提示词模板、结构化字段设计、效果对比数据以及五个真实踩过的坑，适合Fab工程师、质量工程师和正在尝试大模型落地的朋友参考。

分类：半导体AI融合 | 发布：2026-08-15

一、问题背景：FAB里RCA为什么这么难做

在半导体Fab里，异常事件几乎每天都在发生：良率骤降、设备报警、批次延误、缺陷率超标。每一件异常背后，品质部都会要求一份RCA报告，也就是根因分析报告。一份合格的RCA要回答三个问题：发生了什么、为什么会发生、怎么防止它再发生。听起来简单，做起来却非常耗时。

先讲一个我们亲历的真实案例。某批次产品在CMP工序后检测发现划伤类缺陷率从0.5%飙升到3.8%，品质部要求48小时内给出RCA报告。团队连续两天加班，开了三次跨部门会议，期间工艺工程师和设备工程师一度争执不下，最后才发现根因是浆料更换批次后发生颗粒团聚。整个排查过程里，真正用于定位根因的时间只占两成，剩下八成全部消耗在信息收集、会议讨论和报告撰写上。

这个案例非常典型。我们把大量RCA案例复盘后，总结出人工RCA的四个痛点。第一个痛点是经验依赖强：老工程师能凭直觉快速缩小范围，新人面对同样的问题往往无从下手，只能从头到尾把所有可能查一遍。第二个痛点是5Why追问不彻底：很多分析到第二、三个Why就答不上来，链条直接断裂，报告里写一句"供应商来料问题"就草草收场。第三个痛点是证据记录缺失：讨论时有人说"当时好像改过参数"，但没有人去查证变更记录，结论建立在口头记忆上。第四个痛点是报告复用率低：RCA做完就归档，同类问题换一台设备、换一条产线，又从头再来一遍。

为什么我们会想到用GPT来尝试解决？原因在于RCA的本质是"基于证据的因果推理加结构化输出"，这恰好是大语言模型相对擅长的领域。模型虽然没有Fab经验，但它读过海量的工程分析案例，对"原因-机制-证据"这种推理链条的把握并不差；而工程师真正的价值在于对现场、设备和数据的理解。所以我们给自己定的目标很明确：不是让GPT替代工程师，而是让GPT先把80%的脏活干完，工程师只做最关键的证据校验和最终决策。这个定位决定了后面所有的设计思路。

二、结构化5Why方法论：先有框架，再谈自动化

5Why方法起源于丰田生产方式，核心逻辑是对一个问题连续追问"为什么"，直到找到可以采取对策的根本原因。经典的润滑泵案例就是连续五层追问：机器停了是因为超载保险丝断了，超载是因为轴承润滑不足，润滑不足是因为油泵没泵上油，油泵不上油是因为轴磨损，轴磨损是因为没有安装过滤器导致碎屑进入。每一层都有物理证据支撑，链条完整，对策明确。

在FAB里实践5Why，最常见的失败模式有四种。第一种是链条断裂：问到第二层就停在"供应商的问题"这种不可验证的结论上。第二种是答案跳跃：从"参数漂移"直接跳到"更换设备"，中间跨越了两三个因果环节。第三种是主语不明：写"我们没注意""系统出错了"，到底是哪个环节、哪个人、什么机制，完全没有界定。第四种是混淆因果与相关：把"同时发生"当成"因为所以"，这是数据分析里最常见的认知陷阱。

为了让GPT能够按照规范执行5Why，我们把每一层Why结构化成五个必填字段：层级、问题陈述、直接原因、证据来源、验证方式。问题陈述必须包含明确的主语、谓语和对象，并且是可测量、可复现的现象；直接原因必须是与现象直接相邻的物理或逻辑机制；证据来源必须是客观记录，比如设备日志、SPC数据、变更记录；验证方式必须写明用什么手段确认这个原因是成立的。

我们内部立了一条铁律：每个Why的答案必须指向可验证的客观事实，凡是写"可能是""大概是""据说"的一律打回重写。这条铁律同样写进了给GPT的提示词，从源头约束输出质量。下面这张表就是我们使用的5Why结构化模板，字段设计直接决定了GPT输出能不能被后续校验和复用。

表格1：5Why结构化分析模板。注意最关键的约束是每一层的答案都必须能够回查到客观证据，这一点在自动化场景下比人工场景更加重要，因为模型天然倾向于生成"听起来合理"的内容。

三、GPT做RCA的完整落地步骤：五步走

下面把我们的完整流程拆成五步，每一步都给出可以直接复用的设计。这套流程已经在我们内部跑了两个多月，处理了超过三十个真实案例，稳定性是可以接受的。

Step 1：现场信息结构化采集（30分钟内完成）

GPT的输出质量完全取决于输入质量。直接扔一段聊天记录或者口头描述给GPT，输出质量会明显下降，甚至出现大量幻觉。我们的做法是先让现场人员填一张"RCA信息采集卡"，把散落的信息整理成固定字段：事件时间线、涉及设备与腔体号、缺陷或异常描述、相关批次与晶圆数、已有检测数据、近期变更记录、已执行的检查项。

信息采集卡的设计有几个要点。第一，时间线要精确到分钟，并且统一使用本地时区，避免跨班次交接时出现歧义。第二，设备信息要精确到腔体，不要只写设备大类，因为同一台设备的不同腔体可能是独立的故障源。第三，近期变更记录是最高价值字段，很多根因就藏在一次看似无关的配置变更里。第四，已执行的检查项要如实填写，包括"查了什么、结果如何"，这能帮助GPT避免重复建议已经做过的排查动作。

Step 2：设计系统提示词（最关键的一步）

提示词我们分成三段：角色设定、任务说明、输出约束。角色设定告诉模型它是什么身份，我们把模型设定为"半导体FAB资深工艺与质量工程师，熟悉SPC、FMEA、5Why、8D方法"，这能有效减少泛泛而谈的回答。任务说明明确交付物，我们要求模型"基于提供的结构化事件信息生成5层Why链，每层必须包含问题陈述、证据来源与验证方式"。输出约束是整段提示词的核心，我们明确要求"严格输出JSON，禁止编造输入中不存在的证据，证据不足时显式标注信息缺失"。

这里必须强调一点：提示词里的约束只有变成可执行的校验规则才算数。我们给模型配了一个输出校验脚本，解析JSON失败自动重试，字段缺失自动标注，检测到"疑似编造"的关键词（比如引用了输入里不存在的设备编号）直接打回。模板细节见下表，可以直接复制到你们的提示词管理平台里。

表格2：GPT做RCA的提示词模板。重点是输出约束与追问指令的组合：约束负责控制首轮输出质量，追问指令负责把链条走深、走实。

Step 3：多轮追问，让GPT把链条走完

一次生成往往是不够的，尤其是面对复杂异常时。我们的做法是让GPT先输出第一版5Why链，然后按固定的追问指令逐层深入。追问指令一共四条：证据追问，要求模型指出每一层Why的证据在输入信息中的具体出处；假设检验，要求模型回答"如果该层假设不成立，替代假设是什么"；反向5Why，要求模型从可能的对策反推，验证对策是否真正对应根因；对策可行性，要求模型给出三条可选对策以及各自的验证方法。

这四条追问指令我们也做成了模板，不依赖临场发挥。实际使用中，第二轮输出往往比第一轮质量明显提升，因为第一轮模型倾向于给出"最顺滑"的因果链，而追问会迫使它考虑证据强度和替代路径。我们的经验是追问最多三轮，超过三轮边际收益急剧下降，该收手时就收手，剩下的交给工程师去查数据。

Step 4：人工证据校验（不可省略的一步）

无论GPT的输出看起来多么合理，它都只是假设集合，不是结论。工程师必须逐条回查证据：调设备日志确认报警时间、查SPC数据确认参数漂移、翻变更记录确认参数是否被改过。我们要求每条Why链上的证据字段必须是可回查的客观记录，GPT给出的证据如果是推理出来的，必须标注"待验证"字样，直到工程师实际确认。

证据校验是整条链路里唯一不能自动化、也最不应该自动化的一步。大模型的核心风险就是幻觉，它会一本正经地编造"查了SPC系统显示参数漂移了0.3%"，但实际SPC数据里根本没有这条记录。所以我们的原则是：模型负责生成和排序假设，工程师负责证伪和确认，职责边界非常清晰。

整个数据流可以概括为：现场事件数据经过信息采集卡结构化，喂给GPT生成5Why初稿，经过多轮追问完善链条，再由工程师逐条校验证据，最终把确认过的结论结构化入库（流程见图1）。

Step 5：结果结构化入库，形成可复用的资产

校验通过的5Why链以JSON格式导出，字段与模板完全对齐，每份RCA都有唯一编号，关联设备、缺陷类型、工序和发生时间。入库之后，这些报告就不再是躺在归档目录里的死文档，而是可以统计、可以检索、可以复用的活资产。

我们最看重的一个统计维度是根因分布：按工序和缺陷类型统计"哪类根因最常见"。统计结果直接指导系统性改进，比如我们发现划伤类缺陷的根因六成集中在浆料与研磨垫管理环节，据此推动了耗材批次变更管理的专项改善，这类改善的价值远高于单次救火。

四、效果对比与避坑经验

为了验证这套方案到底有没有用，我们在内部做了一组对照实验：纯人工组由一名资深工程师独立完成，GPT辅助组由一名工程师配合GPT完成，两组各处理10个同类RCA案例，内容全部脱敏。对比结果如图2和表格3所示。

平均耗时从9.6小时降到3.2小时，降幅超过六成；5Why链条完整率，也就是能完整走到第五层且每一层都有证据支撑的比例，从60%提升到92%；报告可复用性，定义为新人能否照着报告复现排查过程，从40%提升到85%。需要说明的是，样本量有限，这个数字只能作为参考，但它反映的趋势与我们的体感完全一致。

表格3：纯人工RCA与GPT辅助RCA的对比。注意"经验依赖程度"这一行，GPT辅助组并没有把经验依赖降为零，而是把依赖对象从"老工程师的直觉"转移到了"框架和数据的质量"上。

接下来是重点，五个我们真实踩过的坑。

第一个坑是幻觉证据。GPT会编造"查了SPC系统显示""设备日志显示"这类根本不存在的记录。我们的对策是双管齐下：提示词强制要求证据必须来自输入信息，校验脚本检测引用是否越界，两者缺一不可。

第二个坑是信息不足硬答。输入只有三句话，模型照样能编出五层Why，而且看起来很专业。我们的对策是提示词里强制"信息缺失"标注，同时流程上规定：信息采集卡没填满关键字段，不进入GPT分析环节。

第三个坑是方向被带偏。如果首层Why问错了，整条链条都会跑偏，而且模型会在错误的路径上越走越自信。我们的对策是首层Why由工程师指定，模型只负责展开后续层次，相当于把方向盘牢牢握在工程师手里。

第四个坑是输出格式不稳定。同一份提示词，有时输出表格，有时输出文字，有时混着Markdown。我们的对策是强制JSON Schema校验，解析失败自动重试，连续失败三次就降级为人工分析，绝不让格式问题卡住流程。

第五个坑是数据脱敏。真实晶圆号、批次号、客户信息一旦进入提示词，就会通过API传输到外部模型服务，存在数据合规风险。我们的对策是建立脱敏规则，设备名用别名、批次号用随机代号，脱敏规则本身也版本化管理。

最后补充一个定位层面的提醒：GPT适合的是"信息齐备时的因果推理加速"，不适合"数据还没查出来就让它猜"。它的价值在于把你已有的信息组织成更完整的因果链，而不是替你发现你不知道的事实。这个定位想清楚了，方案才不会跑偏。

五、进阶：从单次RCA到知识库闭环

单次RCA的价值是解决一个问题，知识库闭环的价值是让所有历史问题都变成下一次分析的弹药。我们把历史RCA报告脱敏后向量化存入知识库，新异常发生时先用RAG检索出最相似的三份历史案例，把它们的要点作为参考上下文注入提示词。这样新人做RCA时，起点从"一片空白"变成"历史案例加GPT初稿"，质量下限被显著抬高。

架构上，RCA知识库与MES、SPC等生产系统保持松耦合：生产系统负责提供原始数据，知识库负责沉淀分析结论，GPT位于两者之间做推理加速（架构见图3）。这套架构的好处是任何一层升级都不影响其他层，比如换更强的模型、扩充知识库、调整采集逻辑，都是独立演进。

再往深走一步，知识库沉淀到一定规模后，可以做根因分布的定期复盘，把高频根因反推给流程改进。我们团队有个很朴素的经验：RCA做得好不好，不看单份报告写得漂不漂亮，而看半年后同类问题的发生率有没有下降。大模型在整个体系里的定位始终是放大器，它放大的是团队的框架能力和数据资产，前提是框架足够结构化、数据足够可信。

六、配图说明