LLM-Evals in der Praxis: KI-Features testen, bevor Nutzer es tun
Der erste peinliche Fehler eines KI-Features sieht selten wie ein Benchmark-Problem aus. Er sieht aus wie ein Support-Bot, der selbstbewusst die falsche Rückerstattungsregel nutzt, ein Coding-Assistent, der eine gesperrte Datei ändert, oder ein Sales-Copilot, der ein leeres CRM-Feld mit erfundenen Details füllt. Die Demo war sauber. Der Prompt-Review wirkte plausibel. Dann fand ein echter Nutzer den Fall, den niemand getestet hatte.
Dafür sind LLM-Evals da. Nicht für Leaderboard-Theater, sondern als Frühwarnsystem für Produktteams: realistische Erwartungen werden zu wiederholbaren Tests, Regression Gates und Review-Schleifen.
Warum LLM-Evals anders sind als normale QA
Klassische QA prüft, ob ein bekanntes Input ein erwartetes Output liefert. LLM-Produkte haben oft mehrere akzeptable Antworten. Ein Support-Assistent kann in zehn guten Varianten antworten. Ein Research-Agent kann nützlich sein, wenn er stoppt und fehlenden Kontext erfragt.
Die Rubrik muss deshalb zum Risiko passen: Faktenkonsistenz, Vollständigkeit, Ton, Refusal-Verhalten, Tool-Auswahl, Berechtigungen, Recovery und sichere Stopps. Unser Beitrag zu verlässlicheren AI Agents beschreibt dieselbe Produktlogik: Nicht nur das Modell zählt, sondern die Kontrollfläche um das Modell.
Golden Dataset vor Prompt-Tuning
Ein Golden Dataset ist eine kuratierte Sammlung realistischer Fälle mit erwarteter Reaktion, Bewertungsnotizen und Metadaten. Starten Sie mit 50 bis 200 Beispielen: häufige Jobs, teure Fehler und unangenehme Edge Cases. Für Support gehören wütende Tickets, mehrere Sprachen, fehlende Informationen und Eskalationsfälle hinein. Für Developer Tools gehören kleine Bugs, unklare Refactorings, kaputte Tests und Berechtigungsgrenzen hinein.
Speichern Sie Task-Typ, Risikostufe, benötigte Quellen, erlaubte Aktionen und Pass/Fail-Begründung. So erkennen Sie später, ob ein neuer Prompt Spanisch verschlechtert, Tool-Routing verbessert oder nur den Durchschnitt verschönert. Hamel Husains Artikel zu LLM evals ist hilfreich, weil er produktspezifische Beispiele und menschliches Urteil priorisiert.
Prompts und Modelle wie Produktexperimente vergleichen
Vergleiche sollten kontrolliert sein. Lassen Sie Produktionsprompt, Kandidatenprompt und Kandidatenmodell auf demselben Dataset laufen und schneiden Sie die Ergebnisse nach Task, Sprache, Risiko und Segment. ChainForge hilft beim Vergleichen vieler Prompts und Outputs, Vellum bietet Workflows für Prompt-Management, Evals und Deployment, und DeepEval ist ein Open-Source-Testframework für LLM-Anwendungen.
Wichtiger als das Tool ist die Disziplin: Prompt-Version, Modellname, Retrieval-Einstellungen, Tool-Schema, Temperatur und Systeminstruktionen müssen pro Run gespeichert werden. Das gilt besonders für Multi-Model-Workflows wie in unserem Artikel über Softwareentwicklung mit LLMs.
Regression Gates in CI/CD
Nehmen Sie zuerst ein kleines Smoke-Set in CI/CD auf: gefährliche Policy-Antworten, kaputtes JSON, verbotene Tool Calls, schwere Halluzinationen und Pflicht-Eskalationen. Jeder Pull Request, der Prompt, Modellkonfiguration, Retrieval, Tool-Schema oder Routing ändert, sollte diese Evals ausführen. Hochriskante Fehler blockieren den Merge, niedrigere Bewegungen erzeugen Warnungen.
Beginnen Sie mit deterministischen Checks: Schema-Gültigkeit, notwendige Quellen, verbotene Aktionen, Refusals und einfache Tool-Wahl. Ergänzen Sie später Rubrics oder LLM-as-judge für Ton, Vollständigkeit und Nützlichkeit. Für Agenten passen die Muster aus MCP in Produktion und Operator-Web-Automation: Tool Calls loggen, Fehler klassifizieren, Schemas versionieren und Failure Paths testen.
Human Review hält Evals lebendig
Ein Eval-Set altert. Nutzer, Policies, Modelle und UI ändern sich. Prüfen Sie regelmäßig Stichproben, Beschwerden, Eskalationen und Near Misses. Labeln Sie nicht nur gut oder schlecht, sondern Fehlerarten: fehlender Kontext, falsches Tool, unbelegte Behauptung, schlechter Ton, unsichere Aktion, veraltete Quelle, Over-Refusal oder Under-Refusal. Danach wandern die besten Beispiele ins Golden Dataset.
PMs und Domain Experts gehören hier hinein. Wenn Sie Agent-Dashboards nutzen, verbinden Sie Eval-Fehler mit dem Betriebsbild; unser Agent-Operations-Funnel liefert dafür ein passendes Muster.
Wann offene Game-World-Evals sinnvoll sind
Die meisten Teams sollten mit Golden Datasets und Regression Gates starten. Offene Umgebungen lohnen sich, wenn das Produkt lange Planung, Recovery und viele Tool-Schritte braucht. Die Factorio Learning Environment nutzt Factorio als Sandbox für Agenten, die planen, Ressourcen sammeln, bauen und adaptieren müssen. Für einen FAQ-Bot ist das übertrieben; für Browser-, Coding- oder Operations-Agenten kann es relevant sein.
Gute LLM-Evals machen ein Feature nicht perfekt. Sie machen die Trade-offs sichtbar, bevor Kunden sie finden. Reife Teams wissen, welche Fehler zählen, fangen Regressionen früh ab und halten Menschen dort im Loop, wo Urteil und Verantwortung nötig bleiben.