客户消息 · 固定输入退款审核通过了，钱什么时候回来？
base-support-v1您好，退款会尽快处理，请耐心等待。
- × 品牌语气跑调
- × 时限 + 原路退回缺失
- × 回复格式不稳定
红笔待校：先用固定用例复现，不凭一条好回复下结论。
AI 与提示 · 安全与运营
微调Fine-tuning
微调（fine-tuning）用一批高质量示例训练出新的模型版本，让重复任务的行为、格式与语气更稳定。先用 prompt、结构化输出与少样本做基线；再清洗数据并严格隔离 train / validation / test，用留出集离线复测、版本化发布和回滚。经常变化的新知识优先用 RAG，训练成本、线上成本与延迟都要实测。
把基础客服教成稳定的品牌回复
同一条客户消息贯穿复现、训练与复测。先看真实回复和人工批准示例册，再按阶段操作；训练集、验证集和测试集的去向直接写在活页上。
这是品牌客服的回复册 / 编辑校样桌：用人工批准的成批示例，把基础模型教成稳定的品牌语气与固定格式。
案例 FT-24 · 退款回复VERSION / RELEASEBASE v1 · 可回滚点旧版本随时可切回
- 训练成本
- 一次性增加
- 线上 prompt
- 可缩短
- 延迟 / 单次成本
- 必须实测
默认先看同一条客户消息、基础回复与已批准示例册。下一步：复现基础模型跑调，记录 prompt、结构化输出与少样本基线。
从这本回复册带走五个判断
面板已经把行为变化、数据隔离、版本与回滚落在物件上；这里给这些观察命名。
- 微调教稳定行为，不负责灌入常变知识
- 它适合反复出现的语气、格式与任务模式。价格、政策、库存等经常变化的事实优先走 RAG，让答案在请求时读取最新来源。
- 先把便宜、可逆的基线跑到头
- 先试清楚 prompt、结构化输出与少样本示例，并用固定用例记录 baseline；只有这些手段仍不稳，训练新版本才有可证明的价值。
- 小而高质量，胜过脏而庞大
- 人工批准、去重、脱敏且覆盖边界的 240 条，比混着冲突、重复和隐私的几千条更能教出稳定模式。
- train / validation / test 必须分家
- train 教模型，validation 选候选版本，test 只在最后打开。测试答案混进训练后，离线高分不再代表泛化能力，必须恢复干净分割并重训。
- 版本化 + 离线 eval + 回滚是一整套
- 每次训练产出独立版本；同一消息与留出集做改前 / 改后复测。灰度发布时仍保留 v1 路由，质量、成本或延迟异常就切回。
什么时候值得训练一个新版本
先看症状，再看边界；微调不是“让模型什么都更懂”的万能升级。
- 值得：同类任务长期重复，品牌语气、固定格式或判断规则仍在 prompt + schema + few-shot 基线上持续跑调。
- 值得：有足够的人工批准样例，能在训练前完成清洗、去重、脱敏和数据分割，也有离线 eval 与灰度发布条件。
- 先用 RAG：问题是价格、政策、库存等知识经常更新；把事实写进权重会很快过期，也难解释来源。
- 先别做：需求仍天天变化、只有少量未经审核日志，或没有留出集和回滚路径。
- 算清取舍：微调多了一次训练与评测成本，可能缩短线上 prompt；最终单次成本和延迟要在目标流量下实测。
怎么从基线走到可回滚发布
沿用校样桌上的同一套对象，最短路径是五步。
- 用固定任务集跑 prompt、结构化输出和少样本基线，记录质量、token、成本与延迟。
- 收集人工批准的 input → output 示例；去重、脱敏、解决冲突，再在训练前一次性切分 train / validation / test。
- 只用 train 训练带版本号的候选模型；用 validation 选择训练轮次和候选，不偷看 test。
- 用同一消息、从未见过的 test 和通用安全用例做离线复测，比较 baseline 与候选版本。
- 小流量灰度，监控质量、单次成本和延迟；保留旧版本路由与版本记录，异常立即回滚。
同一目标，只差测试集有没有守住
两边都想让退款回复符合品牌规范，唯一关键差异是数据分割是否干净。
180 条训练、30 条验证、30 条测试；v2 只在最后见 test，同一消息与留出集 28/30 通过，结果可与 v1 baseline 比较，也保留 v1 回滚。
模型提前见过答案，离线分数虚高；团队无法判断新消息是否真能泛化。应恢复干净快照、重新分割并重训，而不是给 v2-dirty 盖发布章。
快速自测
客服语气和 JSON 格式已经稳定，但退款政策与价格每周变化。下一步最合适的做法是什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。