为什么需要评估
模型评估是 AI 工程的”仪表盘”。没有评估就无法量化进步,也无法发现退化。评估的意义在于:
- 选型决策:在多个模型中选出最适合业务场景的
- 质量监控:上线后持续跟踪,及时发现回归
- 优化方向:定位模型的薄弱环节,指导数据集构建
- 沟通对齐:用数据说话,让非技术团队理解模型能力
自动化 Benchmark
通用基准测试
| 基准 | 测量内容 | 典型模型得分(GPT-4o) |
|---|---|---|
| MMLU | 57 个学科的多选知识 | ~88% |
| HumanEval | Python 代码生成 | ~90% |
| GSM8K | 小学数学应用题 | ~96% |
| BBH | 复杂推理任务 | ~92% |
| HellaSwag | 常识推理 | ~95% |
| MATH | 竞赛级数学题 | ~76% |
使用 EleutherAI LM Evaluation Harness
# 安装
# pip install lm-eval
# 命令行评估
# lm_eval --model hf \
# --model_args pretrained=Qwen/Qwen2.5-7B \
# --tasks mmlu,gsm8k \
# --batch_size auto \
# --output_path ./results
自定义评估数据集
通用基准未必能反映真实业务场景。建议构建领域特定的评估集:
import json
from openai import OpenAI
# 领域特定评估
domain_evals = [
{
"input": "用户问:'我的订单没到,怎么办?'",
"expected_actions": ["查询订单状态", "安抚用户情绪"],
"expected_tone": "友好专业",
"not_allowed": ["提供虚假物流信息", "让用户自己联系快递"]
}
]
def evaluate_custom(模型回答, 预期结果):
score = 0
for action in 预期结果["expected_actions"]:
if action in 模型回答:
score += 1
if any(phrase in 模型回答 for phrase in 预期结果["not_allowed"]):
score = 0 # 禁止项出现直接 0 分
return score / len(预期结果["expected_actions"])
人工评估
自动化指标无法完全替代人类判断。以下是三种主流的人工评估方法:
1. 成对比较(Pairwise Comparison)
让标注员同时看两个模型的回答,选出更好的一个。
模型 A 回答:... ←→ 模型 B 回答:...
标注员的选项:
A 更好 | B 更好 | 差不多 | 都不好
优势:标注一致性高,容易统计。推荐使用 Elo 评分系统进行排名。
2. 逐点评分(Likert Scale)
对单个回答从多个维度打分。
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 正确性 | 事实错误 | 部分正确 | 完全正确 |
| 相关性 | 答非所问 | 部分相关 | 精准命中 |
| 完整性 | 遗漏关键点 | 覆盖大部分 | 无遗漏 |
| 安全性 | 有有害内容 | 无问题但模糊 | 安全且清晰 |
3. 多维质检矩阵
evaluation_template = {
"accuracy": {
"score": 0-5,
"issues": ["事实错误", "数据过期", "逻辑矛盾"]
},
"relevance": {
"score": 0-5,
"issues": ["答非所问", "遗漏关键点", "过度延伸"]
},
"format": {
"score": 0-3,
"issues": ["格式不符合要求", "代码不可运行"]
}
}
A/B 测试
A/B 测试是在真实用户流量中比较模型效果的方法。与离线评估不同,A/B 测试能捕捉用户的真实反应。
实验设计
import random
def ab_test_routing(user_id, query):
"""按用户 ID 哈希分流"""
hash_val = hash(f"{user_id}:{experiment_name}") % 100
if hash_val < 50:
return model_a_response(query) # 控制组
else:
return model_b_response(query) # 实验组
观察指标
| 类别 | 指标 | 说明 |
|---|---|---|
| 用户满意度 | 点赞率 | 用户主动点赞的比例,越高越好 |
| 用户参与度 | 追问率 | 用户继续提问的比例 |
| 任务完成 | 解决率 | 客服场景中问题一次性解决率 |
| 业务指标 | 转化率 | 电商场景中推荐到购买的转化 |
| 成本指标 | 单次成本 | 模型 API 费用 + 推理算力 |
A/B 测试至少需要运行 1-2 周,覆盖工作日的不同时段,避免节假日效应。
指标解读的常见陷阱
1. 聚合掩盖
平均分高但某些群体分数极低。比如模型在中文上表现好但在英文上差,整体平均值看不出来。
应对:按维度、按群体拆分分析。
2. 分布漂移
训练时的评估数据和上线后的真实数据分布不同。模型在某个 benchmark 上分数稳步提升,但上线后用户满意度却下降了。
应对:定期更新评估数据集,加入线上真实用户样本。
3. Goodhart 法则
当一个指标变成目标,它就失去了作为衡量标准的意义。如果团队只优化 MMLU 分数,最终会得到一个擅长考试但不实用的模型。
应对:同时追踪多个指标,包括线上行为指标。
4. 评估者偏差
人工评估中,标注员对模型 A 的偏好会影响对所有回答的判断。
应对:盲评(隐藏模型身份)、交叉验证、定期校准标注标准。
评估流程总结
离线 Benchmark → 领域评估集 → 人工评估 → 线上 A/B 测试 → 持续监控
↓ ↓ ↓ ↓ ↓
快速迭代 防退化 用户体验 业务验证 异常告警