Evaluation (Eval-Harness)
Definition
Evaluation macht die Qualität einer KI-Anwendung messbar: Ein fester Satz repräsentativer Fälle mit bekannten Sollantworten prüft jede Änderung - neuer Prompt, neues Modell, neue Datenquelle.
Ohne Evaluation bleibt Qualität Gefühlssache: „Es funktioniert eigentlich ganz gut“ ist keine Grundlage für Entscheidungen. Ein Eval-Harness ist die Testinfrastruktur, die eine Sammlung von Beispielen automatisiert durchspielt und die Ergebnisse gegen die erwarteten Antworten bewertet - teils per Regel, teils per LLM-as-a-Judge. So sieht man schwarz auf weiß, ob eine Änderung besser oder schlechter macht.
Diese systematische Messung ist zugleich das Rückgrat der Compliance. Wer belegen muss, dass ein KI-System zuverlässig arbeitet - etwa im Rahmen des EU AI Act -, braucht genau solche nachvollziehbaren, wiederholbaren Prüfungen. Evaluation verwandelt KI-Entwicklung von Ausprobieren in messbares Ingenieurhandwerk.
In der Praxis
Ein Möbelhersteller tauscht das Modell hinter seiner Produktberatung
Ein Hersteller von Büromöbeln betreibt auf seiner Händlerseite einen Assistenten, der Fragen zu Maßen, Belastbarkeit, Materialkombinationen und Lieferzeiten beantwortet. Nach einem Jahr steht ein Modellwechsel an: Der Nachfolger ist günstiger und schneller. Die Frage ist nur, ob er auch gleich gut antwortet.
Ohne Evaluation ließe sich das erst am Beschwerdeaufkommen ablesen - also zu spät und auf Kosten der Händler. Stattdessen legt das Unternehmen einen Prüfsatz an: 120 echte Fragen aus dem letzten Jahr, jeweils mit der fachlich abgenommenen Sollantwort, bewusst nach Fallgruppen geschnitten - Standardauskünfte, Materialkombinationen, Sonderanfertigungen, Fragen mit harten Zahlenwerten wie Belastungsgrenzen und Lieferfristen, und Fragen, die in eine Rechtsauskunft kippen könnten.
Der Vergleich lief dann in einer Stunde statt in Wochen. Aufschlussreich war nicht die Gesamtquote, sondern eine einzelne Fallgruppe: Bei Fragen mit harten Zahlenwerten rundete das neue Modell häufiger, statt den Wert aus dem Datenblatt zu übernehmen. Aus „belastbar bis 120 kg“ wurde „rund 100 kg“. Über alle Gruppen gemittelt fiel das nicht auf, weil das neue Modell anderswo besser abschnitt - und genau diese Gruppe ist die, aus der Reklamationen entstehen. Der Wechsel kam trotzdem, aber mit einer Prüfregel, die jede Zahl in der Antwort gegen die Quelle hält.
Abgrenzung
Nicht zu verwechseln mit
- Observability
- Observability zeigt, was im laufenden Betrieb tatsächlich passiert ist - rückblickend, auf echten Anfragen. Evaluation prüft vorausschauend, gegen einen festen Satz bekannter Fälle, bevor eine Änderung live geht. Die beiden brauchen einander: Auffällige Fälle aus der Observability werden zu neuen Testfällen in der Evaluation.
- Red Teaming
- Evaluation misst den Normalfall: Tut das System, was es soll? Red Teaming sucht gezielt den Missbrauchsfall: Lässt es sich zu etwas bringen, was es nicht soll? Eine gute Evaluationsnote sagt nichts über die Angreifbarkeit aus - beide Prüfungen beantworten verschiedene Fragen und ersetzen sich nicht.
- Klassische Softwaretests
- Ein Unit-Test kennt genau ein richtiges Ergebnis und schlägt sonst fehl. Bei KI-Antworten gibt es viele richtige Formulierungen, deshalb misst Evaluation nicht Gleichheit, sondern Eigenschaften - Deckung durch die Quelle, Vollständigkeit, Format. Entsprechend ist das Ergebnis kein Grün oder Rot, sondern eine Quote, die man über die Zeit beobachtet.
Fehlerbilder
Worauf es ankommt
Der Testsatz besteht aus Wunschfragen
Wenn das Projektteam sich die Testfälle ausdenkt, entstehen die Fragen, die das System gut beantwortet - sauber formuliert, eindeutig, mit einer Antwort im Dokument. Echte Anfragen sind unvollständig, doppeldeutig und enthalten zwei Fragen in einem Satz. Ziehen Sie die Fälle aus dem echten Posteingang oder den Gesprächsprotokollen, sonst misst der Testsatz die eigene Vorstellung statt der Wirklichkeit.
Keine Sollantwort hinterlegt
Ein Testsatz ohne festgehaltene erwartete Antwort ist kein Testsatz, sondern eine Fragensammlung. Die Bewertung fällt dann auf „sieht plausibel aus“ zurück - und plausibel aussehen ist genau die Eigenschaft, die auch falsche Antworten haben. Die Sollantwort muss nicht wörtlich sein, aber sie muss festhalten, welche Aussagen vorkommen müssen und welche nicht vorkommen dürfen.
Der Testsatz wächst nicht mit
Jeder Fehler, den ein Nutzer im Betrieb meldet, gehört als neuer Fall in den Testsatz - sonst tritt derselbe Fehler nach dem nächsten Umbau wieder auf. Teams, die das unterlassen, reparieren dieselbe Sache mehrfach und wundern sich über Rückschritte. Der Testsatz ist ein lebendes Dokument, und sein Wachstum ist ein gutes Zeichen, kein schlechtes.
Nur auf den Durchschnitt schauen
Eine hohe Gesamtquote klingt beruhigend und verbirgt, dass eine bestimmte Fallgruppe nahezu vollständig scheitert - wenn sie klein genug ist, verschwindet sie im Mittelwert. Genau diese Gruppe ist oft die teure: die Sonderfälle, die Beschwerden auslösen. Werten Sie nach Fallgruppen aus, nicht nur über alles hinweg.
Häufige Fragen
Was zu Evaluation (Eval-Harness) oft gefragt wird
Wie viele Testfälle brauchen wir für eine sinnvolle Evaluation?
Für den Einstieg reichen in aller Regel 50 bis 100 gut ausgewählte Fälle, sofern sie die tatsächliche Bandbreite abbilden - also nicht fünfzig Varianten derselben Standardfrage, sondern die häufigsten Fallgruppen plus die bekannten Problemfälle. Ein kleiner, sorgfältig kuratierter Satz ist deutlich nützlicher als tausend automatisch erzeugte Fragen, weil Sie ihn vollständig verstehen und Abweichungen einordnen können. Der Satz wächst danach ohnehin aus dem Betrieb heraus.
Wer sollte die Testfälle schreiben - IT oder Fachbereich?
Der Fachbereich, unbedingt. Nur dort weiß jemand, welche Antwort fachlich richtig ist und welcher Fehler teuer wird. Die IT baut die Mechanik, die den Satz automatisiert durchspielt und auswertet. Diese Arbeitsteilung ist auch der praktische Grund, warum Evaluation oft liegen bleibt: Sie kostet Zeit von Menschen, die ohnehin ausgelastet sind - planen Sie diese Zeit ausdrücklich ein, statt sie nebenbei zu erwarten.
Was kostet der Aufbau eines Eval-Harness?
Die Technik ist der kleinere Teil: Ein einfacher Harness, der Fälle durchspielt und Ergebnisse gegen Kriterien bewertet, ist in wenigen Personentagen einsatzfähig, und jeder Durchlauf kostet nur die Inferenz für die enthaltenen Fälle - bei hundert Fällen ein Betrag im Cent- bis niedrigen Eurobereich. Der eigentliche Aufwand steckt im Kuratieren der Fälle und Sollantworten durch den Fachbereich. Dem gegenüber steht der Preis der Alternative: Änderungen live testen und Fehler von Kunden gemeldet bekommen.
Ab wann lohnt sich Evaluation?
Ab dem Moment, in dem jemand außerhalb des Projektteams die Anwendung benutzt - also vor dem ersten Produktivgang, nicht danach. Der praktische Auslöser ist meist die erste Änderung: Sobald Sie einen Prompt anpassen, ein Modell wechseln oder eine Datenquelle ergänzen wollen und niemand sagen kann, ob das Ganze dadurch besser wird, fehlt Ihnen die Evaluation. Sie später nachzurüsten ist möglich, aber bis dahin haben Sie jede Entscheidung im Blindflug getroffen.
Von der Definition zur Umsetzung?
Lassen Sie uns besprechen, wie sich das konkret in Ihrem Unternehmen anwenden lässt.
Projekt anfragen