NLP——LLM模型评估指标

本文主要介绍LLM的各种评估指标

LLM 的评估指标

NLP常见的评估指标包括评估指标可能包括准确率、F1 分数、BLEU 分数、ROUGE 分数和 Perplexity等，其中BLUE 和 ROUGE是自然语言处理中用于评估文本生成质量的两种常用指标
还有许多开源的综合评测体系，会借用以上评估指标来评估各自的得分
比如：Big-bench 的文本生成等任务就需要使用 BLEU 分数和 ROUGE 分数等
AGI-Eval 社区中包含大模型相关的各种评估指标，可以在这里面找到各种评估指标的介绍和使用方式等

BLEU（Bilingual Evaluation Understudy）

BLEU 用于评估机器翻译或文本生成结果与参考文本的相似度。它通过计算生成文本与参考文本之间的 n-gram 重叠来评估准确性，并结合简洁惩罚（Brevity Penalty）来惩罚过短的输出。BLEU 得分范围在 0 到 1 之间，1 表示与参考文本完全一致

ROUGE（Recall-Oriented Understudy for Gisting Evaluation）

ROUGE 主要用于评估自动摘要生成的质量。它通过计算生成文本与参考文本之间的 n-gram、词序列或词对的重叠来评估召回率（Recall）
常见的 ROUGE 变体包括 ROUGE-N（n-gram重叠）和 ROUGE-L（最长公共子序列）
ROUGE 得分范围也在 0 到 1 之间，1 表示与参考文本完全匹配

BLUE 和 ROUGE 对比

BLEU ：侧重准确率，常用于机器翻译
ROUGE ：侧重召回率，常用于自动摘要
两者均通过n-gram重叠评估生成文本的质量

pass@k 评估指标

原始的 pass@k 指标 ：为每个问题生成 $k$ 个回复 ，只要其中任意一个回复解决了问题，则判定为当前问题被解决
$$ \text{pass@}k = \frac{被解决的问题数}{总问题数}$$
- 上面的方法方差较大，基本已经被弃用
改进后的 pass@k 指标(原始指标的无偏估计) ：在 Evaluating Large Language Models Trained on Code, OpenAI, 2021 中提出了一种无偏评估方法，对每个任务生成 $n$ 个样本（其中 $n \ge k$），统计通过单元测试的正确样本数量 $c$ 个（$c \le n$），最后计算无偏估计量 ：
$$\text{pass@}k := \underset{\text{Problems}}{\mathbb{E}} \left[ 1 - \frac{\dbinom{n - c}{k}}{\dbinom{n}{k}} \right]$$
- 理解：分母是从 $n$ 个中挑选 $k$ 个的排列组合数；分子是从 $n-c$ 个中挑选 $k$ 的排列组合数，直观理解就是 在 $k$ 次尝试中至少有一次成功的概率
  - 无偏估计量的证明：$P(至少一次成功) = 1- P(全部失败) = 1-\frac{\dbinom{n - c}{k}}{\dbinom{n}{k}}$
  - 当所有样本都正确时，分子为 0，当前问题样本的 $\text{pass@}k = 1$；当所有样本都错误时，分子等于分母，当前问题样本的 $\text{pass@}k = 0$
  - 最终的 $\text{pass@}k$ 是所有问题样本的 $\text{pass@}k$ 的平均值
- 这种评估指标更 Soft，对单个问题样本来说，不是绝对的取值为 $\{0,1\}$，方差更小，更合适在样本数量较少的场景评估
- 注意：即使 $n=k$ 时，也不会退化为原始的 pass@k 指标
- pass@k 评估指标的实现和证明，详情见 Evaluating Large Language Models Trained on Code, OpenAI, 2021

改进后的 pass@K 指标代码实现：

def pass_at_k(n, c, k):
   """
   :param n: total number of samples
   :param c: number of correct samples
   :param k: k in pass@$k$
   """
   if n - c < k: return 1.0
      return 1.0 - np.prod(1.0 - k / np.arange(n - c + 1, n + 1))

独立采样还是 Beam Search？
- 通常使用核采样（Nucleus Sampling/Top-p）或温度采样（Temperature Sampling）进行独立随机采样
- 不能使用 Beam Search，因为 Beam Search 倾向于生成高度相似的序列，缺乏多样性，无法体现 $k$ 次尝试的覆盖能力
样本是否可以重复？
- 在生成阶段，因为是独立采样，完全可能生成两个一模一样的代码块
- 在计算阶段，公式中的 $n$ 是总生成数，$c$ 是正确的数量
- 重复的正确样本计入 $c$，重复的错误样本计入 $n-c$
- 计算过程看作是“无放回抽样”
- 注：开源实现一般没有看到去重，实际上也可以去重？
重点：为什么有的时候，pass@1 提升了，但是 pass@k 反而下降？
- 直观上看，由于 pass@k 中的多个样本是完全独立采样的，所以直观上看，pass@1 提升时，pass@k 也一定会提升（因为 pass@k 理论上是一个独立的随机时间发生了 $k$ 次，至少有一次成功的概率）
- 实际上，由于 pass@k 还跟答案的多样性有关，举例如下：
  - 模型 A 的 pass@1 为 10%，即每次挑选样本，只有 10% 的概率正确，但答案多样性（范围）高（假设生成的答案都不同），那么模型 A 的 pass@10 大约为 67%，假设每次采样 100 个样本用来计算 pass@10，则：
    $$ pass@10 = 1 - \frac{\dbinom{100 - 10}{10}}{\dbinom{100}{10}} \approx 67%$$
  - 模型 B 的 pass@1 为 20%，即每次挑选样本，只有 20% 的概率正确，但答案多样性（范围）极低（假设对同一个样本，生成的答案都相同），那么模型 B 的 pass@100 大约为 20%（多个不同样本，模型正确的概率只有 20%）
    - 不能再用上面的计算公式了，因为对于每个 Prompt 来说，没有多样性的模型是非此即彼，此时一个正确就全正确，一个错误就全错误，所以 pass@k = pass@1 = 20%
  - 结论：对于完全没有多样性的模型，pass@1 和 pass@k 其实是相同的；多样性越高，则 pass@1 和 pass@k 的差距越大

SBS（Side by Side）评估指标

人工评测两个模型的好坏（新旧模型对比）
人工打分为四种：好、坏、一样好、一样坏

MMLU

链接：huggingface.co/datasets/cais/mmlu
MMLU（Massive Multitask Language Understanding）是一个用于评估大规模语言模型在多种任务和领域上理解和推理能力的综合性基准
原始的数据集一共包含 15,908 道题目，涵盖 57 个不同的学科主题，每个主题至少 100 道题目（每个主题包含以 test 集为主，5道 dev 题目和部分 val 集在内的至少100道题目）
它涵盖了广泛的知识领域和任务类型，旨在全面评估模型的多任务学习能力和泛化能力
具体来说，包含以下能力：
多任务评估 ：
- MMLU 包含 57个不同的任务，涵盖了人文学科、STEM（科学、技术、工程和数学）、社会科学和其他领域
- 任务类型包括但不限于问答、文本分类、推理和阅读理解
广泛的知识领域 ：
- 任务涉及的知识领域非常广泛，包括历史、地理、生物、化学、物理、数学、法律、经济、哲学等
- 这种多样性使得MMLU能够全面评估模型在不同领域的知识掌握情况
难度层次多样 ：
- MMLU中的任务难度层次多样，从基础的知识问答到复杂的推理和问题解决任务
- 这种多样性有助于评估模型在不同难度任务上的表现
零样本和少样本学习 ：
- MMLU评估模型在零样本（zero-shot）和少样本（few-shot）学习场景下的表现
- 零样本学习是指模型在没有任务特定训练数据的情况下进行推理，而少样本学习是指模型仅使用少量示例进行推理

MMLU 的评估方法：

任务类型 ：每个任务通常是一个多项选择题或填空题
评估指标 ：主要使用准确率（accuracy）作为评估指标，即模型在所有任务上的平均正确率
数据集 ：MMLU数据集包含大量的问题和答案，涵盖了各种学科和难度级别

MMLU-Redux

链接：huggingface.co/datasets/edinburgh-dawg/mmlu-redux
MMLU-Redux 是 MMLU 的人工精校子集，由 14 位专家对 30 个学科各 100 题共 3,000 道四选一选择题进行重新标注，公开于 Hugging Face（edinburgh-dawg/mmlu-redux），遵循 CC-BY-4.0 许可
针对 MMLU 存在标注错误、问题 / 选项不清晰等问题，推出高质量、低噪音版本，用于更可靠的模型评估
30 个学科 × 100 题 / 学科 = 3,000 题；
每题含 question、choices、answer（0–3）、error_type、source、correct_answer、potential_reason 等字段
采用层级化错误分类体系，先识别再校正；研究显示在 Redux 上模型排名与原 MMLU 存在显著差异

MMMU

链接：huggingface.co/datasets/MMMU/MMMU
MMMU (MultiModal Massive Multi-task Understanding) 是针对多模态场景设计的大规模、多任务、多学科基准，在 2023年提出
MMMU 涵盖10大学科，包括生物学、化学、地理等，共1838道问题
- 每道题目都包含图片和文本信息，需要视觉+语言联合理解
MMMU 评估方式 为问题形式为图片与文字结合，多项选择或开放式问答
MMLU 的主要评估指标 是 准确率（Accuracy） ，即正确回答问题的比例，尤其关注模型处理跨模态输入后的综合能力

MMMU_Pro

链接：huggingface.co/datasets/MMMU/MMMU_Pro
MMMU_Pro (A More Robust Multi-discipline Multimodal Understanding Benchmark)

MMMLU

链接：huggingface.co/datasets/openai/MMMLU
MMMLU（Multilingual Massive Multitask Language Understanding） 是 OpenAI 发布的一个多语言版本的 MMLU 评测基准 ，用于衡量大模型在多种语言上的知识和推理能力
MMMLU 是 OpenAI 基于原始 MMLU 数据集开发的（多语言扩展版）
MMMLU 覆盖了57个学科，与英文 MMLU 一致，但题目被翻译成了 26种不同的语言，包括中文、法语、西班牙语、阿拉伯语等主流及部分低资源语言
MMMLU 用于评估大型语言模型在跨越不同文化和地区时，能否保持广泛且准确的知识理解与推理能力
- 每道题为四选一选择题，涉及科学、人文、社会科学等多个领域
- 各学科问题均以目标测试语言呈现，无需英语中转
通常采用 zero-shot 或 few-shot 设置，即不给或只给少量示例，让模型直接用目标外语作答
核心指标为准确率 (Accuracy)

Big-Bench

链接：待补充
Big-bench（Beyond the Imitation Game Benchmark）是一个大规模、多样化的基准测试，旨在评估语言模型在各种复杂任务上的表现
Big-bench 由社区驱动，包含大量任务，涵盖了广泛的知识领域和技能类型，旨在推动语言模型的能力边界，具体来说，包含以下能力：
Big-bench 包含超过200个任务，涵盖了语言理解、推理、知识问答、翻译、数学计算、编程、常识推理等多个领域
- 任务类型包括但不限于问答、文本生成、分类、排序、逻辑推理等
根据任务类型不同，评估指标可能包括准确率、F1 分数、BLEU 分数、ROUGE 分数等
任务难度从简单到复杂不等，既有基础的语言理解任务，也有需要复杂推理和问题解决能力的任务
- 这种多样性有助于评估模型在不同难度任务上的表现
Big-bench 是由研究社区共同贡献和维护的，任务由来自不同领域的研究者设计和提交
- 这种社区驱动的模式使得Big-bench能够不断扩展和更新，保持其前沿性和多样性
Big-bench 旨在评估模型在未见过的任务上的泛化能力，而不仅仅是在特定任务上的表现
- 通过大量多样化任务的评估，Big-bench 能够全面反映模型的综合能力

BBH

HuggingFace 地址：huggingface.co/datasets/lighteval/bbh
BBH 评估集（Big-Bench Hard）是 BIG-Bench（Beyond the Imitation Game Benchmark） 中最具挑战性的子集，由 Google 研究团队于 2022 年提出，专门用于评估大语言模型在高阶推理任务上的表现
BBH 从 BIG-Bench 的 204 项任务中，筛选出 23 项当前语言模型表现显著低于人类水平的任务
BBH 涵盖复杂推理、因果判断、反事实理解、多步规划等高阶认知能力，包含多个任务的共 21 个子集，下面列举几个任务：
- 因果判断（causal judgment）
- 布尔逻辑推理（boolean expressions）
- 多步数学推理（Multi-step mathematical reasoning）
- 反事实推理（Counterfactual reasoning）
BBH 支持多种提示方式，包括标准提示（answer-only）和 思维链提示（Chain-of-Thought, CoT） ，后者能显著提升模型表现
BBH 可通过 GitHub 官方仓库获取数据集和运行脚本，支持自定义模型评估

