olmes
allenai/olmes加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图：OLMES 系统架构概览，展示了评测流程中模型、任务与指标的交互关系
2024 年 6 月，一篇来自 Allen Institute for AI（Ai2）的论文《OLMES: A Standard for Language Model Evaluations》登上了 arXiv，在学术界引发了不少讨论。论文的核心发现直指一个行业痼疾：同一个模型、同一个数据集，不同团队测出的分数可能相差 10% 以上。
这个现象并非个案。作者调研了 ARC Challenge（AI2 出品的科学问答数据集）在多篇论文中的评测结果，发现 Llama2-13B 和 Llama3-8B 的性能对比，不同论文给出了完全相反的结论——有的说两者相当，有的说 Llama3-8B 领先超过 10 个百分点。
造成这种混乱的原因很简单：评测过程中有太多细节没有统一标准。选择几组 in-context examples、用什么样的 prompt 格式、答案概率怎么归一化、是「多项选择」还是「填空」 formulation——每一个选择都可能让最终分数上下浮动几个百分点。
更关键的是，这些细节往往在论文中一笔带过，甚至完全不写。当另一个团队试图复现时，他们只能靠猜。于是，同一个模型的评测分数在不同的「标准」下变成了一堆无法直接比较的数字。
Ai2 团队提出的 OLMES（Open Language Model Evaluation Standard）正是为了解决这个困境。它不是一个新的基准测试，而是一套严谨的评测操作规范——规定了评测过程中每个环节的标准做法，并给出了每条规范背后的实验依据。
具体来说，OLMES 对以下关键环节做了明确规范：
1. 采样策略：当测试集超过 1500 条时，随机采样 1000 条，确保评测效率与统计显著性之间的平衡。
2. Prompt 格式：为每个任务设计了固定的 prompt 模板，确保每次评测的输入格式完全一致。
3. Few-shot 示例：精心挑选 5 个高质量的 in-context examples，且要求这些示例覆盖所有答案选项（避免模型学到「永远选 A」的捷径）。
4. 概率归一化：对于多项选择类任务，规定了如何对 token 概率进行归一化处理，避免因答案 token 长度不同导致的偏差。
5. 任务 formulation：同时运行「多项选择」（MCF）和「填空」（Cloze）两种形式，取两者的最大值——因为某些模型在不同形式下表现差异显著。
6. 模型规模适配：特别关注从 1B 到 70B 参数量级的大模型评测一致性，确保评测标准在模型规模变化时依然有效。
图：OLMES 论文中的评测结果，展示了 15 个模型在 10 个基准任务上的对比分数（来源：arXiv:2406.08446）
从代码实现角度看，OLMES 项目的技术选型非常明确——完全基于 Python，核心依赖是 EleutherAI 的 lm_eval 框架（版本 0.4.3）。这是一种务实的策略：不需要从零造轮子，而是在成熟的评测框架基础上添加 OLMES 规范层。
核心技术栈：
| 组件 | 技术选型 | 用途 |
|---|---|---|
| 模型推理 | Transformers + vLLM | 支持 HF 原生推理和 vLLM 高效推理 |
| 数据集 | datasets (v3) | 管理和加载评测数据集 |
| 配置管理 | OmegaConf | 结构化任务/模型配置 |
| 指标计算 | lm_eval 内置指标 + 自定义 | 支持 acc、f1、perplexity 等 |
| 输出存储 | 本地/S3/HuggingFace/W&B | 灵活的结果持久化方案 |
| API 模型 | LiteLLM | 通过统一接口调用 GPT-4 等 API 裁判模型 |
目录结构（oe_eval/ 下）：
支持的评测套件（task_suites.py 内置）：
亮点设计：
OLMES 的使用体验完全是面向 AI 研究者和工程师的。没有任何 Web UI，一切操作通过命令行完成。
基本用法：评测单个模型在单个任务上的表现
olmes \
--model allenai/OLMo-2-0425-1B \
--task arc_challenge::olmes \
--output-dir workspace
同时跑多个任务（支持任务别名和组合）
olmes \
--model allenai/OLMo-2-0425-1B \
--task core_9mcqa::olmes mmlu:mc::olmes \
--output-dir workspace
调试模式：预览 prompt，不实际运行评测
olmes --task arc_challenge:mc::olmes --inspect
安装：
git clone https://github.com/allenai/olmes.git
cd olmes
uv sync # GPU 支持需 uv sync --group gpu
# 或
pip install -e .
pip install -e ".[gpu]" # 含 vLLM 支持
硬件要求：评测大模型需要 NVIDIA GPU，vLLM 推理需要 CUDA 支持。纯 CPU 环境下只能运行小模型验证流程。Python 版本要求 3.10–3.12。
依赖复杂性：pyproject.toml 显示直接依赖超过 30 个包（含 ai2-olmo-core、alpaca_eval、pytrec_eval 等重型依赖），安装过程较慢，首次 uv sync 约需 5–10 分钟。
OLMES 并非没有批评声音。最主要的争议在于两点：
其一，5-shot 的选择是否最优？ 论文中提到超过 5-shot 后收益递减，但实际测试中某些任务（如 BoolQ）在更多 shot 下仍有提升。标准是一种保守的折中选择，而非每个任务的最优解。
其二，归一化方法的局限性。对于答案选项长度不一致的情况（如「A. 长答案」vs「B. 短答案」），概率归一化并不能完全消除偏差。论文作者也承认这是 OLMES 的已知局限。
其三，从项目定位看，OLMES 是一个评测执行标准，而非评测分析工具。它告诉你「怎么跑」，但不直接提供结果的可视化分析或趋势对比。用户通常需要自己用 W&B 或写脚本整合结果。
此外，项目本身没有 Docker 支持，在全新机器上部署需要手动处理所有 Python 依赖，对不熟悉深度学习环境的用户来说门槛较高。
OLMES 的影响力已经超出了 Ai2 内部。它被以下关键项目采纳：
从增长曲线看，项目自 2024 年 11 月创建以来保持了稳定更新（最后 push 时间 2026-03-24），说明 Ai2 仍在积极维护并将其作为内部标准工具。
如果把大模型评测比作测量长度，那么 OLMES 就像是发明了一把标准尺子。它不告诉你哪个模型「更好」，而是确保当你用这把尺子测量时，得到的数字是可信的、可复现的。
对于 AI 研究者而言，OLMES 是对比模型性能的基准线——只要你用 OLMES 标准跑评测，你的分数就可以直接与 OLMo/TULU 3 等官方结果对比。对于 开源社区，它降低了评测的随意性，让不同论文之间的模型对比更有意义。对于 模型开发者，它提供了可配置的评测框架，在开发迭代过程中持续追踪模型能力变化。
当然，这把「尺子」也有它的适用范围：它最适合 多选题类基准任务（MCQA），对于开放式生成、Agent 评测等更复杂的评测场景，还需要其他工具补充。
项目基本信息：