如何构建持续评估（Continuous Evaluation）流水线？
难度：高级 分类：Evaluation
简短回答
持续评估流水线是将 LLM/Agent 评估从"一次性测试"升级为"持续运行的质量保障系统"的工程实践。核心理念：评估不是发布前的关卡，而是贯穿整个生命周期的闭环。流水线包含三个阶段：(1) 开发期评估——在 CI/CD 中运行回归测试，Prompt 或模型变更触发自动评估；(2) 上线期评估——灰度发布 + A/B 测试 + 实时质量监控；(3) 运行期评估——对生产流量持续抽样评估，检测性能漂移（drift），自动告警。关键组件包括：Golden Dataset 定期更新、LLM-as-Judge 自动评分、用户反馈闭环、成本和延迟监控、熔断机制（Circuit Breaker）。工具链：CI/CD（GitHub Actions）+ 评估框架（DeepEval/Ragas）+ 观测平台（Langfuse/Braintrust）+ 告警（PagerDuty/Slack）。采用结构化评估的团队报告准确率提升 35-40%、迭代速度提升 5-10x。
详细解析
持续评估 vs 一次性评估
代码块
Plain Text
一次性评估的问题：
├── 评估一次后就"永远有效"的假设是错误的
├── 模型 API 版本更新 → 行为悄悄变化
├── 用户行为演化 → 原有测试集不再代表真实场景
├── Prompt 小修改 → 可能引入意想不到的退化
└── 数据变更（RAG 索引更新）→ 回答质量漂移
持续评估的理念：
├── 评估是 always-on 的，不是 one-shot 的
├── 每次变更自动触发评估（CI/CD 集成）
├── 生产流量持续被抽样评估（在线评估）
├── 指标趋势可视化 + 自动告警
└── 用户反馈回流到评估数据集（闭环）
三阶段流水线架构
代码块
Python
flowchart TD
A["变更触发
Prompt / 模型 / 代码"] --> B["开发期：CI 回归
不达标阻塞 PR 合并"]
B --> C["上线期：灰度发布
5% → 25% → 50% → 100%"]
C --> D["运行期：在线抽样评估
+ 漂移检测"]
D --> Q{"漂移 / 质量退化？"}
Q -- "是" --> E["熔断 / 自动回滚"]
Q -- "否" --> F["用户反馈回流
Golden Dataset 更新"]
F --> B
classDef proc fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
classDef decision fill:#fffde7,stroke:#f9a825,color:#795548
classDef err fill:#ffebee,stroke:#c62828,color:#b71c1c
class A,B,C,D,F proc
class Q decision
class E err
持续评估是闭环而非关卡：三阶段各设门，用户反馈回流 Golden Dataset 让测试集活着。
代码块
Python
class ContinuousEvalPipeline:
"""持续评估流水线的三阶段架构"""
# 阶段 1：开发期评估（CI/CD 集成）
dev_stage = {
"触发条件": [
"Prompt 文件变更（prompts/**）",
"模型配置变更（config/model.yaml）",
"Agent 代码变更（src/agent/**）",
"RAG 索引更新",
],
"评估内容": {
"回归测试": "在 Golden Dataset 上运行，对比基线",
"安全测试": "Prompt Injection、越权操作等",
"格式测试": "输出格式是否符合预期",
},
"阻塞条件": "关键指标低于阈值 → 阻止 PR 合并",
CI/CD 集成实现
代码块
YAML
# .github/workflows/llm-continuous-eval.yml
name: LLM Continuous Evaluation
on:
pull_request:
paths:
- 'prompts/**'
- 'config/model.yaml'
- 'src/agent/**'
在线评估系统
代码块
Python
class OnlineEvaluator:
"""生产流量的持续在线评估"""
用户反馈闭环
代码块
Python
class FeedbackLoop:
"""将用户反馈转化为评估数据"""
监控仪表盘设计
代码块
Plain Text
┌──────────────────────────────────────────────────┐
│ Agent 持续评估仪表盘 │
├──────────────────────────────────────────────────┤
│ │
│ 📊 质量趋势（近 7 天） │
实施路线图
代码块
Plain Text
Month 1: 基础设施
├── 接入 Langfuse/LangSmith，所有请求记录 Trace
├── 定义核心评估指标（质量、安全、延迟、成本）
└── 构建初始 Golden Dataset（50-100 条）
Month 2: CI/CD 集成
├── 回归测试集成到 GitHub Actions
├── Prompt 变更触发自动评估
└── PR 中自动 post 评估报告
Month 3: 在线评估
├── 部署 LLM Judge 对生产流量抽样评估
├── 搭建监控仪表盘
├── 配置告警规则
└── 用户反馈收集机制
Month 4-6: 闭环优化
├── 用户反馈 → Golden Dataset 更新
常见误区 / 面试追问
误区："评估一次就够了，模型又没变" — 即使不主动更换模型，API 提供商也可能更新版本（如 GPT-4 的 0613 → turbo 迁移）。RAG 索引更新、用户行为变化都会导致质量漂移。持续评估是发现这些隐性退化的唯一方式。
误区："在线评估太贵了" — 抽样评估 10% 的请求，用 GPT-4o-mini 做 Judge（成本约 $0.001/评估），1 万请求/天只需约 $1/天。相比质量问题导致的用户流失，这个成本微不足道。
追问："如何处理评估指标之间的冲突？" — 例如质量提升但成本翻倍。建议：(1) 定义各指标的优先级和阈值；(2) 用加权综合得分（如 quality×0.5 + cost×0.2 + latency×0.2 + safety×0.1）；(3) 设置硬性底线（如安全分 < 95% 一票否决）。
追问："小团队如何低成本起步？" — 最小可行方案：(1) 用 Langfuse（免费开源）记录所有请求；(2) 维护 50 条 Golden Dataset，用 pytest 在 CI 中跑；(3) 生产环境收集 👍👎 反馈。这三步花一周就能搭好，之后逐步迭代。