olmo-eval：面向模型开发循环的评估工作台

💻 代码：

https://github.com/allenai/olmo-eval

在构建大语言模型的过程中，你会围绕许多干预措施反复对其进行评估。对其数据、架构或超参数所做的每一次调整——以及每一次规模上的提升——都会让你回到同一个循环中：添加或重新配置基准测试，在每个新的模型 checkpoint 上重新运行它们，记录结果，并检查在小规模实验中奏效的做法在完整训练运行中是否依然成立。

大多数评估工具并非为此而设计——它们要么是为了在已完成的模型上运行既定的基准测试，要么是在沙箱中让模型处理多步骤、使用工具的问题。它们无法跟上不断变化的模型，也无法反映模型在特定真实世界条件下可能表现出的行为。

我们为应对这一评估挑战而开展的上一个项目是 OLMES，即开放语言模型评估标准（Open Language Model Evaluation Standard）。它于 2024 年推出，旨在让大语言模型的基准测试分数在不同版本之间更容易比较。相同的模型在相同的基准测试上却以不同的方式被评分——诸如提示词格式和任务表述等方面往往因论文而异——因此关于哪些模型表现最好的说法往往无法复现。OLMES 将基准测试的选择固定在一个开放、有文档记录的标准中，它成为了评估我们从 Olmo 到 Tulu 的开放模型的基础。

但模型的最终得分只是评估过程的一部分——这正是我们发布 olmo-eval 的原因，这是一个新的工作台，它建立在 OLMES 之上，并将其扩展到 LLM 开发的其余环节。与 OLMES 相比，olmo-eval 减少了实现新评估所需的工作量，在定义评估运行的位置和方式上提供了更大的灵活性，并且更容易将各个组件组合成更大的工作流。智能体和多轮评估作为一等用例得到支持，更强大的分析工具可帮助你判断某项干预是否真正优于基线，还是差异不过是噪声。

olmo-eval 与现有工具的区别

性能上 2.4pp 的变化足以让你做出判断吗？

olmo-eval 在某些方面与 Harbor 有重叠，后者是一个用于在容器化、沙箱化环境中评估 AI 智能体的开放框架。但这两个工具的范围不同。Harbor 主要面向运行和发布智能体基准测试；而 olmo-eval 是为模型开发的日常工作而构建的——添加和配置基准测试、跨检查点运行它们，并逐条提示词地分析结果，而不是将其作为一个总体得分来看待。

Harbor 以完全相同的方式运行一切——在密封、可复现的容器内。由于容器可能消耗大量资源，olmo-eval 让你改为选择每个基准测试的运行方式。一个只需要模型回答问题的基准测试可以直接运行，这样更快也更便宜；一个需要锁定环境的基准测试——比如运行模型所写代码的测试——则采用隔离的容器设置。轻量路径是默认选项，olmo-eval 只有在基准测试确实需要时才会选择重量级设置。

Harbor 添加基准测试的流程是为那些你计划公开发布和分享的评测而构建的，随之而来的是额外的验证步骤。olmo-eval 则是为在开发过程中快速推进而构建的，你添加基准测试的方式取决于该基准测试需要什么：基础评测只需一段简短的定义，并可选让模型在完成基准测试的过程中使用工具；或者——对于已经拥有自己的代码和流程的基准测试——一个轻量封装，让 olmo-eval 能够按原样运行它，并以相同的格式将结果与其他基准测试分数一并报告。

Harbor 和 olmo-eval 都将基准测试与运行时策略（即如何运行模型以生成其答案）分离，这样你可以更改其中一个而无需重写另一个，但 olmo-eval 的设计追求更高的模块化程度。在 olmo-eval 中，被评测的模型、它可以使用的工具、容器化环境，以及任何辅助模型——比如作为评判者的 LLM——都是可替换的组件。你可以在多个测试框架中复用同一个工具，或者将评分模型接入某一个基准测试而不干扰其他基准测试，并且无需费很大力气就能调整小的设置（例如提示词的确切措辞）。

Harbor 会为每个模型报告一个总体得分。olmo-eval 也会报告这些得分，每个得分都附带一个标准误和一个最小可检测效应（即能够可靠地与噪声区分开来的最小差异）。但更有用的视角是将相同的问题在两个模型检查点上逐一排列并逐一比较，同时保持其他一切不变。这有助于你判断总体平均值上的微小变化究竟意味着真正的改进，还是仅仅是噪声。

