[公开] 知识图谱+LLM诊断工艺偏移：因果链可视化实践

【摘要】一次CD偏移排查，八名工程师查了三天，最后发现根因是四周前的一次备件更换。问题不在数据不够，而在数据之间的关系没有被建模。本文给出知识图谱＋LLM的完整实践：图谱Schema设计、从MES/FDC/EDA的实体关系抽取、Text2Cypher查询、因果链路径搜索与可视化，附1200万节点规模的性能数据与五个真实的坑。

分类：半导体AI融合 | 文章类型：P | 发布日期：2026-08-11

一、背景故事：三天八个人，找到四周前的一次换件

事情从一份CD（关键尺寸）量测报告开始。某12英寸Fab的逻辑产品在Poly刻蚀后的CD持续偏大，从规格中心的正0.8nm漂到正3.6nm，虽然还没超出正负5nm的规格线，但趋势明确、CPK从1.62掉到1.09。良率工程师发出预警，工艺、设备、量测三个部门同时启动排查。

第一天，工艺组把刻蚀配方参数逐项调出来比对，RF功率、压力、气体流量、刻蚀时间全部无变更；设备组检查了三台可能涉及的刻蚀机，FDC参数趋势看起来都在正常范围；量测组复检了量测机台的Gauge R&R，确认量测系统没有问题。三个方向都没有发现，第一天结束时的结论是「继续观察」。

第二天，团队扩大排查范围，把光刻侧也拉了进来。检查了曝光剂量、聚焦、显影参数，同样没有明显异常。有人提出可能是光刻胶批次的问题，查了材料批次记录，最近三个月只换过一次胶，时间对不上。

第三天，一位资深工程师凭直觉问了一句：刻蚀机的上下电极最近换过吗？设备组去查维修工单，发现其中一台刻蚀机在四周前做过一次上电极更换，属于计划内的耗材更换，PM后的Qual也通过了。但进一步比对发现，Qual用的是标准监控片，而实际产品的图形密度与监控片差异较大，Qual数据无法反映真实的产品表现。把这台机台跑过的批次单独筛出来，CD偏移的规律立刻清晰了——所有偏大的批次都经过这台机台。

八个人、三天、二十多个人日，最后找到的根因是一次四周前的备件更换。事后复盘时大家最大的感慨是：这条因果链上的每一个环节，数据都在系统里，维修工单在设备管理系统、批次路径在MES、CD数据在SPC、Qual记录在量测系统。数据都有，但它们之间的关系没有被建模，只能靠人脑去连。而人脑能同时连接的信息不超过七八个，遇到跨越四周、跨越四个系统的因果链就无能为力了。

这次事件成了团队做知识图谱的直接动因。本文分享的就是之后一年多的完整实践。

二、技术原理：为什么图谱＋LLM能解决这个问题

先说清楚问题的本质。工艺偏移的排查是一个典型的多跳关系推理问题：从异常现象（CD偏大）出发，要沿着「批次经过哪些设备」「设备用了哪些配方」「设备最近有哪些维护事件」「维护事件影响了哪些参数」这样的关系链条向外扩散，直到找到能解释现象的节点。传统的关系型数据库擅长做单表聚合和有限次Join，但做四跳以上的关系遍历时，SQL会复杂到无法维护，性能也急剧下降。图数据库正好相反，它把关系作为一等公民存储，多跳遍历是原生能力。

图谱的核心是Schema设计。经过多轮迭代，我们的Fab工艺图谱定义了九类实体和十四类关系。九类实体是：批次（Lot）、晶圆（Wafer）、产品（Product）、工序（Operation）、设备（Equipment）、腔体（Chamber）、配方（Recipe）、量测参数（Parameter）、事件（Event，含报警、维护、变更三个子类）。十四类关系包括：批次-经过-工序、工序-使用-设备、设备-包含-腔体、腔体-运行-配方、批次-产生-量测值、设备-发生-事件、事件-影响-参数、配方-派生自-配方（版本关系）等。

关系上必须带时间属性。这是Fab图谱区别于通用知识图谱的最关键一点。批次在什么时间经过哪个腔体、维护事件发生在哪个时间点、配方在哪个时间段生效，这些时间信息决定了因果关系是否成立。没有时间约束的图谱会给出大量看似相关实则不可能的路径——比如把维护事件关联到它发生之前的批次上。我们的做法是在所有事件类关系上强制带valid_from和valid_to两个时间戳，路径搜索时做时序过滤。

