Ein gelungener Testlauf in der Vorführung beweist, dass ein System gute Antworten erzeugen kann. Er beweist nicht, dass es das zuverlässig tut. Sprachmodelle liefern plausible Ergebnisse, deren Qualität von Aufgabe, Kontext und Modellversion abhängt. Einzelne Erfolge führen deshalb zu falscher Sicherheit, einzelne Fehler zu pauschaler Ablehnung. Dazwischen liegt ein kleines, gepflegtes Testset.
Warum Einzelfälle täuschen
Wer ein System vorführt, wählt Beispiele, die funktionieren. Wer es ablehnt, erinnert sich an den einen Fall, der schiefging. Beides ist keine Messung. Hinzu kommt, dass Anbieter Modelle aktualisieren, ohne dass sich an der Oberfläche etwas ändert. Ein Ablauf, der im Frühjahr gute Ergebnisse lieferte, kann im Sommer andere liefern, und ohne Vergleichsbasis bemerkt es niemand rechtzeitig.
Ein Testset mit dreißig Fällen aufbauen
Dreißig reale Fälle reichen für die meisten Workflows aus, wenn sie die tatsächliche Arbeit abbilden. Eine bewährte Verteilung am Beispiel eines Kundenservice-Workflows:
| Anteil | Fallart | Beispiel |
|---|---|---|
| Etwa die Hälfte | Typische Fälle | Standardanfrage zur Lieferzeit einer Bestellung |
| Etwa ein Fünftel | Schwierige Fälle | Mehrere Fragen in einer Nachricht, unklare Produktbezeichnung |
| Etwa ein Siebtel | Fehlende Informationen | Anfrage ohne Bestellnummer oder Kundenkennung |
| Etwa ein Zehntel | Unerwünschte Eingaben | Beleidigende Nachricht, eingebettete Anweisungen, fremde Sprache |
| Der Rest | Grenzfälle mit Richtlinienbezug | Kulanzforderung außerhalb der Regeln |
Die Fälle stammen aus dem echten Posteingang, anonymisiert, wo nötig. Beispiele aus Anbieterdemos gehören nicht hinein.
Bewertungsmaßstab vor dem Test festlegen
Für jeden Fall wird vorab notiert, was ein brauchbares Ergebnis enthalten muss. Bewertet wird dann auf drei Stufen: verwendbar, mit kleiner Korrektur verwendbar, unbrauchbar. Zusätzlich gibt es eine Markierung für kritische Fehler, die unabhängig von der Stufe zum Ausschluss führen: erfundene Fakten, unzulässige Zusagen, Verstöße gegen Datenregeln. Zwei Personen bewerten eine Teilmenge unabhängig voneinander, damit erkennbar wird, ob der Maßstab eindeutig genug formuliert ist.
Fehlerarten statt Durchschnittswerte
Ein Mittelwert von „gut“ verdeckt, dass zwei von dreißig Fällen gefährlich falsch waren. Aussagekräftiger ist die Verteilung der Fehlerarten, weil sie zeigt, wer etwas ändern muss:
| Fehlerart | Was dahintersteckt | Wer sie behebt |
|---|---|---|
| Erfundene Fakten | Passende Quelle fehlt oder wurde nicht gefunden | Redaktion der Wissensbasis, Retrieval |
| Richtig, aber unvollständig | Anweisung oder Kontext lassen Punkte offen | Workflow-Owner |
| Falscher Ton oder falsches Format | Verhalten nicht ausreichend vorgegeben | Prompt und Beispiele |
| Verstoß gegen Richtlinien | Regel fehlt im Kontext oder wird nicht technisch geprüft | Fachbereich und Technik gemeinsam |
| Unnötige Ablehnung | Filter zu streng eingestellt | Technik |
Baseline und Änderungsregel
Das erste vollständige Ergebnis des Testsets ist die Baseline. Danach gilt eine einfache Regel: Jede Änderung an Modell, Prompt, Quellen oder Werkzeugen wird gegen das Testset gefahren und nur übernommen, wenn keine neuen kritischen Fehler auftreten und die Verteilung nicht schlechter wird. Ergebnisse werden mit Datum und Änderungsbeschreibung abgelegt. Das kostet pro Änderung eine Stunde und erspart die Diskussion, ob es „früher besser war“.
Ein Team möchte auf ein neueres Modell wechseln, weil die Antworten natürlicher klingen. Das Testset bestätigt die bessere Tonalität, zeigt aber in zwei von dreißig Fällen erfundene Liefertermine, die das alte Modell nicht produziert hatte. Der Wechsel wird zurückgestellt, bis die Terminangaben aus dem Bestellsystem verpflichtend in den Kontext übernommen werden. Ohne Testset wäre der Fehler bei Kunden aufgefallen.
Das Testset pflegen
Fälle, die im Betrieb tatsächlich schiefgehen, wandern ins Testset. Fälle, die durch Prozessänderungen nicht mehr vorkommen, werden entfernt. Einmal im Quartal prüft der Owner, ob die Verteilung noch der realen Arbeit entspricht. Ob ein beobachtetes Problem überhaupt beim Modell liegt, klärt der Beitrag RAG oder Fine-Tuning; wie dieselben Kennzahlen im laufenden Betrieb überwacht werden, beschreibt der Beitrag zum KI-Monitoring.