HELM（评估框架）

GitHub 开源框架地址：github.com/stanford-crfm/helm/
论文地址：Holistic Evaluation of Language Models, Stanford, 202308
斯坦福地址：crfm.stanford.edu/helm/
HELM（Holistic Evaluation of Language Models，语言模型整体评估）是一个由斯坦福大学开发的综合性评估框架，旨在全面评估大语言模型（LLMs）在多个维度和任务上的表现
HELM 的评估指标涵盖了广泛的能力和场景
HELM 从多个维度对语言模型进行评估，包括但不限于：
- 准确性：模型在各类任务中的表现，如问答、信息检索、摘要生成等
- 稳健性：模型对输入变化的鲁棒性，例如拼写错误、同义词替换等
- 公平性：模型输出是否对不同群体存在偏见或歧视
- 效率：模型的推理速度和资源消耗
- 有毒性：模型生成内容是否包含有害或不当信息
- 不确定性：模型输出的置信度是否合理
- 环境影响：模型训练和运行的能耗及碳排放
HELM 设计了16个核心场景 ，覆盖了语言模型的主要应用领域，例如：
- 问答任务：如 Natural Questions、MMLU 等
- 信息检索：如微软的 Macro 数据集
- 摘要生成：如 CNN/Daily Mail 和 XSum 数据集
- 情感分析：如 IMDB 电影评论数据集
- 毒性检测：如 CivilComments 数据集
HELM采用“自上而下”的方法，由专家团队精心选择和设计评估任务，确保评估的高质量和针对性。其评估方法包括：
- 自动化评估：使用标准指标（如准确率、F1分数、ROUGE等）对模型进行量化评估
- 人类评估：通过众包平台进行A/B测试，评估模型生成内容的有用性和无害性
- 红队分析：邀请领域专家对模型进行对抗性测试，识别潜在风险和漏洞

Arena

Arena(竞技场/角斗场)大模型测评方法是一种凉凉对战评测的方法，用户可以并排与两个匿名模型聊天，并通过投票选出哪一个更好。最后，根据PK结果使用ELO评分系统对模型进行评分和排名‌
除了大模型以外，多模态模型也可以采用这个方式，其中典型的平台包括典型平台包括：
- Chatbot Arena ：由LMSYS Org推出，支持190多种大语言模型的匿名对战和排名，详情见：https://lmarena.ai/
- Compass Multi-Modal Arena ：支持多模态模型的匿名对战，涵盖图像理解和生成任务，详情见：https://rank.opencompass.org.cn/home
- Decentralized Arena：基于群体智能的多维度评估平台，支持自动化和可定制化评测

Arena-Hard

相关链接：(ArenaHard)From Live Data to High-Quality Benchmarks: The Arena-Hard Pipeline, 202404
更多细节待补充

Arena-Hard v2

Arena Hard v2 (ArenaHardV2, Arena_Hard_v2) 数据来源于 github.com/lmarena/arena-hard-auto
Arena-Hard v2（Arena-Hard Benchmark version 2），来自 LMSys (Large Model Systems Organization)
Arena-Hard v2 通常不作为数据集发布，而是用于 LMSys Chatbot Arena 上的模型对战，其问题集为私有
- LMSys Chatbot Arena 是一个用于 LLM 对战的排行榜和评估基准
Arena-Hard v2 是一些挑战性问题的集合，旨在通过更难、更具迷惑性的问题来区分顶级模型之间的性能差异，这些问题通常需要复杂推理、多步逻辑或对细节的精确理解
Arena-Hard v2 使用 GPT-4.1 和 Gemini-2.5 打分来评估模型效果

MATH-500（数学）

huggingface.co/datasets/HuggingFaceH4/MATH-500包含500道题目（都在 test split 里面）
每道题目包含 problem，solution，answer，subject，level，unique_id 列
- subject 列：指出题目类型，比如代数（Algebra）、数论（Number Theory）等
- level 列：指出题目等级，level 越大，难度越大

AMC（数学）

包含 AMC 8，AMC 10，AMC 12 三个赛事，题目难度逐渐提升
AMC 和 AIME 是有一定关系的：
AMC 的题目会被包含在其他数学类测试集中

AIME（数学）

AIME 是美国数学邀请赛（American Invitational Mathematics Examination）的简称‌，是美国数学竞赛（AMC）系列中的高级别赛事，旨在选拔在 AMC10/12 中表现优异的学生，为美国数学奥林匹克竞赛（USAMO/USAJMO）和国际数学奥林匹克（IMO）选拔参赛者
AIME 每年都会有新的题目出现，对 LLM 来说属于比较难的题目
比如 2024 和 2025 数据集如下：
- HuggingFaceH4/aime_2024：共 30 题，包含 id,problem,solution,answer,url,year 列
- MathArena/aime_2025：共 30 题，包含 problem_idx,problem,answer,problem_type 列
  - 题目原始列表：artofproblemsolving.com/wiki/index.php/2025_AIME_II_Problems
- opencompass/AIME2025：共 30 题（两个子集 AIME2025-I 15 题， AIME2025-II 15 题, 都在 test split里面），包含 question,answer 列

OlympiadBench

HuggingFace 链接：huggingface.co/datasets/Hothan/OlympiadBench
论文链接：OlympiadBench: A Challenging Benchmark for Promoting AGI with Olympiad-Level Bilingual Multimodal Scientific Problems, arXiv 20240606, THU
GitHub 链接：github.com/OpenBMB/OlympiadBench
以奥林匹克级别的中英双语 ，且多模态科学问题推动通用人工智能发展的挑战性基准[ACL 2024]
数据集中还包含图片等信息，且有很多个子集，数据量巨大（从 56 行到 1.9K 行不等）
每一行包含多个列，包括了图片，答案和语言等

GPQA

HuggingFace 链接：huggingface.co/datasets/idavidrein/gpqa
GitHub 链接： github.com/idavidrein/gpqa
论文链接： GPQA: A Graduate-Level Google-Proof Q&A Benchmark, arXiv 20231220
GPQA（Graduate-Level Google-Proof Q&A），一个极具挑战性的数据集，包含多个子集，每个子集几十到几百道由生物、物理和化学领域专家编写的多项选择题
GPQA 数据集每行包含很多列，信息非常详细，比如正确答案 1 个，错误答案 3 个等，常常用作 4 选 1 的选择题形式
GPQA 任务类型属于知识 + 复杂推理（MCQ）
GPQA 评估指标常用 Accuracy
GPQA 常用设置 0-shot / few-shot / Chain-of-Thought

GPQA-D

GPQA-D（GPQA Diamond）全称 Graduate-Level Google-Proof Q&A Diamond，是 GPQA（Graduate-Level Google-Proof Q&A）基准的“超高难度”子集，专门用来测试大模型在 博士级科学问题 上的深度推理与专业知识运用能力
HuggingFace 链接（与 GPQA 相同）：huggingface.co/datasets/idavidrein/gpqa
- GPQA-D 在上述链接的子集里
GPQA-D 包含 198 道四选一选择题，涵盖生物学、物理学、化学等专业

ARC 数据集

ARC 数据集，即 AI2 Reasoning Challenge（AI2 推理挑战）数据集
整个 ARC 数据集包含 7787 道问答题目，分为 ARC Challenge Set（挑战集）和 ARC Easy Set（简单集）
ARC 旨在评估大模型对科学问题的理解和推理能力
ARC Challenge Set 包含 2590 道较难的问题
部分论文中也会使用 ARC Benchmark 或 ARC Challenge Benchmark 来表示以数据集为基准
注：还有一个重名的数据集 Abstraction and Reasoning Corpus（ARC）
- 这是由 François Chollet 于 2019 年发布的基准测试集，旨在评估 AI 系统在面对全新任务时的抽象推理和泛化能力

ARC-AGI

通用推理评估数据集
参考链接：Abstraction and Reasoning Corpus for Artificial General Intelligence (ARC-AGI), 2019

RULER

GitHub 地址：github.com/NVIDIA/RULER
RULER 测试集是 NVIDIA 在 2024年6月发布的一个用于评估语言模型长上下文建模能力的基准测试数据集
RULER 的任务类别包括：
- 检索：扩展了大海捞针（Needle in a Haystack，NIAH）测试，包括单针检索（Single NIAH，S-NIAH）、多针检索（Multi-keys NIAH，MK-NIAH）、多值 NIAH（Multi-values NIAH，MV-NIAH）和多查询 NIAH（Multi-queries，MQ-NIAH）四个任务，用于评估模型在不同类型和数量“针”情况下的检索能力，要求检索能力与“针”和“大海”的类型无关，能忽略硬干扰，且在检索多个项目时具有高召回率
- 多跳跟踪 ：提出变量跟踪（Variable Tracing，VT）任务，模拟最小的指代链解析任务，检查模型跟踪相关共现模式和在长输入中绘制跳过连接的行为，通过增加跳数或链的数量来增加任务复杂性
- 聚合：引入常见词提取（Common Word Extraction，CWE）和频繁词提取（Frequent Word Extraction，FWE）任务，作为摘要任务的代理，用于测试模型聚合跨越长距离上下文相关信息的能力
- 问答：在现有短上下文问答数据集的输入中添加干扰信息，以评估模型在各种上下文大小下的问答能力
注：RULER 测试集主要用于评估长上下文语言模型

Longeval (Long-context Evaluation)

Longeval 用于评估大型语言模型在处理和利用长上下文信息时的表现
任务类型包括：
- 长对话理解: 模型需要理解并回应一个非常长的、包含多个轮次的对话历史
- 长文档问答: 模型需要基于一篇长文档（如论文、报告）来回答具体问题
Longeval 的数据长度通常在几千到几万个 token 之间，模拟了用户与AI助手进行长时间、多主题深入交流的场景
- 更侧重于测试模型在多轮对话中维持上下文一致性和记忆关键信息的能力
评估方式：通常使用自动化的脚本，通过比较模型生成答案与标准答案的精确度、召回率或 F1 分数来进行评估
强调了在“对话”和“单文档问答”这两个实用场景下对模型长文本能力进行压力测试的重要性

LongBench

论文地址： LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding, arXiv 2023, THU & Zhipu.AI & IACAS
GitHub 地址： github.com/THUDM/LongBench
Hugging Face 地址：huggingface.co/datasets/THUDM/LongBench
LongBench 是一个非常全面且被广泛使用的多任务、双语（中英）长文本评测基准。它由清华大学的研究团队发布，旨在提供一个标准化的平台来衡量模型在各种长文本任务上的表现。LongBench 的最大特点是其任务全面性和数据多样性 ，覆盖了从单文档理解到多文档推理的广泛场景
LongBench 主要任务类别有：
- 单文档问答 (Single-document QA)
- 多文档问答 (Multi-document QA)
- 摘要 (Summarization)
- 少样本任务 (Few-shot Learning)
- 代码补全 (Code Completion)
- 合成任务 (Synthetic Tasks)

LongBench-V2

论文地址：LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-context Multitasks
GitHub 地址(与 LongBench 想通)：github.com/THUDM/LongBench
Hugging Face 地址：huggingface.co/datasets/zai-org/LongBench-v2
LongBench V2 是 LongBench 升级版，这是一个旨在评估 LLMs 处理长语境问题能力的基准测试
LongBench V2 包含503道具有挑战性的多项选择题，题干文本长度跨度从 8K 到 2M Words 不等，涵盖六大主要任务类别，具体如下：
- 单文档问答（single-document QA）
- 多文档问答（multi-document QA）
- 长语境学习（long in-context learning）
- 长对话历史理解（long-dialogue history understanding）
- 代码仓库理解（code repository understanding）
- 长结构化数据理解（long structured data understanding）
为确保测试的广度与实用性，研究团队从近 100 位拥有不同专业背景的高学历人士处收集数据
- 同时，通过自动化与人工审核相结合的流程，保障测试数据的高质量与高难度
- 难度体现：在15分钟的时间限制下，人类专家的答题准确率仅为 53.7%
o1-preview 模型准确率 57.7%，比人类基准准确率高出 4 个百分点

InfiniteBench

