LLM-Testcheckliste: Ein Leitfaden vor dem Start

Air Canada verlor einen Rechtsstreit, weil sein Chatbot eine Rückerstattungsrichtlinie erfunden hatte. Das Gericht entschied, dass die Fluggesellschaft das einhalten müsse, was der Bot versprochen hatte. Klarna kehrte von seiner AI-first-Kundenservicestrategie ab, nachdem sein Chatbot einen schlechteren Service lieferte als Menschen, und begann, wieder Mitarbeiter einzustellen. Beide Geschichten sorgten für Schlagzeilen, weil das zugrunde liegende Problem dasselbe war. Ein großes Sprachmodell wurde ohne den QA-Prozess, den die Technologie tatsächlich benötigt, in die Produktion gebracht.

Dieses Muster ist weit verbreitet. Der „State of AI”-Bericht 2025 von McKinsey ergab, dass 78 % der Unternehmen KI mittlerweile in mindestens einem Geschäftsbereich einsetzen, doch nur etwa ein Drittel hat sie auf Unternehmensebene skaliert. Die meisten anderen führen Pilotprojekte durch, die entweder in der Entwicklung ins Stocken geraten oder vor der Fertigstellung in Betrieb genommen werden, ohne dass es eine strukturierte Methode gibt, um festzustellen, was gerade passiert.

Diese LLM-Testcheckliste richtet sich an die zweite Gruppe. Sie umfasst sieben Phasen vor der Markteinführung, die Schwellenwerte, die „bereit” von „noch nicht bereit” unterscheiden, die für jede Phase erforderlichen Tools sowie die Fehlermuster, die bei LLM-Tests für produktionsreife Produkte am häufigsten auftreten. Betrachten Sie sie als strukturierten Check vor der Markteinführung.

Warum LLM-Tests traditionelle QA-Annahmen widerlegen

Herkömmliche Software ist deterministisch. Die gleiche Eingabe führt zur gleichen Ausgabe, sodass Testaussagen eindeutig bestehen oder durchfallen. Große Sprachmodelle verhalten sich nicht so. Stellt man dieselbe Frage zweimal, erhält man zwei gültige, aber unterschiedliche Antworten. Ändert man ein Wort in der Systemaufforderung, verändert sich das nachfolgende Verhalten auf eine Weise, die man nicht vollständig vorhersagen kann.

Dieser Nicht-Determinismus verändert die Art und Weise, wie das Verhalten von LLM getestet wird. Man ersetzt binäre Aussagen durch bewertete Schwellenwerte. Man misst, wie oft sich das Modell korrekt verhält, anstatt zu prüfen, ob es dies bei einem einzelnen Durchlauf tut oder nicht. Und man berücksichtigt eine neue Klasse von Fehlern, über die man bei der traditionellen Qualitätssicherung nie nachdenken musste: Halluzinationen, Prompt-Injection, Jailbreaks, das Austreten von Trainingsdaten, Bias-Drift und stille Regressionen nach jedem Modell-Update.

Das Ergebnis ist eine andere Testdisziplin, die sich an den wichtigen LLM-Bewertungsmetriken orientiert und einen größeren Umfang hat als die rein funktionale Korrektheit. Die folgende Checkliste gliedert diese Disziplin in sieben aufeinander aufbauende Phasen.

Die 7-stufige LLM-Test-Checkliste

Führen Sie diese Phasen der Reihe nach durch. Jede Phase liefert eine Ausgabe, die die nächste Phase benötigt. Überspringen Sie die ersten Phasen, werden Sie später dafür bezahlen, wenn die Korrektur eines fehlerhaften Datensatzes oder das Umschreiben einer System-Prompt das Zehnfache dessen kostet, was es am ersten Tag gekostet hätte. Die folgenden sieben Phasen spiegeln die Abfolge wider, der die meisten produktionsnahen LLM-Bewertungsprogramme folgen, und sie lassen sich je nach Risikostufe nach oben oder unten skalieren.

Phase 1: Definieren Sie Ihren Evaluierungsvertrag

Bevor Sie auch nur einen einzigen Test schreiben, dokumentieren Sie drei Dinge: den Anwendungsfall, die Risikostufe und die akzeptablen Schwellenwerte für jede Metrik, die Sie verfolgen möchten. Holen Sie sich für alle drei Punkte die Zustimmung von Produkt, Entwicklung und Qualitätssicherung ein. Ohne diesen Vertrag wird jede spätere Diskussion darüber, ob „das gut genug für die Auslieferung ist”, zu einer Meinungsfrage.