LLM在这套体系里承担三个角色，每个角色的技术方案不同。第一个角色是自然语言到图查询的翻译（Text2Cypher）：工程师用中文问「最近两周CD偏大的批次共同经过了哪些腔体」，LLM把它翻译成Cypher查询语句。这一步的关键是给LLM提供准确的Schema描述和足够多的示例（Few-shot），我们维护了一个包含86个查询范例的样例库。

第二个角色是路径的自然语言解释。图查询返回的是节点和边的集合，对工程师来说不够直观。LLM把路径翻译成因果叙述：「这批Lot在8月3日14:22经过ETCH03的B腔体，该腔体在7月6日更换过上电极，更换后的Qual仅使用标准监控片验证，未覆盖高密度图形产品」。这种叙述极大降低了图谱的使用门槛。

第三个角色是假设生成与排序。当路径搜索返回多条候选因果链时，LLM结合领域知识对候选进行排序，给出优先排查建议。这里必须强调：LLM给的是假设不是结论，最终判定必须由工程师结合数据验证。我们在界面上对所有LLM生成内容做了明确标注，并强制要求每条建议附带可点击的原始数据链接。

还有一个绕不开的问题：相关不等于因果。图谱找到的是关联路径，不是因果关系。为了提升可信度，我们在路径打分中引入了三个统计信号：时序先后性（原因必须早于结果）、暴露组与对照组的效应量（经过该腔体与未经过该腔体的批次CD差异，用Cohen d衡量）、以及倾向得分匹配后的差异（控制产品类型、层次等混淆因素）。三个信号加权后得到因果置信度，低于阈值的路径不推送。

三、现状分析：Fab数据分析的三种典型形态

形态一：报表驱动。这是最普遍的形态，工程师看固定的日报周报，发现异常后手工下钻。优点是成本低、覆盖面广，缺点是只能发现报表维度内的问题，跨维度、跨时间的关联问题基本看不见。多数Fab停留在这个阶段。

形态二：统计模型驱动。用相关性分析、回归、决策树等方法找参数与良率的关系，典型工具是JMP、Spotfire或自研的Commonality Analysis平台。这类方法在单一层次内很有效，比如找出某工序内哪个参数与良率相关性最高。但它的输入通常是一张宽表，宽表的构建本身就需要人预先决定纳入哪些变量，而真正的根因往往就藏在没被纳入的变量里。

形态三：图谱驱动。把系统间的关系显式建模，支持任意跳数的关系遍历和路径搜索。它解决的正是前两种形态的盲区——那些跨系统、跨时间、需要多跳推理才能发现的因果链。但它的建设成本最高，需要打通多个系统的数据、需要持续维护Schema、需要图数据库的运维能力。

三种形态不是替代关系而是互补关系。报表负责日常监控，统计模型负责已知维度内的定量分析，图谱负责未知关系的探索。实践中我们的使用比例大约是：报表覆盖80%的日常需求，统计模型覆盖15%，图谱覆盖5%——但这5%往往是最难、代价最大的那部分问题。

还有一个现实：多数Fab的数据基础不足以直接上图谱。图谱的质量完全取决于底层数据的质量，特别是主数据的一致性。如果同一台设备在不同系统里有不同编码，构建出来的图谱会是断裂的。这也是为什么我们在图谱项目启动前，先花了三个月做主数据的统一。

四、瓶颈问题：五个真实的坑

坑一：LLM幻觉生成不存在的字段。Text2Cypher最常见的失败模式是LLM凭空捏造Schema里不存在的属性名，生成的Cypher语句能执行但返回空结果，工程师误以为「没有找到关联」。我们的解决办法是三层防护：Prompt里注入完整的Schema定义、生成后用Schema校验器验证所有属性名的合法性、执行前把语句展示给用户确认。加上这三层后，非法查询率从初期的23%降到1.8%。

坑二：Schema漂移导致查询失效。生产系统持续演进，新增设备类型、新增事件类别都会改变图谱结构。如果Schema变了而LLM的Prompt和样例库没同步更新，翻译准确率会悄无声息地下降。我们的做法是把Schema定义作为单一数据源（Single Source of Truth），Prompt模板从Schema自动生成，Schema变更触发样例库的回归测试。

坑三：时序对齐错误。不同系统的时间戳基准不一致——设备本地时间、系统UTC时间、业务日归属，三者混用会导致因果顺序判断错误。我们踩过一次典型的坑：因为FDC用设备本地时间、MES用UTC时间，图谱把一次维护事件错误地关联到了它实际发生之前的批次上，给出了完全错误的诊断建议。修复方案是在数据接入层做统一的时间标准化，全部转为UTC存储，展示层再按用户时区渲染。