GitHub地址：github.com/OpenBMB/InfiniteBench
InfiniteBench 专注于评估模型在 “无限”或“极长” 上下文长度下的表现
- 任务通常具有非常长的输入文本（可达 100K tokens 甚至更长），并且答案（或关键信息）往往被刻意放置在输入的非常深的位置（例如中间部分），以此来挑战模型在超长序列中“大海捞针”的能力
- 特别关注模型是否真的利用了全部上下文，而不是仅依赖开头或结尾的信息
InfiniteBench 主要特点：
- 极长的上下文: 输入文本长度远超常规评测
- “大海捞针”式任务: 关键信息被隐藏在长文本的任意位置
- 抗捷径设计: 任务设计旨在防止模型通过只看开头/结尾等“作弊”方式获得高分
- 覆盖英语和中文任务

HelloBench

论文地址：HelloBench: Evaluating Long Text Generation Capabilities of Large Language Models
HelloBench，是层级式长文本生成基准测试（Hierarchical Long Text Generation Benchmark）
HelloBench 将长文本生成任务划分为五个子任务，分别是：
- 开放式问答（open-ended QA）
- 文本摘要（summarization）
- 对话生成（chat）
- 文本补全（text completion）
- 启发式文本生成（heuristic text generation）

MorehopQA

论文地址：MoreHopQA: More Than Multi-hop Reasoning
GitHub：github.com/Alab-NII/morehopqa
MoreHopQA 是多跳数据集
背景：在 MoreHopQA 前，大多数已有的多跳数据集均为抽取式答案数据集（此类数据集的问题答案可直接从给定语境中提取得到）
- 这一特点往往导致模型采用启发式方法或“捷径”解题，而非执行真正的多跳推理
MoreHopQA 数据集将答案形式从“抽取式”转向“生成式”
MoreHopQA 的构建以三个现有多跳数据集为基础，分别是 HotpotQA、2WikiMultihopQA 和 MuSiQue
- 在构建过程中，不再单纯依赖事实推理，而是通过增加一层“拓展问题”来升级原有多跳问题
- 这些拓展问题需涉及以下一种、两种或全部三种推理类型：
  - 常识推理（commonsense）
  - 算术推理（arithmetic）
  - 符号推理（symbolic）
MoreHopQA 数据集通过“半自动化流程”构建而成，最终包含 1118 个样本，且所有样本均经过人工验证
仅有部分模型能实现“完美推理”（即所有相关子问题均回答正确），其中 GPT-4 的完美推理率为 38.7%，Llama3-70B 的完美推理率为 33.4%

HLE（推理）

HLE 是“Humanity’s Last Exam”的缩写，即“人类最后一次考试”，由 Center for AI Safety（AI安全中心）与Scale AI联合打造
HLE 是一个多模态基准测试，旨在成为封闭式学术基准测试的最终版本，用于衡量大语言模型在人类极限能力边界上的通用推理与智能水平
HLE 包含3000个问题，涉及上百门学科，包括数学、人文科学和自然科学等
HLE 包含精确匹配题和选择题两种
- 其中 80% 的问题为精确匹配题，模型需要输出一个完全匹配的字符串作为答案；
- 其余为选择题，模型需要从五个或更多选项中选择一个正确答案
- 此外，10% 的问题要求理解文本和图像参考
HLE 每个问题都有一个已知的明确且易于验证的解决方案，但无法通过快速互联网检索获得答案，通常需要研究生水平的专业知识或高度特定主题的测试知识
HLE由来自 50 个国家的 500 多个机构的近 1000 名学科专家贡献，经过问题筛选、迭代优化、手动审核等流程创建，同时还保留了一部分私有测试集，用于评估模型是否存在过拟合现象
如果模型在 HLE 中获得高分，将表明模型在封闭式、可验证的问题以及前沿科学知识方面具备专家级表现，有助于推动模型在复杂问题上的表现提升，为研究者提供了一个标准化工具，用于比较不同模型在跨学科任务中的表现

IFEval

IFEval（Instruction Following Evaluation）是用于评估大模型指令遵循的指标
链接：huggingface.co/datasets/google/IFEval
IFEval 是一个专门用于评估模型遵循指令能力的基准
- 它不侧重于解决具体问题，而是看模型能否严格按照指令中的各种约束来生成回应
- 约束复杂多样，例如“以 X 开头”、“用 Y 结尾”、“提到某个词 Z 次”、“段落数量不超过 N 个”等等
IFEval 评估集包含大约 400 条带有明确约束的提示（Prompt），涵盖了 25 种不同类型的约束
评估时，通过自动检查生成的内容是否满足所有指令约束来计算模型的准确率
在 IFEval 基准测试中，按照要求严格程度，分为 “strict prompt”（严格提示）和 “non-strict prompt”（非严格提示）两种评估策略（两者主要体现在对模型输出的评估标准上，而不是提示本身的内容）
- Strict Prompt (严格提示) ：采用非常严格的评估标准。模型的输出必须精确匹配所有预定义的要求才算正确
  - 即使内容基本正确，但只要在格式、措辞、顺序或某个细节上与预期有丝毫偏差，就会被判定为错误
  - 这通常用于评估模型执行高度结构化或精确指令的能力
  - 目的是测试模型的精确性和可靠性
- Non-strict Prompt (非严格提示) ：采用更宽松的评估标准
  - 评估者会判断模型的输出是否在语义上满足了指令的核心要求 ，允许一定的表达差异或格式灵活性
  - 只要关键信息正确且意图达成，即使不完全一致，也可能被视为正确
  - 目的是测试模型的理解和意图实现能力

GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents

论文地址：GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents, ACL 2025, SJTU, BateDance
GitHub 地址：github.com/Dlxxx/GuideBench
背景：LLM 正越来越多地被用作领域导向型智能体，这类智能体的运行依赖于特定领域的指南（domain-oriented guidelines），而这些 guidelines 可能与模型自身的常识知识存在冲突
- 这类领域 guidelines 具有两个关键特征：一是包含大量领域专属规则，二是会频繁更新
GuideBench（指南基准）是一个专为评估大语言模型指南遵循性能而设计的综合基准
GuideBench 从三个关键维度对大语言模型进行评估：
- （1）对多样规则的遵循程度
- （2）对规则更新的鲁棒性
- （3）与人类偏好的对齐度

HMMT

HMMT（Harvard-MIT Mathematics Tournament）是 “哈佛-麻省理工大学数学竞赛”，是全美国影响力最大和名校理工科专业认可程度最高的高中数学竞赛之一
HMMT 作为面向全球顶尖高中生的最高水平数学竞赛之一，其题目难度高，覆盖代数、几何、组合数学、微积分等多个领域，需要极强的逻辑推理和创造性解题能力
HMMT 竞赛题通常在多个数学数据集中被整合，目前暂时没有一个独立的 HuggingFace 官方仓库
在大模型评估集中，HMMT 代表了使用哈佛-麻省理工数学锦标赛（HMMT）的题目作为评估数据集
- 将其作为评估指标，旨在衡量模型在专业级数学推理方面的极限
- 数据量通常是历年竞赛的几百到几千道题目
- 比如：HMMT 25 表示 25 年的 HMMT 比赛试题集合

IMO-ProofBench

IMO（International Mathematical Olympiad）：国际数学奥林匹克（全球最高级别数学竞赛）
IMO-ProofBench 是一个证明数据集

附录：一些数学比赛集合

AIME（American Invitational Mathematics Examination）：美国数学邀请赛（高中阶段）
HMMT（Harvard-MIT Mathematics Tournament）：哈佛-麻省理工数学竞赛（全球顶尖高中竞赛）
IMO（International Mathematical Olympiad）：国际数学奥林匹克（全球最高级别数学竞赛）
CMO（Chinese Mathematical Olympiad）：中国数学奥林匹克（中国国家队选拔赛事）
Putnam（William Lowell Putnam Mathematical Competition）：普特南数学竞赛（北美顶尖大学竞赛）

BeyondAIME

链接：huggingface.co/datasets/ByteDance-Seed/BeyondAIME
精心挑选的数学推理数据集，来自字节-Seed

LiveCodeBench (24/8∼25/5)

LiveCodeBench，简称（LCB），通常还会加上时间周期，比如用表达如 LiveCodeBench (24/8∼25/5) 表示 24年8月至 25年5月期间的题目
LiveCodeBench 是一个动态的、持续更新的编程能力评估基准
LiveCodeBench 每周都会从 LeetCode、AtCoder、CodeForces 等在线编程竞赛平台收集最新的、真实的人类竞赛题目
LiveCodeBench 可以有效防止模型在训练数据中“见过”评测题目，从而更真实地反映模型的泛化编程能力

OIBench

论文链接：OIBench: Benchmarking Strong Reasoning Models with Olympiad in Informatics, arXiv 20250612, AGI-Eval && Meituan && BNU && SJTU
链接：huggingface.co/datasets/AGI-Eval/OIBench
OIBench 是美团 Meituan-M17 团队联合上海交大等发布的信息学奥赛（IOI）级算法评测基准，含 212 道高难度原创题，侧重区分模型的推理与链式思考能力，已在 GitHub 与 Hugging Face 开源
原始论文：OIBench: Benchmarking Strong Reasoning Models with Olympiad in Informatics, arXiv 20250612, AGI-Eval && Meituan && BNU && SJTU
- 注：AGI-Eval 是一个由上海交通大学、同济大学、华东师范大学及 DataWhale 等高校和机构联合创建的‌大模型评测社区‌，专注于评估基础模型在人类认知与问题解决任务中的通用能力
OIBench 定位为高区分度的算法编程评测基准，聚焦真实、可复现的模型能力评测
OIBench 包含 212 题（250 候选），题目由高校教练与 ACM-ICPC 团队编制，难度为 IOI 级别，多为“至多仅一个标杆模型能解”的强筛选
测试用例覆盖大数据量与边界，配可验证的 C++ 标准解(C++ 标准解作为金标准，确保公平与可复现)
支持 C++/Python/Java/JavaScript
评测范式为 Zero-shot；提供“伪代码提示”以测思路理解与复现
在 GitHub、Hugging Face 开源（题目私有、未公开，降低训练数据同源污染风险），并托管于 AGI-Eval 社区
- AGI-Eval 社区会更新排名 agi-eval.cn/evaluation/detail?id=60
问题：虽然说是私有化，确实在 HuggingFace Data Studio 上看不到示例，但是 HuggingFace 上有相关的数据文件怎么理解？huggingface.co/datasets/AGI-Eval/OIBench/tree/main/data

OIBench 的区分度足够好

对 18 个主流模型的 zero-shot 评测显示：
- 推理型模型平均约 21.4%，显著高于普通指令微调模型的约 3.6%；
- o4-mini-high 以 36.35 分领先，说明能拉开真实差距
闭源模型平均 14.5%，开源 6.3%；语言偏好上，JavaScript/Python 平均低于 C++/Java 约 10%，中英文差异很小
伪代码提示可显著提升所有模型表现，强推理模型提升更明显；o4-mini-high 以较少 Token 解出更多题，推理效率最佳

OJBench

论文：OJBench: A Competition Level Code Benchmark For Large Language Models, arXiv 20250619, THU & Moonshot AI
GitHub 链接：github.com/He-Ren/OJBench
OJBench comprises 232 programming competition problems from NOI and ICPC, providing a more rigorous test of models’ reasoning skills

ZebraLogic

HuggingFace 链接（Data）: huggingface.co/datasets/allenai/ZebraLogicBench
GitHub（Code for evaluation）: github.com/yuchenlin/ZeroEval
Leaderboard: https://hf.co/spaces/allenai/ZebraLogic
- 注：这里的 hf.co 会重定向到 huggingface.co
ZebraLogic 用于评估逻辑推理能力
每个用例都是一个 Logic Grid Puzzle（Zebra Puzzle）

Sudoku-Bench

HuggingFace 链接：huggingface.co/datasets/SakanaAI/Sudoku-Bench
属于推理数据集
Sudoku-Bench 是一个用于评估模型解决数独谜题能力的基准
- 注：数独是一个经典的逻辑和约束满足问题，它需要模型理解规则（每行、每列、每宫数字1-9不重复）并根据给定的数字进行推理

Aider-Polyglot

官方链接：epoch.ai/benchmarks/aider-polyglot
Aider-Polyglot Code Editing Benchmark，是一个代码编辑基准，对应 AI 编程助手项目 Aider 上的题目
- Polyglot 含义是“多语言的”，意味着支持多语言（C++, Go, Java, JavaScript, Python, and Rust）

SWE-bench

HuggingFace 链接：huggingface.co/datasets/princeton-nlp/SWE-bench
考察解决 GitHub 上 issue 的能力
收集了来自 12 个 GitHub Python 项目（（如 Django, scikit-learn））上的 2,294 个 Issue-Pull Request 对，使用 post-PR 作为参考解决方案
- 每个任务都是一个实际发生过的问题，模型需要像一个软件工程师一样，理解问题描述、定位和修改代码库中的多个文件来修复 bug 或添加功能
- 评估是通过在真实环境中运行测试用例来验证模型提交的补丁（patch）是否成功解决了问题

