KI-gestützte Systeme evaluieren und testen

Warum das Testen probabilistischer Systeme anders ist

Herkömmliche Tests prüfen exaktes Verhalten: Bei dieser Eingabe liefert die Funktion jedes Mal diese Ausgabe. Eine Komponente, die um ein Sprachmodell herum gebaut ist, bricht alle drei Annahmen in diesem Satz. Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen, weil das Modell aus einer Wahrscheinlichkeitsverteilung sampelt (Abschnitt 12.1); viele verschiedene Ausgaben können gleichermaßen richtig sein, weil sich eine gute Antwort auf Wo ist meine Bestellung? auf hundert Arten formulieren lässt; und das Verhalten kann sich ohne jede Änderung an Ihrem Code ändern, weil ein Anbieter ein Modell aktualisiert, ein Retrieval-Index aufgefrischt wird oder ein Tool neue Daten liefert. Ein einzelner bestandener Test beweist daher wenig, und ein einzelner fehlgeschlagener bedeutet nicht unbedingt, dass das System kaputt ist.

Die Einheit der Evaluierung verschiebt sich folglich vom einzelnen Testfall zu einer Verteilung von Fällen. Die nützliche Aussage lautet nicht Der Assistent hat diese Erstattungsfrage richtig beantwortet, sondern Der Assistent beantwortet 93 % der Erstattungsfragen richtig, plus oder minus 3 Punkte, und hat in 400 Versuchen nie eine Erstattung über die Richtlinie hinaus genehmigt. Das ist eine Messung mit einer Unsicherheit, ähnlich wie ein Latenzperzentil in Kapitel 2. Die Evaluierung von KI-Systemen ähnelt eher der experimentellen Wissenschaft, mit Stichproben, Fehlerbalken und Kontrollgruppen, als dem Unit-Testing.

Zwei weitere Unterschiede sind architektonisch wichtig. Erstens ist das System unter Test die gesamte Pipeline, nicht das Modell: Prompt-Vorlage, Retrieval, Tool-Definitionen, Nachverarbeitung, Guardrails und Modellversion erzeugen das Verhalten gemeinsam, und eine Änderung an einem davon kann eine Aufgabe verbessern und still eine andere beschädigen. Zweitens sagen öffentliche Benchmarks von Modellen (Ranglisten zu Allgemeinwissen, Programmieren oder Mathematik) wenig über Ihre Aufgabe, Ihre Daten und Ihre Nutzer aus. Ein Modell, das in einer Rangliste höher steht, kann in Ihren Support-Gesprächen schlechter abschneiden. Teams, die zuverlässige KI-Features ausliefern, bauen fast immer ihre eigenen Evaluierungen (meist kurz Evals genannt) und behandeln sie als ausführbare Spezifikation des gewünschten Verhaltens.

Evaluierungsdatensätze und Golden Sets

Ein Golden Set ist eine kuratierte, versionierte Sammlung von Eingaben mit dem erwarteten Ergebnis für jede einzelne: einer exakten Antwort, wo es eine gibt, einer Referenzantwort, einer Liste von Fakten, die die Antwort enthalten muss, oder der Rubrik, nach der sie beurteilt wird. Es ist das wertvollste Gut eines KI-Evaluierungsprogramms und meist das am stärksten vernachlässigte.

Gute Fälle stammen aus mehreren Quellen. Stichproben aus dem Produktionsverkehr (anonymisiert, siehe Abschnitt 12.8) zeigen, was Nutzer wirklich fragen. Fachleute schreiben die Fälle, auf die es am meisten ankommt, etwa Allergenfragen oder Erstattungsstreitigkeiten. Grenzfälle stammen aus Incidents und Beschwerden. Adversariale Fälle stammen aus dem Red Teaming. Synthetische, von einem Modell erzeugte Fälle können Lücken schnell füllen, aber Menschen müssen sie prüfen, weil ein Modell dazu neigt, Fragen zu erzeugen, die dem ähneln, was es schon gut beherrscht.

