4.2 另两类场景实战与跨场景复用：法律、客服及一个基座挂多个适配器

文档摘要

4.2 另两类场景实战与跨场景复用：法律、客服及一个基座挂多个适配器读者读完这一节，应该能拿走两件事：一是把 4.1 那套「数据—模板—训练—验收」的作战线，平行迁移到法律和客服两个差异很大的场景，并看清它们的共性与坑；二是掌握一个基座挂多个 LoRA 适配器的复用打法——这恰恰是低成本微调真正省钱、省运维的地方。垂直领域微调的价值，不在「训出一个模型」，而在「用一份基座成本，养活一整面领域的适配器墙」。 4.2.1 法律场景实战：准确引用比「答得顺」重要十倍法律微调的目标通常是三类：法条检索问答（「根据民法典，租客提前退租要赔多少」）、合同审查（标出风险条款、缺失条款）、文书生成（起诉状、答辩状草稿）。它和医疗最大的不同是——时效性极强、引用必须可溯源、且答错同样有真实代价。

4.2 另两类场景实战与跨场景复用：法律、客服及一个基座挂多个适配器

读者读完这一节，应该能拿走两件事：一是把 4.1 那套「数据—模板—训练—验收」的作战线，平行迁移到法律和客服两个差异很大的场景，并看清它们的共性与坑；二是掌握一个基座挂多个 LoRA 适配器的复用打法——这恰恰是低成本微调真正省钱、省运维的地方。垂直领域微调的价值，不在「训出一个模型」，而在「用一份基座成本，养活一整面领域的适配器墙」。

4.2.1 法律场景实战：准确引用比「答得顺」重要十倍

法律微调的目标通常是三类：法条检索问答（「根据民法典，租客提前退租要赔多少」）、合同审查（标出风险条款、缺失条款）、文书生成（起诉状、答辩状草稿）。它和医疗最大的不同是——时效性极强、引用必须可溯源、且答错同样有真实代价。

数据构建上，法律语料的「井」是：公开判例库、法律法规全文、律所历史合同与审查意见、文书模板。构造样本时，output 必须带上「依据」而不仅是结论：


{
  "instruction": "审查以下租赁合同条款，指出对承租方不利的风险点。",
  "input": "乙方提前退租的，须向甲方支付剩余租期租金总额的 200% 作为违约金。",
  "output": "风险点：违约金约定为剩余租期租金 200%，明显过高。依据《民法典》第五百八十五条，约定的违约金过分高于造成的损失的，当事人可请求法院或仲裁机构予以适当减少，司法实践通常以实际损失 30% 为参考上限。建议修改为与实际损失相当的合理比例，并约定损失计算方式。"
}

注意 output 的写法：先给判断，再给「依据哪条法律、司法实践怎么认定」。法律模型最怕「结论对、依据错」，因为用户会拿着错误依据去行事。所以训练数据里，凡是涉及条文的，必须人工核对条文编号与内容——这一点和医疗的「用药剂量红线」是同一类事实门。

法律场景的额外护栏：在系统提示里强制模型标注「本回答不构成正式法律意见，重大事项请咨询执业律师」，并混入「超出范围转人工」的拒答样本。法律答错的代价不亚于医疗，护栏不能省。

4.2.2 客服场景实战：多轮、一致、会转人工

客服是另一极：它不要求深专业知识，但要求多轮连贯、语气一致、且知道什么时候该闭嘴转人工。数据来自历史工单、FAQ 知识库、坐席话术。客服微调最该解决的不是「答得对」，而是「答得像、答得稳、答得省人力」。

客服样本的构造重点是多轮上下文和意图分类。例如：


{
  "instruction": "你是某电商的售后客服，根据用户与历史的对话，判断当前意图并给出下一步话术。",
  "input": "历史：用户：我买的耳机坏了。客服：请提供订单号。用户：订单号是 AB123。当前：我想申请退货。",
  "output": "意图：退货申请。话术：已收到您的订单 AB123，耳机在保修期内可申请退货。请您在『我的订单-申请售后』提交，我会同步为您生成退货标签，预计 1 个工作日内审核通过。"
}

客服场景三个坑：

