KI-Modelle evaluieren: Benchmarks und eigene Evals richtig nutzen

Was bedeutet KI-Evaluation?

Eine KI-Evaluation ist eine systematische Prüfung, ob ein Modell oder ein vollständiges KI-System definierte Anforderungen für einen bestimmten Einsatz erfüllt. Sie kann Qualität, Korrektheit, Robustheit, Sicherheit, Geschwindigkeit, Kosten, Datenschutz, Tool-Nutzung und Zuverlässigkeit untersuchen. Wichtig: Evaluation ist breiter als Benchmarking – ein öffentlicher Benchmark ist nur ein Teil des Bildes.

Diese Seite erstellt bewusst keine Rangliste. Sie soll erklären, wie man Rankings und Modelle selbst richtig bewertet. Denn ein Modell ist nicht „gut" oder „schlecht" im luftleeren Raum – es ist für bestimmte Aufgaben unter bestimmten Bedingungen mehr oder weniger geeignet.

Eval, Benchmark und Leaderboard

Drei Begriffe werden oft vermischt:

Ein eigenes Eval kann sehr spezifisch sein: „Ordnet das System deutsche Supportanfragen zuverlässig in unsere 14 internen Kategorien ein?" Dafür muss kein öffentlicher Benchmark existieren. Und ein Benchmark ist nicht dasselbe wie ein Leaderboard: Das eine ist das Testverfahren, das andere die Ergebnisdarstellung.

Modell-Eval vs. System-Eval

Eine reale Anwendung besteht selten nur aus einem Modell. Meist kommen Prompt, Systemanweisungen, RAG, Suche, Tools, Memory, Guardrails und Anwendungscode hinzu. Deshalb sind zwei Ebenen zu trennen:

Das Ziel muss vor der Metrik stehen

Keine Evaluation sollte mit „Welche Benchmarkzahl können wir messen?" beginnen, sondern mit „Was muss das System zuverlässig leisten?". Beispiel Supportklassifikation: Erfolg heißt vielleicht richtige Kategorie, wichtige Fälle nicht übersehen, deutsche Sprache, geringe Latenz und ein definierter Kostenrahmen. Erst danach wählt man passende Metriken.

Modellauswahl ist außerdem multikriteriell: Ein Modell kann bei Accuracy vorn liegen und für den eigenen Fall trotzdem schlechter sein. Weitere Kriterien sind Kosten, Latenz, Kontextgröße, Tool-Unterstützung, strukturierte Ausgaben, Datenschutz, lokaler Betrieb, Lizenz, Hardware, Sprache und Sicherheit. Eine einzelne „Gesamtnote" erzwingt man besser nicht.

Was Benchmarks messen – und was nicht

Ein Benchmark kann sehr Unterschiedliches prüfen: Wissensfragen, Reasoning, Mathematik, Coding, Instruction Following, Multimodalität, lange Kontexte, Sicherheit oder Tool-Nutzung. Ein guter Score bedeutet vor allem: Das Modell war unter den Bedingungen dieses Benchmarks erfolgreich – nicht automatisch, dass es „allgemein besser" ist.

Deshalb ist auch eine „KI-IQ"-Logik unangebracht: Ein Modell besitzt keinen sinnvoll belegten universellen „Intelligenzwert", nur weil es bestimmte Testfragen löst.

Was genau wurde getestet?

Zu jedem Benchmark oder Leaderboard gehören Bedingungen, die das Ergebnis stark verändern können. Sinnvolle Fragen:

• Welches Modell, welche genaue Version bzw. welcher API-Snapshot, welches Datum?
• Welcher Prompt – zero-shot, few-shot oder Chain-of-Thought?
• Waren Tools oder Webzugriff erlaubt?
• Welches Sampling, welche Temperatur, welches Output-Budget?
• Ein Versuch, mehrere Versuche oder best-of-n?
• Welches Bewertungsskript, welche Datenversion?

Modellnamen allein genügen nicht: Aktuelle Produkte können unter gleichem Namen verändert werden. Und schon das Promptformat (direkte Antwort vs. Chain-of-Thought vs. few-shot) kann Werte verschieben – Ergebnisse unterschiedlicher Verfahren sind daher nicht automatisch direkt vergleichbar.

pass@k, Tools und Open-Book

Bei nichtdeterministischer Generierung können wiederholte Läufe unterschiedliche Ergebnisse liefern – Parameter dokumentieren und ggf. mehrfach testen. Besonders bei Coding-/Generationsaufgaben ist pass@k wichtig: pass@1 fragt vereinfacht, wie oft der erste Versuch die Aufgabe löst; pass@k berücksichtigt mehrere Kandidaten. pass@10 darf deshalb nicht mit pass@1 verglichen werden. Ähnlich verzerrt best-of-n (mehrere Antworten erzeugen, beste auswählen) den Vergleich mit einem einzelnen Produktionsaufruf – auch bei Kosten und UX.

