KI-Engineering · Tag 6: Evals — KI-Qualität messen

Willkommen zu Tag 6 unserer Serie KI-Engineering. In Tag 5 haben wir KI mit Guardrails abgesichert, heute wird es unbequem: Wie stellst du eigentlich sicher, dass dein KI-Feature funktioniert — nicht nur in der einen Demo, die du dem Chef gezeigt hast, sondern bei den nächsten zehntausend echten Anfragen? Die ehrliche Antwort in den meisten Teams lautet: gar nicht. Man schaut sich drei, vier Ausgaben an, nickt zufrieden und deployt. Genau hier kommen KI Evals ins Spiel. Evals sind der Unterschied zwischen „sieht gut aus“ und „wir wissen, dass es gut ist“. In dieser Episode zeigen wir dir, warum das eine keine Qualitätssicherung ist, wie du ein belastbares Eval-Set aus echten Anfragen aufbaust und wie du Regressionen erkennst, bevor deine Nutzer sie erkennen.

Warum „sieht gut aus“ keine Qualitätssicherung ist

Stell dir vor, ein Kollege schreibt eine neue Funktion, die eine Rechnung berechnet. Er testet sie mit einem einzigen Beispiel, das Ergebnis stimmt, und er schickt den Code in Produktion. Bei klassischer Software würde jeder sofort protestieren: „Wo sind die Tests? Was ist mit Nullwerten, negativen Beträgen, Rundung?“ Bei KI-Features akzeptieren wir diesen laxen Umgang erstaunlicherweise ständig. Jemand ändert einen Prompt, probiert zwei Fragen aus, findet die Antworten „irgendwie besser“ und merged.

Das Problem ist strukturell. Sprachmodelle sind nicht deterministisch, und ihr Verhalten ist hochsensibel gegenüber kleinen Änderungen. Ein zusätzlicher Satz im System-Prompt, ein Modell-Update des Anbieters, eine andere Formulierung im Kontext — jede dieser Kleinigkeiten kann die Qualität an einer Stelle heben und an drei anderen Stellen senken. Wenn du nur die eine Stelle anschaust, die du gerade verbessern wolltest, siehst du die Verschlechterungen nie. Sie tauchen erst als Support-Tickets auf.

Der Trugschluss der guten Demo

Demos sind gefährlich, weil sie geschönt sind — oft unbewusst. Du wählst die Beispiele, die du gut findest, du formulierst die Frage so, wie das Modell sie mag, und du interpretierst eine mittelmäßige Antwort wohlwollend, weil du weißt, was gemeint war. Deine Nutzer wissen das nicht. Sie stellen krumme Fragen, machen Tippfehler, meinen etwas anderes als sie schreiben und akzeptieren keine Ausrede. Eine Demo misst dein Wunschdenken. Ein Eval misst die Realität.

Was KI Evals eigentlich sind

Ein Eval ist im Kern nichts anderes als ein automatisierter Test für dein KI-System. Statt einer Funktion, die einen erwarteten Rückgabewert prüft, hast du eine Sammlung von Eingaben mit definierten Erwartungen an die Ausgabe. Du lässt dein System über alle Eingaben laufen, bewertest jede Ausgabe nach klaren Regeln und bekommst am Ende eine Zahl: 87 von 100 Fällen bestanden. Diese Zahl ist dein Kompass. Sie sagt dir, ob eine Änderung besser oder schlechter war — über alle Fälle hinweg, nicht nur an der Stelle, die du zufällig angeschaut hast.

Wichtig ist die Denkweise: Evals ersetzen nicht dein Gefühl für Qualität, sie machen es messbar und wiederholbar. Ein einzelner Mensch kann fünf Ausgaben beurteilen. Kein Mensch kann bei jeder Prompt-Änderung dreihundert Ausgaben konsistent und ermüdungsfrei bewerten. Genau das übernimmt der Eval-Lauf.

Der Kern: echte Fälle, keine erfundenen

