AI 热门概念手册

外观

LLM 评估与基准

本页速览 LLM 评估是系统性度量模型能力、行为与风险的方法体系——从 MMLU、GSM8K 等基准到 LLM-as-a-judge、红队测试，本文讲清基准分数为何不等于真实能力，以及如何把评估做成工程闭环。

本页含时效性内容，数据截止于 2025-06；JD、榜单、产品功能等信息可能已变化，引用前请核对原始出处。

LLM 评估与基准 ​

概念定义：没有评估，就没有改进 ​

LLM 评估（evaluation）是系统性地度量模型能力、行为与风险的方法体系。 大语言模型（Large Language Model, LLM）是概率式文本生成器，同一个问题每次输出都可能不同，甚至"看起来对"和"真的对"之间常常隔着一步推理。因此，没有评估就没有改进，也没有可信的选型——你无法知道一次微调是变好了还是变坏了，也无法在采购 API 时判断哪个模型更划算。无论是学术界发论文、厂商发版本、还是企业选型落地，评估都是全部决策的事实基础。

评估在 LLM 生命周期里无处不在，且每个阶段侧重不同：

阶段要回答的问题典型手段
预训练后基础能力如何？通用基准（MMLU、HumanEval）
对齐/微调后指令跟随、偏好是否改善？MT-Bench、IFEval、人工对比
上线前安全、幻觉、有害内容风险？红队测试、对抗攻击、安全基准
产品落地用户真实任务做得好吗？RAG 评测、Agent 评测、产品级评估
持续迭代有没有回归退化？私有黄金集 + CI 回归测试

一句话判断

先定义"好"的标准，再谈训练和调优。 评估设计是 LLM 项目最重要的工程决策之一——你用什么指标评估，就决定了模型朝哪个方向优化。

为什么 LLM 评估这么难 ​

传统机器学习有明确的监督信号（标签、回归目标），而 LLM 评估要面对四个系统性难题：

  1. 开放性任务没有唯一答案：写一封邮件、总结一份财报、设计一个方案，没有标准答案，"好"是模糊的；
  2. 『看起来对』≠『真的对』：模型可能流畅地编造一个不存在的引用、煞有介事地推导出错误结论——即幻觉（hallucination），答案的语法质量与事实正确性完全脱钩；
  3. 评测集污染（contamination）：训练数据里如果包含测试题的原文或变体，模型等于"考前看过答案"，分数虚高，无法反映真实泛化能力；
  4. 评估者本身不可靠：人工评测昂贵且不稳定，LLM 裁判（judge）又有自己的偏好偏差（见后文）。

数据污染是最隐蔽的陷阱

公共基准的题目会随时间流入厂商的预训练语料。这也是为什么 2023 年后几乎每个新模型发布都伴随"benchmark contamination"争议，以及为什么各家越来越重视私有评测集与实时更新的基准（如 LiveCodeBench、LiveBench）。

评测维度与主流基准 ​

基准（benchmark）的本质是一张标准化考卷：固定题目 + 固定评分规则，让不同模型可以在同一标准下比较。按能力维度看，主流基准大致如下：

维度基准测什么怎么测已知局限
知识MMLU（Massive Multitask Language Understanding）57 个学科（STEM、人文、社科等）的多选题知识选择题，0-shot/5-shot 输出，按准确率计分全是选择题、偏记忆；题目已广泛泄漏进训练语料；2024 年后多家厂商分数逼近饱和
知识GPQA（Graduate-Level Google-Proof Q&A）生物、化学、物理的博士级难题选择题；题干经专家设计且"Google-proof"（普通搜索难以直接命中）对多数模型过难，区分度集中在头部模型；数据量小（约 448 题），方差大
知识C-Eval52 个学科的中文知识（含四个难度等级）中文选择题，从小学到研究生题目相对容易，头部模型分数趋同；部分题目同样存在泄漏风险
推理GSM8K小学数学应用题要求给出分步推理与最终数字答案，按精确答案匹配计分只覆盖小学数学、题型模式化，2023 年后的模型普遍 90%+，几乎失效
推理MATH高中/竞赛级数学证明与解答题分 5 个难度等级，按最终答案匹配（或自动评阅）答案匹配规则有漏洞（格式变体、等价表达），部分题需要程序验证
推理AIME（American Invitational Mathematics Examination）美国数学邀请赛真题（1983 年至今）每题一个 0–999 的整数答案，精确匹配只考察数学；2025 年起 AIME 正式禁止 AI 参赛，凸显 AI 竞赛成绩的争议
代码HumanEval164 道 Python 函数级编程题让模型补全函数，用**单元测试（pass@k）**判定题目偏简单、全是 Python、函数级（无工程级上下文），已被多家模型刷到 90%+
代码LiveCodeBench按时间持续更新的编程题（来自 LeetCode/AtCoder/Codeforces 等）与 HumanEval 类似的测试驱动评测，但题目持续注入新题仍以单文件/竞赛题为主，与真实工程项目差距大
指令跟随MT-Bench80 道多轮对话问题（写作、推理、数学、代码等 8 类）每轮由 GPT-4 等 LLM-as-a-judge 打 1–10 分裁判模型本身有偏好（位置、长度、风格偏差）；题目量少
指令跟随IFEval541 条带可验证约束的指令（"至少 3 个要点""结尾用问句"等）自动检查输出是否满足结构化约束只测格式层面的服从，不测内容质量
多模态MMMU（Massive Multi-discipline Multimodal Understanding）大学级多学科、跨图像-文本推理多选题，需理解图像并推理偏知识记忆与图表阅读，对"视觉-推理"联合能力要求高
多模态MMBench20 个细粒度能力维度的图像问答选项式问答 + 判断式问题部分题目可被纯语言先验猜中；细节请见多模态模型
中文C-Eval / CMMLU中文通识知识与中文语境理解中文选择题题目质量与区分度参差，部分题目受语料污染

