一、背景故事：模型把WAT理解成了水质检测

我们最早尝试把大模型用在产线场景，是想做一个内部的技术问答助手，帮新人回答那些反复被问的基础问题。第一版直接接了一个开源基础模型，找了十位工程师试用一周。反馈相当一致：不能用。

不能用的核心原因不是模型笨，而是它完全不理解我们的语言。几个真实的失败例子：问它WAT数据异常怎么排查，它开始讲水质检测（Water Analysis Test）的常见污染物指标；问它这批lot为什么被hold了，它解释hold在电话系统里是通话保持的意思；问它CP良率和FT良率的差异说明什么，它把CP理解成了Critical Path关键路径。这些不是偶发错误，我们后来做的基准测试显示，基础模型在Fab术语解释任务上的准确率只有51.3%，缩写消歧任务更低，只有38.7%。

第一反应是用提示工程解决：把术语表塞进系统提示里。这个办法确实有效，准确率提升到72.6%。但问题很快出现：我们的术语表有四百多条，全塞进去占掉了大量上下文窗口，每次推理的token成本上升了78%，响应时间也明显变慢。而且塞进去的术语越多，模型对每一条的注意力越分散，再往上加收益递减。

于是我们决定试试微调。当时最大的顾虑是成本：听说微调大模型要几十张A100，这不是我们这个规模的团队能负担的。实际做下来发现完全不是这样。本文记录的这次实测，用的是一张24GB显存的消费级显卡，3200条自建数据，训练七小时，电费加折旧的边际成本在两百元人民币量级。这篇文章把整个过程包括踩的坑完整写出来。

二、技术原理：LoRA为什么便宜

全参数微调的做法是把模型所有权重都参与梯度更新。一个70亿参数的模型，光是权重本身用16位精度存就要14GB，训练时还需要存梯度（同样14GB）、优化器状态（Adam需要一阶和二阶动量，再加28GB），合计接近60GB，这还没算激活值。这就是为什么全参数微调需要多卡。

LoRA的核心洞察是：微调过程中权重的变化量往往是低秩的。也就是说，虽然权重矩阵W很大（比如4096乘4096），但微调带来的改变量ΔW可以用两个瘦长矩阵的乘积来近似：ΔW约等于B乘A，其中A的形状是r乘4096，B的形状是4096乘r，r就是秩，通常取8到64。当r等于16时，这两个矩阵的参数量是4096乘16乘2等于131072，而原矩阵是4096乘4096等于16777216，只有原来的0.78%。

表1：四条技术路线的适用边界与选型建议

训练时冻结原权重W，只更新A和B。这样需要存梯度和优化器状态的参数量降到了不足1%，显存需求从60GB级降到十几GB，单张消费级卡就能跑。推理时可以把B乘A加回到W里，得到一个和原模型结构完全相同的新模型，推理速度没有任何损失——这就是本文图1中LoRA方案推理成本只有104（相对基础模型100）的原因，那4%的差异来自输出长度略有增加。

还有一个进一步降低成本的技术是QLoRA，它把冻结的基础模型权重量化到4位存储，显存再降一半以上，让13B甚至更大的模型也能在单张24GB卡上微调。代价是训练速度慢约三成，效果损失在1到2个百分点。我们这次用的是7B模型加标准LoRA，显存占用峰值18.4GB，没有用到量化。

需要明确LoRA能做什么不能做什么。它擅长的是让模型学会一套语言习惯和概念映射：看到WAT就往晶圆允收测试上想，看到hold就理解为批次冻结状态，回答问题时自然使用产线的表达方式。它不擅长的是记住具体的事实性知识，比如某台设备的当前状态、某份文档第几页写了什么。这类需求应该用RAG。把两者对立起来是常见的误解，正确做法是组合使用。

三、现状分析：产线上的大模型应用都在做什么

我调研过的半导体企业里，大模型应用大致有三种成熟度。第一种是直接用商用API做通用助手，写邮件、整理会议纪要、翻译文档。这类应用不涉及领域知识，效果不错，但也没什么门槛，而且涉及内部信息时有合规顾虑。

