[公开] 让大模型读懂FMEA表：自动补全失效模式与后果的工程化做法

【摘要】PFMEA表动辄上千行、更新滞后两年、新工序上线全靠复制粘贴，是很多Fab的真实状态。本文把大模型补全FMEA拆成语料、检索、受限生成、规则校验四层，讲清为什么不能用自由生成、术语词表与JSON Schema如何约束输出、S与O与D的打分一致性怎么校验，并给出一个一千一百五十行PFMEA的离线评测数据与人工采纳率。

分类：半导体AI融合 | 发布：2026-08-17 | 首发：半导体智能制造博客

一、背景故事：一次真实的产线事件

起因是一次客户审厂。审核员抽了三条产线的PFMEA表，问了一个很基础的问题：去年那次设备升级之后，新增的两道工序有没有更新到FMEA里。答案是没有。再往下翻，发现表里还有一道两年前就已经取消的工序，控制措施一栏写的是某个早已停用的检测方法。审核员没有当场开不符合项，但在总结会上说了一句话：这份文件看起来更像是为了审核而存在的。

会后我们把这份PFMEA完整看了一遍，一千一百五十行，覆盖八个工序族。看完的结论比审核员说的更难听：至少有三成的条目是从别的产品直接复制过来的，同一个失效模式在不同工序里有四种不同的写法，严重度打分在不同工序族之间明显不一致，同样是"晶圆破片"，有的地方打八分有的地方打五分。这不是某个人不负责，是因为编制时间跨度六年、经手过至少九位工程师，而且从来没有做过一次全局对齐。

真正让人头疼的是维护成本。我们估算过，请工程师把这份表重新梳理一遍，按每个工序族六点五小时算，八个工序族要五十二小时，还不包括评审会的时间。而更新完之后，下一次工艺变更又会让它开始过时。这是一个典型的"重要但永远排不上"的工作，所有人都知道该做，但没有人有整块时间做。

这就是我们决定试试大模型的背景。目标定得很朴素：不是让AI写出一份可以直接用的FMEA，而是把工程师从零起草的状态变成审阅修改的状态。这两者的工作量差距非常大，前者需要回忆和创造，后者只需要判断。这篇文章写的是这套系统的设计、评测和踩过的坑，重点在工程化而不是模型本身。

二、技术原理：把机制讲清楚

先说清楚FMEA的结构，因为这决定了任务应该怎么拆。一条PFMEA记录的核心字段是：过程步骤、该步骤的功能与要求、潜在失效模式、失效后果、严重度S、潜在失效起因、发生度O、现行控制中的预防措施与探测措施、探测度D，最后是风险优先数RPN或者AIAG-VDA第五版里的行动优先级AP。这些字段之间不是并列关系，而是有明确逻辑链：功能要求决定了什么算失效，失效模式决定了后果，后果的严重程度决定S分，起因决定O分，探测手段决定D分。理解这条链之后就会发现，这个任务本质上不是文本生成，而是在一个有约束的结构里做推理填空。

这也是为什么自由生成的做法一定会失败。如果直接把工序描述丢给模型让它写FMEA，得到的结果通常语法通顺、格式正确、内容看起来合理，但经不起工程师推敲：会出现工厂并不存在的设备名称、引用不存在的检测方法、甚至凭空造出一个听上去很专业但物理上不成立的失效机理。在质量体系文件里，这种错误的危害远大于漏项，因为漏项能被发现，而看似合理的错误会被签字通过。

所以正确的做法是受约束生成。约束来自三个方向：第一是词表约束，失效模式、失效后果、控制措施这三类字段的取值必须来自受控词表，词表从历史FMEA、FA报告、8D报告里抽取并由工程师审定；第二是结构约束，模型输出必须是符合预定义JSON Schema的结构化对象，而不是自然语言段落；第三是证据约束，每一个生成的条目必须附带它所依据的检索片段来源，无法给出来源的条目直接标记为低置信。

检索这一层的设计比模型选择更影响最终效果。切分粒度我们试过三种：按整份文档切、按工序族切、按单条FMEA记录切。最终选的是按单条记录切并附带所属工序族的上下文，因为FMEA的复用单元本来就是单条记录。检索策略用混合方式：BM25负责术语和设备型号这类精确匹配，向量检索负责语义相近但用词不同的情况，两路结果合并后再用一个轻量重排模型排序。纯向量检索在这个场景下表现不好，因为半导体术语的同义变体多，而型号数字的细微差别在向量空间里几乎不可分。

