Evals statt Bauchgefühl: Warum KI-Features ohne Messung scheitern

Das Feature, das im Meeting funktioniert

Es gibt einen Moment, den jedes Team kennt, das gerade sein erstes KI-Feature gebaut hat. Der Prototyp läuft, jemand tippt eine Frage ein, das Modell antwortet flüssig und klug, und im Raum macht sich dieses warme Gefühl breit: Das funktioniert. Drei Wochen später geht es live, und plötzlich erfindet derselbe Chatbot Bestellnummern, die es nie gab, der Zusammenfasser kürzt den entscheidenden Absatz weg, und der Klassifizierer schiebt jede zweite Reklamation in die falsche Schublade.

Die unbequeme Frage in der nachfolgenden Krisensitzung lautet immer gleich: Um wie viel ist es schlechter geworden – und ab wann war es das? Und niemand kann sie beantworten. Es gibt keine Zahl, keinen Vergleich, kein Vorher. Es gab nur ein gutes Gefühl in einem Demo.

Das ist Demo-Driven Development, und es ist die häufigste Art, wie KI-Projekte scheitern. Nicht weil das Modell zu schwach wäre, sondern weil niemand je gemessen hat, was es tatsächlich leistet. Ein Demo zeigt, dass ein System im besten Fall funktionieren kann. Über den Normalfall, über die langen Ränder der echten Nutzung, über Regressionen sagt es exakt nichts.

Was ein Eval eigentlich ist

Die Antwort auf dieses Problem ist alt und unspektakulär: messen. In der KI-Entwicklung heißt das Werkzeug Eval – kurz für Evaluation. Und es ist im Kern erstaunlich simpel:

1. Ein Datensatz repräsentativer Eingaben. Echte Beispiele, mit denen das Feature in Produktion konfrontiert wird – die typischen, die kniffligen, die ärgerlichen. Nicht die drei schönen Fälle aus dem Demo.
2. Eine Methode, die Ausgaben zu bewerten. Eine Funktion, die für jede Eingabe sagt: gut oder schlecht, richtig oder falsch, eine Zahl zwischen 0 und 1.

Das ist alles. Ein Eval ist für ein KI-Feature, was ein Test für normalen Code ist: eine wiederholbare, automatisierte Aussage darüber, ob das System tut, was es soll. Wer Software baut, ohne Tests zu schreiben, gilt zu Recht als leichtsinnig. Wer KI-Features baut, ohne Evals zu schreiben, tut genau dasselbe – nur merkt es lange niemand, weil das Modell auch falsch noch souverän klingt.

Wie man bewertet, hängt von der Aufgabe ab:

• Strukturierte Aufgaben lassen sich hart prüfen. Soll das Modell eine Rechnung in JSON zerlegen, eine Mail in eine von fünf Kategorien einsortieren oder eine Zahl extrahieren, dann gibt es eine richtige Antwort. Exact-Match, Assertions, Schema-Validierung – wie ein klassischer Unit-Test.
• Offene Aufgaben brauchen ein weicheres Urteil. Bei einer Zusammenfassung, einer Antwort im Support-Chat, einem generierten Text gibt es kein einziges korrektes Ergebnis. Hier hilft entweder ein menschliches Rating oder ein zweites Modell als Gutachter – LLM-as-Judge –, das anhand klarer Kriterien Punkte vergibt.
• Golden Datasets sind der Kern: ein kuratierter Satz von Eingaben mit der jeweils erwarteten oder idealen Ausgabe, gegen den man immer wieder prüft.

Sammelt man diese Beispiele und lässt sie bei jeder Änderung automatisch durchlaufen, hat man eine Regression-Suite – die einzige Instanz, die einem ehrlich sagt, ob die letzte „Verbesserung" wirklich eine war.

Warum das bei KI mehr zählt als bei normalem Code

An dieser Stelle könnte man einwenden: Tests kennen wir doch, das ist nichts Neues. Stimmt – und trotzdem ist die Lage bei KI grundlegend gefährlicher. Aus zwei Gründen.

Erstens: Änderungen sind nicht-deterministisch. Klassischer Code tut bei gleicher Eingabe immer dasselbe. Ein Sprachmodell nicht. Dieselbe Anfrage kann heute eine gute und morgen eine schlechte Antwort liefern. Eine einzelne Stichprobe – „ich hab's eben ausprobiert, sah gut aus" – ist deshalb wertlos. Man braucht viele Beispiele und eine Verteilung, kein Anekdötchen.