语气漂移：同一批样本里有的正式、有的随意，模型会学乱。统一话术风格，最好由运营先定一套 persona 再批量标注。
过度承诺：模型容易为了「解决用户」而擅自承诺补偿、时效。训练时把「无法承诺的内容一律转人工/上报」写成硬规则样本。
遗忘上下文：多轮里模型只盯最后一句。训练数据要带足历史轮次，且长度覆盖真实对话深度。

4.2.3 三个场景的共性与差异：一张图看清

把医疗、法律、客服放一起看，能提炼出可迁移的方法论，也能避开「一套配置打天下」的妄念：

```mermaid graph TD MED[医疗] --> COM[共性: 指令-回答SFT/模板约束/拒答样本/人审验收] LAW[法律] --> COM CSV[客服] --> COM MED --> D1[重事实红线/脱敏/低置信转医生] LAW --> D2[重条文溯源/时效性/不构成意见声明] CSV --> D3[重多轮一致/语气persona/转人工] D1 --> R[差异化护栏决定数据构造重点] D2 --> R D3 --> R ```

共性是骨架：都要干净的指令-回答对、都要把输出格式写进模板、都必须混入拒答样本、都得过人审验收门。差异在护栏——医疗守事实与隐私、法律守引用与时效、客服守一致与边界。你每换一个领域，真正要重新设计的不是训练代码，而是「这个领域的红线在哪、数据怎么围绕红线构造」。

4.2.4 跨场景复用：一个基座挂多个适配器

到这里才是低成本微调真正划算的地方。GLM-5.2 基座不动，你为每个场景训一个独立的 LoRA 适配器：医疗一个、法律一个、客服一个。推理时只加载对应适配器，基座权重共享，显存和存储都只多了一小部分适配器文件（通常几十到几百 MB）。

PEFT 支持把多个适配器挂在同一个模型上并动态切换，甚至做加权融合：


model.load_adapter("medical_adapter", adapter_name="medical")
model.load_adapter("legal_adapter", adapter_name="legal")
model.load_adapter("cs_adapter", adapter_name="cs")

# 在线切换：客服对话时
model.set_adapter("cs")
# 医疗问答时
model.set_adapter("medical")

更进一步，如果某个子场景是「医疗 + 客服」（比如医院里的就诊咨询机器人既要懂医学又要会温柔沟通），可以用 add_weighted_adapter 把两个适配器按权重融合成一个新适配器，兼顾两方面的能力。这套打法的运维收益很大：基座升一次级，所有适配器跟着受益；新增一个场景只训一个小适配器，不必重训大模型。

```mermaid graph LR BASE[GLM-5.2 基座冻结] --> A1[医疗适配器] BASE --> A2[法律适配器] BASE --> A3[客服适配器] A1 --> SW[推理时 set_adapter 切换] A2 --> SW A3 --> SW SW --> OUT[单请求只加载一个显存省] A1 --> FUSE[add_weighted_adapter 融合] A3 --> FUSE FUSE --> HYB[医疗+客服混合场景] ```

4.2.5 跨场景复用的三类真实踩坑

最后把实践中最常翻车的点摆出来，都是真金白银换来的教训：

坑一：适配器串味。如果在训「客服适配器」时，训练数据里混进了医疗样本，或者两个适配器 target_modules 重叠且都训过，切换时会出现「客服突然开始聊医学」。防范：每个适配器用独立、干净的数据集；上线前做「跨场景隔离测试」——把医疗问题丢给客服适配器，确认它不会越界回答。
坑二：融合权重拍脑袋。用 add_weighted_adapter 时，权重不是越平均越好。医疗+客服混合，若客服权重过高，专业内容会被冲淡；医疗权重过高，语气又变生硬。建议从 0.5/0.5 起步，用人工盲评微调到「专业度和亲和力都过关」再定稿。
坑三：忘了适配器也要版本管理。基座升级、数据回流重新训练后，旧适配器可能和新基座不兼容。务必给每个适配器记版本号、训练数据快照、对应基座版本，否则出了线上问题你都不知道该回滚到哪个。

走完第 4 章，你已经具备「选场景 → 捞数据 → 洗数据 → 定模板 → 训适配器 → 过验收 → 多场景复用」的完整实战能力。下一章（第 5 章）做整体总结与展望，把这套方法沉淀成可长期复用的资产。