第二种是本地部署基础模型加提示工程。出于数据安全考虑，半导体企业普遍倾向本地部署。这一步的门槛已经很低，用现成的推理框架半天就能搭起来。问题就是本文开头描述的：通用模型不懂领域语言，而提示工程的天花板明显。

第三种是RAG。这是目前落地最多的方案，把内部的SOP、设备手册、故障案例库切块向量化，检索后拼进上下文。RAG的优势是知识更新即时、答案可溯源，这在工程场景非常重要。但RAG有个隐蔽的短板：如果模型不理解查询里的术语，它连检索的query都构造不好。我们实测过，同样的RAG系统，用基础模型做查询理解时检索命中率是68%，换成微调后的模型是89%。这就是为什么两者应该组合。

真正做微调的很少，主要有三个顾虑：一是以为成本高，这个前面已经澄清；二是不知道数据从哪来；三是不知道怎么判断微调到底有没有用。后两个才是真问题，也是本文后面重点讲的部分。

四、瓶颈问题：卡在哪里

第一个瓶颈是数据。微调需要指令数据，格式是问题加回答的配对。但工厂里现成的文档都不是这个格式：SOP是流程描述，故障报告是叙述文本，术语表是词条列表。把这些转成高质量的指令对需要大量人工，这是最大的成本项。我们最初估计三千条数据要花两周，实际用了三周多。

第二个瓶颈是评测。这是我认为最容易被低估的环节。很多人微调完就看loss下降了、随便问几个问题觉得答得不错，就宣布成功了。这非常危险。本文图2展示的就是一个真实的教训：训练损失从头到尾都在下降，但验证集上的术语准确率在step 620左右见顶后开始回落。如果按loss最低选检查点，会选到step 1200，那个检查点的实际能力比最优点低了约6个百分点。

第三个瓶颈是灾难性遗忘。模型学会了Fab术语，但通用能力退化了。我们在一次失败的尝试中把学习率设到5e-4训练了6轮，结果模型确实把术语记得滚瓜烂熟，但让它写一段普通的中文说明，句子结构变得非常僵硬，而且开始在无关的对话里硬塞Fab术语。这个现象在小数据集上尤其明显，因为模型会过度拟合训练数据的表达模式。

第四个瓶颈是评测集污染。我们第一次评测得出的准确率是96.8%，高兴了半天，后来发现评测集里有相当一部分题目和训练集来自同一批原始文档，虽然文字不完全相同但知识点重合。重新构造了一个完全独立来源的评测集之后，真实准确率是92.7%。这4.1个百分点的水分，如果没发现，就会导致对模型能力的错误判断。

五、解决方案：完整的实施方法

先说数据集构造，这是投入最大也最关键的部分。我们最终的3200条数据由四类组成，比例是经过两轮迭代调出来的。

第一类是术语解释对，占比约35%，共1120条。来源是前面提到的内部术语字典。构造方法不是简单地把词条变成问答，那样模型只会学到背诵。我们对每个术语构造了三到四种不同的提问方式：直接问定义、在句子中使用后问含义、给出错误理解让模型纠正、问与相近术语的区别。多样化的提问方式让模型学到的是概念而不是字符串匹配。

第二类是缩写消歧对，占比约20%，共640条。这类专门针对CP、PM、FT这些一词多义的缩写。构造方法是同一个缩写放在不同语境的句子里，要求模型判断此处指什么。这一类数据的效果最明显，缩写消歧准确率从38.7%提升到90.5%，是四项指标中提升幅度最大的。

第三类是流程问答对，占比约30%，共960条。来源是把SOP和故障处理案例改写成问答。这一类最耗人工，因为需要工程师逐条审核答案的技术正确性。我们的做法是先用大模型基于原文档批量生成初稿，再由工程师审核修改，这样比从零写快了大约三倍。审核时的重点是删掉那些看起来对但不严谨的表述，这类内容如果进了训练集，模型会把不严谨的习惯学过去。