评测指标必须在动手之前定好，否则做完了没法判断好坏。我们用了四个：失效模式覆盖率，即人工认定应有的失效模式中被模型找出来的比例；字段级准确率，逐字段判断生成内容是否可直接采纳；幻觉率，即出现工厂不存在的实体或不成立机理的条目占比；以及最终的人工采纳率，分为直接采纳、修改后采纳、拒绝三态。前三个指标用于开发迭代，最后一个才是真正的业务指标。

三、现状分析：多数工厂现在是怎么做的

第一档是纯Excel人工维护，这也是最普遍的状态。优点是零成本、格式灵活，缺点在前面已经说得很清楚：版本混乱、术语不统一、更新滞后、无法复用。这一档的工厂通常还有一个隐性问题，就是FMEA与实际控制计划脱节，表里写着的探测措施在现场其实已经不执行了，而现场实际在做的检查表里又没有。

第二档是模板化管理。建立了标准模板和工序族模板库，新产品导入时从模板复制再修改。这比纯手工好很多，至少保证了结构一致性和基础覆盖度。瓶颈在于模板本身的更新和实例的更新是两条线，模板改了实例不会跟着改，时间一长模板库和实际使用的表之间就产生了分叉，而且分叉是不可见的。

第三档是商用FMEA软件。这类工具在版本管理、评审流程、与控制计划联动方面做得很成熟，有些还带行业知识库。它们缺的是语义能力：知识库通常是按分类树组织的，要靠人去点开找，找不到相近的条目就还是要自己写。换句话说，它解决了管理问题，没有解决编写问题，而编写才是耗时的部分。

我们的定位是在第二档或第三档之上加一层辅助编写能力，不替换现有系统。这个定位很重要：FMEA是质量体系文件，替换承载系统涉及体系文件变更和客户认可，成本极高。做成一个输出建议、由人搬进现有系统的辅助工具，落地阻力会小一个数量级。事后看，这是这个项目能在四个月内跑通的关键决定。

四、瓶颈问题：卡在哪里

第一个卡点是语料质量。历史FMEA是最主要的语料来源，但它本身质量参差，如果直接拿来做检索库，模型会忠实地把历史上的错误和不一致复制到新条目里。我们第一版就吃了这个亏，生成结果里大量出现同一失效模式的四种写法，因为语料里就是这样。语料清洗是绕不过去的前置工作，而且这项工作只能由懂工艺的人做。

第二个卡点是术语的同义变体。晶圆破片、碎片、破损、crack、chipping，在不同工程师笔下指的可能是同一件事，也可能是不同的失效模式。这个问题不解决，覆盖率和准确率的评测都无法进行，因为你无法判断模型输出的和参考答案是不是一回事。建立受控词表并做同义归一，是整个项目里最枯燥但收益最高的一步。

第三个卡点是S、O、D打分的主观漂移。同样的后果，不同工程师打分能差两到三分，而RPN是三个分数相乘，两分的差异会被放大成数倍的RPN差异。模型如果直接学历史打分，只会把这种漂移固化下来。我们的处理是把打分从生成任务里剥离出去：模型只负责判断后果属于哪个已定义的后果等级，分数由等级映射表确定，映射表由质量部门统一维护。

第四个卡点是幻觉。第一版评测里幻觉率高达百分之十四，典型表现是编造设备型号、引用不存在的量测手段、以及生成物理上说不通的失效机理。这一项如果压不下去，工具就无法交付，因为工程师一旦被坑过两次就不会再用了。解决靠的不是换更大的模型，而是词表约束加证据约束加规则校验三管齐下。

第五个卡点是数据不能出厂。FMEA里包含工艺细节和客户产品信息，公有云API方案在合规评审阶段就被否掉了。这直接决定了技术路线：必须本地部署，模型规模受限于现有GPU资源。好在受约束生成任务对模型规模的要求远低于开放式创作，我们最后用的是一个中等规模的开源模型，效果完全够用。

五、解决方案：可落地的完整做法

整套系统分四层。第一层是语料层，负责把历史FMEA、FA报告、8D报告、OCAP文件、工艺规范清洗成统一结构。清洗做四件事：字段对齐、术语归一、去重、质量打标。质量打标是给每条历史记录一个可信度等级，由工程师抽样评定后用规则外推，低可信度的记录仍然入库但在检索时降权。这一层的产出是一个约七千条记录的知识库，其中高可信度约占四成六。

第二层是检索层。输入是新工序的描述、所属工序族、使用设备与关键参数，输出是最相关的若干条历史FMEA记录与相关FA案例。实现上用BM25与向量检索并行，各取前二十条，合并去重后用重排模型取前八条送入生成。这里有一个实用技巧：把工序族作为硬过滤条件而不是软特征，跨工序族的检索结果看起来相似但工程上往往不适用，硬过滤后准确率提升了约九个百分点。

