第十章：LLM CI/CD 与灰度、Canary、A/B 发布
10.1 LLM CI/CD 流水线长什么样
传统 CI/CD 的"测试"阶段是确定性断言,LLM 应用的流水线在这一阶段替换成第 7 章的离线评测门禁,发布阶段则需要比传统蓝绿部署更谨慎的灰度策略——因为质量退化不像应用崩溃那样会立刻报错,而是悄悄发生。
flowchart LR
A["提交 Prompt/模型/路由变更"] --> B["自动化离线评测
(黄金测试集 + 切片门禁)"]
B -->|不通过| A
B -->|通过| C["Shadow 影子流量测试"]
C --> D["小流量灰度 5%-10%"]
D --> E{"线上指标是否达标?"}
E -->|是| F["逐步放量 25% → 50% → 100%"]
E -->|否| G["自动回滚"]
F --> H["全量发布"]
G --> A
style B fill:#fff3cd
style E fill:#fff3cd
style G fill:#fce8e6
10.2 Shadow 测试:让新版本"看见"流量但不影响用户
在真正切流量之前,可以让新版本(新 Prompt/新模型)接收生产流量的复制,产出结果但不返回给用户,只用于离线对比:
def handle_request(request):
response = production_pipeline(request) # 真实返回给用户
if shadow_enabled():
async_run(shadow_pipeline, request) # 异步执行,结果只记录不返回
return response
Shadow 测试的价值在于用真实流量分布验证新版本,而不承担任何用户体验风险,是离线评测(固定测试集)和线上灰度(真实承接流量)之间的中间地带。局限是它只能对比"输出内容",无法验证端到端的用户交互体验(如多轮追问)。
10.3 灰度发布:按比例放量,而不是一步切换
rollout_plan:
- stage: canary
traffic_percent: 5
duration_minutes: 60
guard_metrics:
error_rate_max: 0.02
contract_violation_rate_max: 0.01
p99_latency_ms_max: 8000
- stage: ramp_25
traffic_percent: 25
duration_minutes: 120
- stage: full
traffic_percent: 100
每一阶段都设置护栏指标(guard metrics),这些指标来自第 8 章的可观测性聚合数据。任意护栏指标越界,自动暂停放量或回滚到上一阶段,而不是等人工发现问题。
10.4 A/B 测试:回答"哪个版本更好",而不只是"新版本有没有崩"
灰度发布关注的是"新版本是否安全",A/B 测试关注的是"两个版本哪个业务效果更好",两者可以结合但目的不同:
| 灰度发布 | A/B 测试 | |
|---|---|---|
| 核心问题 | 新版本会不会引发事故 | 新旧版本哪个业务指标更好 |
| 流量分配 | 单调递增(5%→25%→100%) | 长期保持固定比例对照(如 50/50) |
| 判断依据 | 错误率、延迟、契约违反率等护栏指标 | 用户满意度、任务完成率等业务指标 |
| 典型时长 | 数小时到几天 | 数天到数周,需要统计显著性 |
10.4.1 A/B 测试对样本量和统计显著性有明确要求
LLM 输出的业务指标(如用户满意度)方差通常比传统 A/B 测试(如按钮点击率)更大,需要更大的样本量才能得出有统计意义的结论。没有做显著性检验就下结论"新版本更好",是最容易踩的坑——观察到的差异很可能只是噪声。
from scipy import stats
def is_significant(control_scores: list[float], treatment_scores: list[float], alpha=0.05) -> bool:
_, p_value = stats.ttest_ind(control_scores, treatment_scores)
return p_value < alpha
10.5 回滚要快且要有明确触发条件
回滚不应该依赖人工盯着仪表盘做判断,应该把 10.3 节的护栏指标接入自动化回滚:
def check_rollout_health(current_metrics: dict, guard_metrics: dict) -> bool:
for metric_name, max_value in guard_metrics.items():
if current_metrics.get(metric_name, 0) > max_value:
trigger_rollback(reason=f"{metric_name} 超过阈值")
return False
return True
回滚目标应该是第 9 章版本注册表里"上一个已知良好版本"的完整快照——Prompt、模型快照、路由策略三者一起回滚,而不是只回滚其中一项,否则可能出现版本组合不一致导致的新问题。
10.6 常见错误
10.6.1 评测通过就直接全量发布
离线评测无法覆盖生产环境全部输入分布,必须经过 Shadow 测试和灰度放量的验证,才能全量。
10.6.2 灰度阶段不设护栏指标,靠人工盯着看
人工监控响应慢且容易疏漏,护栏指标应该接入自动化的暂停/回滚机制。
10.6.3 把灰度发布和 A/B 测试混为一谈
灰度发布关注"安全性",A/B 测试关注"业务效果哪个更优",两者的流量策略和判断依据都不同,不能用同一套流程处理。
10.6.4 A/B 测试样本量不足就下结论
LLM 业务指标方差大,没做统计显著性检验就宣布"新版本更好",很可能被噪声误导。
10.6.5 回滚只回滚模型,不回滚配套的 Prompt 和路由策略
三者应作为一个整体版本快照一起回滚,否则可能出现新旧配置不匹配引发的次生问题。
10.7 本章总结
- LLM CI/CD 用评测门禁替代传统的确定性测试断言,发布环节需要比传统应用更谨慎的灰度策略;
- Shadow 测试用真实流量验证新版本,但不影响用户,是离线评测和线上灰度之间的中间地带;
- 灰度发布按比例递增放量,每阶段设自动化护栏指标,越界自动暂停或回滚;
- A/B 测试和灰度发布目的不同:前者比较业务效果,后者验证安全性,需要统计显著性支撑结论;
- 回滚要快且自动化,回滚目标是版本注册表里的完整版本快照,而非单一组件。