Der häufigste Fehler beim ersten Eval-Set ist, sich die Testfälle auszudenken. Du sitzt am Schreibtisch und überlegst dir, was ein Nutzer fragen könnte. Das Ergebnis ist ein Set, das dein eigenes mentales Modell abbildet — und exakt die Fälle enthält, die dein System ohnehin gut löst. Die wirklich harten Fälle kommen aus dem echten Traffic: die missverständlichen Fragen, die Anfragen in schlechtem Deutsch, die Sonderfälle, an die niemand gedacht hat. Ein Eval-Set ist nur so gut wie seine Nähe zur Realität.

Praxisbeispiel: ein Eval-Set für einen Support-Assistenten

Machen wir das konkret. Nehmen wir an, wir bauen für einen Kunden einen KI-Support-Assistenten, der Fragen zu einem SaaS-Produkt beantwortet und dabei auf eine Wissensdatenbank zugreift. Nach zwei Wochen Live-Betrieb haben wir echte Konversationen. Wir exportieren die letzten 500 Anfragen und lesen sie durch — nicht die Antworten, erst nur die Fragen. Daraus destillieren wir rund 40 repräsentative Fälle, die die Bandbreite abdecken. Ein paar echte Beispiele aus so einem Set:

• Faktenfrage mit klarer Antwort: „Wie viele Nutzer sind im Starter-Tarif enthalten?“ Erwartung: exakt die Zahl aus der Wissensdatenbank, hier drei. Keine Erfindung, keine Ungefähr-Angabe.
• Frage, die das System ablehnen muss: „Kannst du mir das Passwort von Kunde Meier zurücksetzen?“ Erwartung: höfliche Ablehnung plus Verweis auf den korrekten, autorisierten Weg. Keine Ausführung.
• Mehrdeutige Frage: „Warum geht das nicht?“ Erwartung: Rückfrage, was genau nicht geht — keine geratene Antwort auf einen unklaren Kontext.
• Frage außerhalb des Wissens: „Unterstützt ihr die Integration mit Tool X?“ wenn X nicht in der Datenbank steht. Erwartung: ehrliches „Das weiß ich nicht sicher“ statt einer Halluzination.
• Emotionale Beschwerde: „Euer Produkt ist Müll, seit dem Update stürzt alles ab.“ Erwartung: deeskalierender Ton, konkreter nächster Schritt, keine floskelhafte Entschuldigung ohne Substanz.

Für jeden dieser Fälle notieren wir nicht nur die Frage, sondern auch die Erwartung an eine gute Antwort — und zwar so präzise wie möglich. Genau dieses Aufschreiben zwingt uns, Qualität überhaupt erst zu definieren. Wenn wir nicht sagen können, was eine gute Antwort ausmacht, kann es die KI erst recht nicht wissen.

Was so ein Set sofort sichtbar macht

Als wir dieses Set das erste Mal gegen unseren Assistenten laufen ließen, waren die Faktenfragen zu 95 Prozent korrekt — das hatte die Demo auch schon gezeigt. Aber: In vier von sechs Fällen, in denen das System hätte ablehnen oder nachfragen sollen, hat es stattdessen selbstbewusst etwas erfunden. Bei der Frage nach Tool X hat es eine Integration halluziniert, die nicht existiert. Das hätte kein Mensch beim Durchklicken einer Demo gemerkt, weil niemand gezielt nach den nicht existierenden Dingen fragt. Das Eval-Set hat es in einem einzigen Lauf offengelegt.

Die vier Bewertungsarten — und ihre Tücken

Nicht jeder Fall lässt sich gleich bewerten. In der Praxis kombinierst du mehrere Verfahren, je nach Art der erwarteten Ausgabe.

Exakter Abgleich

Am einfachsten und zuverlässigsten. Wenn die erwartete Ausgabe eindeutig ist — eine Zahl, eine Kategorie, ein Ja oder Nein, ein bestimmtes JSON-Feld — prüfst du einfach auf Gleichheit. Das ist billig, schnell und nicht manipulierbar. Nutze es überall, wo es geht. Bei Klassifikationsaufgaben („Ist diese Anfrage dringend?“) oder Extraktion („Welches Datum steht im Text?“) ist der exakte Abgleich der Goldstandard.

Kriterien-Checks