SWE-bench_Verified

HuggingFace 链接：huggingface.co/datasets/princeton-nlp/SWE-bench_Verified
SWE-bench_Verified 包含 500 条用例，是 SWE-bench 测试集的一个子集，是经过人工质量验证过集合

BigCodeBench

原始论文：BigCodeBench: Benchmarking Code Generation with Diverse Function Calls and Complex Instructions, arXiv 2024 & ICLR 2025,
HuggingFace 链接：huggingface.co/datasets/bigcode/bigcodebench
BigCodeBench 基准测试要求 LLMs 调用来自 139 个库和 7 个领域的多个函数调用作为工具，来解决 1,140 个细粒度任务
- 每个任务包含 5.6 个测试用例，平均分支覆盖率高达 99%
BigCodeBench 包含两个变体
- BigCodeBench-Complete: Code Completion based on the structured docstrings.
- BigCodeBench-Instruct: Code Generation based on the NL-oriented instructions.
  - BigCodeBench-Instruct 能自动将原始文档字符串（docstrings）转换为仅包含关键信息的简短指令

BFCL v3

博客地址：BFCL V3 • Multi-Turn & Multi-Step Function Calling Evaluation
BFCL v3（Berkeley Function Calling Leaderboard v3），用于验证大模型的 FC 能力（function-calling capabilities）
子集 BFCL v3 multi turn: 这个子集专注于多轮对话场景下的函数调用
- 模型不仅要响应当前指令，还可能需要利用前几轮对话的上下文信息来做出正确的函数调用决策
子集 BFCL v3 full: 指的是在整个 v3 数据集上进行的全面评估，涵盖单轮、多轮、并行、多函数等各种复杂的函数调用场景

AST(Abstract Syntax Tree) 准确率指标

通过构建抽象语法树（Abstract Syntax Tree）来计算指标，最早由伯克利（BFCL 的作者团队）提出
详情可参考：Gorilla: Large Language Model Connected with Massive APIs

$\tau$-bench & $\tau^2$-bench (Retail, Airline, Telecom)

关键词：tau-bench, Tau-Bench, $\tau$-bench
论文链接: $\tau$-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, arXiv 20240617
$\tau$-bench（Tool-Agent-User Interaction Benchmark）用于评估 Agent 的交互能力，包含不同的场景
$\tau$-bench 测试模型在复杂的多步骤任务中，如何通过调用一系列 API 或工具来完成目标
$\tau^2$-bench 是该系列的第二个版本，可能在任务复杂性、工具数量或评估维度上有所增强
$\tau$-bench 和 $\tau^2$-bench 包含的任务被设计为贴近真实世界的应用场景，下面是一些子集介绍
- $\tau$-bench-Retail ：专注于零售场景的任务，例如管理库存、查询订单、处理退货等
  - 注：有时候可以用 $\tau$-bench-Retail（P1）代表评测的第一个阶段（Phase 1）？
- $\tau$-bench-Airline ：专注于航空服务场景，例如查询航班、预订机票、管理行程等
- $\tau^2$-bench-Retail ：
- $\tau^2$-bench-Airline ：
- $\tau^2$-bench-Telecom ：$\tau^2$-bench 新增的电信场景

MiniF2F

HuggingFace 链接：huggingface.co/datasets/Tonic/MiniF2F
论文链接：MiniF2F: a cross-system benchmark for formal Olympiad-level mathematics, arXiv 20220228, OpenAI
MiniF2F 数据集是一个由奥林匹克数学竞赛难度级别的正式数学命题组成的资源库，旨在为神经定理证明（neural theorem proving）领域提供跨系统的统一基准测试框架。该基准目前覆盖 Metamath、Lean、Isabelle（部分）和 HOL Light（部分）四种证明系统，包含从 AIME（美国数学邀请赛）、AMC（美国数学竞赛）、国际数学奥林匹克竞赛（IMO）以及高中与本科数学课程材料中精选的 488 道数学命题

NuminaMath-1.5

NuminaMath-1.5 数据集包含 89.6 万个数学问题，涵盖常用数据源和高等数学主题

AoPS Forum

AoPS 论坛（Art of Problem Solving 社区）是面向中学生与数学爱好者的在线数学交流平台，围绕竞赛与进阶数学问题讨论、分享解法与课程互动，广泛用于准备 AMC、AIME、USAMO 等赛事
AoPS 论坛隶属 Art of Problem Solving（AoPS），1993 年创立，覆盖课程、教材与社区板块
社区论坛为核心：按课程/主题分版，支持与讲师和同学交流，支持匿名提问、LaTeX/Asymptote 排版与图片嵌入
搜索功能完善，支持全文、高级筛选与公式搜索，便于定位历史讨论与解法
讨论范围主要是
- 竞赛训练：AMC 系列、AIME、USAMO 等，以及 MathCounts、Math Kangaroo、HMMT、PUMaC 等赛事与夏令营讨论
- 课程配套交流：与 AoPS 在线课程深度整合，便于针对讲义与作业提问
- 趣味与游戏：数学谜题、策略游戏与社区自建游戏板块（如 The Incredible Forum）
AoPS 论坛中会产出一些可用于 LLM 的数据，故而在这里记录

TriviaQA

HF 链接：mandarjoshi/trivia_qa
TriviaQA 是一个大规模开放域问答（Open-Domain QA）数据集
由约 95 万个问答对和来自维基百科与网页的约 66.2 万篇文档构成，平均每个问题有 6 篇“证据文档”支持
适合评估复杂的多文档阅读理解与推理能力
构建方式：爱好者撰写问题，自动检索证据，再经人工验证与机器生成子集混合而成
答案常需多句推理与跨文档综合，难以仅靠短跨度抽取解决，且上下文长、句式与词汇变化大
常见任务包含问答、多文档阅读理解、开放域QA、问题生成等
包含 8 个 subset，每个 subset 包含 3 个 split

FRAMES

原始论文：Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation, arXiv 202409 & 202411 & 202506, Harvard & Google & Meta
HuggingFace 链接：huggingface.co/datasets/google/frames-benchmark
FRAMES（Factuality, Retrieval, And reasoning MEasurement Set），a high-quality dataset designed to test LLMs’ factual responses, retrieval capabilities, and reasoning in generating final answers
高质量的，测试事实响应，检索能力和推理能力的数据集
注：DeepSeek-R1 使用了该指标

Pile-test

Pile-test 是大语言模型评估中常用的标准测试集，源于更庞大的通用文本数据集 The Pile
The Pile 由 EleutherAI 构建的大规模开源文本数据集，总规模约 800GB，涵盖 22 个不同来源的文本类型（如学术论文、网页文本、书籍、新闻、代码等），旨在为模型提供多样化、高质量的训练与评估数据，避免单一数据分布导致的 “过拟合评估”
Pile-test 是 The Pile 的测试子集，与训练集（Pile-train）严格划分，用于客观衡量模型在通用语言理解与生成任务上的泛化能力，由于其覆盖场景广，模型在 Pile-test 上的表现能更真实反映 “通用能力”，而非仅适配某类特定数据

DS-1000

DS-1000，也称为 DS1000，其中 DS 是 Data Science 的含义，包含 1000 个数据科学问题的代码生成基准测试集，是测评代码能力的测试集
原始论文：DS-1000: A Natural and Reliable Benchmark for Data Science Code Generation, 2023, HKU & PKU & Meta AI
开源网站：ds1000-code-gen.github.io
DS-1000 覆盖 NumPy、Pandas 等 7 个 Python 库
DS-1000 具备三大核心特性：
- 数据集的问题均来自 StackOverflow，能够反映多样化、贴近实际场景的实用用例；
- 自动评估具有高度特异性（可靠性），在所有经评估判定为“可接受”的 Codex-002 模型预测解决方案中，仅有 1.8% 存在错误
  - 运行测试用例验证代码的功能正确性
  - 限制 API 使用或关键字来约束代码的表面形式；
- 为防范模型依赖记忆答题，作者对原始 StackOverflow 问题进行了微调，使其与源问题存在差异，从而避免模型通过记忆预训练数据中的解决方案得出正确答案

GAIA

论文地址：GAIA: a benchmark for General AI Assistants
GAIA（General AI Assistants）是通用人工智能助手基准测试
- 论文中提到：该基准若能被攻克，将成为人工智能研究领域的一座里程碑
GAIA 设计的现实世界问题，要求模型具备一系列核心能力
- 例如推理能力、多模态处理能力、网页浏览能力，以及通用意义上的工具使用熟练度
GAIA 的问题对人类而言难度较低，但对多数人工智能系统却极具挑战性：
- 研究显示，人类受访者的正确率达 92%，而配备插件的 GPT-4 正确率仅为 15%
- 这一显著的性能差距，与近年来 LLM 在法律、化学等需要专业技能的任务上超越人类的趋势形成鲜明对比
GAIA 的设计理念与当前人工智能基准测试的主流趋势有所不同，现有基准往往倾向于设置对人类而言难度越来越高的任务
- 作者认为，AGI 的实现，关键在于系统能否展现出与普通人类相当的稳健性（robustness），在这类问题上达到人类水平
GAIA 包含构建了 466 个问题及其对应的答案
- 作者对其中 300 个问题的答案予以保留，以便为排行榜 huggingface.co/gaia-benchmark 提供数据支持

VitaBench

官方博客：美团 LongCat 团队发布 VitaBench：基于复杂生活场景的交互式 Agent 评测基准， 20251020
VitaBench（Versatile Interactive Tasks Benchmark）是高度贴近真实生活场景、面向复杂问题的大模型智能体评测基准
VitaBench 以外卖点餐、餐厅就餐、旅游出行三大高频真实生活场景为典型载体，构建了包含 66 个工具的交互式评测环境，并进行了跨场景的综合任务设计

BABILong

HuggingFace：huggingface.co/datasets/RMT-team/babilong
原始论文：BABILong: Testing the Limits of LLMs with Long Context Reasoning-in-a-Haystack
HuggingFace 排行榜：BABILong Leaderboard
BABILong 是一款可扩展的生成式多任务测评基准，核心用于评估大语言模型在超长文档中跨分散事实的推理能力
- 涵盖 20 种推理任务，包括事实链、归纳、演绎、计数、集合处理等，均基于 bAbI 基准扩展而来
- 以 PG19 语料库的书籍作为背景文本，将任务相关事实隐藏其中，可构建任意长度的测评样本
- 提供预定义的0K至1000万token的样本分割，实测可支持高达5000万token的超长文本评估
BABILong 弥补了Longbench等传统基准仅支持4万token的短板，适配当前LLM的百万级token处理能力
BABILong 能抗数据泄露，通过合成任务事实与自然背景文本混合的方式，避免模型因训练数据重叠获得虚假优势

MemBench

MemBench 是由中国人民大学高瓴人工智能学院与华为诺亚方舟实验室联合构建的大语言模型智能体记忆能力多维度评测基准
- 其核心目标是解决现有评测难以全面衡量 LLM 智能体记忆性能的问题，为智能体记忆机制的研发提供可靠的评估依据
聚焦智能体核心的两种记忆能力
- 事实记忆 ，用于评估智能体对客观信息的存储与召回能力，比如用户的基本需求、任务中的关键参数等；
- 反思记忆 ，侧重衡量智能体对过往经验的归纳总结能力，例如从多次交互中提炼用户行为规律
设计了两种贴合智能体实际应用的场景
- 参与场景（智能体作为参与者直接执行任务、与用户交互）
- 观测场景（智能体作为观察者记录外部事件与信息）
- 覆盖不同应用场景下的记忆需求
突破单一效果评估的局限，从记忆的有效性（记忆内容的准确性、召回率）、效率（记忆存储与检索的速度）和容量（记忆承载上限）三个核心维度展开评估
实验显示，当记忆容量超过 500 条时，多数模型在该基准中的召回率下降超 20%，可有效检测模型的记忆容量瓶颈

FreshQA

