Neue Plattform OLMo-eval für die kontinuierliche Entwicklung und Evaluierung von Sprachmodellen

Die Entwicklung großer Sprachmodelle (LLMs) ist ein hochiterativer Prozess, der eine kontinuierliche Evaluierung quer durch zahlreiche Anpassungen an Daten, Architekturen oder Skalierungen erfordert. Jede Modifikation – sei es an den Trainingsdaten, der Modellarchitektur oder den Hyperparametern – sowie jede Skalierungsebene führt Entwickler zurück in einen Kreislauf aus dem Hinzufügen oder Neukonfigurieren von Benchmarks, deren erneuter Ausführung an jedem neuen Modell-Checkpoint, der Erfassung der Ergebnisse und der Überprüfung, ob eine Verbesserung in einem kleinen Experiment auch im vollständigen Trainingslauf Bestand hat.

Die meisten etablierten Evaluierungstools sind für diese Art der iterativen Entwicklung nicht primär ausgelegt. Sie dienen entweder der Ausführung von Standard-Benchmarks an fertigen Modellen oder der Durchführung von Modellen durch mehrstufige, werkzeugbasierte Probleme in einer Sandbox-Umgebung. Diese Tools sind oft nicht in der Lage, mit einem sich ständig ändernden Modell Schritt zu halten, noch spiegeln sie wider, wie sich ein Modell unter spezifischen realen Bedingungen verhalten könnte.

Die Evolution der Evaluierung: Von OLMES zu OLMo-eval

Eine frühere Initiative zur Adressierung dieser Herausforderung war OLMES (Open Language Model Evaluation Standard), das im Jahr 2024 eingeführt wurde. OLMES zielte darauf ab, Benchmark-Ergebnisse von LLMs vergleichbarer zu machen. Da Modelle oft auf die gleiche Weise, aber mit unterschiedlichen Prompt-Formaten oder Aufgabenstellungen bewertet wurden, waren Behauptungen über die Leistungsfähigkeit von Modellen schwer reproduzierbar. OLMES standardisierte diese Benchmark-Auswahlen in einem offen dokumentierten Format und wurde zur Grundlage für die Evaluierung von Modellen wie OLMo und Tulu.

Allerdings stellt das Endergebnis eines Modells nur einen Teil des Evaluierungsprozesses dar. Aus diesem Grund wurde OLMo-eval entwickelt, eine neue Arbeitsumgebung, die auf OLMES aufbaut und dessen Funktionen auf den gesamten LLM-Entwicklungsprozess ausweitet. Im Vergleich zu OLMES reduziert OLMo-eval den Aufwand für die Implementierung neuer Evaluierungen, bietet mehr Flexibilität bei der Definition, wo und wie diese ablaufen, und erleichtert die Komposition einzelner Komponenten zu größeren Workflows. Agenten- und Multi-Turn-Evaluierungen werden als erstklassiger Anwendungsfall unterstützt, und verbesserte Analysetools sollen dabei helfen zu beurteilen, ob eine Intervention tatsächlich eine Verbesserung gegenüber der Basislinie darstellt oder ob der Unterschied auf Rauschen zurückzuführen ist.

Unterschiede zu bestehenden Tools

OLMo-eval weist Überschneidungen mit Frameworks wie Harbor auf, das ebenfalls die Evaluierung von KI-Agenten in containerisierten Sandbox-Umgebungen ermöglicht. Die beiden Tools unterscheiden sich jedoch in ihrem Fokus. Während Harbor hauptsächlich auf die Ausführung und Veröffentlichung von Agenten-Benchmarks abzielt, wurde OLMo-eval für die tägliche Arbeit der Modellentwicklung konzipiert. Dies beinhaltet das Hinzufügen und Konfigurieren von Benchmarks, deren Ausführung über verschiedene Checkpoints hinweg und die Analyse der Ergebnisse Frage für Frage, anstatt nur eine einzige Gesamtbewertung zu erhalten.