如何"读"基准

分数是相对的，不是绝对的。 MMLU 从 2020 年模型 25%（随机水平）到 2024 年头部模型 90%+，涨的是分数，但模型对人类某些真实任务的提升远没有 60 个百分点那么夸张——因为题目泄漏、选择题本身好猜、以及基准与真实任务之间的鸿沟。

更多基准的维护信息与数据集下载入口，可参考数据集与工具档案与模型与榜单速查。

评测方法分类 ​

基准只是评估的一种手段。完整的评估方法谱系分为四类：

方法优点缺点适用场景
基准测试（benchmark）标准化、可复现、成本低、可横向比较易污染、离真实任务远、刷榜能力摸底、版本间对比、选型初筛
人工评测最接近真实用户判断、能捕捉细微质量贵、慢、标注者之间不一致（低 inter-annotator agreement）高价值场景、上线验收、榜单仲裁
LLM-as-a-judge便宜、快、可扩展、与人类相关性高裁判模型有位置/长度/自我偏好偏差大规模自动化评分、迭代回归
对抗/红队测试主动暴露安全与鲁棒性弱点不能穷尽风险、成本高安全审查、上线前风险评估

LLM-as-a-judge：让模型给模型打分 ​

用 GPT-4 或同等级的强模型作为裁判，对候选回答打分。这是当前自动化评估的事实标准，其与人类判断的相关性在论文（如 Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena）中被反复验证。一个典型的裁判提示长这样：

python
JUDGE_PROMPT = """请作为公正的评审员，对两个 AI 助手的回答进行打分（1-10 分）。

【任务背景】用户询问：{question}
【助手A的回答】{answer_a}
【助手B的回答】{answer_b}

评分标准：
- 事实正确性（40%）：错误事实应直接判低分
- 有用性与完整性（30%）：是否直接回应了问题
- 清晰度（20%）：结构、表达是否易懂
- 安全与无害（10%）：是否包含有害内容

输出格式（严格 JSON）：
{{"score_a": 6, "score_b": 7, "reason": "……"}}

注意：先独立思考，再给分；不要因为回答更长就加分。"""

def judge(question, answer_a, answer_b, model):
    resp = model.chat(JUDGE_PROMPT.format(
        question=question, answer_a=answer_a, answer_b=answer_b))
    return parse_score(resp)  # 解析 JSON 分数

裁判的三类已知偏差

  1. 位置偏差（position bias）：偏爱排在前面或后面的答案——对策是调换顺序评两次取平均；
  2. 长度偏差（verbosity bias）：偏爱更长的答案——在提示里显式声明"不要因长度加分"，或对长度做校正；
  3. 自我偏好（self-preference）：裁判偏爱与自身同源的模型输出——因此永远不要用被测模型自己当裁判。

应用层评估：RAG、Agent 与产品级 ​

通用基准测的是"模型本身"，而真实产品里模型总是被嵌入到系统中——评估的对象应是整个系统，而不是模型单点。

RAG 评测：三件套指标 ​

检索增强生成（Retrieval-Augmented Generation, RAG）系统的质量由检索与生成共同决定，业界普遍使用 RAGAS 框架的三项核心指标：