```mermaid graph TD P1[坑1 适配器串味] --> FIX1[独立数据集+跨场景隔离测试] P2[坑2 融合权重乱拍] --> FIX2[0.5/0.5起人工盲评定稿] P3[坑3 适配器无版本] --> FIX3[记版本/数据快照/基座版本] FIX1 --> DONE[多场景复用稳] FIX2 --> DONE FIX3 --> DONE ```

4.2.6 三场景训练资源账与 RAG 的取舍

把三个场景放在一起算账，能看清「什么时候该微调、什么时候该上 RAG（检索增强）」。资源层面：医疗、法律数据敏感，必须本地 QLoRA 4-bit 训练，基座不联网；客服数据量大但敏感度低，可用 8-bit 甚至 4-bit 均可，对显存最宽容。三者显存都靠 4-bit 压到单张消费级显卡，这是共性。

更关键的是 RAG 与微调的分工：会频繁变动的知识用 RAG，稳定不变的风格/格式/角色用微调。落到三个场景——法律条文时效性强、常更新，优先 RAG 检索最新条文，再用轻量微调只定「引用语气与输出格式」；医疗知识相对稳定但高度私有，以微调为主、用 RAG 补最新临床指南；客服 FAQ 多变、话术常调，以 RAG 为主、微调只负责把 persona 和语气钉死。一句话记住：微调教模型「成为谁」，RAG 给模型「此刻该引用什么」。两者不冲突，在严肃垂直领域往往是「微调打底 + RAG 补鲜」的组合拳。

4.2.7 上线后的跨场景回流闭环

第 4 章的方法论要能长期生效，必须给每个场景都装上「线上日志 → 人工标注 → 增量重训 → 版本回滚」的闭环，而 4.1.7 讲的医疗回流只是其中一个实例。跨场景通用做法是：把每个 adapter 的版本号、训练数据快照、对应基座版本一起登记；线上一旦收集到高价值纠错样本，就并入对应场景的增量集，用 resume_from_checkpoint 小步重训，过完该场景的验收门再灰度替换。由于 4.2.4 的「一个基座多适配器」架构，新增一个场景或回流一个场景，都不影响其他适配器，运维面是平的。真正让这套体系值钱的，不是某一次训练，而是这个能自我修正、可回滚、可扩展的持续闭环。

4.2.6 三场景训练资源账与 RAG 的取舍

把三个场景放在一起算账，能看清「什么时候该微调、什么时候该上 RAG（检索增强）」。资源层面：医疗、法律数据敏感，必须本地 QLoRA 4-bit 训练，基座不联网；客服数据量大但敏感度低，可用 8-bit 甚至 4-bit 均可，对显存最宽容。三者显存都靠 4-bit 压到单张消费级显卡，这是共性。

更关键的是 RAG 与微调的分工：会频繁变动的知识用 RAG，稳定不变的风格、格式、角色用微调。落到三个场景——法律条文时效性强、常更新，优先 RAG 检索最新条文，再用轻量微调只定「引用语气与输出格式」；医疗知识相对稳定但高度私有，以微调为主、用 RAG 补最新临床指南；客服 FAQ 多变、话术常调，以 RAG 为主、微调只负责把 persona 和语气钉死。一句话记住：微调教模型「成为谁」，RAG 给模型「此刻该引用什么」。两者不冲突，在严肃垂直领域往往是「微调打底加 RAG 补鲜」的组合拳。

4.2.7 上线后的跨场景回流闭环

第 4 章的方法论要能长期生效，必须给每个场景都装上「线上日志、人工标注、增量重训、版本回滚」的闭环，而 4.1.7 讲的医疗回流只是其中一个实例。跨场景通用做法是：把每个 adapter 的版本号、训练数据快照、对应基座版本一起登记；线上一旦收集到高价值纠错样本，就并入对应场景的增量集，用 resume_from_checkpoint 小步重训，过完该场景的验收门再灰度替换。由于 4.2.4 的「一个基座多适配器」架构，新增一个场景或回流一个场景，都不影响其他适配器，运维面是平的。真正让这套体系值钱的，不是某一次训练，而是这个能自我修正、可回滚、可扩展的持续闭环。