LLM 应用的评估（Evals）实战

结论先行：Evals 是 LLM 产品的护城河。模型会换、prompt 会改、数据会漂，只有一套可信的评估体系能让你放心迭代。它对 LLM 应用的意义，等价于单元测试之于传统软件。

1. 三层评估金字塔

层	对象	频率	例子
单元级	单个 prompt / 组件	每次改动	JSON 合法率、字段抽取准确率
场景级	端到端任务	每次发布	一组真实用户任务的通过率
线上级	生产流量	持续	用户反馈、拒答率、延迟、成本

2. 先建"黄金集"（Golden Set）

来源：真实日志脱敏 + 人工补齐边界样本（空结果、歧义、对抗、超长）。
规模：起步 50–200 条即可产生价值；宁精勿滥。
结构：{ input, ideal_output?, must_include[], must_not_include[], tags }。不是每条都需要唯一标准答案——很多任务用性质断言比精确匹配更实用。
版本化：黄金集入库/入仓，随产品演进增补，形成回归资产。

3. 指标怎么选

3.1 确定性指标（能算就别用模型）

分类/抽取：精确率、召回率、F1、字段级准确率。
格式：JSON 合法率、schema 通过率。
检索：Recall@k、MRR、nDCG（见 §4）。
运营：p50/p95 延迟、每请求 token/成本、拒答率、错误率。

3.2 LLM-as-Judge（主观质量）

对"有帮助/忠实/连贯"这类难量化维度，用强模型按 rubric 打分：

你是严格评审。依据下面评分表给"回答"打分(1-5)并给出理由。
维度：忠实性(仅依据资料)、相关性、完整性。
资料：{{context}} 问题：{{q}} 回答：{{a}}
输出 JSON: {"faithfulness":n,"relevance":n,"completeness":n,"reason":"..."}

必须校准：先让人工标 30–50 条，测 judge 与人工的一致性（如 Cohen's κ / 相关系数）。judge 与人不一致时，先修 rubric，别急着信分数。注意位置偏差（成对比较要交换顺序取平均）。

4. RAG 专项指标（把检索和生成分开测）

把失败归因到层，否则你会瞎调：

检索层：Context Recall（该被检回的是否检回）、Context Precision（检回的是否相关）。
生成层：
- Faithfulness / 无幻觉：回答是否只由上下文支撑。
- Answer Relevance：回答是否切题。
经验法则：先保证检索 Recall 够高，再优化生成忠实性。参见 RAG 架构的分层调优。

5. 把评估接进 CI：回归门禁

改动 prompt/模型/检索参数
      │
      ▼
跑黄金集  ──►  指标对比基线
      │
      ├─ JSON 合法率 < 99%    → 阻断
      ├─ 关键任务通过率下降 >2% → 阻断
      └─ 成本/延迟回归超阈值   → 告警

原则：任何影响输出的改动都要过评估，像跑测试一样。为可复现，固定随机种子/温度，或对采样类指标多次取均值。

6. 线上评估与反馈闭环

隐式信号：重试率、复制率、点赞点踩、会话时长、人工接管率。
显式反馈：一键报错，把 case 回流进黄金集。
影子/对拍：新版本影子运行，与线上版本对同一流量打分再切换。
漂移监控：输入分布、拒答率、平均分随时间的曲线。

7. 常见坑

只看"感觉变好了"没有数字——无法防回归。
黄金集全是简单样本——线上一到边界就崩。
盲信 LLM-as-Judge 未校准的分数。
把检索和生成混在一个指标里，定位不到根因。
评估数据泄进训练/few-shot，导致虚高。

小结

先花两天搭一个 50 条黄金集 + 少量确定性指标 + 一个校准过的 judge，你的迭代速度和信心会立刻不同。评估体系的成熟度，基本等于 LLM 团队的成熟度。