LLM 评测与运维：从质量指标到灰度控制
0. 元信息
- 主题路径：
docs/topics/llm-applications/subtopics/llm-eval-and-ops/ - 父主题：
llm-applications - 适合对象：已经做出 LLM 原型、希望稳定上线的开发者
- 建议周期：1～2 周
- 前置知识：无额外前置（继承父主题依赖）
- 最终目标：能用多种评测方法衡量质量，监控延迟/错误/成本，并安全执行灰度与回滚
1. 学习路线
评测集与标注规范
→ 人工评测
→ A/B 测试与 LLM-as-judge
→ 质量/延迟/错误监控
→ Token 成本控制
→ 灰度、门槛与回滚
3. 阶段表
| 阶段 | 核心知识 | 实践产出 | 可观察学会标准 |
|---|---|---|---|
| 1. 评测设计 | 任务定义、样本、标签、人工 rubric | 30 条评测集 | 每条样本有期望行为和判定理由 |
| 2. 多方法评测 | 人工、A/B、LLM-as-judge、偏差校准 | 评测脚本与报告 | 能解释三种方法的适用边界，人工抽样校准 judge |
| 3. 监控 | 质量、成功率、P50/P95、首 token、上下文、拒答 | 指标面板和告警 | 能从 trace 定位失败阶段 |
| 4. 成本与灰度 | token 预算、缓存、路由、采样、canary、回滚 | 成本表与灰度方案 | 超门槛自动停止，能复现回滚决策 |
9. 学习资料汇聚（v0.3 自包含）
9.1 背景与动机
LLM 输出具有概率性，传统“接口返回 200”无法代表业务成功。评测把质量变成可比较数据，运维把质量、延迟、错误和成本变成持续反馈，灰度则把上线风险控制在小范围内。
9.2 概念地图
flowchart LR
Dataset[评测集] --> Human[人工 rubric]
Dataset --> AB[A/B 测试]
Dataset --> Judge[LLM-as-judge]
Human --> Gate[质量门槛]
AB --> Gate
Judge --> Gate
App[应用 trace] --> Metrics[质量/延迟/错误/成本指标]
Metrics --> Canary[灰度]
Gate --> Canary
Canary --> Rollback[回滚]
9.3 基础知识讲解
主推 OpenTelemetry 文档（日志、指标、trace）和项目自身的标注 rubric；备查 Ragas 等 RAG 评测工具。LLM-as-judge 只能作为辅助信号，必须保留人工校准样本和评测版本。
9.4 经典问题与经典案例
| 问题 | 最简答案 |
|---|---|
| 评测集过于简单 | 增加真实失败、拒答和长上下文样本 |
| judge 偏爱长答案 | 盲化模型名，加入长度和引用控制项 |
| 平均值掩盖尾延迟 | 同时看 P50/P95/P99 和首 token |
| 成本突然升高 | 记录 input/output token、模型路由和预算 |
| A/B 混入不同流量 | 固定分流、用户分桶和实验窗口 |
| 灰度没有回滚 | 上线前定义质量、错误率和成本阈值 |
9.5 学习难点
- 概念难点：相关性、忠实性、任务成功率不是同一个指标；按任务拆指标。
- 思维难点：评测是实验设计，不是挑几个好例子截图。
- 工程难点：指标必须关联 trace、版本和输入条件，否则无法复盘。
9.6 技术标准与接口
Entity
Dataset/version、rubric、judge score、trace/span、counter、histogram、cost budget、canary cohort。
Scope
指标描述系统表现，不能代替安全审查、人工责任或业务验收；灰度控制发布暴露面，不修复根因。
Structure
掌握成功率、引用正确率、faithfulness、P50/P95、首 token、错误分类、token usage、单位请求成本和回滚阈值。
Ecosystem
OpenTelemetry 是观测基础；Prometheus/Grafana 等负责采集展示；Ragas 等负责部分评测计算。具体命名和采样策略需在项目中固定。
Depth Tiers
L0 知道指标存在；L1 看懂评测报告；L2 能建立评测集和面板；L3 能定位回归并执行灰度；L4 能设计跨版本质量门禁。本子主题要求 L3。
Source
OpenTelemetry、Prometheus、Grafana、Ragas 官方文档；版本快照日期：2026-07-28。