第三层是受限生成层。提示词由四部分组成：任务定义与FMEA字段逻辑链说明、受控词表的相关子集、检索到的历史条目作为示例、以及输出的JSON Schema定义。关键设计是让模型一次只生成一个工序步骤的条目组，而不是整表，这样上下文短、约束强、出错也容易定位。另外强制要求每个条目输出一个evidence字段，填写它依据的检索片段编号，没有依据就填null，这个字段后面会被校验层用到。

第四层是规则校验层，这一层是幻觉率能从百分之十四压到百分之二点一的主要原因。校验规则包括：失效模式与后果必须命中受控词表，否则标记待人工确认；涉及的设备型号必须存在于设备主数据里；后果等级与严重度分数必须与映射表一致；evidence为null的条目一律标记为低置信；同一工序内的重复条目自动合并；以及一条经验规则，探测措施若为在线自动检测但探测度打分高于五分，判定为逻辑不一致需复核。

最后是人机协同的交互设计，这部分对采纳率的影响不亚于模型本身。界面上每条生成结果旁边有三个按钮：采纳、修改后采纳、拒绝，修改和拒绝都要求选择一个原因标签，标签体系只有六个选项，保证工程师愿意点。这些反馈每周回流一次，用于更新词表、调整检索权重和补充示例。运行三个月后，仅靠反馈回流带来的采纳率提升就有十一个百分点，没有做任何模型微调。

六、实战案例：一个完整的改造过程

落地对象就是开头那份一千一百五十行的PFMEA，覆盖八个工序族。项目周期四个月，投入是一名算法工程师全职、一名工艺质量工程师半职、加上八个工序族各一名工程师按需参与评审。硬件用了厂内已有的一台双卡推理服务器，没有新增采购。整体目标定为：把单个工序族的FMEA起草时间从六点五小时压到三小时以内，同时不降低评审通过率。

第一个月做语料。历史FMEA、近五年的FA报告、三年的8D报告，加起来原始记录约一万一千条，清洗后入库七千零四十条。术语归一是最费时的部分，最终建立的受控词表包含失效模式两百一十七项、失效后果六十四项、控制措施一百三十九项，每一项都经过质量部门审定。这一个月几乎没有产出任何看得见的东西，中途被问过两次进度，但后来证明这是整个项目里最值的投入。

第二个月做检索与生成的第一版，并做了第一次离线评测。评测方法是留出法：把两个工序族的现有FMEA作为参考答案，用其余六个族的语料做检索库，让系统为这两个族生成条目，再由三位工程师独立评判。第一版结果并不好看：失效模式覆盖率百分之七十一，字段级准确率百分之五十八，幻觉率百分之十四。这个结果当时让团队有点动摇，但拆开看问题很集中，主要就是幻觉和跨族检索污染两类。

第三个月上校验层和硬过滤，指标改善很明显：覆盖率升到百分之八十六，字段级准确率升到百分之七十九，幻觉率降到百分之二点一。这一步没有换模型也没有微调，全部是工程手段。我把这个过程写进了后来的复盘材料，因为它很好地说明了一件事：在有明确结构约束的业务任务上，工程约束的边际收益通常高于模型能力的边际收益。

第四个月做交互与试点。选了两个工序族做真实使用，八名工程师参与。试点数据是：直接采纳百分之六十二、修改后采纳百分之二十八、拒绝百分之十。拒绝原因排前两位的是"该失效模式在本工序不适用"和"控制措施描述过于笼统"，这两条都在后续通过补充工序特征和细化词表得到了改善。工程师的主观反馈里出现频率最高的一句话是：它想到了我会漏掉的那几条。这句话其实说明了这类工具真正的价值点不在于替代，而在于补全人的盲区。

七、实施效果：数据说话

最终验收数据如下。单个工序族的FMEA起草时间从六点五小时降到二点一小时，优于三小时的目标；八个工序族全量刷新一轮的总工时从五十二小时降到约十七小时。更重要的是刷新周期，过去是两到三年才动一次，现在变成每次工艺变更后随即更新，因为增量更新的成本已经低到可以随手做。这一点改变了FMEA在团队里的性质，它从一份审核文件变成了一个真的会被查阅的参考。

质量侧的指标同样有改善。全量刷新后，失效模式的重复与遗漏条目减少了约四成，术语一致性从抽检的百分之六十三提升到百分之九十六，S分在不同工序族之间的一致性问题基本消除，因为分数改由映射表确定。下一次客户审厂时，同样的抽查方式没有再被提出类似意见，审核员额外问了一个问题是这套词表怎么维护，这说明关注点已经从有没有更新变成了怎么管理。