图1：四种方案的实测对比。LoRA在术语解释与缩写消歧上表现最好且推理成本几乎不增加，但在需要引用具体文档的流程问答上不如RAG，这说明两者应该组合而非二选一。

第四类是通用能力保持数据，占比约15%，共480条。这一类是专门为对抗灾难性遗忘加的，内容是与Fab无关的通用问答、常识推理、文本改写。加了这一类之后，模型在通用任务上的表现基本维持在基础模型水平，同时Fab任务的效果没有明显损失。这个技巧成本很低但很有效，强烈建议保留。

超参数方面，完整的实测结果见本文表2。几个关键结论：秩r取16是性价比最优点，r等于8时术语准确率低约3个百分点，r等于32时提升不到1个百分点但显存翻倍；目标模块一定要挂满，只挂q_proj和v_proj虽然训练快，但效果差约6个百分点，把MLP的投影层也挂上收益明显；学习率2e-4是稳定区间的中值，5e-4在我们的数据规模下会在300步内震荡。

评测方案是整个项目里我最想强调的部分。我们建了三层评测：第一层是自动化的选择题评测集，400道题，覆盖术语解释、缩写消歧、流程问答三类，题目来源与训练数据完全隔离（用了另一个部门提供的文档和一批未纳入训练的老案例）。这一层在训练过程中每50步跑一次，用于选检查点。第二层是人工盲评，50道开放题，两个模型的答案随机打乱后由三位工程师独立打分。第三层是实际使用记录，上线后收集真实提问与用户反馈。

六、实战案例：完整的一次训练

把过程按时间线走一遍。硬件是一张24GB显存的消费级显卡，基础模型是一个70亿参数的开源中文模型。环境准备用了半天，主要是驱动和依赖版本的匹配，这一步的建议是直接用官方推荐的镜像，不要自己一个个装，版本冲突能耗掉一整天。

数据准备三周。第一周做术语解释对和缩写消歧对，这两类有现成的术语字典做基础，产出较快。第二周和第三周做流程问答对，瓶颈在工程师审核。我们的做法是把审核任务拆成每人每天20条，安排在下午相对空闲的时段，五个人两周完成。如果集中安排给一两个人，大概率会因为疲劳导致后期审核质量下降。

第一次训练是失败的。参数设的是r等于8、学习率5e-4、6个epoch。训练很顺利，loss从2.4降到0.31，看起来非常漂亮。但自动评测显示术语准确率只有79.4%，而且人工试用发现模型开始在所有回答里硬塞术语，让它写一封普通邮件都会冒出WIP和OCAP。这就是过拟合加灾难性遗忘的典型表现。

第二次训练调整了三处：r改成16、学习率降到2e-4、epoch降到3，同时加入了那480条通用能力保持数据。训练用时七小时，峰值显存18.4GB。这次每50步跑一次自动评测，得到了图2那条曲线。术语准确率在step 620达到峰值92.8%，之后缓慢回落，到step 1200降到87.2%。我们选了step 620的检查点。

人工盲评的结果与自动评测一致。50道开放题，三位工程师打分，微调后模型在术语使用正确性上平均4.31分（五分制），基础模型2.68分；在回答的专业感上4.12分对2.94分；在通用表达流畅度上4.05分对4.18分，略有下降但差距不显著。这个盲评结果让我们有信心上线。

上线部署很简单。把LoRA权重合并回基础模型导出成完整权重，用推理框架加载，对外提供接口。因为合并后结构不变，原有的部署配置一行都不用改。同时我们保留了RAG层，微调模型负责理解问题和组织语言，RAG负责提供可溯源的文档依据，两者组合后的实际满意度比单独用任何一个都高。

七、实施效果：数据说话

核心指标见本文图1。术语解释准确率从51.3%提升到92.7%，缩写消歧从38.7%提升到90.5%，幻觉率从31.5%降到8.4%。流程问答准确率79.6%，低于RAG的88.9%，这符合预期——需要引用具体文档的任务本来就该交给RAG。组合方案下流程问答达到91.4%，高于两者单独使用。