FreshQA 是由谷歌和 OpenAI 研究团队联合构建的动态问答基准评测集，专门用于评估大型语言模型生成内容的事实准确性 ，尤其针对模型处理实时变化知识和错误前提问题的能力
- 用于暴露当前 LLM 的幻觉问题和知识滞后缺陷
该评测集共包含 600 个自然问题，分为测试集和开发集
- 其中测试集有 500 个样本，四种问题类型各 125 个；
- 开发集 100 个样本，四种问题类型各 25 个，另外还提取了 15 个跨类型示例用于演示
- 这些问题覆盖多类主题，且需模型具备不同层级的推理能力
所有问题归为四大类，适配对不同知识类型的评测需求
- 永不改变的知识 ，比如“谁写了《杀死一只知更鸟》”这类历史、文学领域固定事实问题；
- 慢变知识 ，答案可能隔数年变化，像“纽约市的人口数是多少”；
- 快变知识 ，答案一年内可能多次变动，例如“本年度奥斯卡最佳男主角是谁”；
- 错误前提知识 ，问题基于虚假假设，如“罗杰·费德勒在 2022 年总共赢得了多少个大满贯赛事冠军”，这类问题要求模型能指出前提缺陷而非直接作答
每类问题又分为一跳和多跳两个难度。一跳问题无需额外推理，如“谁是 Twitter 的首席执行官”；多跳问题则需多步推理才能获取答案，如“世界上最高建筑的总高度是多少”
评测采用双模式人工评估程序，累计完成超5万次判断，评估标准严谨
- RELAXED（宽松模式） ，仅关注核心答案的正确性，允许不影响核心结论的非规范表述或次要信息瑕疵
- STRICT（严格模式） ，要求回答中所有表述均符合最新事实，无任何幻觉信息。对于错误前提类问题，模型必须主动指出前提错误才能得分；
- 数字类答案一般不接受近似值，除非基准答案中明确允许

FACTS Grounding

FACTS Grounding 数据集是谷歌 DeepMind 与谷歌研究院联合构建的基准测试数据集，核心用途是评估大型语言模型 基于给定上下文文档生成内容的事实准确性与事实锚定能力 ，以此破解模型“幻觉”问题，目前已搭配 Kaggle 在线排行榜用于实时跟踪模型性能进展
目前数据集仅聚焦长文本输入的事实锚定响应评估
数据来源于公开互联网，但其中的用户请求和系统指令为全新设计，不存在污染问题
数据集共包含 1719 个示例，分为 Public 和 Private 两个集合
- 其中公共集合有 860 条样本，已公开供研究者开展模型评估；
- 私有集合含 859 条样本，仅用于排行榜评分，这种划分能有效避免基准污染和排行榜作弊问题
- 最终榜单分数需结合两个集合的平均性能得出
每个样本均由三部分构成
- 系统指令，明确要求模型只能依据给定上下文文档生成回应，不得调用外部知识；
- 用户请求，涵盖摘要、问答生成、文档改写等真实任务；
- 上下文文档，包含回答问题所需的全部信息，文档平均长度为 2.5k 个 token，最长可达 32k 个 token（约2万个单词）
文档覆盖金融、技术、零售、医学和法律等多个实用领域
- 且数据集刻意避开了需要创造力、数学运算或复杂推理的任务，用户请求也无需领域专业知识，更贴合日常场景下的文本处理需求
研究人员聘请第三方人工标注员，依据长篇输入和各类文本任务撰写长篇输出内容，保障样本的真实性和合理性
- 标注完成后会经过手动验证，移除与指令不一致的样本；同时剔除来源为 PDF 的文档，避免光学字符识别（OCR）可能带来的误差；还会确保用户请求具有实际意义，过滤无效或无价值的内容
该数据集采用两阶段AI评判模式，选用 Gemini 1.5 Pro、GPT-4o 和 Claude 3.5 Sonnet 三款前沿模型作为评判器，以此保障评估结果的客观性和与人工评分的一致性
- 第一阶段先评估模型回应的合格性，若未充分满足用户请求则直接取消评分资格；
- 第二阶段聚焦事实准确性，判断回应是否完全基于上下文文档，无任何幻觉信息
- 最终得分取三款评判模型在所有样本上的评分平均值

Terminal Bench

Terminal-Bench是由斯坦福大学与 Laude 研究所联合开发的开源基准测试与评测框架，专门用于衡量 AI 在真实终端（如 Linux 命令行）环境中完成复杂任务的能力
Terminal-Bench 通过标准化任务和环境，量化AI代理在终端场景的实操能力，为开发者优化代理的可靠性和安全性提供参考依据
其初始版本 Terminal-Bench-Core 包含 80 个人工设计并验证的任务，后续持续扩展，目前“head”版已达 117 题
- 任务覆盖科学工作流、网络配置、网络安全漏洞修复、代码编译部署等多个实用场景，且每个任务都配有人类验证的解决方案和测试用例集
- 每个任务都配备专属 Docker 环境，能确保测试在隔离的沙箱中进行，避免外部环境干扰，同时保证不同开发者和机构测试结果的可重复性，解决了终端任务评估中环境不一致导致的结果偏差问题
- 提供 CLI（命令行界面）工具，开发者通过一条命令就能拉起沙箱、连接代理并执行测试
- 评估时不依赖提示词匹配或主观评价，而是以测试用例是否通过为标准计分，结果客观精准
Terminal Bench 设立了公开排行榜展示各类代理-模型组合的任务解决率，方便开发者直观对比不同 AI 代理的性能
- terminal-bench@2.0 Leaderboard
- terminal-bench@1.0 Leaderboard
该框架不仅有自建任务，还适配了 SWE-Bench Verified、AppWorld 等热门外部评测，开发者接入一次接口就能完成多基准测试
Terminal Bench 作为开源项目，开放了文档、任务注册表等资源

CoreCodeBench

HuggingFace：huggingface.co/datasets/meituan-longcat/CoreCodeBench-Source_Copy
CoreCodeBench 是美团与上海交大联合推出的仓库级代码评测基准，用于测试 LLM 在真实工程场景的编程与调试能力，以自动化单元测试判分，核心指标为Pass@1（首条输出通过所有测试用例的比例）
CoreCodeBench 以 Pass@1 为核心，用真实仓库级任务与自动化测试，评估 LLM 的工程级编程与调试能力，适合筛选能落地的代码模型
CoreCodeBench 场景覆盖：单/多函数的开发（Development）、缺陷修复（BugFix）、测试驱动开发（TDD），并设有高难度子集（Difficult），总计约1545题，源自12个真实开源仓库，更贴近量产级开发
CoreCodeBench 构建流程：通过 CorePipe 自动化 pipeline 定位核心代码、生成题目与测试用例，兼顾规模化与高质量
关键评测指标
- Pass@1：首条生成的代码通过全部单元测试的比例
  - 主指标，衡量一次性正确性与可靠性
- AC@1/AC Rate：同Pass@1（不同文档命名），增量正确率
  - 辅助追踪迭代改进
- 题型细分通过率：按开发/修复/TDD、单/多函数拆分的通过率
  - 定位模型短板与优势场景
相比 HumanEval/MBPP（单函数补全）：覆盖跨文件、多函数协作与缺陷修复，更贴近真实工程
相比 SWE-Bench（仓库级）：自动化生成与判分，可复现性与规模化更好，适合快速迭代评测
快速上手：从 AGI-Eval 社区获取数据集与评测脚本，按统一 Prompt 生成代码，批量执行测试用例统计 Pass@1；建议同时记录题型细分通过率，便于归因优化

AlpacaEval

AlpacaEval 是一种用于评估 LLM 指令遵循能力（Instruction-following）的自动化评估基准
AlpacaEval 是一个让 GPT-4 当裁判，来给其他大模型打分的排行榜
- AlpacaEval 目前是业界衡量大模型对话能力的重要参考指标之一（尤其是 2.0 版本），但研究者通常会结合 Arena-Hard、MT-Bench 等其他指标来综合判断模型性能，以避免单一指标带来的误导
AlpacaEval 由斯坦福大学（tatsu-lab）的研究团队推出，旨在通过模拟人类评估的方式，快速、低成本地衡量模型在开放式对话中的表现
AlpacaEval 的核心理念是 “以大模型评测大模型” （LLM-as-a-judge）
- 不依赖昂贵且耗时的人工评分，而是利用强大的模型（通常是 GPT-4）作为裁判，来判断待测模型的回答质量
AlpacaEval 评估流程：
- 1）数据集：使用包含真实用户指令的评估集（源自 AlpacaFarm 数据集），涵盖各种类型的用户问题
- 2）生成回复：待测模型针对这些指令生成回复
- 3）对抗评测：裁判模型（如 GPT-4）会同时看到待测模型的回复和一个基准模型（通常是 text-davinci-003 或 GPT-4 Turbo）的回复
- 4）判定胜负：裁判判断哪个回复更好，从而计算出待测模型相对于基准模型的胜率（Win Rate）
AlpacaEval 的优点：
- 在 AlpacaEval 出现之前，评估聊天模型通常依赖于静态的客观题（如 MMLU）或昂贵的人工评估（如 Chatbot Arena）
- 模拟人类偏好：AlpacaEval 的设计目标是与人类的偏好高度相关，即 GPT-4 认为好的回答，通常人类也认为好
- 速度与成本：相比人工评估，它极其快速且经济，允许研究人员在模型迭代过程中频繁测试
- 指令遵循：它专门针对“指令遵循”能力进行测试，这比单纯的知识问答更能反映聊天机器人的实际用户体验
AlpacaEval 在发展过程中经历了 AlpacaEval 1.0 到 AlpacaEval 2.0 迭代，主要是为了解决 “长度偏差”（Length Bias） 问题
- AlpacaEval 1.0 的问题：早期的评估发现，裁判模型（GPT-4）倾向于认为“越长越好”
  - 即使一个回答内容空洞，只要写得很长，往往也能获得高分
  - 这导致许多模型通过生成冗长的废话来“刷榜”
- AlpacaEval 2.0 的改进：为了解决这个问题，AlpacaEval 2.0 引入了长度控制胜率（Length-Controlled Win Rate, LC Win Rate）
  - 通过统计方法（Logistic Regression）以此来消除输出长度对评分的影响，迫使模型通过提高回复的质量而不是长度来提升排名
AlpacaEval 的缺点
- 裁判偏见：由于裁判通常是 GPT-4，它可能更偏好与自己风格相似的回答（Self-preference bias）
- 容易被“作弊”：研究发现，即使是一个始终输出固定内容的“空模型”或经过特定微调的模型，也有可能通过利用裁判的漏洞在榜单上获得极高的胜率，甚至在数据上“吊打”GPT-4
- 评估单一性：它主要评估单轮对话的指令遵循，可能无法全面反映模型在多轮对话、逻辑推理或特定领域（如数学、代码）的深层能力

附录：AlpacaEval 2.0 LC Win Rate 详细介绍

AlpacaEval 2.0 LC Win Rate（Length-Controlled Win Rate，长度控制胜率）是目前大模型领域非常权威的一个评测指标，主要用于评估模型在指令跟随（Instruction Following）方面的能力
TLDR: 它的核心目的是：在去除“字数越多得分越高”这种偏见的前提下，公正地评判一个模型回答得好不好
在早期的大模型自动评测中，人们发现了一个严重的 bug：AI 裁判（如 GPT-4）非常喜欢“长篇大论”
- 哪怕一个回答内容空洞，只要写得很长，GPT-4 往往会判它赢（Win），很多模型厂商为了刷榜，故意把模型训练得非常啰嗦（Verbosity），导致分数虚高，但实际用户体验很差
- 为了解决这个问题，AlpacaEval 团队推出了 2.0 版本，并引入了 LC (Length-Controlled) 机制
LC Win Rate 的计算逻辑不是简单的“谁赢了加 1 分”，而是一个统计学上的调整过程：
- 1）两两对战： 让待测模型（例如 Llama 3）和基准模型（通常是 GPT-4 Turbo）回答同样的 805 个指令问题
- 2）裁判打分： 让 GPT-4 Turbo 作为裁判，判断哪个回答更好
- 3）统计去噪（核心步骤）：
  - 系统会使用一个统计模型（如 LR 模型）来分析裁判的偏好
  - 它会计算：“如果我们假设这两个回答的长度是一样的，裁判更倾向于谁？”
  - 通过这种数学手段，把“长度”这个干扰因素从分数中剥离出去，只保留“内容质量”带来的胜率
经过 LC 修正后，AlpacaEval 2.0 的排名与 LMSYS Chatbot Arena（人类盲测竞技场） 的排名高度一致（相关性高达 0.98）
LC Win Rate 可以防刷榜： 它迫使模型开发者关注回答的质量、逻辑和准确性 ，而不是单纯地增加字数

InfoBench