Ein Mathematiksystem mit Taschenrechner löst Aufgaben womöglich besser – misst dann aber „Modell + Werkzeug". Closed-book- und Open-book-Ergebnisse sollten nicht unkritisch vermischt werden.

Benchmark Contamination

Testdaten oder sehr ähnliche Inhalte können in den Trainingsdaten eines Modells enthalten sein. Dann kann ein hoher Score teilweise Wiedererkennung oder Memorisation statt echter Generalisierung widerspiegeln (Sainz et al. fordern, Kontamination pro Benchmark zu messen). Bei proprietären Modellen ist eine vollständige Kontaminationsprüfung schwierig, weil die Trainingsdaten nicht offengelegt sind.

Saturation und dynamische Benchmarks

Wenn Spitzenmodelle fast alle Aufgaben eines Benchmarks lösen (Saturation), macht er Unterschiede schlechter sichtbar. Als Reaktion entstehen schwerere Benchmarks (z. B. die Entwicklungslinie MMLU → MMLU-Pro) und dynamische Benchmarks, die Aufgaben regelmäßig erneuern. Ziele sind geringeres Kontaminationsrisiko, weniger Sättigung und aktuellere Aufgaben – Beispiele sind LiveBench und LiveCodeBench. Auch dynamische Benchmarks haben Grenzen und sind nicht automatisch „die Wahrheit".

Benchmark-Typen mit Beispielen

Jeder Benchmark hat einen Geltungsbereich. Ein Wissens-Q&A-Benchmark beantwortet nicht „Welches Modell schreibt die beste deutsche Marketingmail?", und ein Coding-Benchmark beantwortet nicht „Welches Modell fasst deutsche Verträge am besten zusammen?". Einige illustrative Typen:

SWE-bench ist ein gutes Beispiel für verifizierbare Aufgaben: Der Output (ein Code-Patch) wird durch die Test-Suite des Projekts geprüft. Aber selbst reale GitHub-Issues bilden nicht das gesamte Software-Engineering ab (Meetings, Architektur, Wartung, Deployment fehlen). Real-world heißt nicht gesamte Realität.

Menschliche Präferenztests

Auf Plattformen wie Chatbot Arena (heute unter dem Namen Arena) vergleichen Menschen die Antworten zweier anonymisierter Modelle. Das misst menschliche Präferenz unter den Bedingungen der Plattform – nicht automatisch Wahrheit, Sicherheit, faktische Korrektheit oder Unternehmenstauglichkeit.

Human Evaluation und Rubriken

Für Stil, Verständlichkeit, Nützlichkeit und Domänenqualität sind Menschen oft unverzichtbar. Human Evaluation ist aber teuer, langsam und subjektiv, und verschiedene Bewerter urteilen unterschiedlich. Deshalb lohnt der Blick auf das Inter-Annotator-Agreement: Stimmen mehrere Bewerter überhaupt überein? Wenn nicht, sind Rubrik, Aufgabe oder Ground Truth womöglich unklar.

Offene Aufgaben brauchen klare Rubriken. Nicht „Ist die Antwort gut?", sondern konkret: korrekt? vollständig? Quelle vorhanden? Ton passend? keine erfundene Information? gewünschtes Format? Die Rubrik muss zum Use Case passen.

LLM-as-a-Judge

Ein Sprachmodell kann Antworten anderer Modelle anhand einer Rubrik bewerten. Das ist skalierbar, flexibel und für offene Aufgaben geeignet – aber nicht deterministisch und potenziell verzerrt. Die Forschung zu MT-Bench benennt ausdrücklich Position Bias, Verbosity Bias und Self-Enhancement Bias sowie begrenzte Reasoning-Fähigkeit.

Deterministische, modellbasierte und menschliche Grader

Wenn eine Aufgabe objektiv überprüfbar ist, ist klassischer Code der beste Grader: JSON-Schema validieren, exakten Rechenwert prüfen, Tests ausführen, SQL-Resultset vergleichen, Label gegen Ground Truth prüfen.

Eigene Evals aufbauen

Die aussagekräftigsten Tests sind meist eigene. Ein Golden Dataset ist eine kuratierte Sammlung repräsentativer Fälle mit Eingabe, erwarteter Lösung/Bewertung, Kategorie und ggf. Schwierigkeit – „Gold" ist es aber nur bei guter Ground Truth. Zwei Eval-Zwecke gehören unterschieden:

