LLM-Tests automatisieren bedeutet, nicht-deterministische KI-Systeme systematisch prüfbar zu machen. Weil Sprachmodelle keine konsistenten Ausgaben liefern, ersetzen Akzeptanzbereiche und Bewertungsrubriken klassische Ja/Nein-Assertions. Als Judge-Ansatz bewertet dabei ein zweites LLM die Ausgaben des Systems unter Test, kalibriert an menschlichen Expertenbewertungen.
Das Wichtigste in Kürze
- Nicht-Determinismus ist bei LLMs kein Bug, sondern ein Designmerkmal: Wer das wie Flakiness behandelt und ausschließt, testet am System vorbei.
- Bei RAG-Systemen stecken die meisten Fehler im Retrieval, nicht in der Generierung: Ein korrekt gefiedertes LLM liefert verlässlich brauchbare Antworten.
- Der LLM-as-Judge-Ansatz erreicht laut Studien 80 bis 85 Prozent Übereinstimmung mit menschlichen Urteilen, was dem Übereinstimmungsniveau zwischen zwei Menschen entspricht.
- Qualitätsgates für LLM-Tests brauchen Akzeptanzschwellen statt Binär-Urteilen: Ein Grenzwert von 80 bis 90 Prozent ersetzt das klassische Rot-Grün-Prinzip.
KI-Systeme testen heißt, Nicht-Determinismus als Feature zu akzeptieren
Wer klassische Testautomatisierung gelernt hat, baut auf Determinismus und Konsistenz. Ein Test läuft, das Ergebnis ist reproduzierbar, grün bleibt grün. Bei Sprachmodellen fällt dieses Fundament weg. Ein LLM antwortet auf dieselbe Frage nicht zwingend zweimal gleich.
Der gewohnte Reflex ist, so ein Verhalten auszuschließen: als Race Condition, als Flakiness, als Bug im Testaufbau. Bei generativen Systemen ist das falsch. Der Nicht-Determinismus gehört zum Design des Systems, nicht zu seinen Fehlern.
Anupam Krishnamurthy beschreibt den nötigen Bruch so: Die Erwartungen an eine deterministische, konventionelle Software sind komplett andere als an einen Chatbot, der gefühlt ein Leben für sich selbst hat. Genau dieser Perspektivwechsel steht am Anfang jeder sinnvollen Teststrategie für KI-Komponenten.
Warum KI zunehmend das Testobjekt wird, nicht nur das Testwerkzeug
Zu KI im Testen gibt es viele Beiträge, Meinungen, Tools und Lösungen. Deutlich seltener behandelt jemand die umgekehrte Richtung: KI als Testobjekt.
Anwendungen bekommen immer mehr KI-Bauteile. In Jira und anderen verbreiteten Consumer-Tools steckt inzwischen ein KI-Anteil. Damit verschiebt sich die Frage vom “Wie nutze ich KI zum Testen” zum “Wie teste ich Software, die selbst KI enthält”.
Die manuelle Prüfung durch eine Domain-Expertin reicht dafür nicht. Du kannst nicht dauerhaft von einem Menschen abhängig sein, der jede Antwort einzeln bewertet. Sobald KI-Anteile in Produkten normal werden, braucht es automatisierte Verfahren, um sie zu prüfen.
Vertrauen entsteht über Guardrails, nicht über vollständiges Verständnis
Klassisch baust du Vertrauen in ein System über Verständnis auf: Du weißt, was der Code tut. Bei neuronalen Netzen ist dieses Verständnis nicht vollständig gegeben, und das lässt sich auch nicht wegtesten.
Der Ausweg sind Guardrails, Tests und Evaluations. Auch wenn du dein System nicht zu hundert Prozent verstehst, gibt dir ein definierter Rahmen Sicherheit: Solange sich das Verhalten innerhalb festgelegter Grenzen bewegt, kannst du es nutzen.
Neu ist dieses Denken nur für Softwareentwickler und Tester. Machine-Learning-Fachleute arbeiten längst so. Die Aufgabe für die Testdisziplin besteht darin, eigene Methodiken für diesen Umgang zu entwickeln.
Wie du ein KI-System nach Komplexität der Bewertung zerlegst
Der erste konkrete Schritt ist, das System in Prüfaufgaben unterschiedlicher Komplexität zu zerlegen. Das ist im Kern dasselbe Vorgehen wie im klassischen Testen mit verschiedenen Abstraktionsebenen, nur mit anderen Zielen.
Der passende Testansatz hängt stark vom Use Case ab. Bildgenerierung verlangt andere Prüfungen als Textgenerierung. KI ist ein Werkzeug, und dein Ansatz muss sich an deiner konkreten Lösung ausrichten.
Am Beispiel textbasierter Conversational Models lässt sich die Bewertung in Stufen ordnen:
| Stufe | Was geprüft wird | Wie automatisierbar |
|---|---|---|
| Deterministisch | Faktenantwort in festem Format, z. B. JSON, alphabetisch sortiert | Klassisch mit pytest oder gewohntem Framework, per Assertion |
| Faktbasiert, Freitext | Korrektheit von Freitextantworten mit objektivem Kern | Aufwändiger, aber belegbar |
| Subjektiv | Ton, Hilfsbereitschaft, Präzision der Antwort | Am schwersten, braucht kalibrierte Bewertung |
| Adversarial | Sicherheit gegen Prompt-Manipulation | Eigene Testklasse, nicht optional |
Deterministische Prüfungen sind schnell zu erstellen und liefern sofort Wert. Wenn dein Chatbot Fakten immer im gleichen JSON-Format mit fester Reihenfolge zurückgeben soll, prüfst du das mit einem normalen automatisierten Test. Diese Art von Tests solltest du reichlich haben.
Warum Adversarial Testing bei Sprachmodellen zur Pflicht wird
Bei generativen Systemen gibt es keine klare Grenze zwischen einer Anweisung in natürlicher Sprache und dem Verhalten des Systems. Ein Nutzer kann per Freitext Verhalten auslösen, das eigentlich nicht vorgesehen war.
Daraus entstehen Sicherheitsrisiken, die es vorher so nicht gab. Adversarial Testing prüft gezielt, ob sich das Modell durch manipulative Eingaben aus seinem gewünschten Rahmen drängen lässt.
Diese Prüfung darfst du nicht vergessen, wenn du systematisch vorgehst. Sie gehört neben die faktbasierten und subjektiven Tests, nicht dahinter.
Wie ein LLM ein anderes bewertet: der LLM-as-Judge-Ansatz
Für Freitext und subjektive Kriterien setzt sich ein Ansatz durch, der ein weiteres LLM als Bewerter einsetzt. Ein zweites Modell urteilt darüber, ob die Antwort des Systems under Test in einem akzeptablen Rahmen liegt.
Das klingt einfacher, als es ist. Der berechtigte Einwand: Teilen zwei Sprachmodelle nicht dieselben blinden Flecken? Wie stellst du sicher, dass der LLM-Judge das bewertet, was auch ein Mensch beurteilen würde?
Praktisch lässt sich das Risiko senken, indem du für Judge und System verschiedene Modelle nutzt, weil sie dann weniger Blindspots teilen. Für den Judge kannst du auch ein stärkeres Modell wählen als für das System under Test. Das skaliert besser und verursacht bei tausenden Nutzern geringere Betriebskosten als eine manuelle Bewertung.
Wichtiger als die Modellwahl ist das Alignment mit der Domain-Expertise. Du brauchst strukturierte Rubriken: klar definierte Kriterien mit genauen Bedingungen und mit Beispielen. Beispiele verbessern die Urteilsqualität eines LLM spürbar, dasselbe Muster kennt man aus der normalen Nutzung von Chatbots.
RAG als Testobjekt: warum die Verantwortung bei dir bleibt
Wenn du ein Sprachmodell direkt von einem Anbieter nutzt, kannst du einen Teil der Qualitätssicherung an diesen Anbieter auslagern. Bei einem RAG-System geht das nicht mehr.
Retrieval Augmented Generation nutzt das Sprachmodell nur als Bauteil. Alles drumherum baust du selbst, und damit bleibt die Verantwortung für die Qualität bei dir. Das erhöht automatisch die Pflicht, sauber zu testen.
RAG ist zugleich weit verbreitet, weil es eine niedrig hängende Frucht ist: Du erweiterst die Datenbasis eines LLM, ohne es neu zu trainieren. Genau deshalb taugt es gut als Beispiel für ein realistisches Testobjekt.
Wie du die Fehlerursache zwischen Retrieval und Generation isolierst
RAG lässt sich sauber in zwei Teile trennen: Retrieval und Generation. Diese Trennung ist der Schlüssel, um herauszufinden, wo ein Fehler steckt.
Das Retrieval holt relevante Daten aus einer Vektordatenbank. Dieser Teil enthält in der Regel keinen LLM-Anteil, sondern klassische Machine-Learning-Methoden wie Cosine Similarity, Similarity Search und Semantic Similarity. Die Generation nimmt diese Daten und erzeugt daraus die Antwort.
Aus meiner Erfahrung liegen die meisten Probleme im Retrieval. Wenn du ein LLM richtig mit Daten fütterst, kommt auch etwas Vernünftiges heraus. Anupam Krishnamurthy
Deshalb lohnt es sich, gezielte Tests für Retrieval und getrennt davon für Generation zu bauen. So isolierst du die Ursache, statt das Gesamtsystem als Blackbox zu bewerten. Das Prinzip ist identisch zum klassischen Testen: kleinteilig prüfen, Komponenten und Zusammenspiel trennen.
Von grüner Pipeline zu akzeptablem Rahmen
Deterministisches Testen kennt nur Rot und Grün: ein No-Go oder ein Go. Bei KI-Systemen brauchst du eine unschärfere Basis.
Statt binär zu bestehen, bewegen sich Kriterien in einem Wertebereich, etwa zwischen 50 und 100 Prozent Akzeptanz. Als Quality Gate legst du eine Schwelle fest: Liegt die Bewertung über 80 oder 85 Prozent, gilt das Ergebnis als akzeptabel. Bei subjektiven Kriterien gibt es ohnehin keine streng richtige oder falsche Antwort.
Diese Schwellen kalibrierst du mit menschlichen Experten. Studien zur Übereinstimmung zwischen Menschen und LLM-Judges erreichen Agreement-Raten von rund 80 bis 85 Prozent. Zwischen zwei Menschen liegt die Übereinstimmung oft nicht höher. Ein LLM-Judge muss also nicht perfekter sein als ein menschliches Zweitgutachten, er muss den menschlichen Maßstab treffen.
Modell-Benchmarks geben dir falsche Sicherheit
Öffentliche Modell-Benchmarks vermitteln ein künstliches Gefühl von Sicherheit. Sie behaupten, ein Modell sei so gut wie ein PhD, und liefern damit einen Vergleichswert, der für deinen Kontext wenig aussagt.
Das Problem steckt in der Methode. Modelle werden auf Standards trainiert, ähnlich einem Schüler, dem man vorab die Prüfungsfragen gibt und der sie auswendig lernt. Die Prüfung darauf misst dann Auswendiglernen, nicht Eignung für deinen Anwendungsfall.
Im produktiven Betrieb fällt dir das auf die Füße, wenn dein spezifischer Kontext andere Anforderungen stellt als der Benchmark. Fair bleibt: Kein Anbieter kann deinen Kontext vorwegnehmen, weil er zu spezifisch für deinen Use Case ist. Genau deshalb musst du eigene Benchmarks setzen.
Deine bisherigen Skills sind nicht umsonst
Der Umstieg auf KI-Testen entwertet die Erfahrung von Testern nicht. Die analytischen Ansätze, das System zu zerlegen, Komponenten zu isolieren und kontextspezifisch zu prüfen, gelten weiter.
Der Unterschied liegt im Umgang mit Nicht-Determinismus. Dafür braucht es kreatives und kritisches Denken, aber vieles aus jahrelanger Praxis als Quality Professional bleibt wiederverwendbar.
Der eigentliche Reiz liegt woanders. KI-Testen zwingt dich, Selbstverständliches zu hinterfragen: Wie denken wir, wie kommen wir auf Antworten, was heißt Korrektheit überhaupt. Diese Grundlagen lernt man intuitiv und stellt sie normalerweise nie infrage. Beim Testen generativer Systeme musst du genau das tun.