成本方面，四个月的总投入约合三百二十个人工时加上原有硬件的占用。按每年两次全量刷新加十二次增量更新估算，年节约工时约二百四十小时，第二年即可回本，之后是净收益。这里要提醒的是不要把节约的工时直接等同于人力削减，实际情况是这些时间被转投到了更有价值的工作上，用这个口径去做汇报，比说"省了多少人"更容易得到支持，也更符合事实。

最后说三条经验和一个遗留问题。第一条，语料清洗和词表建设的投入应该占整个项目的四成以上，不要因为它不出效果就压缩。第二条，把打分这类主观性强的任务从模型职责里剥离，交给规则和映射表，是提升可信度最有效的手段之一。第三条，人机协同的反馈闭环要在第一天就设计好，不要等模型效果稳定了再加，因为早期的反馈数据质量最高、信息量最大。遗留问题是跨产品线的迁移：这套东西在同一条产品线内效果很好，换到工艺差异较大的另一条线上时，覆盖率会掉十几个点，目前只能靠补充该线的语料来解决，还没有找到更省力的办法。

八、常见问题答疑

Q：直接用通用大模型加一段提示词不行吗，为什么要做这么多层？

A：可以做出演示，但交付不了。我们做过对照实验，同样的工序描述，纯提示词方案的字段级准确率是百分之四十一、幻觉率百分之十四，加上检索之后准确率到百分之五十八，再加词表和校验才到百分之七十九。差距主要来自两点：通用模型不知道你厂里有哪些设备和检测手段，也不知道你们对失效模式的表述习惯。这两类知识只能靠检索和词表注入，提示词写得再长也补不上。

Q：受控词表要维护，会不会又变成一个没人更新的东西？

A：这是真实风险，所以词表的更新必须寄生在已有流程上而不是新增流程。我们的做法是把词表更新挂在两个已有动作上：一是FMEA评审会，评审中出现的新表述由记录人当场提交词表候选；二是工具里的修改反馈，工程师修改生成结果时如果填入了词表外的表述，系统自动收集为候选。候选每月由质量工程师批量审定一次，单次耗时约一小时。关键是不要设立专门的词表维护岗位或独立的评审会，那种设计通常撑不过半年。

Q：本地部署对硬件要求高吗，小厂能不能做？

A：比多数人预期的低。受约束生成任务的上下文短、输出结构固定，对模型规模的要求远低于开放式写作。我们用的是中等规模开源模型，一台双卡推理服务器就能支撑八名工程师并发使用。真正的成本不在硬件而在语料整理，那部分需要懂工艺的人投入几十到一百多个工时。如果厂里连历史FMEA和FA报告都没有电子化，建议先做电子化和结构化，那一步的价值本身就已经很大。

Q：这套东西能不能扩展到控制计划、作业指导书这类文件？

A：控制计划的扩展性最好，因为它与FMEA字段有天然映射，探测措施、频次、样本量、反应计划这些内容可以从FMEA条目直接推导，我们已经做了一个初步版本，字段准确率比FMEA本身还高，原因是约束更强。作业指导书难度大很多，因为它包含大量步骤性和现场性的描述，语料的结构化程度低，而且错误的后果直接作用于操作现场，风险等级不同，建议在FMEA与控制计划跑稳一年以上再考虑。

十、配图：数据可视化

图1：FMEA补全的四层处理流水线

图2：FMEA知识库与生产系统的对接架构

十一、FMEA字段与大模型任务映射及校验规则对照表

十二、离线评测指标、验收阈值与实测结果对照表

十三、配套资料与实战工具

本文配套完整实战工具包，包含文中涉及的测算模板、参数配置表、排查清单与Python脚本，可直接用于工厂落地实施。

点击上方「VIP资源」下载区，免费获取以下五项配套资料（持续更新中）：

刻蚀PM后首件恢复SOP与Qual Wafer管理模板（含腔体seasoning收敛判据与首件放行Gate对照表）

半导体数据湖分层设计说明书（含Iceberg表结构、元数据字典、小文件合并与分区调优脚本）

FAB工时台账与排班合规自查工具包（含加班统计模板、异常升级流程与沟通话术卡片）

大模型FMEA自动补全工具包（含Prompt模板库、RPN测算表与人工复核Checklist）

Python实战脚本合集（设备恢复数据比对、Parquet分区调优、FMEA向量检索与批量导出）

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

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

你遇到过类似的问题吗？是怎么解决的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：半导体AI融合 | FMEA | 大模型 | RAG检索 | 知识工程 | 风险管理 | 制造业AI