Die Unternehmen, die KI schnell ausliefern, sind nicht jene mit den besten Prompts. Es sind jene, die innerhalb eines Nachmittags sagen können, ob eine Änderung das System besser oder schlechter gemacht hat. Evaluation ist die Fähigkeit, die sich aufsummiert; alles andere ist austauschbar.

Fragen Sie ein Enterprise-Team, woher es weiss, dass sein KI-Feature gut ist, und Sie bekommen meist eine von zwei Antworten: «Wir haben ein paar Beispiele ausprobiert, und die sahen richtig aus» oder «Die Nutzer haben sich nicht gross beschwert». Beides ist Bauchgefühl. Bauchgefühl reicht für einen Hackathon und ist tödlich in der Produktion – denn sobald Sie einen Prompt ändern, ein Modell austauschen oder Ihr Anbieter still und leise seines aktualisiert, haben Sie keine Möglichkeit festzustellen, ob Sie das System gerade verbessert oder kaputt gemacht haben.

Die Investition mit der grössten Hebelwirkung in jedem ernsthaften KI-Programm ist ein Evaluation Harness. Sie ist auch die unspektakulärste – und genau deshalb überspringen die meisten Teams sie und kommen danach nur noch im Schneckentempo voran, weil sie sich nicht trauen, ein System anzufassen, das sie nicht messen können.

Das eigentliche Problem: KI-Systeme verschlechtern sich lautlos

Klassische Software scheitert laut – ein Test wird rot, eine Exception wird geworfen. KI-Systeme scheitern leise. Eine Prompt-Anpassung, die 90 % der Fälle verbessert, kann die übrigen 10 % verschlechtern – ohne Fehlermeldung, ohne Absturz, ohne jedes Signal, bis es ein Kunde bemerkt. Ein Update beim Modellanbieter kann das Verhalten Ihres gesamten Systems über Nacht verschieben. Ohne Evals entdecken Sie solche Regressionen in der Produktion, über Beschwerden, Wochen zu spät und ohne zu wissen, welche Änderung sie verursacht hat.

Dieses Risiko stiller Regressionen ist der Grund, warum Teams ohne Evals erstarren. Sie hören auf, das System zu verbessern, weil jede Änderung ein ungemessenes Glücksspiel ist – und ein eingefrorenes KI-System zerfällt stetig, während sich Modelle, Daten und Nutzerbedürfnisse weiterentwickeln. Fehlende Evals bremsen Sie nicht nur; sie bringen Sie vollständig zum Stillstand.

Ein Framework: die drei Ebenen der Evaluation

Ein vollständiges Harness arbeitet auf drei Ebenen, und die meisten Teams haben bestenfalls ein Fragment von einer davon.

1. Komponenten-Evals (offline, automatisiert)

Ein fixer Datensatz aus Inputs mit bekannten, korrekten Outputs, der bei jeder Änderung durchläuft und das System automatisch bewertet. Für Retrieval: Recall gegen ein gelabeltes Set. Für Extraktion: Genauigkeit auf Feldebene. Für Klassifikation: Precision und Recall pro Klasse. Das ist Ihre Regressions-Suite – sie muss in Minuten durchlaufen und jede Änderung freigeben oder stoppen. Zielen Sie auf 100–500 Fälle aus der realen Nutzung, inklusive der schwierigen und adversarialen, nicht nur der einfachen Mitte.

2. Evals der Output-Qualität (halbautomatisiert)

Für offene Textgenerierung gibt es nicht die eine richtige Antwort, also bewerten Sie anhand von Rubriken: faktische Fundierung, Relevanz, Tonalität, Sicherheit, vorhandene Quellenangaben. Setzen Sie für die Skalierung ein stärkeres Modell als Judge gegen eine explizite Rubrik ein, aber kalibrieren Sie es anhand einer Stichprobe gegen menschliche Bewertungen, damit Sie ihm vertrauen können – ein ungeprüfter LLM-Judge hat seine eigenen Verzerrungen. Entscheidend ist ein reproduzierbarer Score, der sich bewegt, wenn sich die Qualität bewegt.

3. Monitoring in der Produktion (online)