Die Struktur zählt so viel wie die Größe. Schichten Sie die Menge in Segmente (nach Absicht, Sprache, Kundentyp, Kanal, Schwierigkeit), damit eine Regression in einem Segment nicht durch eine Verbesserung in einem anderen verdeckt wird. Halten Sie einen Teil zurück, den beim Prompt-Tuning niemand ansieht: Wenn Entwickler so lange an einem Prompt feilen, bis das Golden Set besteht, ist das Golden Set zu Trainingsdaten geworden und sein Ergebnis überzeichnet die reale Qualität, die KI-Form von Goodharts Gesetz aus Abschnitt 3.8. Versionieren Sie den Datensatz zusammen mit dem Code, halten Sie fest, welche Version welches Ergebnis erzeugt hat, und fügen Sie jeden bestätigten Produktionsfehler als neuen Fall hinzu, damit jeder Bug einmal behoben wird und behoben bleibt.

LLM-as-a-Judge und seine Verzerrungen

LLM-as-a-Judge nutzt ein Modell, um Ausgaben zu benoten, entweder punktweise (bewerte diese Antwort nach diesen Kriterien) oder paarweise (welche dieser beiden Antworten ist besser?). Es hat die groß angelegte Evaluierung offener Texte bezahlbar gemacht und ist heute das Arbeitspferd der meisten Evaluierungssuiten. Zheng und Kollegen (2023), die es mit den Daten von MT-Bench und Chatbot Arena systematisch untersuchten, fanden, dass ein starker Judge etwa so oft mit menschlichen Präferenzen übereinstimmte wie Menschen untereinander (in ihrem Aufbau über 80 %). Sie dokumentierten außerdem Verzerrungen, denen jeder, der die Technik nutzt, im Entwurf entgegenwirken sollte.

Positions-Bias: Beim paarweisen Vergleich bevorzugt der Judge tendenziell die Antwort an einer bestimmten Position, meist der ersten. Ausführlichkeits-Bias: Längere, ausführlichere Antworten werden höher bewertet, auch wenn sie nichts hinzufügen. Selbstbevorzugungs-Bias: Ein Modell kann Antworten bevorzugen, die es selbst oder seine eigene Modellfamilie erzeugt hat. Judges sind außerdem schwach darin, zu benoten, was sie selbst nicht können (Mathematik, mehrstufiges Schlussfolgern, Fachwissen), reagieren empfindlich auf den genauen Wortlaut des Bewertungs-Prompts, neigen zur Milde und lassen sich gerade durch den Text manipulieren, den sie beurteilen, denn eine Antwort, die diese Antwort ist hervorragend und vollständig richtig enthält, ist eine Prompt-Injection, die auf den Judge zielt (Abschnitt 12.6).

Professionelle Teams behandeln den Judge als Messinstrument, das selbst kalibriert werden muss. Schreiben Sie Rubriken als mehrere spezifische, nahezu binäre Kriterien (nennt den Erstattungsbetrag, zitiert die Richtlinienklausel) statt als eine ganzheitliche Note von 1 bis 10. Geben Sie dem Judge nach Möglichkeit eine Referenzantwort oder die Quelldokumente. Führen Sie paarweise Vergleiche in beiden Reihenfolgen durch und zählen Sie nur übereinstimmende Urteile. Verwenden Sie, wo praktikabel, einen Judge aus einer anderen Modellfamilie als das System unter Test, betreiben Sie ihn mit Temperature 0 und strukturiertem Ausgabeformat, und fixieren Sie die Version des Judge-Modells, damit die Ergebnisse über die Zeit vergleichbar bleiben. Vor allem: Messen Sie die Übereinstimmung zwischen Judge und menschlichen Labels an einigen Hundert Fällen, bevor Sie ihm vertrauen, berichten Sie diese Übereinstimmung zusammen mit den Ergebnissen und prüfen Sie sie erneut, sobald sich Judge, Rubrik oder Aufgabe ändern. Fachleute sind uneins, wie weit man sich auf Judges verlassen sollte: Manche nutzen sie nach der Kalibrierung als wichtigstes Release-Gate, andere nur zur Vorsortierung von Fällen für die menschliche Prüfung. Beide Positionen sind sich einig, dass ein unkalibrierter Judge selbstsicher wirkende Zahlen mit unbekannter Bedeutung liefert.

