Die Tooling-Landschaft

Vorab eine Offenlegung: Dieses Kapitel stellt keine Rangliste auf. Das ist eine bewusste Abweichung von der Norm.

Suchen Sie nach „beste LLM-Eval-Tools“. Die obersten Treffer stammen auffallend oft von den verglichenen Tools selbst. Ein Anbieter setzt sich in seinem eigenen Vergleich auf Platz eins. Sein eigenes Open-Source-Framework nennt er das stärkste am Markt. Ein Wettbewerber veröffentlicht eine Seite mit dem Titel „Alternativen zu <diesem Anbieter>“. Diese Seiten sind nicht unehrlich. Die Aussagen darin sind meist vertretbar. Aber es sind Marketingdokumente. Und sie sind das wichtigste veröffentlichte Material zu diesem Thema.

Also: Beschreibungen, Kategorien und die Fragen, die sich zu stellen lohnen. Kein Ranking, keine Empfehlung, keine Punktetabelle.

Die Kategorien sind nützlicher als die Namen

Die meiste Verwirrung über Eval-Tools hat einen Grund: Man vergleicht Tools, die verschiedene Aufgaben erfüllen. Es gibt vier Kategorien. Sie überlappen nur an den Rändern.

1. Benchmark-Harnesses (Ebene A)

Diese Werkzeuge führen standardisierte akademische Benchmarks gegen Modelle aus. Für die Bewertung Ihrer Anwendung sind sie nicht gedacht.

EleutherAI lm-evaluation-harness ist die Referenzimplementierung. Brauchen Sie einen MMLU-Wert, der mit einem veröffentlichten MMLU-Wert vergleichbar ist? Dann ist das der Weg, auf dem der veröffentlichte Wert entstand. Das Werkzeug deckt viele Aufgaben ab. Für die Bewertung offener Modelle ist es der De-facto-Standard.

HuggingFace lighteval ist eine leichtere Pipeline auf denselben Grundlagen. Sie ist an kein Backend gebunden. Verbreitet ist sie bei Arbeiten für Leaderboards.

Greifen Sie zu diesen Werkzeugen, wenn Sie ein Basismodell bewerten, ein Modell veröffentlichen oder einen publizierten Wert reproduzieren. Nicht, wenn Sie ein Produkt bewerten.

2. Anwendungs-Eval-Frameworks (Ebene B)

Bibliotheken, in denen Sie Ihre eigenen Evals schreiben. Hier gehören die meisten Produktteams hin.

Inspect (UK AI Security Institute) zerlegt eine Evaluation in dataset → Task → Solver → Scorer. Es unterstützt mehrstufige Dialoge und Agenten-Abläufe. Es führt Code in einer Sandbox aus, also in einer abgeschotteten Umgebung. Docker ist eingebaut, für Kubernetes und Proxmox gibt es Adapter. Dazu kommen ein Log-Viewer für VS Code und ein Web-Viewer. Die Modellschicht deckt die großen APIs ab, plus lokal vLLM, Ollama und llama.cpp. Inspect Evals liefert einen großen Katalog fertiger Evaluationen mit. Inspect ist der De-facto-Standard für Sicherheitsarbeit an Frontier-Modellen. KI-Sicherheitsinstitute und Labore setzen es ein. Das sieht man dem Entwurf an: stark bei Sandboxing, Agenten und Reproduzierbarkeit.

promptfoo ist ein CLI plus Bibliothek, konfiguriert über YAML. Es dient dem Vergleich von Prompts und Modellen sowie dem Red-Teaming. Das erste Ergebnis kommt schnell. Der Vergleich mehrerer Modelle ist stark. Die eingebaute Angriffssuite ist umfangreich: Berichtet werden über 500 Vektoren in der Open-Source-Fassung.

DeepEval ist ein Framework im Stil von pytest. Seine Metriken decken RAG, Agenten und Mehrfachdialoge breit ab. Es stammt von Confident AI. Dieselbe Firma verkauft auch die gehostete Plattform.

RAGAS begann als Bibliothek für RAG-Metriken. Der größte Teil des Vokabulars in dem RAG-Kapitel stammt von dort. Bis 2026 kamen Metriken für Agenten-Abläufe, Text-zu-SQL und multimodale Aufgaben hinzu.

Befund: OpenAI Evals wird eingestellt. Die Abkündigung erfolgte am 3. Juni 2026. Bestehende Evals werden am 31. Oktober 2026 schreibgeschützt. Dashboard und API werden am 30. November 2026 abgeschaltet. Agent Builder und die Prompts-API folgen demselben Zeitplan. OpenAIs eigener Migrationsleitfaden verweist auf promptfoo.

Das ist eine nützliche Aktualitätsprüfung für jeden Leitfaden, den Sie lesen. Empfiehlt ein Text OpenAI Evals noch als laufendes Produkt? Dann wurde er vor Juni 2026 geschrieben oder seitdem nicht gepflegt.

Quelle: OpenAI Deprecations

3. Observability-Plattformen mit Evaluation (Ebenen B und C)

Diese Plattformen sammeln zuerst Traces. Die Evaluation setzt darauf auf. Lautet Ihr Hauptbedarf „sehen, was in Produktion passiert ist, und eine Stichprobe davon bewerten“? Dann passt diese Kategorie besser als ein Framework.