坑四：图规模膨胀带来的性能问题。Fab的数据量非常大，如果把每片Wafer的每个量测值都建成节点，图规模会迅速失控。我们初版图谱把Die级数据也纳入，节点数三个月就突破了三亿，任何两跳以上的查询都超时。后来重新设计了粒度策略：结构性实体（设备、配方、工序、批次）进图谱，海量的时序数值数据留在列式数据库，图谱节点只存指针。调整后节点数稳定在1200万左右，边约8000万，查询性能恢复到可用水平。

坑五：把相关当因果导致误判。上线初期，系统给出的高分路径中有相当一部分是伪因果——两个现象都由第三个因素引起，但图谱只看到了它们之间的关联。典型例子是「某配方与良率下降相关」，实际上是这个配方主要用于某个特定产品，而那个产品本身良率就低。引入倾向得分匹配控制混淆变量后，伪因果的比例从37%降到11%。剩余的11%通过在界面上强制展示混淆因素提示来提醒工程师。

五、解决方案：五层架构与实施路径

第一层：数据接入与标准化。从MES、FDC、EDA（量测）、设备维修系统、配方管理系统五个源头抽取数据。接入方式以增量为主：MES的批次流转用CDC（变更数据捕获）近实时同步，FDC的参数摘要按小时批量抽取，维修工单按事件触发。标准化的核心工作是三件事：时间统一为UTC、设备编码映射到Golden ID、事件类型归一到统一的枚举表。这一层的工作量占整个项目的45%左右，是最枯燥但最不能省的部分。

第二层：图构建与更新。用Neo4j作为图数据库，节点和关系通过批量导入工具初始化，之后用流式更新维持时效。更新策略上有个重要设计：批次流转这类高频事件采用微批更新（每5分钟一批），维护事件、配方变更这类低频但关键的事件采用实时更新。索引方面，对Lot ID、Equipment ID、时间戳字段建立复合索引，这是保证查询性能的关键。

第三层：路径搜索与因果打分。给定一个异常现象节点，用有界深度的双向广度优先搜索（最大深度设为5跳）找出所有候选路径，然后按三个信号打分：时序合理性（硬约束，不满足直接淘汰）、效应量（Cohen d，暴露组与对照组的标准化均值差）、混淆控制后的净效应（倾向得分匹配）。综合得分超过阈值的路径进入候选集，按分数降序排列。

第四层：LLM交互层。包含Text2Cypher、路径解释、假设排序三个能力。工程实现上有几个要点：Prompt中注入完整Schema和8到12个最相关的Few-shot示例（用向量检索从86个范例中选取）；生成的Cypher先经过语法和Schema双重校验；所有LLM输出标注来源并附原始数据链接；对高风险操作（如生成的查询涉及全图扫描）增加确认环节。

第五层：可视化与协作。因果链用有向图渲染，节点按类型着色，边上标注时间和关系类型；同时提供时间轴视图，把因果链上的事件按时间顺序排列，这个视图对工程师理解「什么时候发生了什么」特别有效。协作方面支持把某条因果链保存为「诊断案例」，附上工程师的验证结论，这些案例会反哺Few-shot样例库，形成正向循环。

实施路径建议分三期。一期（3个月）只做批次-设备-事件三类实体，验证技术可行性和性能；二期（3个月）扩展到配方、参数、产品，接入LLM交互；三期（6个月）完善因果打分、可视化和案例库，推广到全厂。切忌一开始就追求完整Schema，那样六个月都上不了线，团队信心先垮了。

六、实战案例：图谱上线后的三次实战检验

第一次检验：复现开头那个CD偏移案例。团队把历史数据回灌到图谱，输入异常现象「近两周CD均值上移超过2nm的批次集合」，系统在11秒内返回了7条候选因果链，排名第一的正是「ETCH03-B腔体上电极更换事件」，因果置信度0.83。排名第二和第三分别是某配方版本变更和某量测机台的校准事件，经验证均为伪相关。从提问到得到正确假设，全程不到1分钟——对比原来的三天二十人日。

第二次检验：一次真实的薄膜厚度异常。某薄膜工序的厚度均值突然下移1.8nm，工程师用图谱查询后得到排名第一的路径：该工序的两台设备中，DEP02在异常时段的批次占比从常态的48%升到79%（因为DEP01在做PM），而DEP02的厚度基线本来就比DEP01低1.5nm。这不是设备坏了，而是设备配比变化暴露了长期存在的机台间差异（Tool-to-Tool Mismatch）。这个诊断把团队的注意力从「找故障」转向「做机台匹配」，避免了在错误方向上浪费时间。