Wird eine schwere Fähigkeit stabil gelöst, wandert sie in die Regression-Suite. Die besten Evals entstehen aus echten Fehlern: Produktionsfehler und Supportfälle werden verstanden, zu Testfällen gemacht und dauerhaft aufgenommen (sensible Daten vorher behandeln). Wichtig ist die Trennung von Development-, Validation- und Holdout-Set: Wer ständig auf dasselbe Set optimiert, betreibt Eval-Overfitting – der Score steigt, neue reale Fälle bleiben schlecht. Private Evals sind näher am Use Case und haben ein geringeres öffentliches Kontaminationsrisiko (Datenschutz beachten).

Deutsch und die eigene Domäne

Ein Modell mit starkem englischem Benchmarkscore ist nicht automatisch gleich gut für deutsche Aufgaben. Zu testen sind reales Deutsch, Fachsprache, Umlaute, Komposita und lokale Rechts-/Geschäftsterminologie. „Multilingual" ist keine Garantie für jede Sprache – die eigene Sprache und Domäne gehören zusätzlich getestet. Englische Benchmarks sind keine universelle Sprachbewertung.

Faktualität, Halluzination und Robustheit

Bei Wissensantworten sind mehrere Dinge zu trennen: richtige Antwort, richtige Quelle, vollständiger Beleg, keine unbelegte Ergänzung (mehr zu Halluzinationen). Sinnvolle Testfälle enthalten bewusst unbeantwortbare Fragen, erfundene Entitäten, fehlende Quellen oder Widersprüche – um zu prüfen, ob das System Unsicherheit angemessen behandelt. Eine universelle „Halluzinationsmetrik" gibt es nicht. Auch Kalibrierung ist relevant: Eine selbst angegebene „Confidence" eines Modells ist nicht automatisch statistisch belastbar. Und Robustheit heißt: kleine Umformulierungen, Tippfehler, andere Reihenfolge oder Zusatzinfos sollten das Verhalten nicht völlig kippen. Für sicherheitsrelevante Systeme kommen Adversarial-/Red-Team-Evals und eigene Safety-Evals hinzu (schädliche Inhalte, personenbezogene Daten, unzulässige Aktionen) – Sicherheit gehört nicht in „Accuracy" versteckt. Fairness ist kontextabhängig (welche Gruppen, welcher Use Case, welche Folgen) und kein einzelner Score.

RAG, Agenten und Coding evaluieren

Ganze Systeme brauchen eigene Eval-Ebenen:

Bei RAG helfen Retrieval-Kennzahlen wie Recall@k, Precision@k, MRR oder nDCG – entscheidend bleibt: Wurde die benötigte Passage gefunden? Bei Agenten ist neben dem Outcome die Trajectory wichtig: Ein richtiges Endergebnis über einen riskanten oder unnötig teuren Weg ist kein guter Lauf. Und bei Coding gilt: Tests bestehen heißt nicht automatisch guter Code – Code kann grün sein und trotzdem schlecht wartbar oder unsicher; deterministische Tests werden bei Bedarf um Review/Rubrik ergänzt.

Multimodale und Long-Context-Evaluation

Bild-, Audio- und Videomodelle brauchen andere Aufgaben: Wahrnehmung, OCR, räumliche Beziehungen, Audioerkennung, zeitliche Videozusammenhänge, multimodale Halluzinationen (mehr zu multimodaler KI). Textbenchmarks lassen sich nicht einfach übertragen. Und ein großes nominelles Kontextfenster ist kein Qualitätsscore: Zu testen sind Retrieval über lange Kontexte, Multi-Hop, Aggregation, Positionseffekte sowie der Umgang mit relevanter vs. irrelevanter Information.

Kosten, Latenz und Effizienz

Qualität ist nicht alles. Sinnvoll gemessen werden auch Latenz (Gesamtantwortzeit, ggf. Time-to-First-Token, bei Agenten End-to-End) und Kosten – wobei Kosten pro erfolgreich gelöster Aufgabe oft aussagekräftiger sind als reine Tokenpreise. Ein kleineres Modell kann bei ausreichender Qualität wirtschaftlicher sein; das beste Benchmarkmodell ist nicht automatisch die beste Produktionsentscheidung. Bei großen Workloads zählt zusätzlich Durchsatz (Anfragen pro Sekunde, Batchfähigkeit). Überschlagen lässt sich der Kostenpfad mit dem KI-Kostenrechner.

Statistische Unsicherheit

Ein Benchmarkscore ist eine Schätzung anhand einer begrenzten Menge von Aufgaben. Kleine Unterschiede können statistisch bedeutungslos oder praktisch irrelevant sein. Aktuelle NIST-Arbeit (AI 800-3, 2026) betont gültige Unsicherheitsschätzung und unterscheidet ausdrücklich Benchmark-Accuracy (Leistung auf genau diesem Testset) von generalisierter Accuracy (erwartete Leistung auf neuen, ähnlichen Aufgaben) – Letztere lässt sich nicht einfach aus einer Zahl garantieren.