Im Gegensatz zu Harbor, das alle Evaluierungen in isolierten, reproduzierbaren Containern durchführt, ermöglicht OLMo-eval die Auswahl der Ausführungsmethode für jede Benchmark. Ein Benchmark, der lediglich Fragen beantworten muss, kann direkt ausgeführt werden, was schneller und kostengünstiger ist. Ein Benchmark, der eine isolierte Umgebung erfordert – beispielsweise zur Ausführung von vom Modell geschriebenem Code – erhält eine separate Container-Einrichtung. Der leichte Ausführungspfad ist der Standard, und OLMo-eval greift nur dann auf die ressourcenintensivere Einrichtung zurück, wenn eine Benchmark dies tatsächlich erfordert.

Der Prozess zum Hinzufügen einer Benchmark in Harbor ist auf Evaluierungen ausgelegt, die veröffentlicht und öffentlich geteilt werden sollen, was zusätzliche Verifizierungsschritte beinhaltet. OLMo-eval ist hingegen für schnelle Iterationen während der Entwicklung konzipiert. Das Hinzufügen einer Benchmark hängt von deren Anforderungen ab: Eine kurze Definition für eine Basisevaluierung mit Optionen zur Nutzung von Tools durch das Modell oder – für eine Benchmark mit eigenem Code und Verfahren – ein dünner Wrapper, der es OLMo-eval ermöglicht, diese wie vorgesehen auszuführen und die Ergebnisse im gleichen Format wie andere Benchmarks zu berichten.

Sowohl Harbor als auch OLMo-eval trennen Benchmarks von der Laufzeitrichtlinie (wie das Modell ausgeführt wird, um seine Antworten zu generieren), sodass Änderungen an einem Teil vorgenommen werden können, ohne den anderen neu schreiben zu müssen. OLMo-eval ist jedoch auf eine größere Modularität ausgelegt. In OLMo-eval sind das zu evaluierende Modell, die verwendbaren Tools, die containerisierte Umgebung und unterstützende Modelle (z.B. ein LLM als Richter) allesamt austauschbare Komponenten. Tools können über mehrere Harnesses hinweg wiederverwendet oder ein Bewertungsmodell in einen Benchmark integriert werden, ohne andere zu beeinträchtigen. Kleine Einstellungen, wie die genaue Formulierung des Prompts, können ohne großen Aufwand angepasst werden.

Harbor liefert eine Gesamtbewertung für jedes Modell. OLMo-eval bietet ebenfalls solche Bewertungen, jeweils mit einem Standardfehler und einem minimal erkennbaren Effekt (der kleinste Unterschied, der zuverlässig von Rauschen unterschieden werden kann). Die nützlichere Ansicht gleicht jedoch dieselben Fragen über zwei Modell-Checkpoints hinweg ab und vergleicht sie einzeln, wobei alle anderen Faktoren konstant gehalten werden. Dies hilft zu erkennen, ob eine geringfügige Änderung in einem Gesamtdurchschnitt eine tatsächliche Verbesserung oder lediglich Rauschen darstellt.

Die folgende Tabelle fasst die Kernfunktionen von OLMo-eval zusammen:

Ein integrierter Evaluierungs-Stack

OLMo-eval setzt sich aus vier Komponenten zusammen, die einzeln nützlich sind, aber darauf ausgelegt wurden, gemeinsam die experimentelle LLM-Entwicklungsschleife zu optimieren:

