模型评测方法论：怎么给自己的场景做可信的 LLM 评测
模型评测方法论：怎么给自己的场景做可信的 LLM 评测
换模型、改提示词、升级版本——你怎么知道是变好了还是变差了?看公开 benchmark 分数基本没用,因为它的测试数据和你的真实场景往往完全不同。本文讲清怎么构建一套属于你自己业务的评测体系:评测集、评分方法、A/B 对比、回归测试流程。有了它,每次模型更换不再是凭感觉,而是有据可依。
30 秒版本
评测的核心不是选一个分数,而是建一个固定的评测集:从真实业务里挑 30-100 条代表性输入 → 定义「好答案」的标准 → 每次改动前后用同一组题跑一遍 → 人工或 LLM-as-judge 打分 → 对比结果再决定。评测集本身要版本管理,和代码一样。
为什么公开分数不够用
MTEB、MMLU 这类公开基准有价值,但有三个天然局限:
- 数据分布不同:基准考的是通用知识或学术题,你的业务可能是内部文档、特定格式、行业术语
- 没有你的约束:输出格式、语气、合规要求、拒答边界,基准都不测
- 可被针对性优化:模型训练时可能见过类似题,分数高不代表泛化好
所以公开分数的正确用法是「缩小候选范围」,最终选择必须用自己的评测集。
评测集是资产,不是一次性脚本
一套好的评测集能反复用:换模型、换提示词、升级引擎版本、调温度参数,都跑同一组题。它会随着业务演进补充新题,和代码一样需要版本管理。投入半天建起来,后面每次决策都省时间。
第一步:构建评测集
1. 从真实场景采样。 从生产日志或业务方需求里挑 30-100 条代表性输入,覆盖:
| 类别 | 占比建议 | 例子 |
|---|---|---|
| 高频典型任务 | 50-60% | 日常最常见的问题 |
| 边缘/困难案例 | 20-30% | 长输入、歧义、多约束 |
| 必须拒答/边界 | 10-20% | 不该回答、信息不足 |
2. 为每条定义「好答案」标准。 不是写死唯一答案(多数任务没有),而是列检查点:
- 事实是否正确
- 是否覆盖了该覆盖的要点
- 格式是否符合要求(JSON 字段、长度、语气)
- 不该编造时有没有编造
3. 存成结构化文件。 一条评测样本包含 id、输入、检查点、标签(场景类别)。JSONL 或 CSV 都行,重要的是能被脚本稳定读取。
{
"id": "case-001",
"input": "把这段产品描述改写成图像生成提示词",
"checkpoints": ["包含主体与风格描述", "输出为单段文本", "不添加原文没有的数字"],
"category": "high_frequency"
}
第二步:选评分方法
| 方法 | 怎么做 | 适合 | 局限 |
|---|---|---|---|
| 人工评分 | 人按检查点逐条打分 | 质量敏感、样本少 | 慢、贵、主观 |
| LLM-as-judge | 用强模型按 rubric 打分 | 中等规模、快速迭代 | judge 自身有偏差 |
| 自动指标 | 精确匹配、JSON 校验、正则 | 结构化输出 | 测不了开放性质量 |
实践中通常组合:结构化任务用自动指标兜底,开放性任务用 LLM-as-judge 做初筛,再人工抽查 judge 打分不一致的样本。
LLM-as-judge 的两条纪律
① judge 必须用与被测模型不同家族的强模型,避免自评偏好;② 打分 rubric 要写进文件固定下来,不要每次临时改措辞。judge 分数只是相对比较用,不是绝对质量结论——它也可能被表面流畅度带偏。人工抽查是必要的安全网。
第三步:A/B 对比
对比两个模型/两个提示词时,纪律比工具重要:
- 固定同一组题、同一套参数(温度、max_tokens、系统提示,除被测变量外全部一致)
- 只改一个变量——同时换模型和改提示词,结果无法归因
- 盲评:把 A/B 输出打乱顺序再给评分者,避免位置偏好
- 记录逐条结果,不只看平均分——可能 A 在长输入上明显更好,B 在短输入上略好
- 看分布,不只看均值:平均分相近时,看失败案例的严重程度,一个严重幻觉比十个轻微风格差异更重要
# 最小 A/B 骨架:同一组题跑两个配置并保存结果
import json
cases = [json.loads(l) for l in open("eval_set.jsonl")]
results = []
for case in cases:
for variant in ["model_a", "model_b"]:
out = call_model(variant, case["input"]) # 你的调用封装
results.append({"id": case["id"], "variant": variant, "output": out})
json.dump(results, open("run_001.json", "w"), ensure_ascii=False, indent=2)
第四步:回归测试流程
把评测接进变更流程:
- 换模型/升级版本:跑全量评测集,对比上一版基线
- 改提示词:跑评测集 + 该提示词相关的子集
- 引擎/量化档位变更:跑评测集,同时记录延迟与显存
- 判定规则:关键检查点不允许退化;平均分小幅波动看分布
回归的价值在于抓「静默退化」:上游模型更新后不报错、但输出风格变了,只有固定评测集能发现。云端 API 的模型会随平台更新,建议每月跑一次回归;本地模型则在每次升级前跑。
评测不是一次性的
评测集随着业务演进补充新题,老题保留。每次改动的结果归档(带日期、模型/版本、参数、分数)。三个月后你想复盘「为什么当时选了这个模型」,这些记录就是答案。
常见误区
误区一:样本越多越好。 30 条高质量、覆盖边缘案例的样本比 500 条重复的高频题更有信息量。先保证覆盖面,再扩量。 误区二:只看平均分。 平均分掩盖分布:一个严重错误比十个轻微波动更重要,要给失败案例分级。 误区三:评测集跟着提示词一起改。 评测集是标尺,不能为了「让分数好看」改题。要改就显式记录版本变更,并重新建立基线。 误区四:LLM-as-judge 的结论当真理。 它是相对比较工具,结论要用人工抽查校准,尤其是高风险场景。
FAQ
评测集要多大?
LLM-as-judge 可信吗?
云端模型会更新，怎么保证不退化？
A/B 对比要注意什么?
评测集和训练/微调数据要分开吗?
价格在哪里看?
相关阅读
- Embedding 模型选型 — 检索环节的实测方法
- RAG 知识库搭建实战 — 需要评测的典型场景
- 模型版本管理 — 升级与回滚流程
- Qwen 成本优化实战 — 评测与成本的关系
- 生产就绪清单 — 上线前检查