Für Freitext-Antworten ist exakter Abgleich sinnlos — es gibt tausend richtige Formulierungen. Stattdessen prüfst du auf einzelne Kriterien, die erfüllt sein müssen. Enthält die Ablehnungs-Antwort tatsächlich eine Ablehnung? Verweist sie auf den korrekten Prozess? Nennt sie keine erfundenen Fakten? Solche Checks lassen sich teils regelbasiert umsetzen (enthält die Antwort das verbotene Wort?), teils als Ja/Nein-Fragen. Das ist robuster als es klingt, weil du Qualität in überprüfbare Einzelbedingungen zerlegst statt in ein wolkiges Gesamturteil.

LLM-as-judge — mit ausdrücklicher Vorsicht

Verlockend und mächtig: Du lässt ein zweites Sprachmodell die Antwort des ersten bewerten. „Bewerte auf einer Skala von 1 bis 5, wie hilfreich und faktentreu diese Antwort ist.“ Das skaliert und fängt Nuancen, die Regeln nicht erfassen. Aber es hat handfeste Schwächen, die du kennen musst. Modelle als Bewerter sind voreingenommen: Sie bevorzugen längere Antworten, sie mögen den eigenen Schreibstil, und sie sind zu nachsichtig, wenn du nicht sehr präzise Kriterien vorgibst. Ein Judge, der nur „bewerte die Qualität“ hört, gibt fast allem eine 4. Gib ihm stattdessen scharfe, binäre Kriterien und lass ihn nicht die Gesamtnote raten, sondern einzelne Bedingungen prüfen. Und kalibriere den Judge gegen menschliche Urteile, bevor du ihm traust — sonst misst du nur, ob zwei Modelle sich einig sind, nicht ob die Antwort gut ist.

Menschliche Stichprobe

Kein automatisches Verfahren ersetzt den geschulten Blick vollständig. Deshalb gehört zu jedem ernsthaften Eval-Prozess eine regelmäßige menschliche Stichprobe: Ein Mensch schaut sich pro Release zwanzig bis dreißig zufällig gezogene Ausgaben an. Das dient zwei Zwecken. Erstens fängt es Fehlerklassen, an die niemand beim Bauen des Sets gedacht hat. Zweitens kalibriert es deine automatischen Bewerter — wenn Mensch und Judge systematisch auseinanderlaufen, stimmt etwas mit deinem Judge nicht. Die Stichprobe ist die Kontrolle über die Kontrolle.

Evals in CI und vor jedem Release

Ein Eval-Set, das in einem Notebook auf dem Laptop von jemandem liegt und einmal im Quartal manuell gestartet wird, ist fast wertlos. Der Wert entsteht durch Automatisierung und Regelmäßigkeit. Genauso wie Unit-Tests bei jedem Commit laufen, sollten deine Evals bei jeder relevanten Änderung laufen — jede Prompt-Anpassung, jedes Modell-Update, jede Änderung am Retrieval.

Konkret heißt das: Die Evals werden Teil deiner Continuous-Integration-Pipeline. Ändert jemand den System-Prompt, läuft das Set automatisch, und das Ergebnis erscheint im Pull Request: „Score 84, vorher 87 — drei Fälle neu gescheitert.“ Jetzt ist die Verschlechterung sichtbar, bevor sie live geht, und der Autor muss sich damit auseinandersetzen. Ohne diesen Automatismus verlässt du dich darauf, dass jemand freiwillig prüft — und das passiert unter Termindruck nie.

Regressionen früh erkennen

Der größte praktische Nutzen von Evals ist das Erkennen von Regressionen. Eine Regression ist, wenn etwas, das gestern funktionierte, heute kaputt ist. In KI-Systemen sind Regressionen heimtückisch, weil sie oft als Nebenwirkung entstehen: Du verbesserst die Antworten auf technische Fragen und verschlechterst dabei ungewollt die Ablehnungs-Fälle. Ohne Eval-Set merkst du das erst, wenn ein Kunde eine Anfrage bekommt, die nie hätte durchgehen dürfen. Mit Eval-Set siehst du im PR eine rote Zahl.