Offline-Evals können nicht alles vorhersehen, was echte Nutzer tun. In der Produktion messen Sie Ablehnungsrate, Fallback-Rate, Latenz, Kosten pro Aufruf und Nutzersignale (Korrekturen, Daumen, Eskalationen). Speisen Sie laufend Stichproben aus dem echten Traffic in Ihr Offline-Set ein, damit Ihre Eval-Daten die Realität abbilden und nicht Ihre Annahmen zum Go-live.

Praxisbeispiel: ein Extraktionssystem bei einer Modellmigration

Eine Bank betrieb ein KI-System, das 14 Felder aus Trade-Finance-Dokumenten extrahierte, und ihr Modellanbieter kündigte an, dass die verwendete Version abgekündigt wird – sie musste migrieren oder den Support verlieren. Ohne Evals ist das ein beängstigendes Projekt ohne klare Grenzen: den Motor unter einem Produktivsystem austauschen und hoffen.

Weil wir ein Eval-Set mit 220 Dokumenten und Ground Truth auf Feldebene aufgebaut hatten, war die Migration eine Sache von einem Nachmittag statt einem Quartal:

• Aktuelles System durchlaufen lassen: 94,1 % Genauigkeit auf Feldebene (die bekannte Baseline).
• Drei Kandidatenmodelle gegen dasselbe Set laufen lassen: 91,8 %, 94,6 %, 95,2 %.
• Das Modell mit 95,2 % gewählt, bestätigt, dass die zwei beim 91,8-%-Kandidaten verschlechterten Felder nicht relevant waren, und ausgeliefert – mit Evidenz statt Hoffnung.

Das Eval-Set verwandelte eine existenzielle Migration in eine gemessene Entscheidung. Dasselbe Harness fing später eine Prompt-«Verbesserung» ab, welche die durchschnittliche Qualität steigerte, aber die Genauigkeit bei Betragsfeldern von 97 % auf 89 % senkte – eine Änderung, die auf Bauchgefühl hin ausgeliefert worden wäre und echte finanzielle Fehler verursacht hätte.

Dieser zweite Fang ist der eigentliche Ertrag. Das Harness macht Sie nicht nur schneller; es verhindert die selbstbewusste, gut gemeinte Änderung, die still und leise genau die Fälle kaputt macht, auf die es am meisten ankommt.

Wie Sie das erste Eval-Set bauen, ohne den Ozean zum Kochen zu bringen

Der Einwand, den wir am häufigsten hören: Ein Eval-Set aufzubauen sei ein riesiges Labeling-Projekt, für das niemand Zeit hat. Ist es nicht, wenn Sie es richtig zuschneiden. Sie brauchen keine zehntausend gelabelten Fälle; Sie brauchen hundert, die repräsentativ und schwierig sind. Ziehen Sie zunächst ein paar Wochen echter Inputs aus Produktion (oder Pilot) und bilden Sie bewusst drei Töpfe: die häufigen Fälle (damit Sie den Grossteil des Traffics schützen), die bekannten Fehler (jede Beschwerde, jede Eskalation, jedes «die KI hat das falsch gemacht», an das sich das Team erinnern kann) und die Randfälle (ungewöhnliche, aber legitime Inputs). Hundert so zusammengestellte Fälle fangen mehr Regressionen ab als tausend zufällige, weil zufällige Stichproben von der einfachen Mitte dominiert werden, die nie kaputtgeht.

Auch das Labeling muss nicht perfekt sein. Für ein erstes Harness reicht es, wenn eine einzige Fachexpertin oder ein Fachexperte einen Tag lang die Ground Truth für hundert Fälle festlegt, um Änderungen freigeben zu können; strittige Labels verfeinern Sie, sobald sie auftauchen. Das Harness ist ein lebendes Asset: Jeder Produktionsfehler, den Sie entdecken, wird zu einem neuen Fall, sodass das Set genau in Richtung der Inputs wächst, die zählen. Innerhalb weniger Monate enthält das Eval-Set mehr institutionelles Wissen darüber, was «gut» für Ihren Use Case bedeutet, als jedes Spezifikationsdokument – und im Gegensatz zum Dokument lässt es sich ausführen.

