如何评估大语言模型:基准测试五大原则

大语言模型(LLM)已经彻底改变了我们与AI的交互方式,从驱动聊天机器人到生成代码、解决复杂数学问题。但随着这些模型日益复杂,一个关键问题依然存在:我们究竟该如何衡量它们的能力,并确定哪些模型真正更好?
答案就是基准测试和评估框架——我们用来系统化测试、比较和理解LLM性能的方法。学会如何正确评估LLM至关重要。
在这篇博客中,我们将探讨关于LLM评估你需要知道的一切,从优质基准测试的基本原则,到实践中使用的各种评估方法。此外,我们还会提供实用的代码笔记,帮你动手运行针对真实用例的评估。
为什么LLM基准测试和评估很重要
进步的基石
基准测试是AI发展和进步的指南针。它们让我们能回答一些根本问题:对于智能体编程任务,Kimi-K2比Claude更好吗?过去一年,语言模型在数学推理方面进步了多少?哪个开源模型的微调版本在你的内部评估中表现最佳?
以DeepSeek R1的发布为例,它因与前沿模型竞争的性能而登上头条。该公司的声明并非基于主观印象,而是基于在六个不同基准测试上的系统评估,包括AIME 2024、CodeForces、GSM8K和GPQA Diamond。这种标准化比较让AI社区能快速了解DeepSeek R1相对于之前发布的成熟模型(如OpenAI的o1和Anthropic Claude系列)处于什么位置。

来源:https://huggingface.co/deepseek-ai/DeepSeek-R1
追踪AI革命
基准测试还能帮助我们追踪AI能力的更广泛趋势。以MMLU基准测试为例,它测试57个大学学科的知识。通过绘制MMLU性能随时间的变化,我们可以看到去年我们越过了这个有趣的拐点:开源模型在性能上已经与闭源系统持平,甚至在某些情况下更好,这标志着AI格局的重大转变。

来源:https://x.com/maximelabonne/status/1972615048511250647
这种趋同不仅仅是学术上的,它对组织如何部署AI、研究人员如何获取尖端能力以及整个AI生态系统的演变都具有深远影响。
识别能力与局限
或许最重要的是,基准测试不仅能帮助我们了解模型能做什么,还能了解它们不能做什么。它们揭示了盲点,突出了需要改进的领域,并指导研究重点。这对于构建可靠的AI系统和为实际部署设定适当的期望至关重要。最近发布的模型在通用知识基准测试(如OpenAI的SimpleQA)上表现反而下降,就是一个很好的例子。例如,Qwen3 235B在大多数智能体和推理基准测试上优于许多其他模型,但在评估通用知识时,它的表现却严重不佳!这个问题在Qwen3更新的Instruct和Reasoning版本中得到了纠正,它们在SimpleQA上的表现显著提升。

来源:https://x.com/nathanhabib1011/status/1917230699582751157
优质LLM基准测试的五大原则
并非所有基准测试都生而平等。最有价值的评估框架都具备五个关键特征,使其成为模型能力的可靠指标。
1. 难度:移动的目标
一个好的基准测试必须足够有挑战性,以区分不同的模型。这看起来显而易见,但实现起来可能比想象中更难。以MATH基准测试为例,它包含竞赛级别的数学问题(下图中绿色部分)。当它首次推出时,最先进的模型准确率只有个位数——这些问题对AI系统来说似乎几乎不可能解决。
快进到今天,同样的基准测试显示模型准确率超过90%。曾经具有区分度的测试对现代系统来说已经变得常规。这说明了“基准测试饱和”现象:随着模型改进,以前具有挑战性的基准测试变得简单,需要研究人员不断开发新的、更难的评估。
从上面的图表可以看出,这一趋势正在加速。虽然模型在MMLU上达到高性能花了近四年时间,但像GPQA(博士级别问题)这样的新基准测试在短短一年内就看到了快速改进。这种加速反映了我们正在见证的AI发展的空前速度,并突显了拥有越来越难的基准测试以帮助我们区分最佳模型的重要性。