如果你正在寻找……	olmo-eval 提供
编写一个多示例基准测试	带有 `DataSource`、指标和评分接口的任务子类
用其自带的运行器封装一个现有的智能体式基准测试	`ExternalEval` 或 `SandboxedExternalEval`；该基准测试保留其自身的循环和评分，结果会落入 olmo-eval 的 schema 中
在固定基准测试下替换运行时	`--harness` 和 harness 预设；harness 承载提供方、工具、脚手架、沙箱以及辅助提供方
并行容器执行	面向并行执行器的沙箱实例，支持基于能力的路由，以及 Docker 或 Modal 模式
可在不同任务与运行框架之间复用的工具定义	`@tool` 装饰器，支持可选的全局注册表
多轮执行循环	脚手架，例如 `openai_agents`，按运行框架选择，而非固化在任务定义中

一套集成的评估栈

olmo-eval 由四个组件构成，它们各自独立可用，但被设计为协同工作，以收紧 LLM 开发的实验循环：

一种将基准逻辑与运行时策略解耦的任务/套件/运行框架抽象。在 olmo-eval 中，任务就是你定义基准的方式——即被评估的内容。套件将任务分组为你一起运行的一组任务，而运行框架控制每个任务的运行方式。这种分离让同一个任务既能作为标准基线运行，也能配合工具和脚手架运行，而不改变它所衡量的内容。
一个沙箱与能力路由层，其中包括一个异步沙箱规划器。它支持那些模型响应取决于其使用工具所采取行动的评估，例如编写并运行代码或浏览网页。其要点在于评估模型真实的工具使用：当基准需要工具时，olmo-eval 会运行这些工具并将结果反馈给模型。
一种规范化的实验模式，以相同的结构化格式记录每一次运行、其配置以及结果。这使得将相关实验分组、随时间比较检查点，以及避免在长期模型开发工作流中经常累积的不一致成为可能。
一个用于成对模型比较的结果查看器：将两个模型或检查点逐题并排对比，能够揭示总体平均值可能掩盖的微小但真实的性能变化。

在大多数模型评估设置中，添加一个基准测试是一项规模不小的集成工程。而在 olmo-eval 中，所需要的只是一个任务——任务定义了基准数据集、评估请求如何构建，以及模型答案如何评分（全部代码用 Python 编写）：


from olmo_eval.common.formatters import ChatFormatter
from olmo_eval.common.metrics import AccuracyMetric
from olmo_eval.common.scorers import ExactMatchScorer
from olmo_eval.common.types import Instance, SamplingParams
from olmo_eval.data import DataLoader, DataSource
from olmo_eval.evals.tasks.common import Task, register, register_variant

@register("internal_freshqa")
class InternalFreshQA(Task):
    data_source = DataSource(path="s3://evals/internal/freshqa.jsonl", split="test")
    formatter = ChatFormatter()
    sampling_params = SamplingParams(temperature=0.0)
    metrics = (AccuracyMetric(scorer=ExactMatchScorer),)

    @property
    def instances(self):
        loader = DataLoader()
        for idx, doc in enumerate(loader.load(self.config.get_data_source())):
            yield Instance(
                question=doc["question"],
                gold_answer=doc["answer"],
                metadata={"id": doc.get("id", f"freshqa_{idx}")},
            )

变体表达评估策略的变化，而无需复制基准测试：


register_variant("internal_freshqa", "3shot", num_fewshot=3, fewshot_seed=1234)
register_variant("internal_freshqa", "zero", num_fewshot=0)

套件将基准测试分组为可一起运行的标准集合：


from olmo_eval.evals.suites import Suite, register

register(Suite(
    name="base_qa_few_shot",
    tasks=(
"sciq:mc:3shot",
"arc_challenge:mc:3shot",
"internal_freshqa:mc:3shot",
    ),
))

而且由于运行时策略存在于测试框架中而非任务定义中，同一个基准测试可以轻松地在不同的执行条件下重新运行，而不是依赖于生成的轨迹点是否仅仅看起来合理。


# Baseline
olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero

# Same task, same scoring, search/tool runtime enabled
olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero --harness search_agent

可复现的评估，开放呈现

当评估是持续模型开发的一部分、而非一次性运行时，就该使用 olmo-eval——当你需要在可复现的条件下跨多个 checkpoint 反复运行同一组基准测试，并在聚合层面和单题层面比较各种干预措施时。

如果你反复要问的问题是"这个 checkpoint 与上一个有何不同，它究竟在哪里改进或退步了？"，那正是 olmo-eval 为之打造的工作流。

可复现的评估应当与模型的构建方式保持同步——而不仅仅是在模型完成后如何给它打分。olmo-eval 将 OLMES 标准带入活跃的模型开发过程，我们将其公开发布，以便社区能够在此基础上继续构建。