摘要
9-23 用 VeriBench 接CI 门禁（卡住坏版本），9-24 做生产监控（发现坏版本），但二者之间**"怎么把好版本安全放出去"一直是缺口。本文补齐持续交付**：评测门禁 → 模型版本路由与流量切分（接 9-25 网关）→ 灰度指标与自动回滚（接 9-24 监控）→ 在线实验框架（A/B / 影子 / 区间）。传统服务回滚靠重启进程，LLM 应用回滚靠’换模型 + 换上下文’——发布不是终点，而是评测闭环在生产侧的延伸。
一句话结论：把 LLM 应用当成"受版本治理约束的服务"——门禁卡质量、网关做版本路由与流量切分、监控做灰度指标与自动回滚、实验框架做在线对比，让每一次模型/提示词/上下文变更都"可灰度、可回滚、可量化"。
1. 为什么 LLM 应用需要"持续交付"
传统软件：编译过就能上。LLM 应用：模型会悄无声息地变笨——同样的 prompt，换了个微调版本（9-27/02）、改了段 System 提示（9-28/02）、换了个 RAG 检索策略（9-27/01），效果可能断崖。
| 环节 | 9-23 / 9-24 已解决 | 本文补的缺口 |
|---|---|---|
| 上线前 | CI 门禁卡坏版本 | — |
| 上线后 | 生产监控发现坏版本 | — |
| 之间 | — | 灰度发布 / 版本路由 / 自动回滚 |
LLM 应用还有个特殊难点：回滚对象不是二进制，而是"模型权重 + 提示词 + 上下文模板 + RAG 配置"的组合，必须整体版本化。
2. 流水线全景：从门禁到灰度
代码/提示词/模型变更 → 9-23 CI 门禁(VeriBench 通过率 ≥ 阈值) → 打版本标签(模型+prompt+ctx+RAG 配置) → 9-25 网关注册新版本路由 → 灰度(1% → 10% → 50% → 100%) → 9-24 监控盯 SLO(延迟/成本/质量) → 达标全量 / 异常自动回滚 → 在线实验(A/B) 量化业务指标| 阶段 | 负责 | 失败动作 |
|---|---|---|
| 门禁 | 9-23 VeriBench | 阻断合并 |
| 路由 | 9-25 网关 | 不出新版本 |
| 灰度 | 发布控制器 | 暂停放量 |
| 监控 | 9-24 OTel | 触发回滚 |
| 实验 | 实验框架 | 选优胜版本 |
3. 模型版本路由与流量切分（接 9-25 网关）
9-25 的统一网关天然支持"按成本/能力路由"，持续交付把它扩展成版本级流量切分：
# 在 9-25 网关的 router 中增加版本权重ROUTING_TABLE={"chat-prod":{"candidates":[{"model":"kimi-k3-v2","weight":0.10},# 新版本先 10%{"model":"kimi-k3-v1","weight":0.90},# 旧版本兜底],"sticky":True,# 同一用户会话 sticky 到同一版本}}defpick_version(user_id,table):importhashlib,bisect h=int(hashlib.md5(f"{user_id}".encode()).hexdigest(),16)%100cum=0forcintable["candidates"]:cum+=int(c["weight"]*100)ifh<cum:returnc["model"]returntable["candidates"][-1]["model"]
sticky=True很关键：同一用户的多次请求要落到同一版本，否则 A/B 数据失真、体验跳变。
4. 灰度指标与自动回滚（接 9-24 监控）
灰度期盯三类 SLO：质量（Faithfulness / 法官评分，接 9-26）、成本（单请求 token 成本，接 9-20/25）、稳定性（P95 延迟、错误率）。任一越界自动回滚：
defwatch_canary(baseline,candidate,window=300):metrics=otel_query(window)# 9-24 的 OTel 数据deltas={"faithfulness":candidate["faith"]-baseline["faith"],"p95_latency":candidate["p95"]-baseline["p95"],"cost":candidate["cost"]-baseline["cost"],}# 质量跌 >2% 或成本涨 >15% 或延迟涨 >30% → 回滚ifdeltas["faithfulness"]<-0.02ordeltas["cost"]>0.15ordeltas["p95_latency"]>0.30:rollback_to(baseline["version"])alert(f"灰度回滚:{deltas}")returnFalsereturnTrue| 指标 | 回滚阈值（示例） | 说明 |
|---|---|---|
| Faithfulness | 跌 > 2% | 质量优先，宁可慢发 |
| 单请求成本 | 涨 > 15% | 接 9-20 KV / 9-25 成本 |
| P95 延迟 | 涨 > 30% | 体验底线 |
| 错误率 | > 1% | 稳定性底线 |
5. 在线实验框架：A/B / 影子 / 区间
门禁只证明"没坏"，但**哪个版本"更好"**要靠在线实验。
| 实验 | 怎么做 | 适用 |
|---|---|---|
| A/B | 真实流量切分对比 | 已确认安全，比业务指标 |
| 影子（Shadow） | 新版本旁路上线、只记录不服务 | 上线前最后验证 |
| 区间（Holdback） | 留 5% 旧版做对照基线 | 长期监控回归 |
experiment:name:"ctx-v2-vs-v1"variants:-version:"ctx-v2"# 9-28/02 新上下文编排traffic:0.5-version:"ctx-v1"traffic:0.5metrics:[faithfulness,task_success,cost_per_task]min_runtime:72hdecision_rule:"faithfulness 不劣化且 task_success 提升 ≥1% 才全量"影子实验呼应 9-24/03：新版本在生产"影子跑"，输出不返回用户，只用来比对质量与成本，是风险最低的上线前验证。
6. 回滚与应急（接 9-26 护栏）
回滚不是"重启"，而是把版本路由权重一键拨回旧版，并保留现场：
- 版本快照：每次发布记录
模型 + prompt + ctx 模板 + RAG 配置的不可变快照； - 一键回滚：网关改权重即可，秒级生效（比传统回滚还快）；
- 护栏兜底：回滚期间若仍异常，9-26 出站护栏可临时降级为"只返回缓存/模板答案"，保可用性。
defrollback_to(version):ROUTING_TABLE["chat-prod"]["candidates"]=[{"model":version,"weight":1.0}]snapshot_save(version)# 存现场emit_event("rollback",version)7. 小结：从"能服务"到"敢发布"
至此，生产级 LLM 平台骨架彻底闭合：
- 协议/安全（9-19→9-23）：MCP 2.0 + 零信任网关
- 网关/成本（9-25/26）：统一路由 + 内容护栏 + 引擎吞吐
- 评测（9-20→9-26）：RLVR / VeriBench / 法官评测 / 黄金集
- 业务落地（9-27）：RAG / 微调 / 多 Agent
- 手脚与大脑（9-28）：工具调用（动手）+ 上下文工程（记忆）+持续交付（发布）
持续交付是最后一公里：它让前面所有能力安全地抵达生产、可量化地迭代。下一阶段可延伸到"多区域多模型容灾"与"模型生命周期自动退役"——平台从"建好"走向"自治"。
常见问题（FAQ）
Q1：LLM 应用的回滚和传统服务有什么不同？
A：传统回滚换二进制；LLM 回滚换"模型权重 + 提示词 + 上下文模板 + RAG 配置"的组合，必须整体版本化快照，否则回到的可能不是原来的行为。
Q2：灰度比例怎么定？
A：新模型/新提示词风险高，从 1%→10%→50%→100% 递增，每档盯够一个监控窗口（建议 ≥ 数小时覆盖峰谷）；纯配置微调可从 10% 起。
Q3：CI 门禁过了，为什么灰度还会出问题？
A：门禁用的是离线黄金集，生产是真实分布 + 真实工具副作用（9-28/01）。影子实验 + 灰度监控正是补这个 gap。
Q4：A/B 实验要跑多久？
A：至少覆盖一个完整业务周期（建议 ≥72h），让昼夜、工作日/周末波动都被采样，否则结论会被时段偏差污染。
Q5：成本指标怎么算才准？
A：按 9-20/25 的 per-request token 成本，结合 9-24 的 OTel 归因，排除缓存命中（9-25 语义缓存）的干扰，否则会低估真实增量。
Q6：多个版本同时灰度会乱吗？
A：用网关版本表 + sticky 路由集中管理，禁止子 Agent 自己硬编码模型名；所有版本选择收口到 9-25 网关一处。
Q7：回滚后旧版还计费等吗？
A：权重拨回后旧版即为主流量，按正常计费；回滚动作本身零成本（只改路由），比传统回滚的 downtime 损失小得多。
参考资料
- Google《MLOps for LLM Applications》持续交付实践，2026
- 本专栏 9-23《评测驱动模型迭代》：VeriBench 接 CI/CD 门禁
- 本专栏 9-24《从 CI 门禁到生产监控》：在线/影子/漂移监控
- 本专栏 9-25《统一 LLM 推理网关实战》：版本路由与成本感知
- 本专栏 9-26《LLM-as-Judge 自动化评测流水线》：质量 SLO 量化
- 本专栏 9-28《函数调用与工具执行沙箱实战》《上下文工程实战》：发布对象（工具/上下文）的版本化
