基于大模型AI的芯片电子束晶圆检测系统平台设计与实践

做半导体工艺或者设备这一行的朋友应该对“晶圆检测”这四个字不陌生。但今天聊的这套东西不是常规的光学检测机台而是把大模型和人工智能直接塞进电子束晶圆检测平台里做核心引擎。这个方向在行业里属于既有硬件门槛、又有软件深度的交叉地带很多团队在做但真正能把它从论文变成产线工具的并不多。这篇文章我就围绕“基于大模型人工智能的芯片电子束晶圆检测系统平台软件”这个项目把整个设计思路、技术选型、核心实现和踩坑实录都摊开来讲希望能给正在做相关方向的工程师或者准备立项的团队一些参考。先解释清楚这套系统到底解决什么问题。电子束检测设备能够以极高分辨率对晶圆表面进行扫描成像检测物理缺陷、图形异常、异物残留等问题精度远高于光学检测。但电子束扫描速度慢产生的高分辨率图像数据量极其庞大传统基于规则或简单CNN分类器的算法很难同时满足“缺陷检出率高”“误报率低”“适应新缺陷类型快”这三个要求。这套平台软件的核心就是把大模型的能力融入缺陷检测、分类、语义描述和工艺回溯的完整链路中让电子束设备不仅“看得清”而且“想得明白”。如果你是做半导体设备软件开发的、做AI算法工程化的、或者在FAB里负责良率提升的这篇文章都值得看完。我从系统架构到代码实现再到部署上线的坑一项项讲清楚。1. 内容整体设计与思路拆解1.1 电子束晶圆检测为什么需要大模型先聊一个核心问题传统方案为什么不够用。电子束检测EBIElectron Beam Inspection和光学检测OBIOptical Beam Inspection最大的区别在于成像机制。电子束通过扫描电子显微镜的原理逐点轰击晶圆表面收集二次电子或背散射电子信号来成像。它的空间分辨率可以达到纳米级能够看到光学显微镜下完全无法分辨的微小缺陷比如极细的金属残留、接触孔底部的污染物、图形边缘的毛刺。但代价是“慢”。电子束扫描一片晶圆动辄需要数小时甚至一整夜的时间而不像光学检测几十分钟就能扫完。所以电子束检测通常用于关键层抽检、缺陷复查和良率异常回溯不会在产线上对所有晶圆全检。正因为这样电子束检测产出的图像数据非常稀缺且宝贵而且图像中往往存在大量重复的背景纹理、复杂的电路图案和随机噪声。传统的检测算法一般分为两步用DDBDie-to-Die或者DBDie-to-Database模式做差异比对找出异常点再用分类器或者人工review来决定缺陷的类型和严重程度。这里有几个致命的问题。第一DDB比对产生的候选缺陷里假缺陷的数量远多于真缺陷。打一个比方你去车站安检传统算法就像靠“物品是不是金属”来报警结果整条皮带、钥匙串全都触发警报真正的违禁品淹没在提示音里。第二缺陷类型多种多样并且新工艺、新设计不断出现之前从未见过的缺陷形态层出不穷。用定死的分类模型遇到新类型只能重新标注、重新训练周期太长。第三缺陷严重程度的判定非常依赖经验丰富的工艺工程师他们通过看图像结合工艺背景来判断这个缺陷会不会影响良率这一步很难被传统算法替代。大模型的加入恰好改变了这个局面。大模型的几个天然能力在这里都派上了用场其一多模态图像文本对齐能力可以把缺陷图像映射到语义空间让系统能用自然语言生成缺陷描述其二少样本乃至零样本的迁移能力遇到新缺陷类型不需要几千张标注图几十张甚至几张图就能让模型快速学到区分边界其三强大的特征提取和信息压缩能力可以从海量高分辨率图像中自学习到工艺相关的关键模式而不是依赖人工设计的特征。1.2 系统平台的总体架构与功能边界基于上述痛点这套平台软件的整体架构我拆成了五个层次数据接入层、数据管理层、AI分析引擎层、业务应用层、系统集成层。数据接入层负责与电子束机台通信接收扫描原始数据、图像文件、机台日志和工艺配方信息。这里最麻烦的是不同厂商、不同型号的机台数据格式完全不一样有的输出的是TIFF多帧图有的是二进制裸数据有的还带一套私有的元数据文件。所以接入层必须做统一的格式解析和数据标准化。数据管理层负责图像数据的存储、编目、检索和生命周期管理。电子束扫描一张图可能有几百MB甚至上GB一个批次下来就是TB级别的数据。这层还得管好缺陷的标注信息、图像之间的关系同一颗die、同一片wafer、同一个lot为后续模型训练和推理提供干净、可追溯的数据集。AI分析引擎层是整个平台最核心的部分。它承载了大模型的推理服务、缺陷检测模型、语义描述模型和工艺知识库。图像先经过轻量级检测模型快速定位可疑区域再由大模型做精细分类和描述双级级联架构是这套系统精度和速度兼顾的关键。业务应用层是给用户实际使用的界面和流程包括缺陷分布图、缺陷分类结果、review列表、报警规则等。工艺工程师不用关心底层的模型细节只需要在界面上看结果、做确认、反馈标注这些反馈又自动回流到数据层形成数据闭环。系统集成层负责与FAB里的MES制造执行系统、良率管理系统YMS、设备自动化程序SECS/GEM进行对接。检测结果需要能自动传递到良率系统中进行统计和分析否则这套平台的信息就孤立了。这五层架构看起来中规中矩但是实际落地时每一层都有很多细节。下面我从AI引擎和业务实现两个方向分别展开。2. 核心细节解析与实操要点2.1 电子束图像的特点与预处理策略在训练模型前必须先理解电子束图像本身的特点否则后面做的所有事情都事倍功半。第一高噪声。电子束成像本质上是采集二次电子的计数服从泊松分布。束流越低、扫描速度越快噪声越明显。这种噪声在高倍率图像里呈现为大量随机散落的亮点和暗点而且和真正的纳米级缺陷在形态上有时非常接近。第二灰度动态范围大。电子束图像的灰度值反映的是材料表面的局部电势和形貌不同材料、不同结构和不同高度的图形灰度差异非常大。有些图像整体偏暗但局部高亮有些图像背景灰阶分布均匀但缺陷区域的对比度极高。所以全局的归一化方法不好用我的建议是采用分块的局部自适应归一化同时保留灰度直方图信息作为辅助特征。第三图形重复性高。晶圆上同一个die的图形设计是完全相同的这既是检测的有利条件也是干扰项。DDB比对模式就是利用相邻die的重复性来找出差异。但对于AI模型来说如果训练集中不同die的图像差异很小模型很容易过拟合到特定的版图结构上一旦遇到不同产品的晶圆检测性能会迅速下降。基于这些特点我的预处理流程是先做中值滤波去除非局部异常点再做基于灰度的自适应阈值分割来生成缺陷候选区域然后以候选区域为中心裁剪固定尺寸的patch并且同时保留小尺寸的全局上下文图和原始局部放大图一起送入模型。这里有一个经验之谈对于缺陷检测模型输入的图像块不要只裁剪缺陷本体一定要包含足够多的周围图形信息。就好比你判断一个人是不是受伤了不能只盯着伤口那一个点还得看伤口周围的皮肤状态和位置。缺陷周围的图形结构、密度、线条方向往往是判断缺陷类型的决定性因素。2.2 大模型在缺陷分析中的角色分配大模型在这个平台里不是拿来直接当检测器的。我见过一些团队直接把高分辨率整图塞给视觉大模型让它输出缺陷位置和类别结果在真实数据上跑下来效果并不理想。原因很简单电子束图像的分辨率极高而大模型输入有明确的尺寸限制直接缩图会把纳米级缺陷缩小到几个像素信息全部丢失。所以我的设计原则是“让专业的人做专业的事”轻量级检测模型先做“大海捞针”找出可能异常的区域大模型再以裁切好的图像块为输入做缺陷的精细分类、语义描述和工艺相关性判断。具体来说缺陷分析链路里我分配了三类角色第一类是大模型作为“缺陷分类器”。我给每张缺陷patch打上类别标签比如particle颗粒、bridge桥接、not-open未开孔、residue残留、scratch划伤等等。这个任务微调一个视觉语言模型来做输入图像加一个文本提示词比如“请根据以下晶圆缺陷图像判断缺陷类型”模型输出结构化的分类结果。第二类是大模型作为“缺陷描述器”。分类标签只能告诉工程师“这是什么类型”但无法描述“这个缺陷长什么样、有多大、大概在什么位置、周边是什么情况”。用多模态大模型生成一段自然语言描述能够快速帮助工程师review。比如“在金属线密集区域发现一处疑似桥接缺陷缺陷尺寸约为120nm跨越两条相邻金属线周围无其他异常”这样一条描述工程师不需要放大图像就能掌握关键信息。第三类是大模型作为“工艺知识问答引擎”。我构建了一个工艺知识库把设备参数、工艺步骤和历史缺陷案例文本化利用大模型的能力让工程师可以用自然语言提问比如“栅极氧化层工艺中出现颗粒类缺陷可能的主要原因有哪些”系统结合知识库和当批检测数据返回带依据的分析建议。这里是最关键的实操建议不要试图让单个大模型干完所有事更不要用未经微调的开源通用模型直接上线。电子束图像和自然图像存在巨大的domain gap通用视觉模型根本无法区分金属残留和桥接必须用真实的电子束图像做微调。微调数据至少要有每类缺陷200到500张图加上对应的自然语言描述才能达到可用的水平。2.3 半导体场景对AI模型的额外约束半导体制造是极端追求良率和安全的领域AI模型在这里的约束条件比在互联网场景严格得多。第一个约束是误报率False Alarm Rate必须极低。高误报率意味着工程师需要花费大量时间review假缺陷AI不仅没有省人反而增加了负担。为了控制误报我的策略是给模型设置“置信度门槛”和“人工复审通道”双层机制。高置信度的缺陷自动归类入库低置信度的结果进入人工review队列累计反馈修正模型。这样既保证了效率又让模型持续进步。第二个约束是模型的可解释性。在大规模量产线上工艺工程师不会轻易信任一个只输出结论、不讲理由的黑盒模型。所以在缺陷判定界面里我要求模型必须展示依据——包括缺陷区域的热力图、相似历史案例的参考图、以及模型生成的语义描述。有了这些信息工程师才能判断模型的结论是否合理。第三个约束是数据安全与合规。FAB里的晶圆图像数据涉及客户产品的敏感信息不可能直接上传到公网大模型API。所以整套系统必须支持纯本地化部署模型格式要能转换成可在内网GPU服务器上运行的推理引擎。这既是信息安全要求也是响应速度要求。我在选型时综合对比了几种开源基座模型最终选择了支持本地部署和微调的方案。这里补充一句模型不是越大越好。在算力有限、推理时延敏感的生产环境中一个参数量适中、专为视觉任务优化的模型配合良好的训练策略其效果往往优于盲目追求超大参数量的通用模型。毕竟在产线上稳定、可控、可复现才是王道。3. 实操过程与核心环节实现3.1 平台软件的模块划分与数据流设计动手写代码之前我先把平台的模块边界画清楚了。平台分成六个核心服务采集服务、预处理服务、推理服务、标注管理服务、业务展示服务、系统管理服务。各个服务之间通过消息队列和RESTful API通信避免耦合。采集服务是唯一与机台硬件打交道的模块。它通过设备厂商提供的SDK或者SECS/GEM协议实时监控机台的扫描进度当一张图像扫描完成后立即将图像数据拉取到本地存储同时记录图像对应的物理坐标、扫描参数和工艺ID。预处理服务收到原始图像后依次执行降噪、灰度校正、候选区域提取和patch裁剪。这一步输出的结果是一个包含候选缺陷框的JSON文件加上一组JPEG或PNG格式的patch图像。这个服务要用GPU并行处理否则图像处理速度跟不上电子束扫描的产出速度。推理服务是整个平台的大脑。它在GPU服务器上加载两个模型轻量级检测模型和大模型。推理服务对外提供两种接口一种是单张patch的实时推理接口一种是批量异步推理任务。批量异步推理用于处理扫描完成后的全量复查实时推理用于工程师在界面上的交互式判断。标注管理服务是为模型迭代服务的。工程师在review时对模型结果进行确认或修改这些标注数据会进入标注库。标注库里的数据经过清洗和增强后可以触发模型的增量训练任务。业务展示服务就是Web前端我采用的是前后端分离架构前端用Vue3搭建后端用Python FastAPI提供接口。主界面包括晶圆图Wafer Map、缺陷列表、缺陷图像查看器、趋势图表和报警配置。3.2 模型训练与微调流程详解模型微调是整个平台中最核心也最容易出问题的环节。我在这里记录一下我自己跑通的一套流程。第一步数据准备。从FAB拿到历史缺陷图像按缺陷类型进行分类整理。每张图像至少包含一个缺陷并且要有明确的标签。如果条件允许最好让两位以上的工程师独立标注然后取一致性较高的数据作为训练集不一致的样本由经验最丰富的工程师终审。图像尺寸统一裁剪为512x512或1024x1024这个尺寸能较好平衡细节保留和计算开销。第二步基座模型选择。我用人话说一下选择思路。视觉主干网络负责从图像中提取特征大模型负责理解任务描述和生成文本。对于缺陷分类这种任务用图像编码器加轻量级文本解码器的组合就足够了。我选用的是开源的视觉语言模型框架因为它自带图像和文本对齐的能力方便后面做缺陷描述任务。最终微调的参数量控制在几亿到几十亿之间推理速度可以接受。这里有个判断标准如果一个缺陷patch的推理时间超过1秒在批量复查时就会显得很拖沓。第三步LoRA微调。全参微调在算力有限的情况下不建议尝试。我使用LoRALow-Rank Adaptation技术只训练矩阵分解后的低秩增量部分。用一句话解释LoRA的逻辑完整模型权重是“长跑运动员”在特定任务上微调相当于让他去“跨栏”不用重新训练整个人的所有肌肉只需要调整跨栏动作相关的少数肌群。这样训练速度快显存占用小而且可以同时保留多个任务版本的模型按需切换。微调时的超参数可以参考如下设置学习率1e-4到5e-5之间建议用warmup策略前几百步先小步跑再进入正常学习率。Batch size显存允许的前提下尽量设大至少4以上不然BN统计不稳定。训练轮数epochs10到30轮之间同时监控验证集loss防止过拟合。优化器AdamWweight decay设0.01左右。第四步评估与上线。在独立的验证集上计算每个缺陷类别的精确率Precision、召回率Recall和F1分数。不能只看总体准确率一定要分类型统计。颗粒类缺陷通常容易识别而一些形貌细微的缺陷如接触孔底部的微小残留很容易混淆。评估通过后将模型导出为推理引擎可加载的格式部署到GPU服务器上。3.3 推理服务的性能优化与部署实践下面这部分是平台真正能落地到产线的关键推理性能。一套检测平台如果跑得慢在FAB里就是鸡肋。我以一片12英寸晶圆为例来算一笔账。假设电子束机台以抽检模式扫描晶圆的关键层产生约5000个候选缺陷区域。每个候选区域裁剪成一组patch之后需要送入大模型进行精细分类和描述。单个patch的推理时间为0.8秒那么5000个patch的总推理时间大约是4000秒超过一个小时。虽然电子束扫描本身的耗时更长推理可以并行进行但如果不做性能优化推理服务很容易成为整条链路的瓶颈。我采用的优化手段包括模型量化将模型权重从FP16量化到INT8推理速度提升近3倍精度损失控制在1%以内。动态批处理Dynamic Batching把并发请求攒成批次统一推理充分利用GPU并行能力。这里要设置一个合理的最大batch size和等待时间比如等待40毫秒或者攒够32个请求就立即推理。多模型并行部署把轻量级检测模型和大模型分别部署在不同的GPU或者不同的推理实例上避免互相挤占显存。缓存机制相同类别、相似特征的缺陷patch其推理结果可以缓存。实际数据中大量缺陷是重复出现的缓存命中率能达到30%以上能有效降低重复计算的开销。异步任务管理批量复查任务全部走异步队列实时交互推理才走同步接口两者隔离防止批量任务堵塞交互通道。实测下来经过这些优化后单GPU服务器可以支撑约5000个patch的复查任务在10分钟内完成单张图的实时推理延迟低于300毫秒完全满足产线使用要求。这里我特别想强调一下动态批处理的重要性很多人拿到模型之后直接一个个请求发过去GPU一边在疯狂运算一边在空闲等待利用率低得可怜。动态批处理就像是把散客拼成旅行团同一个导游一次带几十个人走同样的路线效率自然翻倍。3.4 与业务系统的集成和自动化流程再好的AI引擎如果和FAB的业务流程脱节价值也发挥不出来。所以在集成层我重点做了两件事。第一件事是和MES系统的对接。通过SECS/GEM协议平台软件能够实时接收来自MES的检测任务指令包括晶圆ID、检测区域、检测模式和工艺配方号。检测完成后平台自动将结果上传回MES生成检测报告。这样可以做到全过程无人干预从设备扫描到AI分析再到结果回报全部自动化流转。实际执行中很多老款机台的SECS/GEM通信模块只支持部分命令需要通过设备厂商提供的底层库来做功能补充这一块需要有嵌入式软件经验的工程师一起协作。第二件事是和良率管理系统YMS的数据打通。平台将每个缺陷的物理坐标、尺寸、类型、所属晶圆和批次信息以标准格式写入YMS数据库。YMS系统将缺陷数据和电性测试数据关联可以分析出哪些缺陷真正导致良率损失哪些缺陷虽然是真实的但对产品性能无害。这层数据打通之后工艺工程师能依据“缺陷-良率”的关联分析精准制定工艺改善方案而不是胡子眉毛一把抓。集成过程中还有一个容易被忽略的点历史数据迁移。项目上线时FAB里往往已经有大量的历史缺陷图像和标注记录散落在旧系统和工程师的本地电脑里。这些数据是模型训练初期最宝贵的资源我专门写了一套数据迁移工具支持批量导入历史图像、解析旧的缺陷坐标文件并自动关联到对应的产品和工艺节点。没有这一步新模型冷启动的数据基础就会很薄弱。4. 常见问题与排查技巧实录这部分我从真实项目里挑几个典型问题整理成速查表每条都是我亲眼见过甚至亲手修过的。4.1 缺陷误报率居高不下这是一个最常见也最头疼的问题。排查思路是先区分误报是来自初检阶段还是模型分类阶段。如果是初检阶段误报多先检查DDB比对时相邻die的对齐是否准确。晶圆经过光刻、刻蚀等工艺后会有微小的形变和偏移如果比对窗口选得不合适或者对位精度不够正常的图形差异都会被标成缺陷。我的经验是把比对窗口从固定尺寸改为自适应根据晶圆图的变形场做非线性匹配同时适当增大比对的容差阈值。如果是模型分类阶段把“假缺陷”当成了“真缺陷”就要检查训练数据的标签是否准确。尤其要注意很多标注人员会把图像噪声当成缺陷标注模型学到的是“有噪声就是有缺陷”上线后自然在每一个噪声区域都在报警。解决办法是严格清洗训练集把这类模糊样本单独挑出来由资深工程师重新标注。另一个有效措施是在模型后处理时引入物理约束规则比如缺陷面积小于某个阈值且对比度低于某个阈值时判定为疑似噪声。4.2 新缺陷类型出现后模型识别不出新工艺导入初期经常会出现模型从未见过的缺陷类型。传统做法是等积累一定量数据后再重新训练但这个周期在产线上根本等不起。我现在的处理方案是两段式应对。短期方案是启动“未知类别检测”机制将模型的输出概率分布中置信度低于设定阈值的结果自动归入“unknown未知”类别并触发报警。工程师在review界面看到这条未知类别样本后可以选择建立新类别并标注少量样本比如20到50张。长期方案是这些少量样本进入持续学习队列等样本量累积到一定程度后执行一轮轻量化微调重复利用LoRA技术模型就会学会新缺陷类型。这套机制让我把新缺陷的适应周期从一个多月缩短到一周左右。这里有一个需要特别注意的问题持续学习有“灾难性遗忘”风险即模型在学习新类别时会把之前学会的旧类别忘掉。我的解决办法是在微调新类别的训练集中混入10%到20%的旧类别代表性样本把旧知识“锁住”。4.3 推理服务显存溢出大模型的显存消耗确实大尤其在动态批处理启动后并发请求一多显存很容易撑爆。我遇到过不止一次推理服务因为显存溢出直接崩溃导致正在处理的整个批次任务全部失败。排查和解决路径是这样的先确认模型加载时的显存占用再评估单batch推理时的额外开销。如果显存紧张最直接的手段是降低最大batch size其次可以做模型切分将模型的不同层分散到多张GPU上如果还想进一步压缩可以针对全连接层的权重做剪枝和量化。还有一个容易被忽略的问题是PyTorch的显存缓存机制显存碎片化严重时即使总显存够用也可能因为找不到连续空闲块而报错。这时可以定期执行显存碎片整理同时在服务启动时设置合理的显存分配策略。另外一定要为推理服务配置健康检查和自动重启机制。我用Kubernetes部署推理服务设置liveness探针定期检测服务状态一旦检测到异常就自动重建容器这样即使出现崩溃也能快速恢复不至于影响长时间无人值守的批量复查任务。4.4 平台与机台设备通信不稳定设备通信是集成阶段绕不开的坑。电子束机台和平台之间的通信经常出现连接超时、数据丢包和命令响应异常的情况。我总结的经验是不要直接使用设备SDK的高层封装去发送大文件传输请求底层暴露的传输控制接口要自己接管。图像数据建议通过单独的FTP/SFTP通道传输而控制命令走独立的TCP长连接两者物理分离避免大数据流量干扰控制指令的实时性。其次要给所有命令响应设置超时重试机制。比如机台在扫描过程中CPU负载很高时SDK命令的响应时间可能长达几十秒如果设置的超时时间只有10秒就会频繁出现误判失败并重复下发指令导致机台状态错乱。还有一个细节是时间同步。机台端和服务器端如果系统时间不同步日志记录、数据关联和批次管理都会出现严重错位。上线前务必部署NTP时间同步服务确保所有节点的时钟偏差控制在毫秒级。为了方便查阅我把上面这些常见问题整理成了一张速查表问题现象可能原因排查方法解决方案误报率高DDB比对未考虑晶圆形变检查缺陷分布是否集中在晶圆边缘自适应比对窗口非线性配准误报率高训练集标签含噪声抽查训练集统计标注一致性清洗数据资深工程师复核新缺陷识别不出模型没见过该类型查看模型输出是否为低置信度启用未知类别检测持续学习显存溢出并发请求过多或碎片化监控显存占用曲线限流、模型切分、碎片整理通信超时大文件传输挤占控制通道检查网络流量分布控制通道和数据通道分离结果数据错乱设备端与服务器时间不同步对比两端日志时间戳部署NTP服务统一时钟5. 更进一步从检测工具到良率大脑的扩展路径这套平台跑通之后整个系统的价值和潜力其实远远不止“检缺陷”那么简单。我最近在做的扩展方向是把平台从“检测工具”升级成“工艺良率大脑”。第一个方向是缺陷根因分析。利用大模型的语义理解能力把缺陷图像、设备工艺参数、历史维修记录和材料批次信息进行关联分析。当某一类缺陷出现频次异常升高时平台自动推送根因假设。比如系统发现“某批次晶圆边缘区域颗粒缺陷增多”结合设备参数时间线可能定位到“光刻胶涂布设备的喷头清洗频率降低”这一关键变量。这类跨模态的关联推理在过去需要工程师人工翻看大量数据和日志现在交给大模型做初步筛选和推理效率大幅提升。第二个方向是建立跨厂区、跨设备的“缺陷知识库”。半导体制造集团往往有多个厂区不同厂区使用不同厂商的设备但生产的可能是一样的产品。过去每个厂的数据是孤岛无法直接对比。现在通过平台将各个厂区的缺陷图像和描述统一汇聚到知识库形成一个中心化的“缺陷百科全书”。当某个厂区发现异常缺陷时可以立即检索其他厂区是否出现过类似情况以及当时的处理措施和最终效果。这种知识共享机制能显著缩短异常处置周期。第三个方向是自动生成检测报告和工艺建议。原来工程师每天要花大量时间写报告而现在平台可以自动生成标准化的检测日报、周报并根据缺陷趋势自动给出建议比如“近三天金属线桥接缺陷比例上升2.1%建议检查光刻胶显影工艺的漂洗时间”。虽然最终决策仍然需要人来拍板但大模型把大量重复性、整理性的工作接了过去工程师可以把精力集中在真正需要判断力的环节上。回到最初的问题电子束晶圆检测这个细分赛道过去一直被设备和算法的高门槛限制着。大模型的出现给这个领域带来了新的变量。它不是来替代电子束硬件设备的而是让电子束设备采集到的珍贵图像数据释放出更大的价值。对我来说这个项目最大的成就感不是模型跑通了、上线的指标达标了而是系统的确帮工艺工程师省下了大量盯图的时间让他们能更快地找到影响良率的真正根因。最后分享一个我认为最有价值的经验在这个系统里最难的永远不是算法而是算法工程师和工艺工程师之间的沟通。算法工程师要听得懂“金属线桥接”“接触孔底部残留”这些工艺术语工艺工程师也要理解模型不是“看一眼就能判断”而是需要他们持续提供高质量标注和反馈。把这两个团队的语言对齐了技术落地只是时间问题。希望这篇文章能给正在做类似方向的朋友一些启发少走一些弯路。