来源:https://x.com/_jasonwei/status/1889096555254456397
2. 多样性:超越单领域测试
大语言模型是通用系统,人们将其用于从娱乐到工作等方方面面,因此它们的评估应反映这种广度。一个只测试数学推理的基准测试可能会错过常识推理或创意写作方面的关键局限。MixEval框架很好地说明了这一原则,它展示了不同领域——从STEM领域到社会动态——如何在评估空间中占据不同的区域。

来源:https://arxiv.org/abs/2406.06565
这种多样性要求体现在两个层面。首先,我们需要覆盖不同能力的多个基准测试。其次,单个基准测试应包含多样化的问题类型,以避免被擅长特定模式但缺乏真正理解的模型“钻空子”。
3. 实用性:连接基准测试与真实AI用例
一个基准测试可能很难且多样,但如果它不能连接到实际应用,其价值就有限。最好的基准测试要么测试对用户直接重要的能力,要么为更复杂的任务奠定基础。
以GSM8K为例,它测试数学应用题。为什么这很重要?首先,它为更复杂的定量推理任务(如财务分析)奠定了基础。其次,它直接帮助用户(学生可以向ChatGPT寻求作业帮助)。第三,它为更广泛的推理能力提供了一个可衡量的代理,帮助研究人员研究AI系统是否能真正“思考”问题。
同样,HumanEval通过LeetCode风格的问题测试编码能力。这个基准测试很有价值,因为编码技能可以迁移到构建软件智能体,帮助用户准备技术面试,并提供关于AI系统将自然语言转化为精确指令能力的见解。
4. 可复现性:隐藏的复杂性
优质基准测试最容易被忽视的方面之一是可复现性。相同的评估应在不同的实现和研究人员之间产生一致的结果。不幸的是,这比看起来更难实现。
以MMLU基准测试为例,它要求模型在四个多项选择中做出选择。这听起来很简单,但实际上有不止一种实现评估的方法:
- 原始方法:向模型提供选项A、B、C、D,并比较每个标记(Token)的概率
- 替代方法:在比较概率时包含所有可能的标记
- 序列方法:比较每个选项完整文本描述的概率
当来自不同机构的研究人员实现这些方法时,他们得到了不同的结果和模型排名——这可以从下图中看出,微小的输入提示变化导致了性能的高方差。这种不一致性令人担忧,因为它意味着关于模型能力的结论可能取决于实现细节,而不是实际的性能差异。

来源:https://arxiv.org/abs/2310.11324
5. 数据污染:看不见的问题
或许LLM评估中最隐蔽的挑战是数据污染,即基准测试问题出现在模型的训练数据中。现代语言模型在大量互联网文本上进行训练,可能包括包含基准测试问题的学术论文、教科书和网站。
GSM8K与GSM1K的对比完美地说明了这个问题。GSM8K是一个广泛使用的数学应用题基准测试,而GSM1K包含保证新颖的类似问题。当研究人员比较模型在这两个基准测试上的表现时,他们发现许多模型在GSM1K上的得分显著较低,这表明高的GSM8K得分可能部分反映了记忆——而不是真正的数学推理能力。

来源:https://arxiv.org/abs/2405.00332
当观察MATH基准测试中的数据污染时,这个问题更加突出。当最先进的模型在美国数学奥林匹克(USAMO 2025)发布几小时后进行评估时(以完全排除数据污染的可能性),即使是当时最好的推理模型表现也极差,准确率低于5%!