成本方面，一次完整训练七小时，按显卡功耗和电价折算，加上硬件折旧分摊，单次训练的边际成本在两百元人民币量级。最大的成本其实是三周的数据准备人工，五个人参与、合计约120人时。按工程师人力成本折算约在三万元量级。这个投入对绝大多数团队都是可承受的。

使用效果上，助手上线半年，累计处理提问约一万一千次。用户反馈的有用率（回答后用户点了有帮助的比例）从基础模型版本的34%提升到76%。新人组的使用频次明显高于资深组，这符合设计初衷。带教师傅反映，基础术语类问题被问的次数减少了大约六成。

也有做得不够好的地方，需要诚实地说。第一是知识时效性。微调进去的知识是训练时点的快照，半年内我们新增了三十多个术语和两次流程变更，模型完全不知道。目前的应对是靠RAG层兜底，但这不是根本解法。我们计划的做法是每半年增量重训一次，把新数据加进去重新跑，因为单次成本很低，这个频率是可以承受的。

第二是评测集的维护成本。400道题的评测集建起来花了不少功夫，而且随着模型能力提升，原有题目区分度下降，需要不断补充更难的题。这是一个持续投入，很容易在项目热度过去后被荒废。我们的做法是把评测集维护写进了季度工作计划，每季度补充30道新题并淘汰10道过时题。

最后总结一句给想尝试的团队：微调的技术门槛比想象中低得多，真正的门槛在数据质量和评测严谨性。如果只能记住一句话，那就是不要用loss判断模型好不好，一定要建立独立来源的下游任务评测集，并且在训练过程中持续跑它。本文图2那条先升后降的曲线，是这次实测最有价值的产出。

图2：训练损失持续下降，但验证集术语准确率在step 620左右见顶后开始回落，这是典型的过拟合信号。只看loss不看下游指标会选错检查点，这是本次实测踩到的最大的一个坑。

表2：LoRA关键超参数的实测影响与推荐值

八、延伸补充：工程细节、避坑清单与演进方向

8.1数据构造的五条实操经验

第一，同一个知识点要有多种提问形式，否则模型学到的是字符串匹配而不是概念。第二，一定要有纠错型样本，即给出一个错误理解让模型指出问题，这类样本对提升鲁棒性效果显著。第三，答案长度要有变化，如果所有答案都是三百字，模型会学到不管问什么都答三百字。第四，避免答案里出现具体的日期、设备编号、人名，这些会随时间失效的内容不该进微调数据。第五，训练数据必须做一次去重和相似度检查，我们第一版数据里有7%的近重复样本，这部分会导致模型对特定表述过拟合。

8.2避坑清单

坑一：只看loss选检查点。前面已详述，必须用下游任务指标。坑二：评测集与训练集同源。构造评测集时要用完全独立的文档来源，并且做一次交叉检查，把与训练数据相似度过高的题目剔除。坑三：不做通用能力回归测试。每次训练后都应该跑一遍通用任务，确认没有明显退化。

配套资料与实战工具包

本文涉及的脚本、参数模板、检查清单已整理成配套资料包，可直接用于工厂落地实施，内容随实践持续更新。点击文章上方「VIP资源」下载区免费获取：

• Fab术语微调数据集构造规范（四类样本配比、多样化提问模板与去重方法）
• LoRA超参数实测对照表与训练脚本（含目标模块配置与早停策略）
• 三层评测体系搭建指南（自动评测集构造、盲评表单、污染检查方法）
• 灾难性遗忘对抗方案（通用能力保持数据构造与回归测试清单）
• LoRA与RAG组合部署配置说明（权重合并、推理服务与检索层对接）

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

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

你在实际项目里遇到过类似情况吗？是怎么处理的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：半导体AI融合|半导体Fab | MES系统| SPC |良率提升|智能制造