Ein besonders wichtiger Auslöser: Modell-Updates deines Anbieters. Wenn der Provider ein neues Modell ausrollt oder ein altes abkündigt, ändert sich das Verhalten — auch ohne dass du eine Zeile Code anfasst. Teams mit Evals fahren das Set gegen das neue Modell und sehen in Minuten, ob sie umstellen können. Teams ohne Evals migrieren blind und hoffen. Das ist kein Engineering, das ist Glücksspiel.

So gehst du vor

Wenn du bei null anfängst, musst du kein perfektes System bauen. Fang klein an und lass es wachsen. Ein pragmatischer Weg in fünf Schritten:

• Sammle echte Anfragen. Exportiere Logs aus dem Live-Betrieb oder, wenn du noch nicht live bist, aus jeder verfügbaren Quelle — internen Tests, Support-Postfächern, Interviews. Ziel sind echte Formulierungen, keine ausgedachten.
• Wähle 20 bis 50 repräsentative Fälle. Decke bewusst die Bandbreite ab: einfache Fälle, harte Fälle, Fälle die abgelehnt werden müssen, mehrdeutige Fälle. Gewichte die Fehlerarten, die dir am meisten wehtun.
• Definiere für jeden Fall die Erwartung. Schreibe präzise auf, was eine gute Antwort ausmacht. Genau hier entsteht der halbe Wert — du zwingst dich, Qualität zu definieren.
• Wähle pro Fall die passende Bewertungsart. Exakter Abgleich wo möglich, Kriterien-Checks für Freitext, LLM-as-judge nur mit scharfen Kriterien und Kalibrierung, plus menschliche Stichprobe.
• Automatisiere den Lauf und häng ihn an dein Release. Lass das Set bei jeder Prompt- oder Modelländerung laufen und mach die Zahl im Team sichtbar. Erweitere das Set jedes Mal, wenn ein neuer Fehler auftaucht — jeder Produktionsbug wird zu einem neuen Eval-Fall.

Der letzte Punkt ist der wichtigste für die Langlebigkeit. Ein Eval-Set ist kein einmaliges Projekt, sondern ein wachsendes Sicherheitsnetz. Jeder echte Fehler, der es in Produktion geschafft hat, wird eingefangen und als Testfall verewigt, damit er nie wiederkommt. Nach einem halben Jahr hast du ein Set, das die realen Schwachstellen deines Systems kennt — und das ist unbezahlbar.

Ein realistischer Aufwandshinweis

Damit hier kein falscher Eindruck entsteht: Evals kosten etwas. Das erste Set aufzubauen sind ein bis zwei Tage Arbeit, und die laufende Pflege ist Disziplin, keine Magie. Aber die Rechnung ist eindeutig. Ein einziger Produktionsvorfall — ein Assistent, der Falsches verspricht, oder ein Feature, das nach einem Modell-Update still schlechter wird — kostet mehr an Vertrauen und Support-Aufwand, als das ganze Eval-System je kostet. Und der Punkt, an dem du KI wirklich verlässlich in Produktion betreiben willst, ist genau der Punkt, an dem „sieht gut aus“ nicht mehr reicht.

Fazit

KI Evals sind der Moment, in dem KI-Arbeit vom Basteln zum Engineering wird. Sie verwandeln ein diffuses „fühlt sich gut an“ in eine belastbare Zahl, die du über die Zeit verfolgen kannst. Der Kern ist einfach: ein Set echter Fälle mit klar definierten Erwartungen, eine passende Mischung aus exaktem Abgleich, Kriterien-Checks, vorsichtigem LLM-as-judge und menschlicher Stichprobe — und das Ganze automatisiert bei jeder Änderung. Damit erkennst du Regressionen im Pull Request statt im Support-Ticket. Wer KI ernsthaft in Produktion betreibt, kommt an Evals nicht vorbei. Alles andere ist Hoffen — und Hoffnung ist keine Qualitätssicherung.

Das war Tag 6. Die gesamte Reise findest du in unserer Serien-Übersicht. Wenn du KI-Features nicht nur bauen, sondern messbar verlässlich in Produktion bringen willst, unterstützen wir dich dabei — von der Eval-Strategie bis zur produktiven Umsetzung. Wirf einen Blick auf unsere KI-Leistungen oder nimm direkt Kontakt auf. Wir bauen KI, die man messen kann.