1. Eine Task/Suite/Harness-Abstraktion, die Benchmark-Logik von der Laufzeitrichtlinie entkoppelt. Eine "Task" definiert in OLMo-eval einen Benchmark – das, was evaluiert wird. Eine "Suite" gruppiert Tasks zu einem Satz, der gemeinsam ausgeführt wird, und ein "Harness" steuert, wie jede Task ausgeführt wird. Diese Trennung ermöglicht es, dieselbe Task als Standard-Baseline oder mit Tools und Scaffolding auszuführen, ohne die Messgröße zu verändern.
2. Eine Sandbox- und Capability-Routing-Schicht, einschließlich eines asynchronen Sandbox-Planers. Dies unterstützt Evaluierungen, bei denen die Antwort eines Modells von den Aktionen abhängt, die es mit Tools ausführt, wie z.B. das Schreiben und Ausführen von Code oder das Surfen im Web. Ziel ist es, die tatsächliche Tool-Nutzung des Modells zu evaluieren: Wenn ein Benchmark Tools erfordert, führt OLMo-eval diese Tools aus und speist die Ergebnisse zurück an das Modell.
3. Ein normiertes Experimentalschema, das jeden Lauf, seine Konfiguration und die Ergebnisse im selben strukturierten Format aufzeichnet. Dies ermöglicht es, verwandte Experimente zu gruppieren, Checkpoints über die Zeit zu vergleichen und die Inkonsistenzen zu vermeiden, die sich oft in langwierigen Modellentwicklungsworkflows ansammeln.
4. Ein Ergebnisbetrachter für den paarweisen Modellvergleich: Das Gegenüberstellen von zwei Modellen oder Checkpoints Frage für Frage zeigt kleine, aber reale Leistungsänderungen auf, die ein Gesamtdurchschnitt verbergen kann.

In den meisten Modell-Evaluierungssystemen ist das Hinzufügen eines Benchmarks ein umfangreiches Integrationsprojekt. In OLMo-eval ist lediglich eine "Task" erforderlich – Tasks definieren den Benchmark-Datensatz, wie Evaluierungsanfragen erstellt werden und wie Modellantworten bewertet werden (alles in Python-Code):

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}")},
            )

Varianten ermöglichen Änderungen in der Evaluierungsrichtlinie, ohne den Benchmark zu duplizieren:

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

Suites gruppieren Benchmarks zu Standardsätzen, die gemeinsam ausgeführt werden:

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",
    ),
))

Da die Laufzeitrichtlinie im Harness und nicht in der Aufgabendefinition verankert ist, kann derselbe Benchmark unter verschiedenen Ausführungsbedingungen leicht erneut ausgeführt werden, anstatt sich darauf zu verlassen, ob ein generierter Punkt nur plausibel erscheint.

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

# Gleiche Aufgabe, gleiche Bewertung, Suche/Tool-Laufzeit aktiviert
olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero --harness search_agent

Reproduzierbare Evaluierung offen zugänglich gemacht

OLMo-eval ist für Szenarien konzipiert, in denen die Evaluierung Teil einer kontinuierlichen Modellentwicklung ist und nicht eine einmalige Ausführung. Dies gilt, wenn Sie dieselben Benchmarks wiederholt über Checkpoints hinweg unter reproduzierbaren Bedingungen ausführen und Interventionen sowohl auf aggregierter als auch auf Fragen-Ebene vergleichen müssen.

Wenn Ihre wiederkehrende Frage lautet: "Wie unterscheidet sich dieser Checkpoint vom letzten, und wo genau hat er sich verbessert oder verschlechtert?", dann ist dies der Workflow, für den OLMo-eval entwickelt wurde.

Reproduzierbare Evaluierung sollte mit der Art und Weise Schritt halten, wie Modelle entwickelt werden – nicht nur, wie sie bewertet werden, sobald sie fertiggestellt sind. OLMo-eval führt den OLMES-Standard in die aktive Modellentwicklung ein und wird offen zugänglich gemacht, damit die Community darauf aufbauen kann.

Bibliographie

• Allen Institute for Artificial Intelligence. (2026, 12. Juni). OLMo-eval: An evaluation workbench for the model development loop. Hugging Face Blog.
• Allen Institute for Artificial Intelligence. (2026, 12. Juni). Latest research | Ai2. Allenai.org.
• Allen Institute for Artificial Intelligence. (2026, 12. Juni). Ai2's Post. LinkedIn.
• Allen Institute for Artificial Intelligence. (2024, 2. November). allenai/olmes. GitHub.
• Allen Institute for Artificial Intelligence. (2024, 28. Oktober). allenai/OLMo-in-loop-evals. GitHub.
• Allen Institute for Artificial Intelligence. (o. D.). ai2-olmo-eval. PyPI.
• Enterprise DNA. (2026, 1. Juni). OLMO-eval — Open Source · Directories by Enterprise DNA. EnterpriseDNA.co.