• Langfuse: Open-Source-Tracing mit Evaluation. Es lässt sich selbst hosten. Für viele Teams mit Vorgaben zum Datenstandort entscheidet das die Wahl.
• Arize Phoenix: Open-Source-Tracing und -Evaluation. Das Team dahinter kommt aus der ML-Observability und kennt das Feld tief.
• LangSmith: die engste Integration mit LangChain und LangGraph. Stark, wenn Sie ohnehin in diesem Ökosystem sind. Weniger überzeugend, wenn nicht.
• Braintrust: Plattform mit Schwerpunkt Evaluation, mit Prompt-Playground und CI-Anbindung.
• W&B Weave: Evaluation und Tracing innerhalb von Weights & Biases. Naheliegend, wo das Experiment-Tracking schon dort läuft.
• Evidently: aus der Tradition des ML-Monitorings. Überwacht Drift und Datenqualität, ergänzt um LLM-Evaluation.
• MLflow: allgemeines Experiment-Tracking, um LLM-Evaluation ergänzt. Wo es bereits läuft, ist es oft der Weg des geringsten Widerstands.

Die Kategorie wächst zusammen: Alle bauen die Funktionen aller anderen nach. Der Unterschied liegt immer seltener in den Fähigkeiten. Er liegt im Hosting-Modell, im Preis und in der Frage, in welchem Ökosystem Sie ohnehin sind.

4. Selbstgebaut

Unter ernstzunehmenden Teams weiterhin sehr verbreitet. Und kein Zeichen von Unreife.

Eine pytest-Suite, ein Datensatz im Repository, ein Grader-Modul und Ergebnisse in einer Tabelle: Das ist ein vollständiges und vertretbares Eval-System. Teams wählen es aus zwei Gründen. Erstens: Die Eval-Logik ist das Domänenwissen. Das Interessante sind Ihre Kriterien, nicht der Runner. Zweitens: Frameworks zwingen ein Metrikvokabular auf, das vielleicht nicht passt.

Was Teams am häufigsten selbst bauen, selbst wenn sie eine Plattform nutzen:

• Die Annotationsoberfläche. Fast alle bauen sie selbst. Ein maßgeschneiderter Viewer auf einem Bildschirm schlägt jedes generische Tool. Mit einem KI-Coding-Assistenten ist er an einem Nachmittag fertig.
• Domänenspezifische Grader. Keine Bibliothek kennt Ihre Geschäftsregeln.
• Den Judge-Prompt. Fertige Judge-Metriken sind genau das, wovor das Judge-Kapitel am stärksten warnt.
• Trace-Auswertung und Stichprobenziehung. Ihre Schichtungslogik gehört Ihnen.

Wie man wählt, ohne zu ranken

Diese Fragen unterscheiden wirklich. Sie sind grob danach geordnet, wie stark sie das Feld eingrenzen:

Wo dürfen Ihre Daten liegen? Muss die Lösung selbst gehostet oder in der EU gehostet sein? Dann scheidet der größte Teil der Kategorie sofort aus. Diese Vorgabe ist nicht verhandelbar, wo sie gilt. Stellen Sie diese Frage zuerst.

Brauchen Sie Tracing, Evaluation oder beides? Sie haben noch keine Observability in Produktion? Dann ist eine Plattform mit Traces plus Evaluation wirtschaftlicher als ein Framework plus ein eigenes Tracing-Projekt.

In welcher Sprache ist Ihr Stack? Dieses Ökosystem ist überwiegend auf Python ausgelegt. Ein TypeScript-Team hat tatsächlich weniger Optionen. Es sollte prüfen statt annehmen.

Brauchen Sie Ausführung in einer Sandbox? Coding-Agenten und Computer-Use-Agenten brauchen isolierte Umgebungen. Inspect bringt das mit. Die meisten Plattformen nicht.

Wer schreibt die Evals? Labeln Fachexperten und setzen Entwickler um? Dann gewichten Sie die Bedienbarkeit der Annotation hoch. Machen Entwickler beides? Dann reicht vielleicht eine Bibliothek im Repository.

Was kostet der Ausstieg? Datensätze und Ergebnisse in einem offenen Format, das Sie exportieren können, sind mehr wert als jede einzelne Funktion. Denn dieses Ökosystem ist jung. Sie werden Ihre Meinung ändern.

Eine Anmerkung zu den Metrikbibliotheken

Jedes Framework liefert fertige Metriken mit: Faithfulness, Answer Relevancy, Correctness, Halluzination, Toxizität. Sie sind der schnellste Weg zu Zahlen auf einem Dashboard.

Behandeln Sie sie als Anfangsvokabular, nicht als Messung. Eine fertige Metrik enthält die Definition der Eigenschaft von jemand anderem. Sie wurde auf die Daten von jemand anderem abgestimmt. Gegen Ihre Labels wurde sie nicht validiert. Und nicht validierte Judge-Metriken haben ein unbekanntes Vorzeichen.

Fertige Metriken sind wirklich nützlich, um zu erkunden und um die erste Woche zu überstehen. Die Alignment-Messung ersetzen sie nicht. Aber weil sie fertig vorliegen, sind sie bequem. Und genau diese Bequemlichkeit bringt Teams dazu, die Messung zu überspringen.

Häufiger Fehler: Zuerst die Plattform wählen. Die Tool-Entscheidung kommt erst, wenn Sie wissen, was Sie messen. Und was Sie messen, kommt aus der Fehleranalyse. Teams, die zuerst eine Plattform wählen, verwenden am Ende deren Standardmetriken. Denn die sind schon verdrahtet. So kommt es, dass ein Team Faithfulness berichtet, obwohl das Problem des Produkts der Retrieval-Recall war.