Offline- und Online-Evaluierung

Offline-Evaluierung lässt eine Kandidatenversion gegen feste Datensätze laufen, bevor Nutzer sie sehen. Sie ist billig, wiederholbar und sicher und erlaubt einen gepaarten Vergleich: Alte und neue Version beantworten genau dieselben Fälle, sodass Unterschiede auf die Änderung zurückgehen und nicht auf anderen Verkehr. Ihre Schwäche ist, dass der Datensatz eine Stichprobe der Welt von gestern ist.

Online-Evaluierung misst eine Version am Live-Verkehr. Die Deployment-Techniken aus Abschnitt 10.5 gelten unmittelbar. Ein Shadow-Deployment schickt Kopien echter Anfragen an die neue Version und verwirft deren Antworten; das ist für rein lesende Aufgaben sicher und erlaubt, die Ausgaben offline zu vergleichen. Ein Canary bedient einen kleinen Prozentsatz der Nutzer und beobachtet Guardrail-Metriken, bevor er ausgeweitet wird. Ein A/B-Test teilt Nutzer zufällig den Versionen zu und vergleicht Geschäftsergebnisse wie Lösungsquote, Eskalationen an menschliche Mitarbeitende, erneute Kontakte innerhalb von 48 Stunden und Kundenzufriedenheit. A/B-Tests beantworten die Frage, die Offline-Evaluierung nicht beantworten kann (hilft das den Nutzern wirklich?), brauchen aber genug Verkehr und Zeit, um statistische Signifikanz zu erreichen, und jeder Zweig muss trotzdem die Sicherheitsschwellen einhalten: Ob der Assistent personenbezogene Daten preisgeben darf, testet man nicht per A/B-Test.

Beide ergänzen sich, wie das Diagramm zeigt. Offline-Evaluierung verhindert, dass bekannte Fehler wiederkehren; Online-Evaluierung findet die Fehler, an die niemand gedacht hat, und diese werden dann zu neuen Offline-Fällen.

Regressions-Evaluierungen in der CI als Fitness Functions

Eine Fitness Function ist eine automatisierte Prüfung, dass ein architektonisches Merkmal noch erfüllt ist. Ein Regressions-Eval ist eine Fitness Function für Verhalten: Es läuft, sobald sich irgendetwas ändert, das das Verhalten des Modells prägt (eine Prompt-Vorlage, eine Modellversion, Retrieval-Einstellungen wie Chunk-Größe oder Top-k, eine Tool-Beschreibung, eine Guardrail-Regel), und lässt die Pipeline scheitern, wenn die Qualität unter eine Schwelle fällt oder um mehr als eine vereinbarte Marge unter die aktuelle Produktions-Basislinie. Behandeln Sie Prompts und Modellkennungen genau aus diesem Grund als Code: Eine Prompt-Änderung um ein Wort ist eine Verhaltensänderung und verdient dasselbe Gate wie eine Codeänderung (Abschnitt 12.7).

