第 20 章：评测体系

这是《LLM 应用开发 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 没有评测，Prompt、模型、检索和工具的修改都是盲改。LLM 应用评测要把主观质量转化为可比较、可回归、可归因的指标。

20.1 评测分层

不同层的问题要分开归因，端到端分数下降时不一定是模型退步，可能是检索或解析变差。

20.2 数据集结构

{
  "case_id": "order-refund-001",
  "user_role": "customer",
  "input": "订单 A-10001 能退款吗？",
  "expected": {
    "intent": "refund",
    "required_tools": ["get_order"],
    "answer_points": ["食品不支持无理由退款"],
    "forbidden": ["承诺具体到账时间"]
  },
  "tags": ["order", "refund", "policy"]
}

用例类型：

1. 高频请求；
2. 边界条件；
3. 模糊输入；
4. 多轮上下文；
5. 拒答场景；
6. 注入攻击；
7. 权限越界；
8. 历史坏案例；
9. 不同语言和格式。

20.3 离线评测

def evaluate_case(runner, case):
    actual = runner(case["input"])
    return {
        "case_id": case["case_id"],
        "intent_match": actual["intent"] == case["expected"]["intent"],
        "answer_points_hit": hit_points(actual["answer"], case["expected"]["answer_points"]),
        "forbidden_hit": contains_any(actual["answer"], case["expected"]["forbidden"]),
    }

流程：

变更
  -> 固定种子运行评测集
     -> 自动评分
        -> 抽样人工复核
           -> 指标对比
              -> 发布 / 打回

20.4 LLM as Judge

用模型评估模型输出时，需要评分标准：

维度：
1. 相关性：是否回答问题；
2. 忠实性：是否基于上下文；
3. 完整性：是否覆盖关键点；
4. 安全性：是否违反策略；
5. 引用准确性：引用是否成立。

每项 0-5 分，并给出证据。

风险：

1. 偏好长答案；
2. 偏好自家生成风格；
3. 评分不稳定；
4. 被输出中的自证话术误导；
5. 无法替代业务标注。

因此 Judge 结果必须与人工标注定期校准。

20.5 RAG 指标

20.6 Agent 指标

Agent 评测要检查轨迹，而不只看最终答案。

20.7 在线评测

线上信号：

注意反馈偏差：不满意的用户更可能反馈，沉默用户不代表完全满意。

20.8 统计显著性

比较两个版本时：

1. 固定评测集和随机种子；
2. 记录样本量；
3. 计算置信区间；
4. 分层比较；
5. 看业务关键指标；
6. 警惕多重比较；
7. 小样本提升不下结论。

示例：

v12 正确率 82.4%，n=500
v13 正确率 84.1%，n=500

提升 1.7 个点是否稳定，需要按类型和区间分析，而不是只看均值。

20.9 评测平台

基本能力：

1. 数据集版本管理；
2. 多配置并行运行；
3. 自动和人工评分；
4. trace 关联；
5. 指标看板；
6. 坏案例管理；
7. 权限和脱敏；
8. CI 集成；
9. 历史版本对比。

坏案例闭环：

线上问题
  -> 脱敏入集
     -> 归因
        -> 修复
           -> 回归
              -> 验证上线

20.10 常见反模式

本章小结

评测体系要覆盖组件、端到端、安全和线上指标，用版本化数据集、固定配置和可回放 trace 支撑回归。模型评分可以做规模化辅助，但必须与人工标注和真实用户结果校准。

思考题

1. 端到端分数下降时如何定位原因？
2. LLM as Judge 有哪些偏差？
3. RAG 应额外评估哪些指标？
4. Agent 为什么必须评估轨迹？
5. 如何把线上坏案例变成回归用例？