来源:https://arxiv.org/abs/2503.21934v1
对于开源模型和数据集,这种污染问题尤其严重,因为训练数据与测试数据的重叠更有可能发生,也更难检测。
LLM评估方法的类型
LLM评估包含几种不同的方法,每种方法都有其自身的优势和适用场景。
多项选择与分类基准
最直接的评估方式是给模型出选择题或分类任务。这类基准评分清晰客观,也容易大规模实施。典型例子包括:
- MMLU(大规模多任务语言理解):测试常识知识
- HellaSwag:常识推理
- MATH:数学解题
这些基准的演变揭示了一个有趣模式:我们常看到基准的“家族”迭代——随着模型能力提升,新版本会取代旧版本。比如 SWAG 被 HellaSwag 取代,GLUE 升级为 SuperGLUE,MMLU 也进化到 MMLU-Pro(后者增加了选项数量以提升难度)。
如果你需要运行分类评估,Together AI 的新 Evaluations API 可以提供帮助。具体代码实现可以参考我们的示例 Notebook。
生成与开放式评估
选择题虽然评分简单,但无法反映我们实际使用语言模型的方式。现实中,我们常要求模型生成自由格式的回复,因此生成评估对理解真实场景下的性能至关重要。相关基准包括:
- GSM8K(小学数学):通过自动验证答案来测试分步数学推理
- HumanEval:通过函数补全和测试用例评估代码生成能力
- TruthfulQA:衡量事实准确性及抵抗模型幻觉(Hallucination)的能力
这类评估更贴近真实使用场景,但评分难度也相应增加。给选择题或封闭式数学题打分很容易,但要评估得出正确答案的所有正确步骤,或者评判实现同一问题的多种正确代码方案之间的优劣,就复杂多了。
人工评估
如果想进一步提升评估在真实场景中的有效性,可以考虑人工评估。它能捕捉自动化指标常忽略的细微质量因素,但面临规模和一致性的挑战。
LM Arena 代表了人工评估的黄金标准。用户与匿名模型互动,并对回复质量投票。这种众包方式生成的 Elo 排名,反映了真实用户在不同查询下的偏好。
Arena 的优势在于规模——它收集并整合了数百万次对话中用户对各种话题的偏好。不过,这些查询往往偏向日常闲聊,而非专业领域任务。
专项人工评估则聚焦特定领域,例如代码(Code Arena、软件工程 SWE-bench 或 HealthBench)。这类评估通常由领域专家参与,他们能评判技术正确性以及普通用户可能忽略的质量维度。
用大语言模型当裁判
用大语言模型评估其他大语言模型,因其可扩展性和灵活性而广受关注。这种方法既保持了评估对真实使用场景的代表性,又通过用 LLM 替代人工执行评估,兼顾了可扩展性。
Alpaca Eval 2.0 用 GPT-4 作为裁判,根据参考答案给模型回复打分,从而提供不同模型的胜率。Arena Hard 则从 Chatbot Arena 中精选困难提示,构建具有挑战性的评估集。多轮对话基准则评估模型在连续交互中的对话能力。
“LLM 当裁判”的主要优势在于评估标准可定制。不同于固定指标,你可以指示裁判模型评估特定方面,比如技术准确性、对初学者的清晰度,或者行业术语的使用。
但这种方法也有明显局限。裁判模型往往倾向于给更长的回复打高分(无论质量如何),并且经常对同系列模型的回复有偏好(例如 GPT 模型更青睐 GPT 的回复)。因此,适当的校准和偏差校正对确保结果可靠至关重要,LM Arena 后来增加的风格控制功能就是一个例子。
我们也在新的 Evaluations API 中支持运行“LLM 当裁判”的评估,具体实现可以参考以下 Notebook:
可靠评估的最佳实践
有效评估大语言模型需要使用多个互补的基准,而不是依赖单一指标,因为不同基准捕捉的是模型能力的不同方面。评估标准应与你的实际用例对齐:如果你在构建客服聊天机器人,就该优先评估帮助性和对话能力,而非创意写作或数学推理。
要警惕数据污染风险——使用新颖的测试集,并对结果保持适当的怀疑态度。对于生产系统,建议实施持续评估框架来监控性能随时间的变化,因为用户行为、数据分布或模型更新都可能导致模型漂移。
通过 A/B 测试验证基准改进是否真的带来了更好的用户体验,并建立明确的触发机制:当性能下降到可接受阈值以下时,就启动重新训练或模型替换。
评估大语言模型既是科学也是艺术,不仅需要考虑“评估什么”,更要思考如何可靠、有意义地“进行评估”。随着语言模型变得更强大、更普及,稳健的评估框架也日益关键。评估领域发展迅速,新基准和新方法不断涌现,但核心原则不变:采用多维度视角,让评估贴合真实需求,并对任何单一指标保持审慎态度。最终问题不在于模型能否通过我们的测试,而在于我们的测试是否足够成熟,能确保这些系统安全、有效地服务于既定目标。
觉得有用?分享给更多人