KI-Systeme testen: eine Teststrategie für LLM-Anwendungen, RAG und KI-Agenten

KI-Systeme testen ist nicht dasselbe wie mit KI testen

Wer nach KI-Testing sucht, findet vor allem Ergebnisse dazu, wie KI Tests für gewöhnliche Software erzeugt oder pflegt. Dieser Leitfaden behandelt die andere Richtung: Software zu testen, deren Verhalten aus einem Sprachmodell kommt. ISTQB hat beides 2026 getrennt. Version 2.0 des Lehrplans Certified Tester AI Testing konzentriert sich ganz auf das Testen KI-basierter Systeme und behandelt jetzt auch generative KI und große Sprachmodelle, Inhalte zum Testen mit KI wurden entfernt.

Getestet wird die Anwendung, nicht das Modell. Ein Support-Chatbot besteht aus einem Modell, einem System-Prompt, Retrieval über Ihre Dokumente, Tools, Filtern und dem Code drumherum, und ein Fehler kann in jedem dieser Teile entstehen. Die singapurische Behörde IMDA unterscheidet in ihrem Starter Kit zum Testen von LLM-Anwendungen deshalb Output-Tests, die die Anwendung als Blackbox behandeln, von Komponententests innerhalb der Pipeline.

Qualitätssicherung für KI-Systeme

Warum ein einzelnes erwartetes Ergebnis nicht mehr reicht

Ein klassischer Testfall vergleicht die Ausgabe mit einem erwarteten Ergebnis. Auf eine Frage wie „Kann ich reduzierte Ware nach 30 Tagen zurückgeben?“ gibt es viele richtige Antworten in unterschiedlichen Worten und einige falsche, die ähnlich aussehen. Ein exakter Vergleich lässt gute Antworten durchfallen und schlechte durch, die zufällig dieselben Wörter nutzen. Das ist das Problem des Testorakels: Um zu entscheiden, ob eine Ausgabe richtig ist, braucht es eine eigene Methode.

Es gibt drei brauchbare Orakel. Code für alles mit einer festen Antwort: ein Betrag, ein Datum, ein Schema, ein Tool-Aufruf, ein zitiertes Dokument, das existiert. Eine Person mit Fachwissen, die eine Stichprobe von Hand bewertet. Und ein LLM-Judge, ein zweites Modell, das eine enge Ja-Nein-Frage beantwortet und nur so gut ist wie seine Übereinstimmung mit dieser Person. Nutzen Sie sie in dieser Reihenfolge und validieren Sie jeden Judge, bevor Sie seinen Zahlen trauen.

LLM-Judge validieren

Teststufen: deterministisch und statistisch

Vieles an einem KI-System lässt sich weiterhin klassisch testen. Teilen Sie die Suite danach auf, ob eine Prüfung genau eine richtige Antwort hat.

Halten Sie den deterministischen Teil schnell und streng: Ein Fehler dort ist ein Bug. Behandeln Sie den statistischen Teil als Messung: Weisen Sie eine Quote aus, vergleichen Sie sie mit dem Schwellenwert und lesen Sie die fehlgeschlagenen Fälle.

Techniken aus dem CT-AI-Lehrplan, die sich übertragen lassen

Der CT-AI-Lehrplan nennt adversariales, metamorphes, Drift-, A/B- und Back-to-Back-Testen unter den Techniken für Modelltests, dazu exploratives Testen und Red Teaming für generative KI. Für eine LLM-Anwendung sieht das so aus.

• Metamorphe Tests: Stellen Sie dieselbe Frage mit anderen Worten, in anderen Sprachen oder in anderer Reihenfolge und erwarten Sie dieselben Fakten. Sie brauchen keine erwartete Antwort, nur Konsistenz.
• Back-to-Back-Tests: Lassen Sie aktuelle und neue Version auf denselben Fällen laufen und sehen Sie sich die Fälle an, die sich verändert haben. Das ist der Kern von Regressionstests bei Prompt- und Modellwechseln.
• Adversariale Tests und Red Teaming: Prompt Injection, versteckt in Dokumenten oder E-Mails, die das System liest, Anfragen außerhalb seines Zwecks, Versuche, an Daten anderer Nutzer zu kommen.
• Drift-Tests: Lassen Sie ein festes Set regelmäßig laufen, weil sich Dokumente ändern und ein Modell-Alias auf eine neue Version zeigen kann.
• Exploratives Testen: Eine Testerin oder ein Tester mit Fachwissen spricht eine Stunde mit dem System und notiert jede seltsame Antwort. So finden sich Fehlertypen, an die beim Testset niemand gedacht hat.

