In den meisten KI-Projekten kommt der Moment, in dem jemand sagt: «Sieht wirklich gut aus, gehen wir live.» Meist stützt sich dieses Urteil auf ein Dutzend handverlesener Beispiele, die in einem Meeting ausprobiert wurden. Dann trifft das System auf echten Betrieb, und die Fragen beginnen. Warum hat es ein Lieferdatum erfunden? Warum ist es schlechter geworden, seit wir den Prompt geändert haben? Ist es besser oder schlechter als letzten Monat?
Keine dieser Fragen lässt sich ohne Evaluationen beantworten, kurz Evals: ein fester Satz von Testfällen mit bekannten richtigen Antworten, der automatisch läuft, jedes Mal, wenn sich etwas ändert. Evals sind für KI-Systeme, was automatisierte Tests für Software sind. Niemand würde einen Zahlungsdienst ohne Tests ausliefern; ein KI-System, das Rechnungen liest oder Kunden antwortet, verdient dieselbe Disziplin.
Bei der Arbeit beginnen, nicht beim Modell
Ein brauchbares Eval-Set entsteht aus dem Prozess, den das System unterstützt, nicht aus allgemeinen Benchmarks. Öffentliche Ranglisten zeigen, wie ein Modell bei Prüfungsfragen abschneidet. Sie sagen nichts darüber, ob es das richtige Fälligkeitsdatum aus den Rechnungen Ihrer Lieferanten liest.
Deshalb sammeln wir zuerst echte Fälle, wo nötig anonymisiert:
- Typische Fälle, im Verhältnis, in dem sie tatsächlich vorkommen. Sind 70 % der Bestellungen einfache Nachbestellungen, sollten es 70 % des Sets auch sein.
- Schwierige Fälle, die die Fachleute kennen: der Lieferant, der den Gesamtbetrag auf Seite zwei setzt, die Kundin, die in drei Sprachen schreibt.
- Fälle, in denen «weiss ich nicht» die richtige Antwort ist: fehlende Daten, Fragen ausserhalb des Auftrags, widersprüchliche Dokumente. Ein System, das immer antwortet, ist gefährlicher als eines, das manchmal ablehnt.
- Angriffsfälle: Eingaben, die das System zu Fehlverhalten bringen wollen, etwa eine E-Mail mit Anweisungen an die KI.
Fünfzig gut gewählte Fälle schlagen fünfhundert zufällige. Das Set wächst mit der Zeit: Jeder Fehler aus dem Betrieb wird ein neuer Testfall, damit derselbe Fehler nicht unbemerkt zurückkommt.
Messen, was fürs Geschäft zählt
«Genauigkeit» klingt einfach, verbirgt aber Entscheidungen. Bei einem Agenten für die Rechnungsverarbeitung ist ein falscher Betrag viel schlimmer als eine fehlende Bestellnummer. Bei einem Wissensassistenten mag eine Antwort ohne Quelle für interne FAQ akzeptabel sein, für Compliance-Fragen nicht.
Die Kennzahlen vereinbaren wir mit den Verantwortlichen des Prozesses, typischerweise:
- Korrektheit pro Feld oder pro Antwort, gewichtet danach, was ein Fehler kostet.
- Quellentreue: Ist jede Aussage durch eine Quelle gedeckt, die das System tatsächlich gefunden hat?
- Qualität der Ablehnung: Lehnt das System ab, wenn es soll, und nur dann?
- Latenz und Kosten pro Fall, denn eine richtige Antwort, die eine Minute dauert oder einen Franken kostet, kann den Business Case trotzdem verfehlen.
Jede Kennzahl erhält einen Schwellenwert, der vor dem Go-live erreicht sein muss. Der Schwellenwert wird festgehalten, bevor die Resultate bekannt sind, damit niemand in Versuchung kommt, die Torpfosten zu verschieben.
Die Bewertung automatisieren, dann den Bewerter prüfen
Manche Antworten lassen sich mechanisch prüfen: Ein ausgelesener Betrag stimmt oder er stimmt nicht. Freitext ist schwieriger. Hier kann ein zweites Modell als Bewerter dienen und die Antwort mit einer Referenz und einem Bewertungsraster vergleichen. Das funktioniert gut, aber nur, wenn der Bewerter selbst validiert ist: Menschen bewerten eine Stichprobe, wir vergleichen, und wir vertrauen dem automatischen Bewerter nur dort, wo er mit ihnen übereinstimmt.
Evals hören nie auf
Mit dem Go-live endet die Evaluation nicht. Anbieter aktualisieren ihre Modelle, Dokumente ändern sich, Nutzer finden neue Formulierungen. Drei Gewohnheiten verhindern, dass die Qualität abdriftet:
- Das ganze Eval-Set bei jeder Änderung laufen lassen: neuer Prompt, neue Modellversion, neue Sucheinstellung. Sinkt ein Wert, geht die Änderung nicht live.
- Stichproben aus dem Betrieb regelmässig von Menschen prüfen lassen, mit maskierten Personendaten.
- Warnsignale überwachen: steigende Ablehnungsraten, mehr manuelle Korrekturen, längere Antworten, höhere Kosten.
Was das in der Praxis bedeutet
Bevor ein Pilot live geht, sollten Sie einen kurzen Bericht sehen können: das Eval-Set, die vereinbarten Kennzahlen, die Schwellenwerte und die Resultate, mit Beispielen, wo das System scheitert. Kann ein Anbieter Ihnen das nicht zeigen, lautet die ehrliche Antwort auf «Ist es bereit?»: «Das wissen wir noch nicht.»
Dieser Bericht ist auch das beste Werkzeug für den nächsten Entscheid. Er zeigt, welche Fehler bleiben, was sie kosten würden und ob mehr Arbeit, ein anderes Modell oder ein Freigabeschritt durch einen Menschen der günstigste Weg ist, sie zu beheben.