Hinzu kommt: Ground Truth kann fehlerhaft sein – falsche Labels, mehrdeutige Fragen, veraltete Antworten, kulturelle Verzerrung. Kein Benchmark ist automatisch fehlerfrei.

Reproduzierbarkeit und Regression

Ein nachvollziehbares Eval dokumentiert Modell, Version, Datum, Prompt, System-Prompt, Parameter, Tools, Testset-Version, Grader und Codeversion. Ohne diese Angaben ist ein späterer Vergleich kaum belastbar (auch Benchmark-, Dataset- und Harness-Version beachten).

Offline, Online und Slicing

Offline wird ein Testset kontrolliert ausgeführt; online zählen reale Produktionsmetriken (Task Completion, Eskalationsrate, Feedback, Fehlerquote) – nur datenschutzkonform. Ein A/B-Test vergleicht Varianten unter realen Bedingungen, braucht aber eine sinnvolle Erfolgsmetrik und ausreichend Daten; Nutzerzufriedenheit ist nicht dasselbe wie Wahrheit. Sehr wichtig ist Slicing: Ergebnisse nach Gruppen auswerten (einfach vs. schwer, Deutsch vs. Englisch, kurz vs. lang, normal vs. adversarial), sonst versteckt ein Gesamtdurchschnitt schwache Teilgruppen. Ein guter Eval zeigt Fehlerklassen (korrekt, Quellenfehler, Formatfehler, Toolfehler, Sprache, Sicherheit) statt nur „87 %".

Die BOMOTS-Eval-Methode

Eine einfache, wiederholbare Methodik:

• Schritt 1 – Aufgabe definieren: Was soll wirklich funktionieren?
• Schritt 2 – reale Testfälle sammeln (keine künstlichen Demo-Prompts).
• Schritt 3 – Erfolgskriterien festlegen: Was ist richtig/gut/sicher?
• Schritt 4 – Grader auswählen: Code, Modell oder Mensch.
• Schritt 5 – Baseline erstellen: aktuelles System messen.
• Schritt 6 – Kandidaten unter gleichen Bedingungen testen.
• Schritt 7 – Fehler nach Kategorien analysieren.
• Schritt 8 – Kosten und Latenz ergänzen.
• Schritt 9 – Holdout prüfen (nicht auf das Testset optimieren).
• Schritt 10 – Regression-Suite aufbauen und pflegen.

Konkrete Beispiele

Vier konstruierte Beispiele (keine echten BOMOTS-Tests) zeigen, warum ein öffentlicher Score selten ausreicht:

Wann Leaderboards helfen – und wann kaum

Ein Leaderboard hilft für einen schnellen Überblick, eine klar definierte Einzelfähigkeit, das Reduzieren von Kandidaten und das Beobachten von Entwicklung. Es sagt wenig, wenn der eigene Fall eine andere Sprache, Domäne, spezielle Tools, eigene Daten, strenge Sicherheitsanforderungen oder ganz andere Kosten-/Latenzgrenzen hat. Rankings sind außerdem zeitkritisch: Wird auf ein Leaderboard verwiesen, gehört ein Abrufdatum dazu; aktuelle Modellwerte kopiert BOMOTS nicht in statischen Text, weil sie schnell veralten.

Und Benchmarks sind keine Sporttabelle: Statt „Sieger/Verlierer/Champion" ist die faire Sprache „stärker auf Test X, schwächer auf Test Y, unter diesen Bedingungen".

Häufige Missverständnisse

Praxis-Checkliste: ein KI-Modell seriös evaluieren

• Welche reale Aufgabe soll gelöst werden, und was bedeutet Erfolg?
• Welche Fehler sind besonders teuer oder gefährlich?
• Welche Sprache und Domäne liegen vor?
• Habe ich realistische Testfälle mit verlässlicher Ground Truth?
• Welcher Grader passt (Code, Modell, Mensch)?
• Muss ich Tool-Use oder RAG mitprüfen?
• Welche Safety-Fälle brauche ich?
• Welche Kosten- und Latenzgrenzen gelten?
• Sind alle Kandidaten gleich konfiguriert, und welche Version wird getestet?
• Wurde mehr als ein Lauf benötigt (Varianz)?
• Gibt es ein separates Holdout-Set?
• Werden Fehler nach Kategorien analysiert und ist das Ergebnis reproduzierbar?
• Wird nach Modell-/Prompt-/RAG-Updates erneut getestet?

Weiterführend: Modellverzeichnis, Modell-Finder, RAG, KI-Agenten, Halluzinationen und Large Language Models.

• Modell-Finder
• Modellverzeichnis
• Halluzinationen
• RAG
• KI-Agenten
• Kostenrechner