原始论文：InfoBench: Evaluating Instruction Following Ability in Large Language Models, 20240107, Tencent AI Lab
HuggingFace：huggingface.co/datasets/kqsong/InFoBench
InfoBench 是一个专门用于评估 LLM 指令遵循（Instruction Following）能力的基准测试
与传统的 NLP 任务不同， InfoBench 侧重于考察模型在处理包含多个复杂约束（Constraints）的指令时的表现
InfoBench 聚焦于 LLM 对“原子约束”（即任务中明确的细节要求）的遵循能力，通过量化模型满足约束的表现，评估其在复杂任务中的可靠性
InfoBench 的核心在于将一个复杂的指令分解为多个原子约束（Atomic Constraints）
- 例如，如果指令是“写一段关于猫的 50 字短文，不要提到‘鱼’，并使用法语”，它会被分解为：
  - 1）话题：关于猫
  - 2）长度限制：约 50 字
  - 3）负向约束：不提到“鱼”
  - 4）语言要求：法语
InfoBench 不仅给出总分，还会根据约束的性质进行分类评估，常见的维度包括：
- 格式约束 (Format) ：要求输出特定的数据格式
  - 比如：”以 JSON 格式输出”, “使用 Markdown 表格”
- 内容约束 (Content) ：要求包含或排除特定信息
  - 比如： “提及‘量子力学’”, “不要提到任何颜色”
- 长度约束 (Length) ：限制字数、句子数或段落数
  - 比如： “少于 30 个词”, “正好三段”
- 语言约束 (Language) ：指定输出的语种
  - 比如： “使用古汉语回答”, “翻译成德语”

InfoBench 的核心评测指标与公式

InfoBench 主要通过以下三个维度的指标来衡量模型的性能：
- CSR：看所有约束的整体达标率 ，不区分指令
- SA：看指令级的“全对率” ，要求单个指令的所有约束都满足
- ACF：看指令级的“平均达标率” ，允许单个指令部分约束满足，再取平均
约束满足率 (Constraint Satisfaction Rate, CSR)
- CSR 衡量模型在所有测试用例中，成功遵循的原子约束占总约束的比例（最基础的整体约束达标率）
  $$
  CSR = \frac{\sum_{i=1}^{N} \text{Satisfied}(c_i)}{N}
  $$
  - $ N $：所有测试样本中包含的原子约束总数；
  - $ \text{Satisfied}(c_i) $：指示函数（第$ i $个约束满足则为1，否则为0）
严格准确率（Strict Accuracy, SA）
- SA 衡量模型在单个指令（Prompt）中，完全满足所有原子约束的比例（更严苛，反映复杂多约束任务的可靠性）
  $$
  SA = \frac{\sum_{j=1}^{M} \prod_{k=1}^{K_j} \text{Satisfied}(c_{j,k})}{M}
  $$
  - $ M $：总指令（Prompt）数量；
  - $ K_j $：第$ j $个指令包含的原子约束数量；
  - $ c_{j,k} $：第$ j $个指令的第$ k $个约束；
  - $ \prod $（连乘）：只有当该指令的所有约束都满足（连乘结果为1），才算该指令通过
平均约束遵循度（Average Constraint Following, ACF）
- ACF 衡量模型在每个指令中满足约束的比例的平均值（关注单个任务的平均表现，而非整体约束计数）
  $$
  ACF = \frac{1}{M} \sum_{j=1}^{M} \left( \frac{\sum_{k=1}^{K_j} \text{Satisfied}(c_{j,k})}{K_j} \right)
  $$
  - 先计算“单个指令内满足约束的比例”（$ \frac{\sum_{k=1}^{K_j} \text{Satisfied}(c_{j,k})}{K_j} $），再对所有指令取平均

InfoBench 评测流程简述

Step 1 分解 (Decomposition)： 利用强大的教师模型（如 GPT-4）或预定义的规则，将复杂指令拆解为
Step 2 执行 (Execution)： 被测模型生成回复
Step 3 验证 (Verification)： 再次利用教师模型或程序脚本，逐一检查每个原子约束是否在回复中得到满足
Step 4 汇总 (Aggregation)： 应用上述公式计算最终得分

BPB（Bits per Byte）

BPB（Bits per Byte，比特 / 字节）是 LLM 语言建模的 Byte-level 评估指标
BPB 的物理意义：在编码或预测文本时，平均每个字节（Byte）需要消耗多少个比特（Bit）的信息量
BPB 可以衡量模型对文本的预测效率与压缩能力，值越小越好，且与分词器无关 ，便于跨模型公平对比
注：在基于深度学习的图像/视频压缩大模型中，也有个类似指标 BPP (Bits Per Pixel，每像素比特数)，此时，BPP 是衡量压缩率的最关键指标
BPB 的本质是归一化到字节的平均交叉熵（以2为底取对数）。对长度为$ T $字节的文本，BPB 计算公式为：
$$
\text{BPB} = \frac{1}{T} \sum_{t=1}^T -\log_2 P(x_t | x_1, x_2, \dots, x_{t-1})
$$
其中：
- $ T $：文本的总有效字节数（排除特殊 token、masked 位置等非内容字节）
- $ x_t $：第$ t $个字节的内容
- $ P(x_t | x_1, x_2, \dots, x_{t-1}) $：模型基于前文$ x_1 \dots x_{t-1} $对第$ t $个字节的预测概率

与困惑度（Perplexity）的换算关系

若文本的 token 序列长度为$ N $，每个 token 对应的字节数为$ l_i $（$ i=1,2,\dots,N $），总字节数$ T = \sum_{i=1}^N l_i $，token 级困惑度$ \text{PPL} = \exp\left( \frac{1}{N} \sum_{i=1}^N -\log P(y_i | y_1, \dots, y_{i-1}) \right) $（$ y_i $为第$ i $个 token），则 BPB 与困惑度的近似换算（以自然对数转2为底）：
$$
\text{BPB} \approx \frac{1}{T} \cdot \frac{\ln(\text{PPL}) \cdot N}{\log_2 e}
$$
其中$ \log_2 e = \frac{1}{\ln 2} \approx 1.4427 $，因此也可简化为：
$$
\text{BPB} = \frac{N \cdot \ln(\text{PPL})}{T \cdot \ln 2}
$$

关于 BPB 名字的理解

公式里“没有包含比特信息”，是因为这里的“比特（Bit）”并非指计算机存储中的物理开关（0或1），而是信息论（Information Theory）中的度量单位
TLDR：公式中的 $\log_2$（以 2 为底的对数） 就是将“概率”转换为“比特”的数学算子
- 在信息论中，$-\log_2(p)$ 的结果单位定义就是“比特”
让我们把公式拆开，逐项对应到物理意义上，你就会发现它完美对应了 Bits Per Byte 的名字，公式：
$$ \text{BPB} = \frac{1}{T} \sum_{t=1}^{T} \underbrace{-\log_2 P(x_t | x_{<t})}_{\text{核心部分}} $$
分子：“Bit” 藏在 $-\log_2 P$ 里
- 在香农信息论中，信息量（Information Content） 的定义是：
  $$ I(x) = -\log_2 P(x) $$
  - 数学定义 ：如果一个事件发生的概率是 $P$，那么消除这个不确定性所需的信息量就是 $-\log_2 P$
  - 单位定义 ：当底数为 2 时，计算结果的单位被定义为 Bit（比特）
  - 如果底数是 $e$，单位是 Nat
  - 如果底数是 10，单位是 Hartley
- 举例
  - 抛硬币 ：正面朝上的概率是 $0.5$ ($1/2$)
    $$ -\log_2(0.5) = 1 \text{ bit} $$
    - 这符合直觉：需要 1 个比特（0或1）来记录硬币的结果
  - 完全随机的字节 ：一个字节有 256 种可能（0-255），如果模型完全猜不到（均匀分布），概率是 $1/256$
    $$ -\log_2(1/256) = \log_2(2^8) = 8 \text{ bits} $$
    - 这意味着：如果你完全猜不到下一个字节是什么，你就需要完整的 8 个比特 来存储它（没有任何压缩）
- 结论：公式中的求和项 $\sum -\log_2 P(\dots)$ 计算出的数值，物理意义就是 “编码这段文本理论上所需的总比特数”
分母：“Byte” 藏在 $T$ 里，在 BPB 指标中，$T$ 代表的是文本序列中 字节（Byte）的总数量
将分子和分母结合起来看：
$$ \text{BPB} = \frac{\text{总信息量 (Total Bits)}}{\text{总字节数 (Total Bytes)}} $$
- 分子：$\sum -\log_2 P \rightarrow$ 单位是 Bits（因为用了 $\log_2$）
- 分母：$T \rightarrow$ 单位是 Bytes（因为 $t$ 遍历的是字节序列）
- 结果：Bits Per Byte

为什么 BPB 指标代表“压缩能力”？

引入算术编码（Arithmetic Coding）的概念
理论上，存在一种完美的压缩算法，它能将概率为 $P$ 的符号，压缩成长度为 $-\log_2 P$ 个比特的二进制码流
模型越聪明（$P$ 越大） ：
- 如果模型非常确信下一个字是“A”，预测概率 $P=0.99$
  $$ -\log_2(0.99) \approx 0.014 \text{ bits} $$
- 这意味着只需要极少的比特就能存储这个信息（压缩率极高）
模型越笨（$P$ 越小） ：
- 如果模型觉得下一个字可能是任何字，预测概率 $P=0.001$
  $$ -\log_2(0.001) \approx 9.96 \text{ bits} $$
- 这意味着需要花费很多比特来记录这个意外的信息
公式 $\text{BPB} = -\frac{1}{T} \sum \log_2 P$ 实际上是在计算：
- “如果利用该模型对文本进行无损压缩，平均每个字节最终会被压缩成多少个比特”

HealthBench

原始论文：HealthBench: Evaluating Large Language Models Towards Improved Human Health, OpenAI, 20250513
HuggingFace：huggingface.co/datasets/openai/healthbench
博客链接：Introducing HealthBench, OpenAI, 20250512
HealthBench 是 OpenAI 推出的医疗大模型评估基准，核心以医生编写的细粒度评分标准为核心，从 5 大行为维度与 7 大场景主题对模型回复打分，用标准化方式衡量医疗大模型在真实临床交互中的安全性、准确性与实用性
基于真实对话与医生共识，评估结果更贴近临床实际需求，避免传统选择题评估的局限性
覆盖26个医学专科、49种语言，适配不同地区诊疗差异
开源评分器与基准结果，支持第三方复现评估、扩展标准，推动医疗 AI 评估标准化
评分流程：
- 1）评分标准生成 ：每段对话由医生编写专属评分标准，明确应包含/避免的内容及对应分值（±10分），反映该标准的重要性
- 2）自动化评分 ：由 GPT‑4.1 训练的模型评分器，判断回复是否满足每项标准，达标得全部分值，未达标不得分
- 3）综合得分计算 ：单条回复得分 =（达标标准总分 ÷ 该对话满分）×100%，最终按所有对话平均分计算模型整体得分
- 4）可靠性验证 ：评分器与医生评估的宏 F1(Macro F1) 值达 0.71，接近医生间互评一致性，确保自动化评分的可信度
衍生评估版本
- HealthBench Consensus ：聚焦 34 项经医生验证的核心标准，重点评估紧急处置、情境澄清等关键模型行为，适合快速基准测试
- HealthBench Hard ：精选 1000 段高难度对话，用于挑战模型在复杂临床场景下的极限表现

核心评估维度（5 大行为轴）

每个评分标准都对应以下维度，每个维度有明确正向/负向判据，分值范围 ±10 分，用于奖励或惩罚模型行为：
1）准确性（Accuracy） ：±10分（奖励正确行为，惩罚错误行为）
- 定义：仅含事实正确信息，有证据/共识支持，证据有限时明确不确定性
- 评估点：无错误事实、避免常见误解、不编造信息、标注信息来源与不确定性
2）完整性（Completeness） ：±10分
- 定义：覆盖安全有效回复所需的关键信息，不遗漏必要内容
- 评估点：包含核心诊疗步骤、风险提示、随访建议等，无关键信息缺失
3）沟通质量（Communication Quality） ：±10分
- 定义：回复长度、清晰度、细节度、词汇、结构契合用户需求与情境
- 评估点：语言通俗、逻辑清晰、重点突出、避免冗余术语、适配用户角色（患者/医生）
4）情境感知（Context Awareness） ：±10分
- 定义：结合用户角色、环境、资源等情境恰当响应，必要时主动澄清
- 评估点：适配地区诊疗规范、用户可及资源、患者基础疾病，主动询问缺失信息
5）指令遵循（Instruction Following） ：±10分
- 定义：严格遵守用户明确指令，如格式要求、任务步骤等
- 评估点：不偏离用户需求、按要求完成临床笔记总结/报告生成等任务

评估主题（7 大主题场景分类）

