BlogTesten
Abnahmekriterien für KI-Systeme: Wann ist eine LLM-Anwendung gut genug?
Schreiben Sie die Kriterien als Fehlertypen, nicht als Liste erwarteter Antworten. Geben Sie jedem einen Schweregrad und eine geforderte Erfolgsquote, bevor der Test beginnt: gar keine Fehler bei den wenigen, die Sie nie akzeptieren können, eine Mindestquote bei den übrigen. Messen Sie dann jede Quote an genug Fällen und mit wiederholten Läufen und werten Sie ein Kriterium erst als erfüllt, wenn das ganze Konfidenzintervall auf der richtigen Seite der Anforderung liegt. Liegt die Anforderung noch im Intervall, hat der Test noch nicht entschieden: Liegt die gemessene Quote über der Anforderung, klären mehr Fälle die Frage, sonst muss das System besser werden. Der Rechner unten zeigt, welches dieser Ergebnisse Ihre eigenen Zahlen ergeben.
Kriterien als Fehlertypen
Ein klassisches Abnahmekriterium beschreibt, was die richtige Ausgabe ist. Bei einem KI-System funktioniert es besser, zu beschreiben, was nicht schiefgehen darf, weil es viele richtige Antworten und eine überschaubare Zahl von Fehlerarten gibt. Typische Kriterien für einen Assistenten im Kundenservice: Er nennt einen falschen Preis, Betrag oder ein falsches Datum, er widerspricht der Regel im Quelldokument, er beantwortet eine Frage außerhalb seines Zwecks, statt abzulehnen, er übersieht den Wunsch, mit einem Menschen zu sprechen, er gibt Daten eines anderen Kunden preis.
Finden Sie diese Fehlertypen, indem Sie zuerst echte Ausgaben oder Ausgaben aus dem Pilotbetrieb mit einer Fachperson lesen. Shreya Shankar und Kollegen haben festgestellt, dass Menschen ihre Kriterien beim Bewerten von Ausgaben schärfen, und nennen das Criteria Drift. Lesen Sie also eine Stichprobe, vereinbaren Sie die Kriterien anhand dessen, was Sie gefunden haben, und frieren Sie sie vor dem Abnahmetest ein.
Schweregrad und Schwellenwert, vor dem Test festgelegt
Geben Sie jedem Fehlertyp einen Schweregrad und eine geforderte Erfolgsquote. Das Starter Kit der IMDA zum Testen von LLM-Anwendungen sagt, dass jede Organisation ihre eigenen Schwellenwerte bestimmen und sie vor dem Test festlegen sollte, mit einem Schwellenwert von null für gravierende Schäden. Wer sie zuerst festlegt, verhindert, dass über die Zahlen gestritten wird, wenn die Ergebnisse schon da sind.
| Fehlertyp | Schweregrad | Geforderte Erfolgsquote |
|---|---|---|
| Gibt Daten eines anderen Kunden preis | Kritisch | 100 %, kein Fehler erlaubt |
| Falscher Betrag, Preis oder falsches Datum | Hoch | Mindestens 99 % |
| Widerspricht der Regel in der Quelle | Hoch | Mindestens 97 % |
| Übersieht den Wunsch nach einem Menschen | Mittel | Mindestens 95 % |
| Antwortet außerhalb des Zwecks, statt abzulehnen | Mittel | Mindestens 90 % |
Diese Zahlen veranschaulichen das Format, sie sind keine Empfehlung. Die richtige Anforderung hängt davon ab, was ein Fehler Sie kostet, ob ein Mensch ihn bemerken würde und wie gut der Prozess vor dem KI-System lief.
Ein Kriterium, das keinen Fehler erlaubt, lässt sich durch Tests allein nicht beweisen. Ein fehlerfreier Lauf begrenzt nur die Fehlerquote: Bei 300 Fällen ohne Fehler reicht das 95-%-Intervall der Fehlerquote immer noch bis 1,3 %. Kritische Kriterien brauchen deshalb auch Kontrollen außerhalb des Modells, etwa Zugriffsregeln, die den Fehler unmöglich machen.
Jede Quote mit Intervall messen
Eine Erfolgsquote aus einem Testset ist eine Schätzung. Bestehen 90 von 100 Fällen, kann die wahre Quote für diese Art von Frage spürbar darunter oder darüber liegen. Das Wilson-Score-Intervall, das sich bei kleinen Stichproben und bei Quoten nahe 100 % gut verhält, setzt das 95-%-Intervall für 90 von 100 auf 82,6 % bis 94,5 %.
Daraus ergeben sich drei Ergebnisse pro Kriterium. Das Kriterium ist erfüllt, wenn die untere Grenze des Intervalls die Anforderung erreicht. Es ist nicht erfüllt, wenn die obere Grenze darunter liegt. Liegt die Anforderung im Intervall, hat der Test noch nicht entschieden, und mehr Fälle machen das Intervall enger. Bei einer Anforderung von 85 % ist 90 von 100 unentschieden, bei genau gleicher Erfolgsquote würden 196 Fälle es klären, in ganzen Fällen gerechnet 180 von 200.
Fälle gelten als unabhängig. Zählen Sie einen Fall nur als bestanden, wenn er in jedem geforderten Lauf bestanden hat.
- Gemessene Erfolgsquote
- 90,0 %
- Untere Grenze des Intervalls
- 82,6 %
- Obere Grenze des Intervalls
- 94,5 %
- Nötige Fälle bei dieser Quote
- 196
Kriterium erfüllt: Selbst die untere Grenze des Intervalls erreicht die geforderte Erfolgsquote.
Kriterium nicht erfüllt: Selbst die obere Grenze des Intervalls liegt unter der geforderten Erfolgsquote.
Noch nicht entschieden: Die geforderte Erfolgsquote liegt im Intervall. Mehr Fälle mit derselben Quote würden es klären.
Noch nicht entschieden, und mehr Fälle mit dieser Quote reichen nicht für die Anforderung. Das System muss besser werden, oder die Anforderung braucht einen zweiten Blick.
Geben Sie ganze Fallzahlen ein, nicht mehr bestandene als ausgeführte Fälle und eine geforderte Erfolgsquote zwischen 1 und 99,9.
Der Rechner behandelt Fälle als unabhängig. Stammen mehrere Fälle aus demselben Dokument oder Gespräch, ist das echte Intervall breiter, und unser Leitfaden zur Stichprobengröße bei Evals zeigt, wie Sie das berücksichtigen.
Wiederholte Läufe und Konsistenz
Lassen Sie jeden Fall mehrmals mit den Produktiveinstellungen laufen. Ein Fall, der in einem Lauf besteht und im nächsten nicht, ist kein flaky Test, den man löscht. Er zeigt, wie oft ein Nutzer den Fehler sehen würde. Zählen Sie den Fall als Einheit: Fünf Läufe über 100 Fälle sind nicht 500 unabhängige Fälle.
Bei einem System, das handelt, etwa einem Agenten, der Erstattungen auslöst, kann es sinnvoll sein zu verlangen, dass jeder Lauf eines Falls besteht. Im Benchmark τ-bench löste gpt-4o in einem einzelnen Versuch etwa 61 % der Retail-Aufgaben, in allen acht Versuchen gelangen weniger als 25 %. Eine Anforderung an die Quote einzelner Läufe hätte das verdeckt.
Kriterien in den Vertrag schreiben
Baut eine Agentur oder ein Anbieter das System, vereinbaren Sie Fehlertypen, Anforderungen und die Art der Messung, bevor gebaut wird, und behalten Sie das Testset auf Ihrer Seite. Der Anbieter kann eine Stichprobe zum Entwickeln bekommen, während die Fälle für die Abnahme ungesehen bleiben, damit das System nicht genau auf den Test hin optimiert wird. Lassen Sie das Set bei der Abnahme über die Oberfläche laufen, die Ihre Nutzer haben werden, und dokumentieren Sie zu jedem Fehler Eingabe, Ausgabe und verletztes Kriterium.
Vereinbaren Sie vorab, was nach einem unentschiedenen Ergebnis passiert: meist ein größerer Testlauf oder eine feste Zeit begleiteter Nutzung mit einer Stichprobe, die von Hand geprüft wird. Wie die Abnahme rechtlich funktioniert, hängt von Ihrem Vertragstyp ab, klären Sie das also mit Ihrer Rechtsabteilung oder Ihrer Kanzlei. Dieser Text ist keine Rechtsberatung.
Fragen
Was, wenn ein Kriterium nicht erfüllt ist?
Lesen Sie zuerst die fehlgeschlagenen Fälle. Sie lassen sich meist auf ein oder zwei Ursachen zurückführen, etwa ein fehlendes Dokument, eine Anweisung im Prompt, die das Modell ignoriert, oder ein Problem im Retrieval. Beheben Sie die Ursache und lassen Sie dann das ganze Set laufen, nicht nur die fehlgeschlagenen Fälle, weil Korrekturen oft etwas anderes kaputt machen.
Können wir mit einem unentschiedenen Ergebnis abnehmen?
Als geschäftliche Entscheidung ja, wenn das Risiko gering ist und Sie danach eine Stichprobe echter Gespräche prüfen. Halten Sie fest, dass das Ergebnis unentschieden war und wann Sie wieder hinsehen. Bei Kriterien mit hohem Schweregrad ergänzen Sie Fälle, bis das Ergebnis klar ist.
Sollten die Kriterien in jeder Sprache gleich sein?
Die Kriterien ja. Messen Sie sie aber getrennt pro Sprache, weil sich die Qualität zwischen Sprachen oft unterscheidet und eine gemeinsame Quote eine schwache Sprache verdecken kann.
Warum das Wilson-Intervall und nicht plus minus ein paar Punkte?
Die einfache Normalapproximation verhält sich bei kleinen Stichproben und Quoten nahe 100 % schlecht, also genau dort, wo Abnahmeanforderungen liegen, und kann sogar über 100 % hinausreichen. Das Wilson-Intervall bleibt zwischen 0 und 100 % und ist dort verlässlicher.
Verwandte Leistungen
Mehr aus dem Blog
KI-Systeme testen
Eine Teststrategie für LLM-Anwendungen, RAG-Assistenten und Agenten: Teststufen, Testorakel, wiederholte Läufe, Testdaten und die übertragbaren CT-AI-Techniken.
Stichprobengröße für Evals
Wie Sie Eval-Ergebnisse mit Konfidenzintervallen versehen, zwei Prompts oder Modelle Fall für Fall vergleichen und ein Testset für den Unterschied bemessen, den Sie erkennen müssen.
Regressionstests für LLM-Anwendungen
Was laufen muss, wenn sich Prompt, Modell, Dokumentindex oder Anbieter ändern: ein eingefrorenes Set von Fällen, zuerst deterministische Prüfungen, validierte Judges und ein Vergleich Fall für Fall.
Fehleranalyse für LLM-Anwendungen
Wie Sie mit einer Fachperson rund 100 Traces lesen, freie Notizen zu einer gezählten Fehlertaxonomie verdichten und entscheiden, welche Fehler ein Eval verdienen.
Quellen
- IMDA: Starter Kit for Testing LLM-Based Applications for Safety and Reliability (Januar 2026)
- Shankar et al.: Who Validates the Validators?
- Edwin B. Wilson: Probable inference, the law of succession, and statistical inference (1927)
- Evan Miller: Adding Error Bars to Evals
- Yao et al.: τ-bench, a benchmark for tool-agent-user interaction
Mit einem Engineer sprechen
Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.
Die Buchung läuft über Google Kalender.
Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.
Sehen Sie in Ihrem E-Mail-Programm nach dem Entwurf
Senden Sie ihn von dort ab, und ein Engineer antwortet Ihnen persönlich mit Terminvorschlägen für ein 30-minütiges Gespräch. Hat sich kein Entwurf geöffnet, schreiben Sie uns an miki@cloudsail.com.