跳到主要内容

LLM 评测数据集与回归测试

📊 LLM 评测的目标不是得到一个漂亮的总分，而是判断：这次模型、Prompt、检索或工具变更，是否让真实用户任务变好，并且没有破坏已有能力。

评测体系的四层结构​

  1. 样例级断言：格式、关键词、工具调用、引用和安全边界是否满足。
  2. 数据集指标：正确率、召回率、平均评分、失败率。
  3. 切片分析：按场景、语言、难度、用户类型、输入长度拆分。
  4. 线上指标：采纳率、任务完成率、人工接管率、延迟与成本。

Benchmark 适合比较通用能力，业务回归集才适合决定是否发布。

**核心原则：**评测单位应尽量接近用户任务。对 Agent，优先评价“订单是否正确取消”，而不是最后一段文字是否流畅。

先把任务类型分清​

任务主要指标不要只看
分类/抽取Accuracy、Precision、Recall、F1、Schema 合规率文本相似度
问答正确性、相关性、完整性ROUGE/BLEU
RAGRecall@K、MRR、Context Precision、Faithfulness最终答案总分
Agent任务成功率、工具选择、参数正确率、步骤数最终文本好不好看
代码编译率、单测通过率、pass@k、安全扫描与参考代码相似度

构建高质量回归集​

每条样例至少包含：

{
  "id": "refund-017",
  "input": "用户请求",
  "context": "可选上下文",
  "expected": {
    "facts": ["必须出现的事实"],
    "forbidden": ["不能出现的内容"],
    "tool": "lookup_order"
  },
  "slice": ["中文", "退款", "缺少订单号"],
  "severity": "critical"
}

来源优先级：线上失败案例 > 人工设计边界案例 > 合成扩充 > 公共 Benchmark。每次修复事故时，把最小失败输入加入回归集。

LLM-as-Judge 怎么用才可靠​

  • 使用明确 rubric，把“好”拆成可观察标准。
  • 尽量盲评并随机交换 A/B 顺序，降低位置偏差。
  • 对关键样例使用多次评分或多个 Judge。
  • 定期用人工标注集校准 Judge，计算一致率。
  • Judge 输出必须包含分项分数和简短证据，便于审计。

**注意：**Judge 容易偏爱更长、更自信、措辞相似的答案；同源模型还可能产生家族偏差。

RAG 要拆开评​

若 Recall@K 不达标，先修检索；证据已召回但答案错误，再修上下文组装和生成。不要用一个总分掩盖故障位置。

CI 回归门禁​

  • 固定模型版本、Prompt 版本、数据集版本和采样参数。
  • 重试只处理网络错误，不要用“多跑几次取最好”掩盖波动。
  • 对关键切片设置独立阈值；严重安全样例应零容忍。
  • 同时比较质量、P95 延迟和单次任务成本。
  • 保存失败样例、模型原始输出、工具轨迹和 trace ID。
def gate(candidate, baseline):
    assert candidate["critical_pass_rate"] == 1.0
    assert candidate["task_success"] >= baseline["task_success"] - 0.01
    assert candidate["p95_latency_ms"] <= baseline["p95_latency_ms"] * 1.10
    assert candidate["cost_per_task"] <= baseline["cost_per_task"] * 1.15

常见公共数据集​

  • MMLU / MMLU-Pro：多学科知识与推理。
  • GSM8K / MATH：数学推理。
  • HumanEval / MBPP / SWE-bench：代码生成与软件工程。
  • TruthfulQA：诱导性问题下的真实性。
  • MT-Bench / Arena 风格评测：多轮对话偏好。

公共榜单可能存在数据污染，不能直接代表业务效果。

发布前检查清单​

  • 覆盖正常、边界、对抗和缺失信息案例
  • 测试集与开发样例隔离
  • 有切片指标，不只看平均分
  • 对 Judge 做过人工校准
  • 同时监控质量、延迟、成本和安全
  • 每个生产事故都会沉淀为回归样例