1. 先搞明白：行业黑话到底在难为谁
做模型落地这几年，我越来越觉得“领域知识注入”这件事，十有八九卡在了一个特别尴尬的地方——不是模型不行，而是我们跟模型之间经常“交流不畅”。你以为是数学题做不对，实际是题目里的词就没看懂。
前阵子帮一家做供应链金融的公司做内部模型优化，对方业务方给定了一堆词：账期、授信、贴现、回款核销、头寸管理。我拿这些词去问通用基座模型，模型倒是能答出个大概，但一落到具体业务语境就露馅了。比如问“存货质押融资的授信额度怎么核定”，通用模型会给你列一堆教科书式的风控指标，完全忽略了这家公司实际业务里“动产价值波动率”和“仓单重复质押”才是真正要命的东西。这就是黑话没对齐。
行业内的人说“回款核销”，其实指的是资金流和应收账款的匹配动作，背后带着一套内部流程；模型如果只把它当成“收到钱”的近义词，那下游生成的对账单、催收话术就全是错的。
所以先说一个基本判断：给模型做领域知识注入，本质上不是“往词表里加点词”，而是要让模型理解一套领域的“话语体系”。这套话语体系分三个层次，我做项目的经验里，大多数翻车都出在第二、第三层。
- 第一层是缩写词。像医疗里的“CT/MRI”，金融里的“IRR”“VaR”，法律里的“民诉法”“审限”。这层最好办，告诉模型全称就行。
- 第二层是业务术语。像“库存跌价准备”“暴雷”“白条”“过桥资金”，这些词有明确的业务含义，但模型在预训练数据里见过太多泛化用法，容易往通用语义上跑偏。
- 第三层是“隐含规则”。这是最阴间的部分。比如“夹层融资”在履历里不能写“业务上有瑕疵”，必须写成“结构上有优化空间”；再比如某些行业里“积极沟通”的意思是“你自己看着办，我不担责”。这类黑话没有标准解释，完全依赖内部语境。
我在做方案的时候，通常会用一套模板去做黑话拆解，每个术语至少要回答四个问题：它在业务流程的哪个环节出现？它跟相邻术语的边界是什么？它对生成结果有什么约束？它有没有反面词或容易混淆的词？
这个动作看起来费时间，但它是后面所有注入方案的“地基”。地基不打好，后面不管用上下文还是微调，模型都会在关键决策点上犯迷糊。
2. 领域知识注入的几条路：能选的不多
理清楚黑话层级之后，接下来是选路。
我把领域知识注入大致分成三个档位：上下文工程、微调注入、基座预训练。这三条路不是相互替代的关系，而是成本和效果的递进关系。实际操作中我见过太多人一上来就微调，理由是“上下文不靠谱，塞不进那么多知识”。这话对了一半，但另一半是：你塞不进那么多知识，很可能是因为你不会塞，而不是上下文这条路走不通。
2.1 上下文工程：最轻量的“临时补习”
上下文工程是成本最低、见效最快的方式，尤其适合知识量在几十条到几百条的小业务场景。它的核心思路是把领域词典、业务规则、示例对答组织成结构化的上下文前缀，在每次调用时一起发给模型。
我有一个自己常用的上下文模板结构，大致分四块：角色设定、领域词典、规则约束、少量示例。
角色设定不是简单写一句“你是供应链金融专家”，而是要写明“你服务的对象是谁、回答要遵循什么标准”。比如：
你是一名供应链金融风控助手。你的用户是某公司的业务操作员，回答要面向实际操作，不要输出教科书理论。当涉及额度、期限、利率时，必须给出具体数字范围，不能只说“根据情况而定”。领域词典部分，我建议做成“术语+一句话定义+边界说明”的格式，比如：
回款核销：指将客户回款与应收账款明细进行匹配并销账的过程。注意：核销不等于收款，只有完成匹配并标记状态才算核销。规则约束是处理隐含规则的地方，要把“不能怎么说”“只能怎么说”写明白。示例部分给3到5组典型问答就够，太多会挤占长度。
这个方案的好处是改起来快、可审计，业务方可以随时拿着上下文问“为什么这单答错了”，因为每一处知识都能追到上下文里。坏处是占token，跑大批量任务时成本会明显上升，另外上下文长度一旦逼近模型上限，性能会呈非线性下降，不是你想塞多少就能塞多少。
2.2 微调注入：把知识写进参数
当业务知识的量级超过几千条、且你需要在高频调用中控制成本时，微调就进入了视野。微调的本质是通过梯度更新，把领域知识“压进”模型参数里，这样推理时不需要每次携带大段上下文。
但这个“压进去”的过程远没有听起来那么优雅。模型是一个巨大的非线性系统，它对知识的记忆并不是像一个硬盘分区一样，给领域知识划了一块专属空间，而是把新知识分散地写到海量参数里，跟通用知识混在一起。这种写作方式直接导致了灾难性遗忘问题的产生——你为了让模型学会行业黑话，顺手把它的通用对话能力给改歪了。
我在后面专门用一整节讲遗忘问题，这里先只说判断标准：如果你的场景是每次调用都固定围绕同一批业务FAQ，微调很合适；如果业务方希望你只在某些特殊任务里说行业黑话、平时还是要当通用助手跟用户闲聊，那你就要非常小心了，纯微调很容易把模型的“人格”也调没。
2.3 基座预训练：重活儿，普通人别碰
第三条路是继续预训练，也就是在海量领域语料上对模型做增量训练。这需要极其庞大的算力和数据，“普通人别碰”四个字就是我的全部建议。中小企业或者单项目团队，基本不应该把这条路放进选项里，除非你有千卡级别的资源。
现实情况是，绝大多数项目的最佳路径是“上下文工程打底 + 微调强化 + 评测反馈”。接下来，我重点聊聊微调这条路上最臭名昭著的坑——灾难性遗忘。
3. 灾难性遗忘是怎么发生的
“灾难性遗忘”这个词听上去很吓人，实际上也真的很要命。它指的是模型在针对下游任务微调时，为了学会新任务而大幅更新参数，导致原本掌握的通用知识和能力被“冲掉”。
我最早遇到这个情况是做一个法律文书项目，在通用模型上加了些法律文本做微调。模型很快学会了“被告”“原告”“审限”这些词的用法，但与此同时，你让它写一封日常邮件，它开始不自觉地带出“特此告知”“逾期未复视为放弃权利”这种法律腔。这就属于典型的能力畸变，不是要求模型忘掉什么，而是它在某个方向的分布被调得太极端。
3.1 参数纠缠：模型不是一个可以单独涂改的记事本
理解遗忘，最有效的一个类比是画一幅水彩。你想在画布上加重某一块区域的蓝色，但你手上的笔不可能只碰到那一小块，它会在周围晕开。模型的参数更新也是这样：你想让它强化“回款核销”这个知识集群，但梯度更新会连带影响到跟这个集群有参数传递关系的其他能力，比如通用中文生成、逻辑推理、甚至安全规范遵从。
参数纠缠的直接后果是：领域能力和通用能力在参数层面是共享的，不存在一个干净的“分区开关”。这解释了为什么行业里很多人发现，模型微调后领域准确率提升了20%，但通用benchmark直接掉了5到10个点。这5到10个点，就是“晕染”出去的代价。
3.2 学习率的双刃剑效应
第二个关键变量是学习率。很多人一上来就把学习率调得很高，因为想让模型“快点学会”。大模型微调里，学习率过高意味着权重更新幅度大，模型确实能更快拟合新数据，但这种拟合往往是“记住”而非“理解”。
我做过一组对比实验：相同的数据集，一组用学习率2e-4，另一组用5e-5。结果前者的领域准确率只比后者高不到1%，但通用能力评测掉了差不多6个百分点；而后者领域准确率略低，但通用能力几乎无损。这个实验让我彻底明白了一件事：领域知识注入不是一个“越用力越好”的活，而是要非常克制。
打个比方，你给一个已经经验丰富的员工培训新的业务规则，最怕的是什么？是培训太用力，让他把原来做事的基本原则都忘了，只记住了一套新话术。学习率就是培训的“强度旋钮”。
3.3 数据配比失衡引发的“回滚”
第三个变量是数据配比。这是很多项目团队最忽视、但影响最持久的一个点。
实际操作里，领域知识注入的数据往往来自业务方提供的FAQ、话术库、内部文档，这些数据有一个特点：话题高度集中。比如客服场景，几千条数据全是“退款怎么退”“发票怎么开”“物流怎么查”。如果你只用这批数据微调，模型会疯狂向“客服话术分布”偏移。看起来不错，但实际上它丧失了对其他话题的响应能力。
这种回滚现象还不像遗忘那么突然，而是逐渐的、润物细无声的。你今天测了一个数学题，模型还能答个七七八八；两周后你换一个更复杂的推理题，发现模型已经不太会“一步步思考”了，只会机械地给结论。原因就是持续偏向领域数据后，通用推理路径在参数里的“交通优先级”被领域路径给挤占了。
了解了遗忘的机理，就可以谈怎么跟它博弈了。
4. 博弈实操：我踩坑踩出来的平衡方案
这一节是全文的干货中心。我把这几年做过的领域注入项目里，反复验证过有效的平衡策略整理出来，每一条背后都有对应的坑。
4.1 数据配比的“三七法则”与动态调整
最先要解决的是数据配比问题。我的经验是：领域数据跟通用数据的比例，不要低于3:7，也不要高于5:5。低了模型学不进去，高了容易遗忘。具体数值要看领域数据量和多样性，但我见过的翻车项目，绝大多数是领域数据占比超过70%。
这里有一个很容易被忽略的细节：通用数据不是随便找一批开放数据就算完，而是要选择跟你目标任务形态相近但内容更广的数据。比如你做的是对话式客服，那通用数据里要多放对话类数据；你做的是文档摘要，那通用数据里要放各种题材的文本。否则模型虽然没遗忘，但能力分布会变得跟你的通用数据同构，一样会偏。
我自己的操作是动态配比。第一轮先用7:3，让模型快速理解领域框架；第二轮根据评测结果调整到8:2甚至9:1，做精细化打磨。这个“先宽后窄”的过程，比一上来就锁定精配比更稳。
4.2 LoRA到底怎么选rank、alpha
当前微调界的主流方案是LoRA。它通过低秩分解来减少可训练参数量，比较好的兼顾了效果和成本。但LoRA也有自己的“旋钮”要调，最核心的两个参数是rank和alpha。
rank决定了低秩矩阵的维度，实际控制的是“模型能够为领域知识开辟多少参数空间”。我踩过的坑是：rank设得太小，比如8，模型学到的只是领域表面的用词习惯，遇到没见过的组合就废；设得太大，比如128，就把通用参数的底层结构改动了，遗忘风险显著增加。
我个人比较稳妥的起点是rank=32，alpha=64（alpha一般取rank的1到2倍）。在多轮实验后，如果领域准确率卡在阈值上不去，再考虑上升到rank=64；如果发现通用能力下滑明显，则把rank降到16重新试。记住一个原则：LoRA的rank不是越大越好，它决定的是“模型允许自己改变多少底层习惯”，改得太多，跟全量微调就没区别了。
4.3 混合训练与回放缓冲区
跟遗忘博弈的另一招是混合训练。这个方法最早的灵感来自人类的学习方式：一个外科医生既可以做复杂手术，也可以跟家人聊家常，是因为他并没有为了练习手术而停止使用日常语言。混合训练就是让模型在同一个训练批次里，既看到领域数据，也看到通用数据，两者同时更新。
实现上，我用的是数据流拼接：每个step的batch里，按比例混入领域样本和通用样本。领域样本负责引导模型学新知识，通用样本负责“钉住”原有能力，防止权重向领域方向过度漂移。
再进一步，就是所谓“回放缓冲区”（replay buffer）。它是指在训练过程中，定期从原始的通用数据池里随机抽取一批样本，跟领域数据一起喂给模型，做持续性的“基础能力维护”。更精细的做法是优先回放那些模型当前最容易遗忘的通用能力样本，比如推理、常识问答、代码等，这个需要根据评测结果动态生成，算是进阶玩法。
4.4 分层学习率与冻结策略
最后一个实操技巧是分层学习率。不同层级的参数，对领域知识和通用知识的敏感度不一样。大体上，靠近输入端的底层编码层学到的是词法、句法结构，这些跟通用语言能力高度相关，不宜大改；靠近输出端的高层，跟具体任务、风格、事实知识关联更紧密，可以放开一点学。
实际操作里，我通常的做法是：对底层参数设置更小的学习率（比如1e-5），对顶层设置较大的学习率（比如5e-5），形成一个梯度差。在LoRA的框架下，因为只训练注入的低秩矩阵，这个策略就简化为“把注入矩阵均匀初始化，但在训练中选择性冻结部分层的LoRA参数”。
这样做非常有效，但要注意不要完全冻结底层，一点底层的适应都没有，领域词汇的语义映射会建立得很慢。
5. 评测：没有评测的微调都是耍流氓
我在跟很多团队交流时发现一个普遍现象：大家不是不做评测，而是只做“领域评测”，也就是看领域数据上的准确率。这种单维评测会把项目带进盲区——你只看到了模型在领域里答得好，却不知道它已经开始在通用场景里“胡言乱语”。
完整的领域注入评测，至少要覆盖两个维度：领域能力维度和通用能力维度。缺一个都不完整。
5.1 领域能力的评测集怎么建
领域评测集的建设，原则是“业务方参与、尽量贴近真实场景”。不要用微调训练集里的同分布文本来做评测，那是开卷考试，只能测出模型的记忆力。
我的做法是从业务方那里收集两类数据：一类是历史真实问题，经过脱敏后直接用于评测；另一类是“变种问法”，比如同一个业务问题，用不同的话术、不同的上下文来表达。变种问法非常重要，因为领域黑话在真实场景中的表达是千奇百怪的，用户不会按照标准术语提问，只会按自己的习惯说。
一个容易忽略的点是评测集的“难度分布”。我建议把评测题分成三档：入门题（直接使用标准术语）、进阶题（术语组合、业务嵌套）、刁钻题（涉及边界情况、缩写歧义、隐含规则）。只有三档都做完，才能判断注入是否真正掌握了“话语体系”。
5.2 通用能力的“体检项”
通用能力评测不用做得很重，但要覆盖关键能力面。我自己的标配是五类：常识问答、逻辑推理、文本摘要、代码生成、安全合规。每类准备50到100道题，训练前先测一次作为基线，训练后再测一次做对比。
这里要给一个关键建议：通用能力评测集在训练过程中最好完全锁死，不要更换题目。因为你要观察的是模型能力的变化曲线，换了题就没法对比了。我见过一个团队为了“防止模型过度拟合评测集”，每轮都换新题，最后根本没法判断遗忘是真发生了还是题目变难了，非常浪费时间。
5.3 遗忘容忍度：什么样算“灾难性”
评测做完，怎么判断遗忘是否到了“灾难性”级别？我的经验是从两个维度看，而不是只看一个绝对分数。
第一个维度是通用能力的绝对下降幅度。比如训练前通用基准分是85，训练后变成78，这7个点的下滑已经很厉害了。第二个维度是业务收益和通用损失的比值。如果领域能力提升了15个点，通用能力只掉了2个点，这笔账还划算；但如果领域提升8个点，通用掉了7个点，这个交换就是亏的。
还有一个更实用的小技巧：除了自动化评测，务必要做人工抽测。让一个不参与模型开发的业务方人员，跟微调后的模型做几轮自由对话，观察它说话是否自然、逻辑是否清晰、有没有出现奇怪的语调变化。很多时候，模型是否被“调坏了”，业务方人员5分钟闲聊就能感觉出来，比任何benchmark都灵敏。
6. 实战复盘：一个虚构的智能客服项目
讲完方法论，我拿一个自己参与过的项目做整体复盘，把从黑话梳理到微调上线、再到处理遗忘的完整流程串一遍。
背景是某中型电商平台要做智能客服升级，目标场景是处理售后咨询中的“退款时效”“运费争议”“少件补发”这三类高频问题。业务方提了要求：既要能准确理解内部话术（比如“仅退款”和“退货退款”的区别），又不能在用户闲聊时显得像个机器人。
第一步，我带着业务方梳理了27个核心术语，建了黑话表。重点是“仅退款”“退货退款”“换货”之间的边界：仅退款不涉及退货动作，一旦用户说“我不想退但我就要退钱”，模型要识别出这是不符合规则的诉求，不能一味迎合。
第二步，做上下文工程。我先把27个术语和5组示例问答拼进上下文，做了一版轻量方案，给业务方快速看效果。这个版本能解决大概60%的基础咨询，但遇到复杂的多轮对话还是不行，比如用户说“我上周买的东西少了一件，但我已经申请退款了，这算不算我占便宜”，模型就乱了。
第三步，决定微调。我们整理了大约8000条真实售后对话（脱敏后），做了标签化和术语对齐，再按3:7比例混入通用对话数据，用LoRA rank=32、alpha=64、学习率4e-5进行训练，训练了3个epoch。评测结果是领域准确率从58%提升到84%，通用能力评测分下降约4个百分点，处于可接受范围。
第四步，处理残留问题。我们发现模型在“仅退款”场景回答得很好，但一聊到物流相关信息，就会不自觉重复售后话术，比如用户问“我的快递到哪了”，模型却说“请您提交退款申请”。这明显是领域数据过度激活的结果。处理方式是加回放缓冲区，把1000条物流类通用对话混入第二轮训练，并降低学习率到2e-5。第二轮后，这个问题显著缓解。
这个项目最大的教训是：千万不要想着一轮微调就能解决所有问题。模型的能力是“调”出来的，不是“炼”出来的。通用对话能力和领域黑话能力必须交替增强，像走钢丝一样，左右摇摆、逐步收敛。
7. 写在最后的个人体会
做完这类项目，我最大的体会是：领域知识注入和灾难性遗忘之间的博弈，本质上不是一道“技术题”，而是一道“取舍题”。
模型的能力资源是有限的，你往一个方向倾斜，就必然在另一个方向有所牺牲。行业里没有一个参数是“既完全不遗忘、又高效注入”的银弹。所有的技巧——数据配比、回放缓冲区、lora调参——都是在帮你控制取舍的幅度和方向，而不是帮你消灭取舍本身。
所以我劝准备做这件事的朋友，动手之前先想清楚三件事：你的领域能力底线是多少？你的通用能力上限容忍度是多少？你的业务方是否接受一个“偏科”但足够专业的助手？
想清楚了再去调参，你会少走很多弯路。想不清楚就硬调，项目的结局大概率是：领域能力没提上去，通用能力还给调没了，两头不讨好。
最后分享一个小技巧：每次微调完后，把模型放在一个跟业务完全不相关的场景里，随便聊几个日常话题。如果它聊得自然流畅，说明这把没调坏；如果它老是往业务上扯，那不管领域评测分数多高，我建议你都不要上线。因为用户不会按照你的分诊台来提问，他们只会按照自己的直觉来对话。
