大模型评估不能只看一个排行榜分数。训练 loss 下降、benchmark 提升，都只是局部信号；真正上线前，要同时看能力、稳定性、安全性、成本和用户真实反馈。

一、为什么评估很重要#

大模型训练里最危险的一句话是：

这个版本看起来更聪明。

"看起来"不够，必须有评估体系。

原因很简单：

训练 loss 下降，不代表用户体验变好。
一个 benchmark 提升，可能另一个能力退化。
偏好优化后，模型可能更会聊天，但数学变差。
安全训练后，模型可能更安全，但过度拒答。
Agent 成功率提高，可能是靠更多工具调用和更高成本换来的。

所以评估体系要回答的是：

1
模型到底在哪些能力上变好了？
2
在哪些能力上变差了？
3
变化是否显著？
4
是否值得上线？
5
上线后真实用户是否买账？

二、评估要分层#

可以把大模型评估分成五层：

层次	关注点	例子
通用能力	基础知识、推理、代码、数学	MMLU、GSM8K、HumanEval
领域能力	是否适合具体业务	医疗、法律、金融、教育测试集
产品能力	指令跟随、格式、RAG、Agent	IFEval、工具调用准确率、任务成功率
安全能力	是否有害、越狱、隐私泄露	红队集、安全分类器、人工审核
线上效果	用户是否满意，业务指标是否提升	A/B、满意度、留存、badcase rate

离线 benchmark 是基础，业务评估和线上实验才决定能不能用。一个模型如果只在公开榜单上强，但在真实业务任务里不稳定，那它仍然不是一个好版本。

三、离线 Benchmark#

Benchmark 的优点是标准化、可复现、方便横向比较。

常见类型：

1. 通用知识#

MMLU
C-Eval
CMMLU

这类评估适合看模型的知识覆盖和考试型能力。

2. 数学推理#

GSM8K
MATH

这类评估关注数学题求解、推理链和最终答案。

3. 代码能力#

HumanEval
MBPP

通常会看生成代码是否通过测试。

4. 指令跟随#

IFEval
MT-Bench
AlpacaEval

这类评估更接近 assistant 能力，比如是否遵守格式、约束和多轮指令。

5. 长上下文#

可以评估：

长文档问答。
Needle-in-a-haystack。
多文档信息整合。
长代码库理解。

Benchmark 的问题是：它容易被污染，也容易被过拟合。

所以不能只看榜单分数，还要关注测试集是否进入训练数据、是否符合真实业务场景。

四、领域评估#

如果模型要进业务，领域评估比通用 benchmark 更关键。

比如：

医疗：诊断建议、用药风险、病历摘要。
法律：合同审查、条款解释、案例检索。
金融：研报摘要、风险提示、合规问答。
教育：题目讲解、学习路径、错题分析。
企业知识库：内部制度问答、工单处理、代码助手。

领域评估集最好来自真实场景：

高频用户问题。
历史 badcase。
专家构造的边界样本。
线上日志抽样脱敏。
对业务有高风险的关键场景。

评估维度也要业务化：

维度	说明
正确性	事实和结论是否对
完整性	是否覆盖关键点
可解释性	是否说明依据
稳定性	同类问题是否表现一致
合规性	是否越权、过度承诺
可执行性	用户能不能按回答行动

五、RAG 评估#

RAG 系统要分开评估"检索"和"生成"。

检索阶段常见指标：

指标	含义
Recall@k	正确文档是否出现在前 k 个结果里
Precision@k	前 k 个结果里有多少是相关的
MRR	第一个正确结果排得越靠前越好
nDCG	综合考虑相关性和排序位置
Hit@k	前 k 个结果是否命中

生成阶段常见指标：

Answer Correctness：答案是否正确。
Faithfulness：答案是否忠实于检索证据。
Citation Accuracy：引用是否对应原文。
Hallucination Rate：是否编造证据。
Refusal Quality：没有证据时是否正确拒答或提示不确定。

一个 RAG badcase 要拆开看：

1
是没检索到？
2
还是检索到了但模型没用？
3
还是模型用了错误证据？
4
还是问题本身需要澄清？

只有拆开，才能知道该优化 embedding、rerank、chunk、prompt，还是生成模型。

六、Agent 评估#

Agent 评估更不能只看最终文本。

关键指标包括：

Task Success Rate：任务成功率。
Tool Call Accuracy：工具选择和参数是否正确。
Step Count：完成任务用了多少步。
Cost：token、时间、API 调用成本。
Recovery Rate：工具失败后能否恢复。
Safety Violation Rate：是否调用危险操作。
Human Intervention Rate：是否需要人类接管。

coding agent 可以看：