Zweitens, und das ist der eigentlich brisante Punkt: Änderungen sind global. In normalem Code ist eine Änderung lokal. Man ändert eine Funktion, und nur was diese Funktion aufruft, ist betroffen. Bei KI ist jede relevante Stellschraube global. Man formuliert eine Zeile im Prompt um, tauscht das Modell gegen eine neue Version, dreht an der Temperatur – und das beeinflusst potenziell jede Ausgabe gleichzeitig.

Genau hier liegt die Falle. Man optimiert den Prompt, damit das Modell höflicher antwortet, freut sich über die drei Fälle, die man gegenprüft – und merkt nicht, dass dieselbe Änderung die Trefferquote bei der Datenextraktion still um 30 % gesenkt hat. Ohne Eval sieht man das nicht. Man sieht es erst, wenn die Kunden es sehen.

Dieses Risiko wird konkret in dem Moment, in dem man ein Modell wechselt – und das passiert ständig, weil Anbieter Versionen abkündigen, neue Modelle billiger oder schneller sind. Der Wechsel von einem Claude- oder GPT-Modell auf das nächste ist kein Drop-in. Das neue Modell ist im Schnitt vielleicht besser und in genau dem Teilbereich, der für das eigene Produkt zählt, trotzdem schlechter. Ohne Eval ist so ein Wechsel ein Blindflug mit verbundenen Augen. Mit Eval ist es eine Zahl: vorher 87 %, nachher 91 %, der Format-Fehler ist von 4 % auf 1 % gefallen – grünes Licht.

Was man eigentlich misst

„Gut oder schlecht" ist ein Anfang, aber ein zu grobes Maß. Ein brauchbarer Eval zerlegt Qualität in Dimensionen, die man einzeln verfolgen kann. Welche das sind, hängt vom Feature ab – aber dieser Katalog deckt die meisten Fälle ab:

• Task-Erfolg. Die Kernfrage: Hat das System die Aufgabe gelöst? Die richtige Kategorie getroffen, die korrekte Zahl geliefert, die brauchbare Antwort gegeben.
• Faithfulness / Halluzinationsrate. Bei allem, was auf Quellen beruht – RAG, Zusammenfassungen, Q&A über Dokumente –, die wichtigste Zahl überhaupt: Wie oft behauptet das Modell etwas, das nicht in der Quelle steht? Eine flüssige, selbstbewusste Erfindung ist gefährlicher als ein ehrliches „weiß ich nicht".
• Format-Treue. Wenn nachgelagerte Systeme die Ausgabe weiterverarbeiten, muss das Format stimmen. Valides JSON, das richtige Schema, keine Fließtext-Vorrede vor dem Code. Ein einziges Feld zu viel kann eine ganze Pipeline brechen.
• Latenz und Kosten. Auch wenn die Qualität stimmt: Ein Feature, das pro Antwort 30 Sekunden braucht oder das Token-Budget sprengt, ist in Produktion untauglich. Beides gehört in den Eval, nicht erst in die Rechnung am Monatsende.
• Refusal- und Übervorsichts-Rate. Das stille Gegenstück zur Halluzination: Modelle, die zu oft mit „das kann ich nicht beantworten" abblocken, obwohl sie es könnten und sollten. Übermäßige Vorsicht ist genauso ein Produktfehler wie übermäßige Erfindung.
• Failure-Mode-Buckets. Das Wertvollste an einem reifen Eval ist nicht die Gesamtnote, sondern die Sortierung der Fehler nach Typ. Scheitert das Modell an langen Eingaben? An einer bestimmten Sprache? An Tabellen? Erst die Cluster zeigen, woran man als Nächstes arbeiten muss.

Eine einzige Prozentzahl ist beruhigend und führt in die Irre. Erst die Aufschlüsselung verwandelt einen Eval von einer Note in ein Diagnosewerkzeug.

Wo sich der Aufwand nicht lohnt

Jetzt der ehrliche Teil – sonst zieht man die falschen Schlüsse und baut Eval-Infrastruktur für Dinge, die sie nicht brauchen.

Evals sind nicht gratis. Ein guter Datensatz will kuratiert, ein LLM-Judge will kalibriert, die Suite will gewartet werden, wenn sich die Anforderungen ändern. Dieser Aufwand ist nur gerechtfertigt, wenn das Feature ihn wert ist. Für einen Wegwerf-Prototyp, ein internes Skript, das eine Person zweimal im Monat nutzt, oder eine einmalige Datenmigration ist „probier's aus und schau drauf" völlig legitim. Vibes sind bei niedrigem Einsatz eine vernünftige Strategie. Niemand schreibt Unit-Tests für ein Bash-Einzeiler, und niemand sollte einen Golden Dataset für ein Wochenend-Experiment bauen.

