本文只讲一件事:系统上线跑起来之后,模型、权重、prompt 这一层怎么版本化、怎么升、怎么回滚。不是割接——搬人搬数据见上线切换与数据迁移;不是宕机冗余——见灾备与高可用;不是首次验收——见验收测试与评测;不是数据回流与 badcase 治理——见持续运营与迭代;也不是选底座、走 RAG 还是微调——那是底座选型与技术路线的题目。边界很窄:一次模型侧发布,从准备到灰度到回滚。
一、三个典型翻车场景
第一种,升级后引用变了,没人发现。换了新版权重,回答更流畅,大家都说「变聪明了」。三周后有律师核对底稿,发现引的条文序号对不上现行文本;回查日志才知道升级当天引证准确率就掉了,没人看这个数。法律 AI 的退化不报警、不中断,只是慢慢变得不可信。见幻觉与引证核验。
第二种,prompt 与模型版本脱钩。模型换了,提示词沿用上一版;更常见的是半年里有人救急改过三次线上 prompt,一次记录没留。等要复现某个错误答案,谁也说不清当时跑的是哪版模型配哪版提示词。
第三种,回滚回不去,因为索引也一起动了。发布单写着「升级模型」,实际顺手换了 embedding、重建索引,还覆盖旧索引省磁盘。要回滚时才发现权重能秒切、索引得重跑——几分钟的回滚变成以小时计的抢修。
共同点:把「线上系统由哪些部件组成」当成默认知识,而非写下来的清单。
二、要版本化的到底是哪几样东西
一次问答的输出由下面五样共同决定,任一悄悄换掉,复现和归因就同时失效:
| 对象 | 具体内容 | 变更代价 | 能否快速回滚 |
|---|---|---|---|
| 基座权重 | 底座名称、版本、参数档位 | 大,需完整回归 | 可以,旧权重没删 |
| 微调产物 | LoRA 适配器或全参数检查点、训练数据快照 | 中,与基座强绑定 | 可以,须与基座配套 |
| prompt 与模板 | 系统提示词、任务模板、few-shot 示例、格式约束 | 小,但影响立竿见影 | 可以,前提是有记录 |
| embedding 与索引 | embedding 模型、切分策略、索引结构 | 最大,需全量重建 | 不能秒回,除非并存 |
| 后处理与校验规则 | 引证校验、脱敏、拒答策略 | 小 | 可以 |
微调产物与基座是一对:LoRA 在特定基座上训出,换基座还挂旧适配器往往比不挂更差(见案例库微调实战)。五样要用一个统一版本号捆住——发布的最小单位不是「模型」,是这五样的一个确定组合。
三、换 embedding = 索引必须重建,这条没有例外
这是模型层升级唯一的硬约束。embedding 换了向量空间就换了:新模型编码的查询向量与旧模型编码的文档向量落在不同空间,相似度计算失去意义。
危险在于系统不会报错:检索照常返回、答案读着完整,只是相关性变差,没回归集就发现不了。检索层选型见向量库与检索引擎选型,知识库怎么切怎么建见律所 RAG 知识库建设。
三条纪律:
- 换 embedding 要按工程排期,不能当配置改。重建耗时取决于语料规模与算力,先测一小批样本再推算。
- 新旧索引并存,不要就地覆盖。新索引单独构建验证,切换只改一个指向,稳定满一个业务周期再回收旧索引——这是把回滚从抢修变成改配置的唯一办法。
- 切分策略变了等同于换 embedding。chunk 大小、重叠长度、是否按条款边界切,同样让旧索引作废。
四、回归测试集:律所自己的金标准集
没有回归集,「升级效果更好」只是手感,手感又对新版本天然有利。公开 benchmark 也不能当验收依据——它测通用能力,律所关心的是本所业务线上引证准不准、要素抽没抽全、口径合不合习惯:
| 构成 | 来源 | 要点 |
|---|---|---|
| 常规业务题 | 各业务线真实问答记录(脱敏) | 覆盖主要案由,按业务量配比 |
| 历史 badcase | 此前修好的错误答案 | 防回潮,最容易在升级后复发 |
| 引证核验题 | 答案须落到具体条文或案号 | 抓引证漂移,升级中最敏感的探针 |
| 边界与拒答题 | 超出库范围、诱导性提问 | 验证该拒答时是否仍拒答,而不是开始编 |
| 权限题 | 不同角色对同一问题的可见范围 | 确认升级没绕过权限 |
三条要点:金标准须经业务律师确认,别拿另一个模型的输出当标准;题目要固定,新题先进增量池;评判以相对比较为准。权限维度见多租户与权限隔离架构。
五、灰度发布顺序与人群
顺序原则和割接一致:按答错代价从小到大放,但模型升级多一层手段——影子流量。
| 阶段 | 流量与人群 | 观察什么 |
|---|---|---|
| 影子 | 真实请求复制给新版本,只记录不展示 | 新旧答案差异、异常率、延迟 |
| 内测 | 信息化团队 + 少量种子律师 | 回归集表现、明显错误 |
| 单业务线 | 案件量大、争议标准化的业务线 | 引证准确率、要素漏项、频次是否下滑 |
| 全所 | 全部内部场景 | 指标稳定性、纠错量 |
| 对外交付 | 意见书、检索报告等对客户产出 | 等前四阶段稳定,永远放最后 |
影子阶段最值得投入:用真实问题分布验证,又不让律师担风险。要看的不是「新版本对不对」,而是新旧答案在哪些问题上分叉——分叉点就是下一轮要补的题。工作台边界见律师工作台:案件胜算量化。
另有一条常被忽略:灰度期间要能按用户稳定路由。同一位律师这次命中新版、下次命中旧版,只会觉得系统不稳定,反馈也就失去价值。
六、回滚触发条件表
发布前写死,事中现判一定拖延。阈值由团队按自身基线设定,这里给的是判定口径:
| 触发条件 | 判定口径 | 判定人 | 动作 |
|---|---|---|---|
| 引证造假 | 引证指向不存在或明显不匹配的条文/案号 | 业务负责人 | 一票否决,立即回滚 |
| 权限越界 | 任意一例确认的越权检索 | 合规官 | 一票否决,立即全量回滚 |
| 回归集塌陷 | 通过率较上一版本下降超设定阈值 | 技术负责人 | 回滚当前灰度批次 |
| 拒答策略失效 | 边界题上由拒答转为强行作答 | 技术负责人 | 回滚,查后处理规则是否配套 |
| 性能不可用 | 高峰期响应超出约定上限并持续 | 运维负责人 | 降级或回滚,视批次 |
| 使用量异常 | 灰度人群使用频次持续下滑 | 项目负责人 | 暂停后续批次,先访谈 |
两条配套约定:回滚路径必须演练过;每次回滚出原因说明,否则同一个坑下次还踩。性能判断依据见推理性能与 GPU 利用率,指标怎么采见运维监控与告警体系。
七、版本记录与发布单模板
一张表解决「当时跑的是哪一版」,每次发布填一份归档:
| 字段 | 填写说明 |
|---|---|
| 发布编号 / 日期 | 唯一编号,便于日志与工单反查 |
| 基座版本 | 名称 + 版本 + 参数档位 + 权重来源与校验值 |
| 微调产物 | 适配器版本、训练数据快照号、配套基座 |
| prompt 版本 | 版本号 + 变更摘要 + 变更人 |
| embedding 与索引 | embedding 版本、切分参数、索引批次号、是否重建 |
| 后处理规则 | 引证校验、脱敏、拒答策略版本 |
| 回归结果 | 较上一版本的升降 + 明显退化项 |
| 灰度计划 | 各阶段人群、时间、指标 |
| 回滚方案 | 回滚到哪个组合、预计耗时、是否演练过 |
| 审批人 | 技术、业务、合规三方 |
关键在最后两行:没有回滚方案的发布单不该批准;三方签字保证业务与合规知道线上换了东西——很多纠纷不是技术出错,是业务方不知情。
八、升级窗口时间线
以含基座更换的大版本为例:
| 时间 | 动作 | 产出 |
|---|---|---|
| T-14 天 | 离线部署新组合,跑全量回归集 | 回归对比报告 |
| T-10 天 | 如换 embedding,新索引单独构建验召回 | 新索引批次号 + 召回抽检 |
| T-7 天 | 开影子流量,收集新旧答案差异 | 差异清单 |
| T-3 天 | 发布单评审签字,回滚演练 | 发布单 + 演练记录 |
| T 日 | 内测人群切换,现场值守 | 切换记录 |
| T+3 | 放单业务线 | 日报 |
| T+7 | 批次评审,决定是否全所 | 评审结论 |
| T+30 | 确认稳定后回收旧索引存储 | 存储回收记录 |
注意 T+30:旧索引与旧权重的保留期,就是回滚能力的实际期限,为省磁盘提前删掉等于裸奔。
九、模型升级十项自查清单
- 五类对象(基座 / 微调产物 / prompt / embedding 与索引 / 后处理)是否都有版本号并捆成一个可发布组合?
- 本次是否只改一层?有没有把换基座、换 embedding、改 prompt 打包发布?
- 涉及 embedding 或切分变更时,是否按全量重建索引排期?
- 新索引是否与旧索引并存,切换是否只改一个指向?
- 回归集是否自建、含真实脱敏题与历史 badcase,金标准是否经确认?
- 回归结果是否给出较上一版本的升降并列出退化项?
- 灰度顺序是否为影子 → 内测 → 单业务线 → 全所 → 对外交付,能按用户稳定路由?
- 回滚触发条件表是否已定,引证造假与越权是否一票否决?
- 回滚路径是否演练过,预计耗时是否写进发布单?
- 旧权重与旧索引保留到何时、谁有权清理,是否白纸黑字?
十、常见问题
Q:多久升级一次比较合适?
A:没有标准周期,但有一条原则——一次发布只改一层。prompt 与后处理可按周迭代,微调产物按月,基座更换属大版本,须走完整回归与灰度。
Q:开源底座出了新版本,要不要马上跟?
A:别为版本号升级。先在离线环境跑自己的回归集看本所题目是否真有提升——通用能力更强不等于法律场景更准。选型见底座选型一文。
Q:prompt 谁有权改?
A:线上 prompt 应与代码同等对待:进版本库、走评审、可回滚。留一个「临时改一下」的口子,半年后没人说得清线上跑的是什么。急救可有,当天补记录。
Q:能不能新旧模型同时在线,让律师自己选?
A:短期灰度可以,长期不建议。两套版本并存意味着回归、监控、排查全部翻倍,律师还会拿两边不一致的答案问哪个对。
Q:回归集要多大?
A:取决于业务线数量,原则是每条主要业务线都有足够题量支撑判断,而非总数好看。宁可题少而金标准扎实——标准答案不可靠,通过率就没意义。
Q:升级要不要停机?
A:按上面的灰度做通常不需停机。需要窗口的是索引指向切换那一刻和权重加载期的显存高峰,避开业务高峰即可。
Q:厂商托管的模型服务,这套还适用吗?
A:适用,更要盯。托管模型可能在你不知情时被更新,合同要写明变更通知义务,并保留自己的回归集定期跑。私有化的价值之一就是版本何时变由你决定。见私有化部署方案。
Q:小所没有专职人力,这套能简化到什么程度?
A:最少三样:记录五类版本的发布单、一套小而金标准可靠的回归集、一条演练过的回滚路径。影子流量与多阶段灰度可按人力裁剪,这三样砍掉任一都是赌博。用量口径见API / MCP 定价。
升级方案先过一遍再动手
提供当前模型组合与语料规模,1 个工作日内反馈版本管理与升级灰度方案建议。演示阶段不收费。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:上线切换与数据迁移 · 持续运营与迭代 · RAG 与微调技术路线 · 律师工作台 · 裁判文书 API / MCP 定价