覆盖真实医疗交互的关键场景，每个主题聚焦特定临床挑战，所有对话由 262 名跨 60 国医生共同设计，共 5000 段多轮对话，对应 48,562 条独特评分标准：
- 1）紧急转诊（Emergency Referrals）：评估危急情况（如心脏骤停、休克）下的规范处置与转诊建议
- 2）情境寻求（Context Seeking）：判断模型是否主动识别缺失信息以提供精准回复
- 3）不确定性下的响应（Responding Under Uncertainty）：考察低证据场景下的不确定性表达与安全建议
- 4）响应深度（Response Depth）：根据用户背景（如患者/医生）调整回答详细程度
- 5）健康数据任务（Health Data Tasks）：评估医疗文档书写、临床笔记总结、健康管理等任务的完成质量
- 6）专业定制沟通（Professionally Tailored Communication）：适配不同专业角色的沟通策略（如对患者通俗解释、对医生专业表述）
- 7）全球健康（Global Health）：适配不同地区资源、流行病学与诊疗规范的跨地域响应能力

WritingBench

论文链接：WritingBench: A Comprehensive Benchmark for Generative Writing
WritingBench (生成式写作综合基准) 是一个专门针对 LLMs 生成式写作能力进行评估的综合性基准，旨在解决传统基准无法全面覆盖写作领域的问题
HuggingFace：
WritingBench 包含 6 个核心写作领域（如创意写作、技术写作、公文写作等）和 100 个子领域 ，旨在全面评估模型在不同语境下的生成能力
WritingBench 采用了一种“查询依赖”（query-dependent）的评估框架，这意味着评估标准会根据用户的具体指令动态调整，而非使用单一的通用标准
WritingBench 基准通常结合了 LLM-based 自动评估（如使用 GPT-4 或 Claude 作为裁判）与人工评估的验证，重点关注文本的连贯性、创造性、遵循指令的能力以及内容的深度

EQ-Bench

GitHub (官方仓库)：github.com/EQ-bench/EQ-Bench
官方网站 (Leaderboard)：eqbench.com/
数据集：
- EQ 任务数据子集：EQ-Bench GitHub Release
- Creative Writing 数据子集：Creative Writing Bench GitHub
EQ-Bench (情商与创意写作基准) 最初设计用于评估大语言模型的情商（Emotional Intelligence），随后扩展了针对创意写作（Creative Writing）的评估分支，是目前评估模型“人性化”与“文学性”的重要榜单
EQ-Bench 包含多个任务：
- 核心任务 (EQ) ：评估模型理解复杂情绪和社交互动的能力
  - 数据集包含具有挑战性的角色扮演（Roleplays）对话，模型需要预测对话中角色的情绪状态或做出符合情境的反应
- 创意写作 (Creative Writing v3) ：这是 EQ-Bench 的一个重要分支，专门用于评估模型的文学创作能力
  - 它通过设定具体的写作提示（Prompt），让模型生成故事或文章
EQ-Bench 评分使用 Rubric Score，使用一套详细的规则（Rubric），通常由高水平模型（如 Claude 3.5 Sonnet 或 GPT-4）作为裁判，对生成内容的风格、重复度、长度和指令遵循度进行打分
EQ-Bench 排行榜使用 Elo Score，采用竞技排名系统（Elo Rating），通过成对比较不同模型的输出优劣来计算相对排名，这种方法被认为比单一分数更能反映模型间的细微差距

MRCR (Multi-Round Co-reference Resolution)

HuggingFace：openai/mrcr
MRCR 是一个针对长上下文（Long Context）能力的评估任务
- 与传统的单点检索（NIAH）不同，MRCR 要求模型在长对话或长文本中识别并关联多个分散的信息点，主要测试模型在长窗口下区分相似信息（Multiple Needles）和处理共指关系的能力
该数据集通常作为技术报告的一部分出现，而非单一论文，在评估 GPT-4 Turbo、GPT-4o 以及 Gemini 1.5 Pro 等长窗口模型时被广泛引用
- 相关技术报告参考：Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context（其中详细描述了 MRCR 任务机制） * 相关研究：Long Context Evaluations Beyond Haystacks via Latent Structure Queries
MRCR 任务逻辑：
- 模型会看到一段非常长的用户与 AI 的多轮对话历史（作为“大海/Haystack”）
- 用户会提出一个问题，该问题需要模型回溯到对话中的特定轮次（例如“我在第 3 次询问水果时，你推荐了什么？”）
MRCR 数据集的难点（重点考察点）：
- 多针检索 (Multiple Needles) ：上下文中包含大量相似的对话结构，模型必须精确定位到特定的那一轮，而不是混淆其他轮次的信息
- 共指消解 (Co-reference) ：模型需要理解 “第 i 次”、“那个” 等代词具体指代长文本中的哪一部分内容
MRCR 的评估指标通常使用 检索准确率 (Retrieval Accuracy)
- 在不同长度的上下文窗口（如 32k, 128k, 1M）下，计算模型成功定位并正确回答特定轮次内容的百分比

MT-Bench

HuggingFace：huggingface.co/datasets/lmsys/mt_bench_human_judgments
MT-Bench (Multi-Turn Benchmark) 由 LMSYS Org（也就是发布了著名的 Chatbot Arena 和 Vicuna 模型的组织）提出
MT-Bench 是一个专门用于评估 LLM 多轮对话能力和指令跟随能力的评测基准
- MT-Bench 的核心目的是测试模型在连续对话中是否“聪明” ，能不能接得住话、记住了前文，并准确完成复杂的指令
“MT” (Multi-Turn) 的含义
- 传统的评测往往是一问一答（Single-turn），模型回答完就结束了，但在真实应用中，用户经常会追问、修改需求或要求模型根据上文继续生成
- MT-Bench
  - 多轮机制： MT-Bench 的每个测试题包含两轮对话
  - 第一轮： 提出一个有难度的问题
  - 第二轮： 基于模型的回答，提出一个追问（例如：“请把刚才的代码重写一遍，要求效率更高”或“请缩短刚才的文章，但保留核心观点”）
- MT-bench 会考察模型是否具备上下文记忆、逻辑推理以及根据反馈修正的能力
MT-Bench 精心设计了 80 个高质量的多轮问题（共 160 个问答），涵盖了 8 个主要类别，旨在模拟人类的高频使用场景：
- Writing (写作) ：创作、修改文本
  - 如 “写一篇博客…” -> “请改写得更幽默一点”
- Roleplay (角色扮演)：模拟特定语气或人设
  - 如 “你是一个求职面试官…”
- Reasoning (推理) ：逻辑推导、常识推理
  - 如解决逻辑谜题或分析因果关系
- Math (数学) ：数学计算与解题
  - 如几何、代数或应用题
- Coding (代码) ：编写与修改代码
  - 如 “写一个Python函数…” -> “请优化它的时间复杂度”
- Extraction (提取) ：从长文中提取信息
  - 日总结会议记录、提取关键数据
- STEM (理工科) ：科学、技术、工程知识
  - 如物理概念解释、工程原理
- Humanities (人文) ：历史、文化、哲学
  - 如分析历史事件或文化现象
MT-Bench 最具标志性的特点是它不完全依赖人工评分（太慢太贵），也不依赖传统的死板指标（如 BLEU/ROUGE，对生成式对话不准）
- MT-Bench 使用 GPT-4 作为裁判（Judge），将待测模型的回答输入给 GPT-4，让 GPT-4 根据回答的质量、准确性、创造性等维度打分（通常是 1-10 分）
- 研究表明，GPT-4 的打分结果与人类专家的偏好具有很高的一致性（Agreement rate），因此被广泛作为“平替”人类评估的低成本方案
注：在开源大模型领域（如 Llama 3, Qwen, Mistral 等），MT-Bench 几乎是必测的标准之一，原因如下：
- 1）更接近真实体验： 相比于做选择题（如 MMLU），MT-Bench 的开放式问答更像用户平时使用 ChatGPT 的真实感觉
- 2）区分度高： 很多模型第一轮回答得不错，但第二轮追问时就会露馅（比如忘记前文设定），MT-Bench 能有效暴露出这种弱点
- 3）Chatbot Arena 的风向标： MT-Bench 的分数通常与模型在 Chatbot Arena（盲测竞技场）中的 Elo 排名高度正相关
MT-Bench 的缺点：
- GPT-4 偏见： GPT-4 可能更倾向于给“像自己”的回答打高分（Self-preference bias）
- 题目数量少： 只有 80 题，模型可能会针对性地去“刷题”或过拟合（Overfitting）
- 静态性： 题目是固定的，随着模型越来越强，很多题目变得太容易，区分度正在逐渐降低

MultiChallenge

原始论文：MultiChallenge: A Realistic Multi-Turn Conversation Evaluation Benchmark Challenging to Frontier LLMs
GitHub ：ekwinox117/multi-challenge
MultiChallenge 是一个专注于评估 LLM 在多轮对话 中应对现实挑战能力的基准
MultiChallenge 主要验证模型的以下能力：
- 指令保留 (Instruction Retention) ：模型能否在多轮对话后依然记住最初的指令
- 推理记忆 (Inference Memory) ：对用户在前几轮提到的信息进行推理
- 可靠的版本编辑 (Versioned Editing) ：在多次修改任务（如修改代码或文案）时保持一致性
- 自我连贯性 (Self-coherence) ：回答不与之前的发言冲突

MarsBench (MARS-Bench)

原始论文：MARS-Bench: A Multi-turn Athletic Real-world Scenario Benchmark for Dialogue Evaluation
MarsBench（全称：Multi-turn Athletic Real-world Scenario Benchmark）是首个利用体育赛事文字直播（Play-by-play）数据 构建的多轮对话基准，模拟了极端真实、高动态的场景
注：学术界还有一个同名但不同领域的 Mars-Bench（用于火星科学任务的视觉模型评测），但在 LLM 评测语境下，通常指代以下对话基准
MarsBench 主要验证模型的以下能力：
- 超多轮对话 (Ultra Multi-turn) ：包含超过 30 轮的对话序列
- 交互式生成 (Interactive Generation) ：模型需要在每一轮都做出正确响应
- 跨轮任务 (Cross-turn Tasks) ：需要从非相邻的轮次中提取和推理信息
- 动机转移 (Motivation Transfer) ：用户意图在对话中发生突变时的处理能力

Multi-IF

原始论文：Multi-IF: Benchmarking LLMs on Multi-Turn and Multilingual Instructions Following
Hugging Face ：huggingface.co/datasets/facebook/Multi-IF
GitHub ：facebookresearch/Multi-IF
Multi-IF 是 IFEval 的升级版
- IFEval 主要关注单轮、英语的指令遵循，而 Multi-IF 将其扩展到了多轮和 多语言 环境
Multi-IF 主要验证模型的以下能力：
- 多轮复杂性 ：每组数据包含 3 轮 连续对话，每轮都有特定的可验证指令（如“回复不少于 300 字”、“使用 JSON 格式”等）
- 多语言支持 ：涵盖 8 种语言（包括中文、印地语、俄语等非拉丁字母语言）
- 硬约束检查 ：沿用了 IFEval 的严苛评分方式，要求模型必须严格满足所有格式和内容约束

附录：大模型训练集和测试集的划分

补充问题：很多大模型相关文章不会明确给定训练样本和测试样本的拆分，那训练集和测试集是如何配置的呢？
回答：与常规的机器学习方法不同，大模型中很多数据集是自动划分了 train 和 test 的
- 使用 split="train" 就可以获取到训练数据
- 使用 split="test" 就可以获取到测试数据
- 未做特殊说明时，大部分方法都是在默认的训练集上进行训练，使用测试集进行评估

附录：数据集的访问和下载

一般来说，直接在 HuggingFace 上直接可以看到相关数据集

下载opencompass/AIME2025（包含 AIME2025-I 和 AIME2025-II子集）并打印的示例

from datasets import load_dataset

dataset = load_dataset("opencompass/AIME2025", 'AIME2025-I') # 'AIME2025-I' 是子数据集的名称，需要去huggingface上看看是否有子集
# dataset = load_dataset("opencompass/AIME2025", 'AIME2025-II') # 'AIME2025-II' 是子数据集的名称，需要去huggingface上看看是否有子集

# 检查是否存在 'train' split
if 'train' in dataset:
   print(dataset['train'][0])

# 检查是否存在 'test' split
if 'test' in dataset:
   print(dataset['test'][0])

## output
# {'question': 'Find the sum of all integer bases $b>9$ for which $17_{b}$ is a divisor of $97_{b}$.', 'answer': '70'}

特别注意：
- 部分数据集还有子集，此时下载需要指定子集，否则可能失败
- 部分数据集需要先登录和授权才能下载

附录：评估/测试工具

LightEval