Wenn Ihre Organisation ISO/IEC TS 42119-2 folgt, im November 2025 erschienen, lassen sich dieselben Techniken in den dort beschriebenen Testprozess nach ISO/IEC/IEEE 29119 für KI-Systeme einordnen.

Regressionstests für LLM-Anwendungen

Woher die Testfälle kommen

Die besten Fälle kommen aus echter Nutzung: Gespräche, Tickets oder Aufgaben, die das System schon bearbeitet hat, gelesen von jemandem, der die Domäne kennt. Hamel Husain und Shreya Shankar empfehlen, mit dieser Fehleranalyse zu beginnen, statt vorab Evaluatoren zu schreiben, weil die Fehlertypen erst beim Lesen der Ausgaben klar werden. Shankar und Kollegen nennen den Effekt Criteria Drift: Beim Bewerten von Ausgaben finden Menschen erst heraus, welche Kriterien sie haben.

Das widerspricht festen Abnahmekriterien nicht. Lesen Sie zuerst eine Stichprobe aus dem Pilotbetrieb, vereinbaren Sie Kriterien und Schwellenwerte anhand dessen, was Sie gefunden haben, und frieren Sie sie für den Abnahmetest ein. Vor dem Start, wenn es noch keine echte Nutzung gibt, beginnen Sie mit Fällen, die Ihre Fachleute schreiben, und mit synthetischen Fällen entlang festgelegter Dimensionen wie Thema, Kundentyp und Schwierigkeit. Enthalten Fälle personenbezogene Daten, pseudonymisieren Sie sie, bevor sie in ein Repository gehen.

IMDA nennt mindestens 30 bis 50 Prompts für ein enges Thema und etwa 100 bis 200 für ein breiteres. Ob das reicht, hängt davon ab, wie nah die gemessene Erfolgsquote an Ihrem Schwellenwert liegt, und genau das berechnet der Rechner in unserem Leitfaden zu Abnahmekriterien.

Abnahmekriterien für KI-SystemeFehleranalyse für LLM-Anwendungen

Wer für die Qualität eines KI-Systems verantwortlich ist

Hier treffen sich drei Rollen. Die Fachperson entscheidet, was eine richtige Antwort ist, und bewertet Fälle. Die Entwicklung verantwortet die deterministischen Tests, die Judges und das Gate in der CI. QA verantwortet Teststrategie, Abnahmekriterien und Freigabebericht und fragt immer wieder, was noch nicht abgedeckt ist. In einem kleinen Team kann eine Person zwei dieser Rollen haben. Entscheidend ist, dass die Fachperson nicht fehlt, denn niemand sonst kann sagen, ob eine Antwort stimmt.

Was der AI Act vom Testen verlangt

Für Hochrisiko-KI-Systeme verlangt Artikel 9 des AI Act im Rahmen des Risikomanagements Tests anhand vorab festgelegter Metriken und probabilistischer Schwellenwerte, und Artikel 15 verlangt ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit. Nach dem Digital Omnibus, veröffentlicht am 24. Juli 2026, gelten diese Anforderungen ab dem 2. Dezember 2027 für Hochrisiko-Systeme nach Anhang III und ab dem 2. August 2028 für solche nach Anhang I. Die meisten Chatbots und internen Assistenten sind keine Hochrisiko-Systeme, aber genau diese Nachweise (Kriterien, Fälle, Ergebnisse und Entscheidungen) wollen Kunden und Prüfer meist sehen. Das ist keine Rechtsberatung.