回归测试与 A/B 评测
一、回归测试
1.1 为什么需要回归测试
LLM 系统中任何环节的变更都可能导致能力退化：
- 模型权重更新（微调、偏好优化）
- Prompt 模板修改
- RAG 管线变更（检索策略、分块方式、嵌入模型）
- 模型版本升级（API provider 更新）
- 推理引擎配置变更
1.2 回归测试方法
黄金数据集（Golden Dataset）
- 精心策划的输入-期望输出对
- 覆盖关键业务场景和边界情况
- 每次模型变更后运行，对比结果
- 维护成本高但是最可靠的回归检测
自动化评测管线
- Promptfoo：开源 LLM 回归测试 CLI
- Braintrust：评测和实验平台
- LangSmith / LangFuse：追踪和评测
- DeepEval：多维度评估框架
LLM-as-a-Judge 回归
- 用强模型评估新模型在回归测试集上的表现
- 成对比较：旧模型 vs 新模型
- 单点评分：新模型输出是否达到质量阈值
1.3 回归测试最佳实践
-
分级测试：
- P0（关键路径）：每次变更必跑，阻塞发布
- P1（重要功能）：每日跑
- P2（边界情况）：每周跑
-
覆盖率：
- 功能覆盖：所有主要功能都有测试用例
- 场景覆盖：典型用户场景 + 边界场景
- 回归用例：从线上问题转化而来的"永不退化"测试
-
评估门禁（Eval Gate）：
- 设定质量阈值，低于阈值自动阻止部署
- 结合自动化指标和 LLM-as-a-Judge 评分
二、A/B 评测
2.1 A/B 测试设计
流量分配
- Canary 部署：5-10% 流量到新版本
- Shadow Mode：新版本并行运行但不服务用户（暗线对比）
- A/B 分流：50/50 或按比例分流
分流策略
- 随机分流（用户级或请求级）
- 分层分流（确保用户特征均衡）
- 时间片分流（交替时段）
2.2 关键追踪指标
| 类别 | 指标 |
|---|---|
| 任务质量 | 任务成功率、答案准确率 |
| 用户体验 | TTFT、延迟、会话长度 |
| 安全性 | 有害输出率、安全事件 |
| 用户反馈 | 正/负反馈率、编辑率 |
| 成本 | 每请求成本、GPU 利用率 |
2.3 统计显著性
- 样本量计算：基于预期效果量和基线率
- 置信区间：通常要求 95% 置信度
- 测试时长：确保足够样本和周期完整性
- 多重比较校正：同时测试多个指标时需校正
2.4 A/B 测试陷阱
- Novelty Effect：用户对新版本有短暂偏好
- Simpson's Paradox：总体和分组结论可能相反
- 不完整数据：部分用户流失导致偏差
- 外部因素：时间段、事件等干扰因素
三、生产部署流程
3.1 标准发布流程
离线评测通过
-> Shadow Mode（暗线运行，收集对比数据）
-> Canary（5% 流量，监控关键指标）
-> 扩大流量（25% -> 50% -> 100%）
-> 全量发布
3.2 回滚策略
- 即时回滚：检测到关键指标退化时立即回滚
- 版本固定（Version Pinning）：避免 API provider 静默更新
- 蓝绿部署：维护两个环境，快速切换
3.3 持续评测
- 不只是发布时评测，而是持续监控
- 实时监控输出质量漂移
- 定期运行回归测试套件
- 收集用户反馈形成新的测试用例
四、工具推荐
| 工具 | 用途 |
|---|---|
| Promptfoo | 回归测试 CLI |
| LangSmith | 追踪 + 评测 + A/B |
| Braintrust | 评测和实验平台 |
| Evidently AI | 数据和模型漂移监控 |
| Arize | 生产监控和异常检测 |
| Grafana + Prometheus | 基础设施指标监控 |
五、前沿趋势（2024-2025）
- 自动化回归修复：检测到回归后自动调整超参数
- 持续评测（Continuous Eval）：将评测嵌入 CI/CD 管线
- 回归悬赏：从真实用户问题中提取永不退化的测试用例
- 多模型 A/B：同时对比多个候选模型