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

来源：https://huggingface.co/blog/allenai/olmo-eval 返回文章列表 (https://huggingface.co/blog)

Tyler Murray 的头像 (https://huggingface.co/undfined)

Kyle Wiggers 的头像 (https://huggingface.co/Ai2Comms)

• olmo-eval 与现有工具的不同之处 (https://huggingface.co/blog/allenai/olmo-eval#how-olmo-eval-differs-from-existing-tools)
• 集成评估堆栈 (https://huggingface.co/blog/allenai/olmo-eval#an-integrated-evaluation-stack)
• 开源可复现评估 (https://huggingface.co/blog/allenai/olmo-eval#reproducible-evaluation-made-open)

💻 代码：https://github.com/allenai/olmo-eval

Ai2 Olmo-Eval 图形开发 v3 (https://cdn-uploads.huggingface.co/production/uploads/638e39b249de7ae552d977b5/LrVpULz4nL1G-aQ4lGdSd.png)

在构建大型语言模型的过程中，你需要反复评估模型，经历无数次干预。每一次对数据、架构或超参数的调整——以及每向更高规模迈出的一步——都会让你回到同一个循环：添加或重新配置基准测试，在每个新的模型检查点上重新运行它们，记录结果，并检查某个在小实验中有效的方法是否在全量训练中仍然成立。

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

我们上一个解决评估挑战的项目是 OLMES (https://github.com/allenai/olmes)，即开放语言模型评估标准。该项目于 2024 年推出，旨在让不同版本间的 LLM 基准分数更易于比较。当时，相同的模型在相同的基准测试上以不同的方式评分——提示格式和任务制定等细节常因论文而异——因此关于哪个模型表现最好的说法往往无法复现。OLMES 将基准测试的选择固定在一个开放、有文档记录的标准中，并成为我们评估从 Olmo 到 Tulu 等开放模型的基础。

但模型的最终分数只是评估过程的一部分——因此我们发布了 olmo-eval (https://github.com/allenai/olmo-eval)，这是一个新的工作台，它建立在 OLMES 之上，并将其扩展到 LLM 开发的其余环节。与 OLMES 相比，olmo-eval 减少了实现新评估的工作量，在定义运行位置和方式上提供了更大的灵活性，并且更容易将各个组件组合成更大的工作流。代理式和多轮评估作为首要用例得到支持，更强的分析工具帮助你判断某个干预是否真正改进了基线，或者差异只是噪音。

https://huggingface.co/blog/allenai/olmo-eval#how-olmo-eval-differs-from-existing-toolsolmo-eval 与现有工具的不同之处

olmo-eval 博客 Kyle 草稿 - Google 文档-图片-1 (1) (https://cdn-uploads.huggingface.co/production/uploads/638e39b249de7ae552d977b5/Um1iTvUD-lxxWYBvsNiOx.png)

2.4 个百分点的性能变化足以做出判断吗？

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）都是可替换的组件。你可以在多个 harness 中重用工具，或将评分模型插入一个基准测试而不影响其他测试，并且可以轻松调整小设置（例如提示的确切措辞），而无需大量工作。

Harbor 为每个模型报告一个整体分数。olmo-eval 也报告这些分数，每个分数都带有标准误差和最小可检测效应（能可靠地与噪音区分的最小差异）。但更有用的视图是将相同的问题在两个模型检查点上对齐，并在所有其他条件不变的情况下逐个比较。这有助于你判断整体平均值的一个微小变化是表明真正的改进还是仅是噪音。

https://huggingface.co/blog/allenai/olmo-eval#an-integrated-evaluation-stack集成评估堆栈

olmo-eval 由四个组件组成，它们各自有用，但设计上协同工作，以收紧实验性 LLM 开发循环：

1. 一个任务/套件/harness 抽象层，将基准逻辑与运行时策略解耦。 任务是你定义基准测试的方式——评估什么。套件将任务分组为一组你一起运行的测试，harness 控制每个任务如何运行。这种分离使得同一任务可以作为标准基线运行，也可以附带工具和 scaffolding 运行，而无需改变它衡量的内容。
2. 一个沙盒与能力路由层，包含异步沙盒规划器。 这支持模型的响应依赖于它使用工具所采取的行动的评估，例如编写和运行代码或浏览网页。重点是评估模型真实的工具使用：当基准测试需要工具时，olmo-eval 运行这些工具并将结果反馈给模型。
3. 一个标准化的实验 schema，以相同的结构化格式记录每次运行、其配置和结果。 这使得能够将相关实验分组、随时间比较检查点，并避免长周期模型开发工作流中常累积的不一致性。
4. 一个用于成对模型比较的结果查看器： 将两个模型或检查点逐问题对齐，能够揭示整体平均值可能掩盖的微小但真实的性能变化。

在大多数模型评估设置中，添加一个基准测试是一项相当庞大的集成工作。在 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",
    ),
))

由于运行时策略存在于 harness 而非任务定义中，因此可以轻松地在不同执行方式下重新运行同一基准测试，而不是依赖生成的某点轨迹是否看起来合理。

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

# 同一任务，相同评分，搜索/工具运行时启用
olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero --harness search_agent

https://huggingface.co/blog/allenai/olmo-eval#reproducible-evaluation-made-open开源可复现评估

当评估是持续模型开发的一部分（而非一次性运行）时——当你需要在可复现条件下跨检查点反复运行相同基准测试，并在总体和逐问题级别比较干预效果时——请使用 olmo-eval (https://github.com/allenai/olmo-eval)。

如果你反复遇到的问题是“这个检查点与上一个有何不同，它具体在哪些地方改进或退步了？”，那么这正是 olmo-eval 所针对的工作流。

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