KI-Modelle mit eigenen Evals wählen, nicht nur mit Leaderboards
Ein Leaderboard ist ein guter Startpunkt, aber ein schlechter Kaufbeschluss. Das Modell auf Platz eins kann in öffentlichen Präferenztests glänzen und trotzdem für Ihre Support-Mails, Code-Reviews, Tabellen, Agent-Workflows oder Latenzvorgaben unpassend sein. LM Arena und Chatbot Arena liefern nützliche Signale; sie ersetzen aber nicht die Frage, ob ein Modell Ihre echten Aufgaben zuverlässig löst.
Öffentliche Rankings verdichten Prompts, Nutzergruppen, Bewertungsmethoden und Produktdetails zu einer Zahl. Ihre Realität ist enger: bestimmte Kunden, Tonalität, Kosten, Antwortzeit, Datenschutz, Tool-Zugriff und Fehlertoleranz. Für eine grobe Orientierung zu Consumer-Modellen hilft unser Claude-vs-GPT-Leitfaden. Die endgültige Entscheidung sollte auf eigenen Tests beruhen.
Ein persönliches Eval-Set bauen
Ein persönliches Eval-Set ist eine kleine Sammlung echter Aufgaben, erwarteter Qualitätsmerkmale und Bewertungsregeln. Einzelpersonen können mit 20 guten Prompts viel lernen; kleine Teams sehen mit 50 bis 100 Fällen oft genug Unterschiede für eine Migration.
Sammeln Sie reale Arbeit: Support-Tickets, Sales-E-Mails, Code-Review-Kommentare, Produktanforderungen, Spreadsheet-Aufräumarbeiten, Recherchefragen, Meeting-Zusammenfassungen und Agent-Abläufe. Entfernen Sie private Daten, aber behalten Sie die Schwierigkeit: lange Kontexte, widersprüchliche Anweisungen, mehrsprachige Texte, unklare Eingaben und riskante Grenzen.
Für Entwickler passen dazu unser AI for developers guide und das GPT-5 developer migration playbook: Das Eval sollte wie Ihr Repository, Ihre Fehler und Ihre Review-Regeln aussehen.
Rubrics vor dem Vergleich definieren
Bewerten Sie nicht erst, nachdem Sie wissen, welches Modell geantwortet hat. Legen Sie vorher eine einfache Rubrik fest: Aufgabenerfolg 0 bis 3, Faktentreue 0 bis 3, Befolgung der Anweisungen 0 bis 3, Nutzbarkeit 0 bis 3. Ziehen Sie Punkte für gefährliche Aktionen, erfundene Details, Datenschutzprobleme oder übertriebene Sicherheit ab.
Für subjektive Arbeit ergänzen Sie Ton, Kürze und Markenfit. Für Code nutzen Sie Tests, wo möglich. Für Tool-Workflows prüfen Sie, ob das Modell das richtige Tool wählt, fehlende Informationen abfragt und rechtzeitig stoppt. Bei Tool-Architektur hilft unser Artikel zu MCP, CLI und Function Calling.
Beispielprompts für Model-Evals
Research: Fassen Sie fünf Quellenauszüge zusammen, listen Sie offene Fragen auf und markieren Sie jede Behauptung, die verifiziert werden muss.
Support: Ein Kunde ist verärgert, weil ein Export zweimal fehlgeschlagen ist. Schreiben Sie eine Antwort unter 140 Wörtern, ohne ein Fixdatum zu versprechen.
Coding: Aus fehlendem Test, Funktion und Diff den kleinsten plausiblen Fix vorschlagen und erklären, was vor einer Änderung geprüft werden sollte.
Kaufentscheidung: Drei AI-Writing-Tools anhand gelieferter Notizen vergleichen, Fakten von Annahmen trennen und keine Features erfinden.
Agent: Mit Kalender-, E-Mail- und CRM-Tools einen Termin verschieben; markieren, welche Schritte vor Ausführung Bestätigung brauchen.
Nützliche Quellen sind Anthropic zu Testing and Evaluation, OpenAI zu custom evals and graders und Hamel Husains praktischer Beitrag zu LLM evals.
Regression, Kosten und Latenz zusammen betrachten
Ein Modell mit leicht besserem Score, aber dreifacher Latenz kann im Produkt schlechter sein. Ein billiges Modell, das riskante Fälle still falsch löst, wird über Support und Nacharbeit teuer. Erfassen Sie Modell, Datum, Prompt-Version, Einstellungen, Latenz, geschätzte Kosten, Passrate, schwere Fehler und Notizen.
Betrachten Sie Kategorien statt nur Mittelwerte. Vielleicht gewinnt ein Modell bei Langtext, ein anderes bei strukturierter Extraktion und ein drittes bei sicherem Tool-Einsatz. Dann brauchen Sie Routing, nicht einen Gesamtsieger. Für Browser- und Agent-Automation ergänzt unser AI browser automation stack guide die Perspektive.
Wann Evals erneut laufen sollten
Wiederholen Sie Evals bei neuen Modellen, Preisänderungen, Routing-Änderungen, großen Prompt-Updates, neuen Tool-Rechten, aktualisierten Retrieval-Korpora oder geänderten Geschäftsprozessen. Einzelpersonen können monatlich zehn Lieblingsprompts testen; Indie-Hacker sollten vor Default-Wechseln den Risikosatz laufen lassen; Käuferteams testen vor Beschaffung, Rollout und nach realer Nutzung.
Das Ziel ist nicht, Eval-Forschung zu betreiben. Das Ziel ist, öffentliche Rankings zur Vorauswahl zu nutzen und die eigentliche Entscheidung mit eigenen Aufgaben zu treffen.