评估与回归测试

第 15 章讲了看日志、做标注。但「效果好不好」不能只靠感觉。本章讲如何用评估数据集与指标，把效果变成可比较的数字，并在每次改动后做回归测试。

1. 为什么需要评估体系

提示词、检索参数、模型一变，效果可能悄悄变差。没有量化基线，你无法回答「这次改动是变好了还是变差了」。

核心做法：准备一组固定评测集（问题 + 期望答案/标准），每次改动都跑同一集，对比分数。

2. 构建评测集

# 评测集条目（dataset.yaml 示意）
cases:
  - query: "如何申请退款？"
    expected: "在订单页点击退款，需 3 个工作日内审核"
    golden_retrieval: ["退款政策#第2节"]
  - query: "订单号 ORD-12345 到哪了？"
    expected_contains: ["已发货", "物流"]

💡评测集要覆盖边界

除了典型问题，也要放「答不出该说不知道」的问题、敏感问题、超长输入。只测理想样本会高估效果。

3. 常用评分指标

命中率（Recall）：标准答案所需片段是否被召回
包含率（Contains）：回答是否含关键事实
GPT 评分：用一个强模型当评委，按 rubric 打 1–5 分
人工标注：对关键场景做抽样人工核对

evaluation:
  metrics: [recall, contains, gpt_score]
  gpt_rubric: "回答是否准确、完整、无幻觉，1到5分"
  threshold:
    gpt_score: 4.0
    recall: 0.8

4. 回归对比流程

每次发布前，先跑评估，再与上一版分数对比：

# 伪流程
run_eval --app current --dataset cases.yaml --out v_new.json
compare v_old.json v_new.json
# 若 gpt_score 下降超过 0.3，则阻断发布

⚠️分数不能替代人工

自动化指标适合抓「明显退步」，但语气、合规等细节仍需人工抽查。把评估当「预警」，别当「终审」。

🎯动手做

整理 10 条你应用最常见的问题及期望答案，跑一次评估，记录当前 gpt_score 与 recall，作为后续改动的对比基线。

小结

用固定评测集把效果量化，避免拍脑袋
指标覆盖召回、包含、GPT 评分与人工
回归对比能拦住「越改越差」的发布
指标预警、人工终审；下一步讲应用版本管理 →