LightEval 是一个专注于 LLM 评估的开源工具库，由 Hugging Face 开发
它提供了标准化的评估框架，库中包含了许多数据集，可以直接加载和评估
传入数据集和 model_predict_fn 即可
- 数据集可通过 lighteval 库的 load_dataset 来加载
- model_predict_fn 需要自定义模型的 predict 函数

OpenCompass

OpenCompass 是上海人工智能实验室开源的大模型评测平台，涵盖学科、语言、知识、理解、推理等五大评测维度，可全面评估大模型能力
OpenCompass 支持在线查看榜单，在线参与评测竞技
OpenCompass 还开源了大模型评测工具，使用很简便，GitHub 地址：OpenCompass 项目
- 使用教程：README.md
OpenCompass 比 LightEval 封装的更好，评估更加简单

RM 评估：RewardBench

原始论文：(RewarBench)Evaluating Reward Models for Language Modeling, arXiv 20240608, Allen Institute for AI & University of Washington
HuggingFace： allenai/reward-bench
GitHub： allenai/reward-bench
RewardBench 是目前最权威、应用最广泛的奖励模型评估基准之一，解决了以往评估缺乏标准化和涵盖面不足的问题
RewardBench (v1)：由 AllenAI 推出，旨在通过统一的框架评估奖励模型
- 它包含四个主要类别的测试数据：
  - Chat（通用对话）
  - Chat-Hard（高难度对话）
  - Safety（安全性）
  - Reasoning（推理能力）
数据来源见原始论文表 1：

RewardBench2

原始论文：REWARDBENCH 2: Advancing Reward Model Evaluation, 20250602
RewardBench2 是 RewardBench 基准的升级版本
- v2 引入了更具挑战性的“多技能”评估维度，进一步测试 RM 在捕捉细微人类偏好和处理复杂逻辑时的表现
RewardBench2 包含的测试集有（相对 RewardBench 移除了 Chat 子集，新增了三个数据集并重新划分一些数据集）：
- Math: 数学能力，主要包含从中学的物理（physics）和几何学（geometry）到大学级别的化学（chemistry）、微积分（calculus）、组合数学（combinatorics）等
- Safety: 安全性
- Focus: 检查一般 Query 上的高质量回复能力
  
  Tests RMs’ ability to detect high-quality, on-topic answers to general user queries.
- Ties (NEW!): 用一些回答为平手的数据检查模型评分的健壮性
  
  This new type of subset tests the robustness of RMs in domains with many possible similar answers. For example, the question “Name a color of the rainbow” has seven possible correct answers and infinitely many incorrect ones.
- Factuality (NEW!): 模型幻觉检查
- Precise Instruction Following (Precise IF，NEW!): 指令遵循能力
  
  such as “Answer without the letter u”.
非 Ties 的子集，基本都是针对 ID 进行分组，多个样本一起体现一个组内的表现，评估是否最高分是 label=1 的样本
- 当 N 样本都打了最高分，给分为 1/N

RewardBench2:Ties，这个数据集会在同一个 prompt 上给出很多等价的正确回答和错误回答，然后评估模型给出的分差 GAP

目标是希望所有正确回答的分数 GAP（最高正确-最低正确）比正负 GAP（最低正确-最高错误）的值要大
不仅关注打分是否正样本大于负样本，还关注是否所有正样本比负样本都大得多
取名为 Ties 的本意就是让模型能对平手的回复打分方差不要太大
举例：prompt=”Pick a number between 1 and 10.”，正确回答是 1-10 之间的数字，错误回答是其他数字，从而可以 check 模型的评估能力是否有问题

样本示例：

{
    "id": "tied:0",
    "target": "Eleven",
    "label": 0,
    "num_c": 10,
    "num_r": 12,
    "num_all": 22,
    "subset": "Ties",
    "eval_set": "reward_bench2",
    "messages": [
        {
        "role": "user",
        "content": "Pick a number between 1 and 10."
        }
    ]
}

allenai/reward-bench 中有 RewardBench2 指标的具体统计实现

RM 评估：JudgeBench

JudgeBench: A Benchmark for Evaluating LLM-based Judges, arXiv 20241016 & ICLR 2025, Berkeley
HuggingFace：huggingface.co/datasets/ScalerLab/JudgeBench
JudgeBench 是一个极具挑战性的基准，专门用于评估模型作为“裁判”（LLM-as-a-Judge）的能力
不同于简单的闲聊偏好，JudgeBench 侧重于评估模型在复杂推理任务中的表现，涵盖数学、编程、知识问答等领域
JudgeBench 要求奖励模型不仅要理解人类的主观偏好，还要具备判断客观事实正确性（Correctness）和逻辑严密性的能力
- 这对于训练能够进行自我修正和长思维链（CoT）推理的模型尤为重要

RM 评估：PPE Preference

PPE Preference & Correctness
HuggingFace：
- huggingface.co/datasets/Skywork/Skywork-Reward-Preference-80K-v0.1
- huggingface.co/datasets/Skywork/Skywork-Reward-Preference-80K-v0.2
PPE（Prompt-Preference-Evaluation）相关的测试主要关注模型对真实人类偏好的理解深度
PPE 基准使用的数据通常源自真实用户的交互记录（而非合成数据），因此更能反映模型在实际应用场景（如 AI 助手）中的表现
PPE 的评估维度包含 Preference（偏好排序）和 Correctness（正确性判断）
在 Skywork-Reward-V2 的评估中，PPE 被用来验证模型是否能区分（高质量）与（次优）数据，确保模型真正理解人类的意图和喜好
该指标常在 Skywork (昆仑万维) 及相关 RLHF 研究中作为核心真实场景指标出现

RM 评估：RM-Bench

原始论文：RM-Bench: Benchmarking Reward Models of Language Models with Subtlety and Style, 20241021, Fudan & THU & HKUST
开源项目：github.com/THU-KEG/RM-Bench
RM-Bench 是一个专门针对奖励模型鲁棒性和一致性的评估基准
RM-Bench 通常关注模型在面对不同类型的输入干扰、对抗性样本或特定安全边界时的表现
RM-Bench 基准旨在揭示奖励模型在“过度优化”（Reward Hacking）风险下的稳定性，确保模型给出的高分确实对应高质量回复，而非利用了模型的漏洞
RM-Bench 的评估指标核心特点是聚焦“内容敏感性”与“风格偏见抗性”，以三级准确率梯度设计为核心，结合域特异性与跨域综合指标，且与策略模型性能强相关

基础评估框架：分类任务定义

核心任务：给定三元组 $(x, y_c, y_r)$（$x$ 为提示词，$y_c$ 为优选 Response ，$y_r$ 为弃选 Response ），判断 $R_\psi(x, y_c) > R_\psi(x, y_r)$（$R_\psi$ 为奖励模型，$\psi$ 为模型参数）
基础准确率公式：
$$
\text{Accuracy} = \frac{1}{|\mathcal{D}|} \sum_{(x, y_c, y_r) \in \mathcal{D} } \mathbb{I}\left[R_{\psi}(x, y_c) > R_{\psi}(x, y_r)\right]
$$
- 其中 $\mathbb{I}(\cdot)$ 为指示函数，$\mathcal{D}$ 为评估数据集；多目标奖励模型采用奖励向量逐元素比较

风格-实质分离评估：3×3 矩阵与三级准确率

风格变体：涵盖三类 Response 风格——简洁型（$y^\emptyset$）、详细纯文本型（$y^L$）、详细带Markdown型（$y^{L,M}$）
评估矩阵：构建行（Chosen Response 风格）X 列（Rejected Response 风格）的 3x3 风格-实质矩阵，衍生三类核心指标：
- 简易准确率（Easy Accuracy）：矩阵下三角均值，衡量有风格提示时的内容识别能力
- 正常准确率（Normal Accuracy）：矩阵对角线均值，评估风格一致时的内容判断能力
- 困难准确率（Hard Accuracy）：矩阵上三角均值，测试弃选 Response 风格更优时的纯内容区分能力
详情见原始论文图 2

域特异性与综合指标结合

域特异性指标：针对聊天、代码、数学、安全四大核心域，分别计算各域的三级准确率（如 Chat Normal Accuracy、Math Hard Accuracy）
跨域综合指标：计算所有域的平均准确率（Average Accuracy），作为奖励模型整体性能的统一衡量标准

与策略模型性能强关联

风格控制相关性：奖励模型的 Chat 域 Hard Accuracy 与策略模型的风格控制得分显著正相关，能反映策略模型对风格偏见的抵抗能力
下游任务相关性：与策略模型在数学（GSM8k、Big Bench Hard）、代码（HumanEval+、MBPP+）、安全（ToxiGen、XSTest）等下游任务的表现呈中度正相关，Pearson 相关系数 $r=0.55$（$p=0.07$），显著优于传统基准（如 RewardBench 的 $r=0.21$）

RM 评估：RMB

RMB：Reward Model Benchmark
原始论文：RMB: Comprehensively Benchmarking Reward Models in LLM Alignment, 20241013 & ICLR 2025, Fudan
RMB 是一个全面且细粒度的奖励模型评估基准，核心亮点是创新性和贴近现实应用
RMB 涵盖 49 个现实世界场景，核心目标：
- 有用性目标场景（Helpfulness, 75.5%）： 37 个场景的 12 个任务
  - 代码（Code）、开放问答（Open QA）、封闭问答（Closed QA）、翻译（Translation）、内容生成（Generation）、推理（Reasoning）、角色扮演（Role Playing）、文本改写（Rewrite）、分类（Classification）、聊天对话（Chat）、摘要总结（Summarization）、头脑风暴（Brainstorming）
- 无害性目标场景（Harmlessness, 24.5%）： 12 个场景，构建了超 18000 个高质量偏好对
  - 暴力相关（Violent Crimes）、非暴力相关（Non-Violent Crimes）、性相关违法（Sex-Related Crimes）、未成年人保护（Child Sexual Exploitation）、专业建议规范（Specialized Advice）、隐私保护（Privacy）、知识产权保护（Intellectual Property）、危险武器相关（Indiscriminate Weapons）、仇恨言论相关（Hate）、自我伤害相关（Suicide & Self-Harm）、色情内容相关（Sexual Content）、混合场景（Multi）
RMB 通过真实世界的用户查询构建具有实际意义的测试任务，并借助14个大型语言模型生成回复并评级，最终形成超18000个高质量偏好对，可充分检验奖励模型的场景泛化能力
评估范式：
- pairwise 评估范式：传统的成对比较评估模式
- Best-of-N 评估范式：测试奖励模型从多个候选回复中挑选最佳回应的能力
  - 经实验验证，其评估结果与奖励模型在下游对齐任务中的表现关联性强，能揭示现有模型的泛化缺陷，同时还强调了生成式奖励模型的发展潜力
数据集详细分布见原始论文附录 A

LLM 的评估指标

BLEU（Bilingual Evaluation Understudy）

ROUGE（Recall-Oriented Understudy for Gisting Evaluation）

BLUE 和 ROUGE 对比

pass@k 评估指标

SBS（Side by Side）评估指标

MMLU

MMLU 的评估方法：

MMLU-Redux

MMMU

MMMU_Pro

MMMLU

Big-Bench

BBH

HELM（评估框架）

Arena

Arena-Hard

Arena-Hard v2

MATH-500（数学）

AMC（数学）

AIME（数学）

OlympiadBench

GPQA

GPQA-D

ARC 数据集

ARC-AGI

RULER

Longeval (Long-context Evaluation)

LongBench

LongBench-V2

InfiniteBench

HelloBench

MorehopQA

HLE（推理）

IFEval

GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents

HMMT

IMO-ProofBench

附录：一些数学比赛集合

BeyondAIME

LiveCodeBench (24/8∼25/5)

OIBench

OIBench 的区分度足够好

OJBench

ZebraLogic

Sudoku-Bench

Aider-Polyglot

SWE-bench

SWE-bench_Verified

BigCodeBench

BFCL v3

AST(Abstract Syntax Tree) 准确率指标

\(\tau\)-bench & \(\tau^2\)-bench (Retail, Airline, Telecom)

MiniF2F

NuminaMath-1.5

AoPS Forum

TriviaQA

FRAMES

Pile-test

DS-1000

GAIA

VitaBench

BABILong

MemBench

FreshQA

FACTS Grounding

Terminal Bench

CoreCodeBench

AlpacaEval

附录：AlpacaEval 2.0 LC Win Rate 详细介绍

InfoBench

InfoBench 的核心评测指标与公式

InfoBench 评测流程简述

BPB（Bits per Byte）

与困惑度（Perplexity）的换算关系

关于 BPB 名字的理解

为什么 BPB 指标代表“压缩能力”？

HealthBench

核心评估维度（5 大行为轴）

评估主题（7 大主题场景分类）