Es gibt noch eine zweite, subtilere Gefahr: den Goodhart-Effekt. „Wird ein Maß zum Ziel, taugt es nicht mehr als Maß." Wer seinen Prompt so lange gegen denselben 50-Beispiele-Datensatz optimiert, bis die Zahl auf 99 % steht, hat womöglich nur gelernt, diese 50 Beispiele zu lösen – und nichts darüber hinaus. Ein veralteter Eval-Satz, gegen den man monatelang trainiert, wird selbst zur Illusion von Qualität. Deshalb muss der Datensatz leben: regelmäßig erweitert, mit echten neuen Fehlerfällen gefüttert, gelegentlich gegen ein frisches, ungesehenes Set geprüft.

Die Linie verläuft nicht zwischen „Evals immer" und „Evals nie", sondern entlang des Einsatzes. Proportionaler Rigor, keine Zeremonie. Ein kundenkritisches KI-Feature, an dem Umsatz oder Vertrauen hängt, verdient eine ernsthafte Eval-Suite. Ein internes Hilfswerkzeug verdient einen prüfenden Blick und gut. Die Kunst ist, ehrlich einzuordnen, in welcher Kategorie man gerade arbeitet.

Wie man anfängt

Der häufigste Grund, warum Teams keine Evals haben, ist nicht Ablehnung – es ist die Vorstellung, das sei ein riesiges Projekt. Ist es nicht. Der Einstieg ist klein und konkret:

1. Mit 20 bis 50 echten Beispielen anfangen. Nicht erfunden, nicht idealisiert. Greif in echte oder realistische Eingaben und schreib für jede auf, wie eine gute Antwort aussieht. Schon dieser Akt – das Erwartete zu formulieren – schärft das Verständnis des Features mehr als jedes Demo.
2. Sie bewerten. Für strukturierte Aufgaben eine harte Assertion. Für offene Aufgaben anfangs ruhig ein menschliches Rating in einer Tabelle, später ein LLM-Judge mit klaren Kriterien. Perfekt muss es nicht sein, nur konsistent.
3. In die CI verdrahten. Der entscheidende Schritt: Der Eval läuft automatisch bei jeder Prompt-Änderung, jedem Modellwechsel, jedem Pull Request. Genau wie die Unit-Tests. Eine Änderung, die die Trefferquote senkt, wird sichtbar, bevor sie live geht – nicht danach.
4. Aus Produktionsfehlern wachsen lassen. Jeder echte Fehler in Produktion ist ein Geschenk: Er wird zum nächsten Eval-Fall. So wächst der Datensatz organisch genau in die Richtung, in der das System schwach ist, und jeder einmal gefixte Fehler bleibt für immer gefixt.

Nach ein paar Wochen hat man, fast nebenbei, eine Regression-Suite, die einem den Rücken freihält. Und das Gefühl beim nächsten Modellwechsel ist ein völlig anderes – nicht „hoffentlich bricht nichts", sondern „die Zahlen sagen, es ist besser geworden".

Fazit

Ernsthafte KI-Arbeit ist Engineering, kein Prompt-Roulette. Der Unterschied zwischen einem Team, das ein KI-Feature in Produktion zuverlässig betreibt, und einem, das von einer Krisensitzung zur nächsten stolpert, ist selten das Modell. Es ist die Frage, ob jemand misst.

Ein Demo erzeugt ein Gefühl. Ein Eval erzeugt eine Zahl – und nur Zahlen lassen sich vergleichen, verfolgen und verbessern. Ohne sie fliegt jedes Team blind: Es kann Regressionen nicht erkennen, Modelle nicht gefahrlos tauschen, Prompts nicht systematisch verbessern und am Ende nicht einmal sagen, ob das Produkt heute besser ist als letzte Woche.

Evaluation-Driven Development ist für KI-Features, was Tests für Software sind: kein Luxus, sondern die Grundlage, auf der man überhaupt erst seriös bauen kann. Man muss nicht groß anfangen. Aber man muss anfangen zu messen. Alles andere ist Hoffnung – und Hoffnung ist keine Strategie für ein Produkt, dem Menschen vertrauen sollen.