摘要

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），效果可能断崖。

LLM 应用还有个特殊难点：回滚对象不是二进制，而是"模型权重 + 提示词 + 上下文模板 + RAG 配置"的组合，必须整体版本化。

2. 流水线全景：从门禁到灰度

代码/提示词/模型变更 → 9-23 CI 门禁(VeriBench 通过率 ≥ 阈值) → 打版本标签(模型+prompt+ctx+RAG 配置) → 9-25 网关注册新版本路由 → 灰度(1% → 10% → 50% → 100%) → 9-24 监控盯 SLO(延迟/成本/质量) → 达标全量 / 异常自动回滚 → 在线实验(A/B) 量化业务指标

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

5. 在线实验框架：A/B / 影子 / 区间

门禁只证明"没坏"，但**哪个版本"更好"**要靠在线实验。

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 损失小得多。

参考资料

1. Google《MLOps for LLM Applications》持续交付实践，2026
2. 本专栏 9-23《评测驱动模型迭代》：VeriBench 接 CI/CD 门禁
3. 本专栏 9-24《从 CI 门禁到生产监控》：在线/影子/漂移监控
4. 本专栏 9-25《统一 LLM 推理网关实战》：版本路由与成本感知
5. 本专栏 9-26《LLM-as-Judge 自动化评测流水线》：质量 SLO 量化
6. 本专栏 9-28《函数调用与工具执行沙箱实战》《上下文工程实战》：发布对象（工具/上下文）的版本化