Eine weitere Praxis, die sich selbst bezahlt: Versionieren Sie das Eval-Set zusammen mit dem System und halten Sie die Scores jedes Releases fest. Wenn jemand sechs Monate später fragt «Ist das besser oder schlechter geworden?», haben Sie ein Diagramm statt einer Debatte. Und wenn eine Aufsichtsbehörde oder ein internes Risikokomitee fragt, wie Sie Qualität sicherstellen, ist «Hier ist unsere versionierte Eval-Suite und die Score-Historie jedes Releases» eine Antwort, die das Gespräch beendet. Das Harness ist gleichzeitig Ihr Entwicklungsbeschleuniger und Ihr Compliance-Nachweis – dasselbe Artefakt dient beidem, und genau deshalb ist es die Investition mit der höchsten Rendite im ganzen Programm.

Stolpersteine

• Ein Eval-Set aus einfachen Fällen. Wenn es die schwierigen, mehrdeutigen und adversarialen Inputs nicht enthält, bedeutet ein bestandener Score nichts. Kuratieren Sie aus echten Fehlern.
• Eine einzige globale Genauigkeitszahl. Schlüsseln Sie nach Feld, Klasse oder Anfragetyp auf – ein Durchschnitt versteckt die Regression in den 10 %, auf die es ankommt.
• Einem LLM-Judge blind vertrauen. Kalibrieren Sie ihn gegen menschliche Bewertungen, sonst messen Sie die Verzerrungen des Judges.
• Ein statisches Eval-Set. Das Nutzerverhalten verschiebt sich; speisen Sie echten Produktions-Traffic zurück ins Set, sonst veraltet es.
• Evals als einmaliges Deliverable behandeln. Das Harness ist ein lebendes Asset, das mit jedem neu entdeckten Fehlermuster wächst.

Entscheidungs-Checkliste

1. Können wir automatisch und innert Minuten feststellen, ob eine Änderung das System verbessert oder verschlechtert hat?
2. Enthält unser Eval-Set schwierige, mehrdeutige und adversariale Fälle aus der realen Nutzung?
3. Bewerten wir nach Segment (Feld/Klasse/Anfragetyp) und nicht nur mit einer globalen Zahl?
4. Bewerten wir offene Outputs gegen eine explizite Rubrik, mit einem kalibrierten Judge?
5. Überwachen wir Ablehnungen, Fallbacks, Latenz und Kosten in der Produktion?
6. Speisen wir echten Traffic zurück ins Eval-Set, um es aktuell zu halten?
7. Könnten wir eine erzwungene Modellmigration an einem Nachmittag statt in einem Quartal bewältigen?

Die gridz-Sicht

Prompts sind an einem Tag kopiert, und Modelle werden quartalsweise zur Commodity; das Evaluation Harness ist das Asset, das Ihnen gehört und sich aufsummiert. Es erlaubt Ihnen, ein besseres Modell in der Woche seines Erscheinens einzusetzen, eine Qualitätsaussage gegenüber einer Aufsichtsbehörde zu belegen und sich kontinuierlich zu verbessern, statt aus Angst zu erstarren. Wir bauen das Harness, bevor wir das Feature skalieren, denn das Team, das Qualität messen kann, ist das Team, das schnell vorankommt, ohne die Fälle kaputt zu machen, die zählen. Wenn Ihre KI-Roadmap keinen Posten für Evals enthält, ist das das Erste, was wir beheben würden – sprechen Sie uns an.

Konkret ist der günstigste und wertvollste Schritt, den Sie diesen Monat machen können: Stellen Sie aus Ihren eigenen Produktionsfehlern und häufigen Anfragen ein Eval-Set mit hundert Fällen zusammen, lassen Sie es von einer Fachperson an einem Tag labeln und hängen Sie es so ein, dass es bei jeder Änderung läuft. Dieses eine Artefakt verwandelt Ihre KI-Entwicklung von ängstlichem Rätselraten in gemessenes Engineering – Sie fangen die gut gemeinte Änderung ab, die still die wichtigen Fälle kaputt macht, und Sie können das nächste bessere Modell mit Evidenz statt mit Bangen übernehmen. Alles andere in einer reifen KI-Praxis wird einfacher, sobald Sie automatisch die einzige Frage beantworten können, die zählt: Hat diese Änderung es besser oder schlechter gemacht?