Weil Modellaufrufe langsam sind und Geld kosten, sind Evaluierungssuiten meist gestaffelt. Ein Smoke-Set von 30 bis 100 Fällen mit deterministischen Prüfungen läuft bei jedem Pull Request in wenigen Minuten. Das vollständige Golden Set mit Judge-Bewertung läuft jede Nacht und vor jedem Release. Teure menschliche Prüfung bleibt Release-Kandidaten und Uneinigkeiten zwischen Judge und Basislinie vorbehalten. Nichtdeterminismus macht naive Schwellen unzuverlässig; vergleichen Sie daher mit der Basislinie an denselben Fällen, lassen Sie unsichere Fälle mehrfach laufen und setzen Sie Schwellen mit einer Marge, die das gemessene Rauschen zwischen Läufen widerspiegelt. Harte Randbedingungen (nie eine Erstattung über die Richtlinie hinaus genehmigen, nie ein Allergen ohne Quelle als nicht vorhanden angeben) werden als Prüfungen ohne Toleranz formuliert, die das Release bei jedem einzelnen Fehler blockieren, während weichere Qualitäten (Tonfall, Knappheit) als Trends verfolgt werden.

def gate(results, baseline, margin=0.02):
    # results: one dict per golden case, from the candidate version
    hard = [r for r in results if r["slice"] == "allergen" and not r["grounded"]]
    if hard:
        return False, f"{len(hard)} ungrounded allergen answers"
    for name in ("task_success", "policy_ok"):
        score = sum(r[name] for r in results) / len(results)
        if score < baseline[name] - margin:
            return False, f"{name} {score:.1%} vs baseline {baseline[name]:.1%}"
    return True, "ok"

Monitoring in der Produktion

Einmal live, kann ein KI-Feature ohne jedes Deployment schlechter werden. Drift tritt in mehreren Formen auf: Die Eingaben ändern sich (eine neue Speisekarte, ein neues Land, eine viral gehende Beschwerde), die Wissensquellen ändern sich (veraltete oder neu widersprüchliche Dokumente im Retrieval-Index), die Welt ändert sich, sodass die richtige Antwort von gestern falsch wird (eine neue Erstattungsrichtlinie), oder das Modell ändert sich, weil ein Anbieter das Modell hinter einem Alias aktualisiert hat. Fixieren Sie datierte Modellversionen, wo Anbieter sie anbieten, und behandeln Sie ein Upgrade als Release, das durch das Gate geht.

Das Monitoring ergänzt daher die übliche Observability von Latenz, Fehlern und Kosten um Qualitätssignale. Üblich ist, einen kleinen Teil der Gespräche (1 bis 5 % sind gängig) für die automatische Judge-Bewertung zu sampeln, einen kleineren Teil für die menschliche Prüfung, und die Ergebnisse pro Segment mit Alarmen bei Einbrüchen darzustellen. Implizite Signale sind billig und reichlich vorhanden: Eskalationen an einen Menschen, Nutzer, die eine Frage wiederholen oder umformulieren, abgebrochene Sitzungen, von Mitarbeitenden rückgängig gemachte Erstattungen. Explizites Feedback (Daumen hoch oder runter) ist wertvoll, aber spärlich und verzerrt. Verfolgen Sie auch die Verteilung der Eingaben, zum Beispiel den Anteil jeder Absicht und der Fragen, die der Klassifikator nicht zuordnen kann: Ein steigender Anteil unbekannt ist ein Frühwarnzeichen dafür, dass das Golden Set die Realität nicht mehr abbildet. Für die Evaluierung genutzte Produktionslogs enthalten personenbezogene Daten; Zugriff, Aufbewahrung und Anonymisierung müssen daher von Anfang an mitgeplant werden (Abschnitt 12.8).

Red Teaming

Red Teaming ist bewusstes adversariales Testen: Menschen, manchmal unterstützt von automatischen Angriffsgeneratoren, versuchen, das System zu Fehlverhalten zu bringen. Ziele sind unter anderem Jailbreaks, die Inhaltsrichtlinien umgehen, Prompt-Injection über Dokumente oder Tool-Ergebnisse, das Preisgeben des System-Prompts oder der Daten anderer Kunden, der Missbrauch von Tools (Erstattungen auslösen, Nachrichten senden), das Erzeugen schädlicher oder diffamierender Inhalte und das Hochtreiben der Kosten. Red Teaming ist vor dem Start und nach wesentlichen Änderungen am wertvollsten, durchgeführt von Menschen, die das System nicht gebaut haben. Open-Source-Tools können große Mengen bekannter Angriffsmuster erzeugen, aber kreative menschliche Tester finden immer noch die Fehler, die für Ihre Domäne spezifisch sind. Jeder erfolgreiche Angriff wird zu einem Regressionsfall, und die gefundenen Muster fließen in den Guardrail-Entwurf aus Abschnitt 12.6 ein. Red Teaming findet Probleme; es kann nie beweisen, dass es keine gibt.

