上次发布后指标变差，你们用了多久定位到原因？
发布太快与太慢都伤
· 太快 ✗：评测跑不充分、回滚预案缺失、用户被频繁打扰 ✔；
· 太慢 ✗：问题长期不修、改进堆积、团队失去节奏 ✔。
发布节奏应该由"风险与批次大小"决定 ✔，而不是由心情或日历决定 ✔。
一、按改动类型定节奏
| 改动类型 | 建议节奏 | 理由 |
|---|---|---|
| 提示词/参数微调 | 随时（走四道关 ✔） | 影响可评测、可回滚 ✔ |
| 模型版本更换 | 低频 + 灰度 ✔ | 影响面大、行为变化多 ✔ |
| 检索/切分变更 | 固定窗口（如每周一次 ✔） | 需要重跑索引、观察质量 ✔ |
| 界面/文案 | 可随时（但仍要过门禁 ✔） | 风险低 ✔ |
| 权限/额度/默认值 | 谨慎 + 提前公告 ✔ | 影响用户预期 ✔ |
关键：小步快跑用于低风险 ✔，低频有序用于高风险 ✔。
二、四条纪律（无论节奏）
1. 一次只改一类 ✔（见检查清单那篇 ✔ —— 便于归因 ✔）；
2. 每个批次可独立回滚 ✔（见灰度开关 ✔）；
3. 发布说明带评测结论 ✔（见发布说明那篇 ✔）；
4. 不在高峰前发布 ✔（尤其模型替换 ✔）。
三、"合并批次"与"拆分发布"
· 合并：多个小改动一起上 ✔（减少用户打扰 ✔）—— 但必须是互相独立的 ✔，否则归因不了 ✗；
· 拆分：一个大改动拆成几次上 ✔（每次范围更小 ✔）—— 但要注意中间态是否可用 ✔。
判断标准 ✔：每次发布后，如果指标变差，能否定位到具体某一项 ✔？
不能，就该拆 ✔。
四、该观测什么
· 发布频率与每次发布的规模（改动行数/文件数 ✔）；
· 发布后回滚率（高说明评测或灰度不足 ✔）；
· 发布后一周的失败类型变化 ✔；
· 用户投诉与发布时间的相关性（是否总在发布后 spike ✔）。
五、一条判据
> 你们上一次发布后指标变差 ✔，用了多久定位到原因 ✔？
> 超过一天，说明批次太大或改动混合了 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：错误预算：允许错多少、超了怎么办
下一篇：给文档库打质量分：五个维度与三档动作 →
第 147 / 171 篇