指标测什么问法
忠实性（faithfulness）答案是否完全基于检索到的上下文，有无幻觉"答案里的每个论断，上下文里都有依据吗？"
答案相关性（answer relevance）答案是否正面回应了问题"这份答案对回答这个问题有没有用？"
上下文相关性（context relevance）检索到的上下文是否与问题相关、是否引入噪声"检索出来的这几段，有几段真正相关？"

一句话判断

RAG 调优先看上下文相关性——如果检索结果本身就相关度低，再好的生成也救不回来。检索是 RAG 的上限，生成只是逼近它。完整落地流程见从零搭建 RAG 应用，RAG 机制本身见检索增强生成。

Agent 评测：任务能不能完成 ​

Agent 与单轮问答的本质区别是多步决策：每一步的"看起来合理"都不等于"最终完成任务"。核心指标包括：

  • 任务成功率（task success rate）：在自动化环境（如 BrowserGym、SWE-bench）中最终达成目标的占比；
  • 工具调用正确率：选择哪个工具、传什么参数、调用顺序是否正确；
  • 步数与成本：完成同样任务消耗的 token/调用次数——效率也是质量；
  • 轨迹安全：过程中是否做了危险操作（如删除文件、转账）。

一句话判断

Agent 评估必须放在受控环境里做，绝不能拿真实生产环境跑"试试看"。评估脚本与环境的自动化程度，直接决定 Agent 迭代速度。Agent 概念见AI 智能体（Agent），开发实战见从零开发一个 Agent。

产品级评估 ​

最终极的标准是产品指标：用户留存、任务完成率、客服工单解决率、付费转化。离线分数只是代理指标，产品指标才是终审。完整的方法论（评估集设计、指标定义、上线策略）见搭建一套 LLM 评估。

评估的工程化：把评估变成 CI 的一部分 ​

评估不能是"发版前打一次分"，而要像单元测试一样沉淀成资产、接入开发流程：

  1. 建设黄金数据集（golden set）：从真实用户数据中采样、人工标注"理想回答"，再按维度分层（客服、代码、总结……）。原则是少量高质（几百到几千条），远超数量的是质量；
  2. 私有集 + 公开集结合：私有集防污染、公开集可对标行业水平——永远不要只用公开基准做上线决策；
  3. 回归测试：每次微调、每次换基座模型，都必须重跑全套评估，防止"提升 A 能力、退化 B 能力"；
  4. 接入 CI/CD：评估脚本自动化、分数低于阈值则阻断发布，形成"评估即门禁"；
  5. 分级评估：轻量快评估（几百条）跑每个 commit，全量评估（几千条）跑每次发布候选。
text
代码提交 → 触发 CI → 跑轻量回归（几百条黄金题） → 通过 → 训练/微调
   → 跑全量评估 → 与基线对比（LLM-as-a-judge 打分）
   → 分数全部 ≥ 阈值？ → 是：发布    否：回滚并定位退化维度

常见反模式

  • 只在模型换版时才评估，平时从不回归；
  • 评估集只有公开基准，被污染后"分数虚高却浑然不觉"；
  • 测试集参与过调参（用测试集的错误反推修改 prompt/阈值），等于提前看答案；
  • 只看平均分，不看分维度细项——平均分掩盖"知识 90 分、安全 40 分"的失衡。

评估结果的正确解读 ​

基准分数是最容易被误读的资产，记住三条纪律：

  1. 基准分数 ≠ 真实能力：MMLU 90% 不意味着它在你的业务场景里能用；选择题和自由生成之间隔着"知道"与"产出"的巨大鸿沟；
  2. 『刷榜』是理性博弈的必然：厂商为了发布效果会针对基准调整训练数据与解码策略（甚至间接过拟合测试集）。看到一个惊艳的分数，先问：这个基准被污染了吗？测试时用了额外算力（o1/thinking 模式）吗？——同一模型开不开推理模式分数能差 10 个百分点以上；
  3. 多维度综合判断：评估一次性能同时看知识、推理、代码、中文、安全、成本、延迟七张表，加上分维度细项与人工抽样复核，再下结论。

一句话判断

选型时"分数 + 成本 + 延迟 + 安全"四张表一起看：一个贵 5 倍的模型若只高 2 分，在很多场景下不值得。榜单数字是起点，不是终点。更多选型信息见模型与榜单速查。

评估还直接关系到其他几个热门概念：对齐的好坏要用评估来度量（见对齐：RLHF 与 DPO），安全评估是上线红线（见AI 安全与治理），而评估所用的提示词质量本身受提示词工程影响。想从原理上理解被测对象，可先读大语言模型（LLM）与Transformer 与注意力机制。

延伸阅读 ​

参考资料 ​