测试通过率。
patch 是否最小。
是否引入无关改动。
是否遵守代码风格。
是否能解释修改原因。

web agent 可以看：

是否找到正确信息。
是否使用可信来源。
点击路径是否合理。
是否误填表单或越权操作。

Agent 的评估重点是"完成任务的过程是否可接受"，不是只看最后一句话。

七、安全评估#

安全评估至少要覆盖：

有害内容：暴力、自伤、违法指导。
隐私泄露：个人信息、密钥、内部数据。
越狱攻击：诱导模型绕过安全规则。
提示注入：工具和网页内容操纵模型。
偏见歧视：性别、地域、种族等敏感方向。
高风险建议：医疗、法律、金融等过度承诺。
幻觉：编造事实、引用、数据来源。

安全评估不能只靠模型自评，通常要结合：

红队样本。
自动安全分类器。
人工审核。
对抗测试。
线上监控。

这里要注意一个平衡：

1
拒答不足 -> 安全风险
2
过度拒答 -> 用户体验差

所以安全评估也要看 helpfulness，不是拒答越多越好。

八、线上 A/B 实验#

离线评估通过后，还要线上验证。

常见线上指标：

用户满意度。
点赞/点踩率。
追问率。
重新生成率。
任务完成率。
人工接管率。
投诉率。
留存和转化。
badcase rate。
平均成本和延迟。

A/B 实验要注意：

用户随机分流。
样本量足够。
指标提前定义。
高风险场景灰度放量。
监控负向指标。
保留回滚方案。

一个模型离线分数更高，但线上用户更不满意，是完全可能的。

比如它回答更长，benchmark 觉得完整，用户却觉得啰嗦。

九、评估集怎么构建#

一个好的内部评估集应该包括：

1. 固定集#

长期不变，用来做版本间对比。

2. 回归集#

收集历史 badcase，防止旧问题复发。

3. 挑战集#

专家构造高难和边界问题。

4. 线上抽样集#

从真实日志脱敏抽样，保持贴近用户分布。

5. 安全集#

覆盖越狱、隐私、有害内容和高风险建议。

评估集也要版本管理。否则今天测的题和明天测的题不一样，分数就没法比较。

十、自动评测和人工评测怎么配合#

大模型评估经常会用 LLM-as-a-Judge，也就是让另一个模型做裁判。它很方便，但不能无脑相信。

自动评测适合：

大批量初筛。
格式检查。
明确 rubric 下的打分。
对比两个版本的相对变化。
RAG faithfulness、引用一致性等半结构化判断。

人工评测适合：

高风险领域。
主观体验。
安全边界。
复杂推理过程。
自动裁判分歧大的样本。

比较稳的做法是：

1
规则评测：先抓格式、schema、测试是否通过
2
模型裁判：扩大覆盖面，快速发现问题
3
人工抽检：校准模型裁判，处理高风险样本
4
线上 A/B：验证真实用户行为

如果使用模型裁判，要固定：

judge 模型版本。
prompt 模板。
打分 rubric。
随机种子或温度。
评测样本版本。

否则评测本身也会漂移。

十一、评分 Rubric 怎么设计#

一个好的 rubric 要把"回答好不好"拆成可判断的维度。

比如企业制度问答可以这样拆：

维度	评分关注点
正确性	是否符合制度原文
完整性	是否漏掉关键材料或条件
证据性	是否引用正确文档
可执行性	用户是否知道下一步怎么做
合规性	是否越权承诺或泄露内部信息
简洁性	是否没有无关展开

如果只给一个总分，评估很难反向指导训练。拆成维度后，badcase 才能归因：是检索问题、生成问题、格式问题，还是安全问题。

十二、统计显著性和回归保护#

模型评估要防止被小样本波动骗到。

比如版本 A 在 100 道题上对了 82 道，版本 B 对了 84 道，不一定说明 B 稳定更好。可能只是样本波动。

线上 A/B 也一样。要提前定义：

主指标。
护栏指标。
最小样本量。
实验时间窗口。
分流策略。
回滚条件。

同时要有回归集。每次线上出过严重问题，都应该沉淀到回归评估里。否则模型迭代几轮后，很容易把老问题重新带回来。

十三、本篇小结#

评估体系的关键是分层和归因：

1
Benchmark 看基础能力
2
领域集看业务适配
3
RAG/Agent 指标看产品链路
4
安全集看边界
5
人工评测看主观质量和高风险判断
6
线上 A/B 看真实用户行为
7
回归集防止旧问题复发

训练阶段的 loss 只能说明模型更拟合某批数据，不能说明它真的更适合使用。真正可靠的模型迭代，必须让训练、评估、上线和数据飞轮连起来。