Die Risikostufe ist am wichtigsten. Ein kundenorientierter Chatbot kann eine Halluzinationsrate von etwa 5 % tolerieren. Ein medizinischer oder juristischer Assistent muss unter 1 % bleiben. Wählen Sie zuerst die Stufe, dann folgen die Schwellenwerte. Gängige Ausgangspunkte für Produktionsbereitstellungen:

• Treue: 0,75 oder höher auf einer normalisierten Skala von 0 bis 1.
• Antwortrelevanz: 0,70 oder höher.
• Toxizität: 0,10 oder niedriger.
• Halluzinationsrate: 5 % oder weniger für den allgemeinen Gebrauch, 1 % für Kontexte mit hohem Risiko.

Der Vertrag wird zum Zulassungskriterium. Wenn ein Modell einen Schwellenwert nicht erfüllt, wird es nicht ausgeliefert.

Phase 2: Kuratieren Sie Ihren Golden-Dataset

Der Datensatz ist die Grundlage für jeden folgenden Test. Ein schwacher Datensatz liefert Zahlen, die zwar überzeugend aussehen, in der Produktion jedoch nichts bedeuten.

Erstellen Sie für eine einfache Einführung mindestens 50 Beispiele. Für eine produktionsreife Bewertung sollten Sie 500 oder mehr anstreben. Die beste Quelle sind echte Nutzungsdaten, anonymisiert und mit Labels versehen. Wenn Sie diese noch nicht haben, simulieren Sie repräsentative Eingaben in drei Kategorien: normale Fälle, auf die Nutzer meistens stoßen, Randfälle wie seltene Szenarien und fehlerhafte Eingaben sowie adversarische Eingaben, einschließlich Jailbreak-Versuchen und Prompts, die den Gültigkeitsbereich verletzen.

Wenn Teams fragen, wie sie LLM-Anwendungen testen können, ohne zuvor einen Golden-Dataset zu erstellen, lautet die ehrliche Antwort: Das geht nicht. Der Datensatz muss zuerst da sein, auch wenn er zunächst klein ist, und wachsen, während Produktionsprotokolle in den ersten Wochen der Nutzung neue Fehlermuster aufzeigen.

Phase 3: Testen der Ausgabequalität

Hier fangen die meisten Teams an, oft früher, als sie sollten. Das Testen der Ausgabequalität umfasst drei Metriken, die zusammenwirken:

• Die Genauigkeit misst, ob die Antwort des Modells im Rahmen des Ausgangsmaterials bleibt. Dies ist für jedes RAG-System unverzichtbar.
• Die Relevanz der Antwort misst, ob die Antwort tatsächlich die Frage des Nutzers beantwortet. Eine originalgetreue Antwort kann immer noch die falsche Frage beantworten.
• Die Halluzinationsrate misst, wie oft Ausgaben sachlich falsche Aussagen enthalten, wobei die Schwellenwerte an Ihre Risikostufe angepasst werden.

Bei RAG-Pipelines erfolgt das Retrieval-Testing vor dem Generierungs-Testing. Branchenanalysen zeigen durchweg, dass die Mehrheit der RAG-Fehler im Retrieval liegt und nicht im Modell selbst. Ein praktischer Satz von RAG-Bewertungstools deckt Retrieval-Lücken auf, bevor sie in die Antworten an die Nutzer gelangen.

Zu den Tools, die in dieser Phase gut funktionieren, gehören DeepEval, Ragas und G-Eval für die Bewertung nach dem „LLM-as-a-judge”-Prinzip. Planen Sie für diese Phase bei einem kundenorientierten Produkt ein bis zwei Wochen ein.

Phase 4: Testen auf Voreingenommenheit und Sicherheit

Sicherheitstests decken zwei unterschiedliche Bereiche ab. Die Toxizitätsbewertung erkennt schädliche, beleidigende oder diskriminierende Ausgaben bereits zum Zeitpunkt der Generierung. Voreingenommenheitstests decken systematische Unterschiede in der Art und Weise auf, wie das Modell verschiedene demografische Gruppen behandelt, selbst wenn einzelne Antworten für sich genommen in Ordnung erscheinen.

Automatisierte Scanner erkennen die offensichtlichen Fälle. Googles Perspective API ist ein gängiger Maßstab für Toxizität, und Bibliotheken wie AIF360 helfen bei der Überprüfung der demografischen Fairness. Automatisierte Tools übersehen jedoch subtile, kontextspezifische Schäden. Aus diesem Grund fordern das NIST AI Risk Management Framework und sein Generative AI Profile, automatisierte Bewertungen mit menschlicher Überprüfung über den gesamten KI-Lebenszyklus hinweg zu kombinieren. Die leistungsstärksten Programme kombinieren jeden automatisierten Scan mit einer manuellen Überprüfung von 50 oder mehr Grenzfällen, die zur menschlichen Beurteilung markiert wurden.