第三次检验：一次失败的诊断。某产品的CP良率下降3.2个百分点，图谱给出的排名第一路径指向某个物料批次，因果置信度0.71。工程师按这个方向查了两天，最终证伪——真实根因是客户侧更改了测试程序的判定阈值，这个信息压根不在图谱覆盖的五个数据源里。这次失败给团队上了一课：图谱只能在它看得见的数据范围内推理，边界之外的因素它永远发现不了。之后团队在界面上加了明确提示：「本诊断基于MES/FDC/EDA/维修/配方五源数据，未覆盖测试程序、客户变更、外部供应链等信息」。

关于使用频率的真实数据：上线一年，图谱累计被使用1847次，其中排查类查询1203次、探索类查询644次。活跃用户42人，占目标用户群的63%。使用频率呈明显的长尾分布，前10名用户贡献了58%的查询量——这提示我们工具的推广不能只靠上线培训，需要持续的案例宣讲和场景挖掘。

成本方面也如实分享。图谱平台的一次性建设投入约为2.5人年，年度运维成本包括图数据库服务器（3节点集群）、LLM API调用（月均约1.2万次调用）和0.5人力的维护。相比之下，收益主要体现在排查工时的节省：按平均每次深度排查节省12人日、年度深度排查约35次计算，年节省约420人日，投入产出比是清晰的正向。

七、实施效果：从三天到十分钟

效果一：诊断效率。复杂跨系统问题的根因定位时间从平均2.8天缩短到平均0.4天（约3.2小时），缩短86%。其中纯图谱查询耗时通常在10到30秒，其余时间用于工程师验证假设。

效果二：假设准确率。系统给出的Top3候选路径中包含真实根因的比例（Top3命中率）为74%，Top1命中率为51%。这个数字看起来不算高，但要理解它的参照系——在没有图谱之前，工程师第一天提出的假设方向命中率大约在30%左右。

效果三：伪因果控制。引入倾向得分匹配和混淆变量提示后，伪因果推荐比例从37%降到11%，且剩余的伪因果中有八成会被界面上的混淆提示标记出来，工程师能快速识别。

效果四：查询性能。图规模稳定在1200万节点、8100万边，五跳以内路径查询的P50响应190毫秒、P95响应810毫秒、P99响应2.3秒。这个性能支撑了交互式的探索体验，工程师可以连续追问而不必等待。

效果五：Text2Cypher准确率。经过Schema注入、Few-shot优化和校验器三层加固，中文自然语言查询的可执行率从初期的77%提升到98.2%，语义正确率（返回结果符合用户意图）从61%提升到89%。剩余的失败案例主要集中在含有复杂时间约束和嵌套聚合的问题上。

效果六：知识沉淀。一年内积累了217个已验证的诊断案例，这些案例既是Few-shot样例库的来源，也成了新工程师的培训教材。团队观察到一个有意思的现象：新人使用图谱的频率显著高于资深工程师，因为资深工程师脑子里有自己的因果模型，而新人需要工具补足经验——从这个角度看，图谱本质上是把资深工程师的经验结构化、可复用化。

最后给准备做类似项目的团队三条建议。第一，先解决主数据一致性，图谱的质量上限由数据基础决定，跳过这一步做出来的图谱是断裂的。第二，Schema从小做起，三类实体上线远好于九类实体永远在设计。第三，把LLM定位为「解释器和翻译器」而不是「决策者」，所有结论必须可追溯到原始数据，这是工程场景下AI应用能被信任的前提。

八、配图说明

图1：知识图谱上线前后六项核心指标对比，定位时长从67小时降至3.2小时

图2：十二个月内图规模、查询性能与使用量的同步演进曲线

九、附表：关键数据对照

附表1：实体类型等关键维度对照

附表2：因果打分信号等关键维度对照

十、配套资料与VIP资源

本文配套了完整的实战资料包。关注博客「VIP资源」区，可免费获取以下5项配套资料（持续更新MES/SPC/EAP/良率实战资料）：

Fab工艺知识图谱Schema定义文档（9类实体、14类关系、完整属性与时间约束设计）

Text2Cypher提示词模板与86条查询范例库（含Schema注入与校验器实现思路）

因果打分算法实现说明（时序约束/Cohen d/倾向得分匹配的计算步骤与阈值标定）

图谱数据接入标准化清单（五源系统字段映射、时区统一、Golden ID对齐操作指南）

知识图谱项目三期实施计划模板（含里程碑、资源投入、性能压测方案与验收标准）

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

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

你在实际工作中遇到过类似情况吗？欢迎在评论区分享你的实战经验，一起交流进步。

标签：半导体AI融合 | 半导体 | 智能制造 | Fab实战 | 工程师笔记