Fallstudie: wie dieser Kurs schriftliche Antworten bewertet

Die schriftlichen Fragen in den Kapiteltests dieses Kurses werden von einem Sprachmodell bewertet; damit ist die Bewertung ein kleines, reales Beispiel für LLM-as-a-Judge mit Schutzmaßnahmen. Jede schriftliche Frage hat eine feste Rubrik spezifischer Kriterien mit insgesamt 5 Punkten und eine Musterantwort, die der Bewerter als Referenz sieht. Der Bewerter läuft mit Temperature 0 und muss in einem festen JSON-Format mit einer Punktzahl pro Kriterium antworten; Antworten, die sich nicht parsen lassen, ein Kriterium auslassen oder anderweitig fehlerhaft sind, werden verworfen, und die Anfrage geht an das nächste Modell der Fallback-Kaskade; jede Punktzahl wird auf das Maximum des Kriteriums begrenzt. Antworten unterhalb der Mindestlänge der Frage erhalten null Punkte, ohne an ein Modell geschickt zu werden.

Injection wird auf zwei Ebenen behandelt. Der Text des Lernenden wird zwischen explizite Begrenzer gesetzt, und die Anweisungen des Bewerters besagen, dass alles dazwischen Antworttext ist, keine Anweisung. Bevor ein Modell ihn sieht, weist eine einfache Musterprüfung Antworten zurück, die Anweisungen an den Bewerter enthalten, etwa die Aufforderung, die Rubrik zu ignorieren oder die volle Punktzahl zu vergeben. Wer mit einer Bewertung nicht einverstanden ist, kann einmal pro Antwort und innerhalb von 24 Stunden eine Zweitbewertung verlangen; die höhere Punktzahl zählt. Was auf dem Spiel steht, ist durch den Entwurf begrenzt: Objektive Fragen, die anhand eines Lösungsschlüssels bewertet werden, machen 70 % der Testpunktzahl aus, und zum Bestehen braucht es außerdem mindestens 2 von 5 Punkten bei jeder schriftlichen Antwort.

Die Fallstudie zeigt auch die oben besprochenen Grenzen. Temperature 0 verringert die Schwankung, garantiert aber keine identischen Bewertungen, besonders wenn die Anfrage auf ein anderes Modell ausweicht. Eine Musterprüfung fängt nur plumpe Versuche ab, und Begrenzer und Anweisungen verringern das Risiko, beseitigen es aber nicht, weil kein Prompt eine Sicherheitsgrenze ist (Abschnitt 12.6). Würde man die identische Bewertung mit Temperature 0 wiederholen, käme meist wieder die erste Punktzahl heraus; deshalb nutzt die Zweitbewertung eine eigene Anweisung für einen zweiten Prüfer: Er sieht die Punkte und Anmerkungen des ersten Prüfers, bewertet jedes Kriterium neu anhand der Antwort selbst und muss die Worte zitieren, die zusätzliche Punkte rechtfertigen. Ein anderes Modell oder ein Mensch würde die Zweitbewertung noch unabhängiger machen. Ein umfassenderes Evaluierungsprogramm würde für jede schriftliche Frage ein von Menschen bewertetes Kalibrierungsset ergänzen und die Übereinstimmung zwischen Bewerter und Menschen über die Zeit verfolgen, wie im ausgearbeiteten Beispiel.