Der Compliance-Druck verstärkt diese Phase nun zusätzlich. Der EU-KI-Gesetzentwurf verlangt von risikoreichen KI-Systemen, dass Tests zur Genauigkeit, zur Minderung von Verzerrungen und zur menschlichen Aufsicht dokumentiert werden. Für Produkte, die in der EU eingesetzt werden, ist diese Phase nicht mehr optional, selbst wenn Sie sie zuvor übersprungen haben.

Phase 5: Sicherheits- und Red-Team-Tests durchführen

LLMs schaffen eine Angriffsfläche, für die herkömmliche Sicherheitstests nicht ausgelegt sind. Die fünf häufigsten Angriffsvektoren, die vor der Markteinführung geprüft werden sollten:

• Direkte Prompt-Injektion, bei der Benutzereingaben die Systemprompt überschreiben.
• Indirekte Prompt-Injektion durch bösartige Anweisungen, die in abgerufenen Dokumenten, URLs oder hochgeladenen Dateien eingebettet sind.
• Jailbreaks unter Verwendung von Rollenspielen, hypothetischen Rahmenbedingungen oder DAN-artigen Prompts, die Sicherheitsfilter umgehen.
• Versuche, die System-Prompt zu extrahieren, wodurch Ihre Vorlage und darin enthaltene sensible Informationen offengelegt werden.
• Leckage von Trainingsdaten durch manipulierte Abfragen, die Fragmente des Trainingsdatensatzes des Modells extrahieren.

Automatisierte Scanner wie Garak und PyRIT decken bekannte Angriffsmuster auf der Eingabe- und Ausgabeschicht ab. Sie sind notwendig, aber nicht ausreichend. Indirekte Injektionen durch vertrauenswürdige Inhalte und verkettete Tool-Exploits müssen in der Regel von menschlichen Red-Team-Mitgliedern aufgedeckt werden, da sie von Kontext abhängen, den der Scanner nicht erkennen kann.

Kombinieren Sie bei Produktionsbereitstellungen die automatisierte Baseline mit gezielten Penetrationstest-Services. Dies ist die Phase, in der Teams, die auf externes Fachwissen verzichten, am meisten verlieren, da die LLM-Angriffe mit den größten Auswirkungen selten in der Dokumentation aufgeführt sind.

Phase 6: Validierung von Leistung, Latenz und Kosten

Leistungstests für LLM-gestützte Produkte gehen über die Frage „Fühlt sich die Antwort schnell an?” hinaus. Drei Zahlen sind am wichtigsten. Die Zeit bis zum ersten Token (TTFT) bestimmt die wahrgenommene Geschwindigkeit bei Streaming-Schnittstellen und sollte beim Chat unter einer Sekunde liegen. Die gesamte Antwortlatenz, insbesondere der p95-Wert, sagt mehr über die tatsächliche Benutzererfahrung aus als der Durchschnitt. Die Kosten pro Anfrage müssen sowohl bei der Baseline als auch bei dem zehnfachen des erwarteten Produktionsvolumens erfasst werden, da sich die Architektur, die 10 Testbenutzer für zweihundert Dollar im Monat bewältigt, bei fünfzigtausend gleichzeitigen Sitzungen ganz anders verhält.

An dieser Stelle stellen Teams, die sich fragen, wie sie LLMs unter realistischer Last testen können, fest, dass ihre Pilotarchitektur nicht skalierbar ist. Caching-Ebenen, Fallback-Modelle, Ratenbegrenzung und Lastverteiler verändern das Latenz- und Kostenprofil in der Produktion. Führen Sie Lasttests an der Produktionsarchitektur durch, nicht am Pilotprojekt.

Phase 7: Regressionssuite und Observability festlegen

Die letzte Phase ist diejenige, die die meisten Teams als optional betrachten, was auch der Grund dafür ist, dass sie das System bereitstellen und es dann stillschweigend verschlechtern. Jede Aktualisierung der Prompts, jeder Modellwechsel und jede Änderung der Wissensdatenbank kann das zerstören, was gestern noch funktioniert hat.

Bündeln Sie die Tests aller vorherigen Phasen in einer Regressionssuite, die bei jeder Änderung und nicht erst bei jeder neuen Version ausgeführt wird. Erfassen Sie Basiswerte, damit zukünftige Regressionen sofort sichtbar werden und nicht erst nach einer Kundenbeschwerde. Sorgen Sie vor dem Start für Observability in der Produktion, nicht erst nach dem ersten Vorfall. Tracing, Protokollierung von Reaktionen und Drift-Warnungen sollten vom ersten Tag an vorhanden sein.

Regressionstests für LLM-gestützte Produkte unterscheiden sich von herkömmlichen Regressionstests. Die Suite ist probabilistisch, die Schwellenwerte werden bewertet, und die Vergleiche erfolgen über Verteilungen hinweg statt anhand exakter Übereinstimmungen. Das Prinzip ist jedoch dasselbe: Erkennen Sie die Regression in der CI, nicht erst auf dem Screenshot eines Kunden in den sozialen Medien.

Wo LLM-Tests trotz Checkliste schiefgehen

Selbst eine vollständige Checkliste für KI-Tests lässt Raum für vorhersehbare Fehler. Drei Muster tauchen bei Überprüfungen von LLM-gestützten Produkten vor der Markteinführung immer wieder auf.

Die Bewertung als Einführungsritual behandeln. Teams führen die Checkliste einmal durch, erreichen ihre Schwellenwerte, bringen das Produkt auf den Markt und legen die Testsuite beiseite. Das erste Modell-Update macht stillschweigend die Hälfte der erzielten Verbesserungen zunichte, und niemand bemerkt es, bis ein Nutzer darauf hinweist. Die Lösung besteht darin, die Regressionstestsuite zu einem festen Bestandteil jeder Bereitstellung zu machen, nicht zu einem Meilenstein, den man abhakt und vergisst.

Das Modell isoliert testen. Ein Modell, das in einer Sandbox gut abschneidet, kann in der Produktion dennoch versagen, weil die Datenabfrage fehlerhaft ist, die Systemaufforderung veraltet ist oder eine Tool-Integration im falschen Moment eine Ratenbegrenzung durchführt. Die Checkliste funktioniert nur, wenn sie auf den vollständig integrierten Stack angewendet wird, einschließlich der Orchestrierungsschicht, der RAG-Pipeline und aller nachgelagerten APIs, auf die das Modell zugreifen kann.

Das Überspringen von Adversarial Testing, weil das Produkt risikoarm erscheint. Auch interne Tools können geknackt werden. Jedes LLM, das mit echten Daten, Tools oder Benutzereingaben verbunden ist, gehört in Stufe 5, unabhängig davon, ob Ihre Zielgruppe aus einem Team oder einer Million Benutzern besteht. Der Fall Klarna ist hier aufschlussreich. Ein Support-Bot, den Benutzer dazu gebracht hatten, Python zu schreiben, war keine risikoreiche Bereitstellung, aber die Reputationsschäden sorgten dennoch für weltweite Berichterstattung.

Von der Checkliste bis zur Markteinführung

Ein Testdurchlauf vor dem Launch dauert bei einem kundenorientierten Produkt in der Regel drei bis sechs Wochen. Interne Tools können in ein bis zwei Wochen bereitgestellt werden, wenn der Datensatz bereitsteht. Hochrisikoreiche Bereitstellungen in regulierten Branchen benötigen in der Regel sechs bis zwölf Wochen, um die Compliance-Prüfung zu bestehen.

Der siebenstufige Ablauf bietet Ihnen die Struktur. Die Schwellenwerte geben Ihnen die Kontrolle. Die Regressionssuite und die Observability-Ebene bieten Ihnen eine Möglichkeit, das zu bewahren, was Sie durch das Testen überhaupt erst erreicht haben. Was diese Checkliste Ihnen nicht geben kann, ist die Zeit, die Sie ursprünglich nicht für das Testen eingeplant haben.

Wenn Sie näher am Launch sind, als Ihnen lieb ist, kontaktieren Sie uns, und wir sagen Ihnen, welche Phasen Sie angesichts Ihres Zeitplans zuerst durchführen sollten. Die LLM-Testdienstleistungen von QAwerk decken den gesamten Ablauf ab, mit erfahrenen Senior-Ingenieuren, die sich mit der Bewertung von Produktions-LLMs vor dem Launch auskennen.

FAQ

Erfahren Sie, wie QA-Validierung eines LLM-gestützten Chat- und Onboarding-Flows einer KI-Matchmaking-App half, in 4 US-Städte zu expandieren und 6,7 Mio. USD Finanzierung zu sichern

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie erhalten