LLM-Anwendungen testen und absichern

Qualität, Robustheit und Sicherheit generativer KI-Systeme systematisch prüfen

01 Intro

Klassische Softwaretests gehen meist davon aus, dass sich für eine definierte Eingabe ein erwartbares Ergebnis bestimmen lässt. Bei Anwendungen mit Sprachmodellen gilt diese Annahme nur eingeschränkt. Antworten können variieren, fachlich plausibel und trotzdem falsch sein, von kleinen Änderungen des Kontexts abhängen oder sich nach einem Modellupdate verändern. Klassische Testverfahren bleiben deshalb notwendig, reichen allein aber nicht aus.

Der Kurs vermittelt einen systematischen Quality-Engineering-Ansatz für LLM-Anwendungen. Die Teilnehmer entwickeln Evaluationsdatensätze, Qualitätsmetriken und automatisierte Tests, untersuchen Halluzinationen und Robustheit und testen RAG-, Tool- und agentische Systeme. Security wird dabei nicht als separates Randthema behandelt: Prompt Injection, untrusted Content, Datenabfluss, Berechtigungen und missbräuchliche Tool-Aufrufe werden als konkrete Testgegenstände in die Teststrategie integriert.

Kurs-ID

AI-012

Dauer

3 Tage

Format

Präsenz · Live Online · Inhouse

Vorkenntnisse

Erfahrung in Softwaretest, Qualitätssicherung oder Softwareentwicklung und Grundverständnis LLM-basierter Anwendungen

02 Trainingsprogramm

Inhalte

LLM-Anwendungen als Testobjekt

probabilistisches Verhalten und mehrere valide Antworten
Modell, Prompt, Kontext und Anwendungslogik
Retrieval, Tools und Agenten als Teile des Gesamtsystems
fachliche Richtigkeit, Relevanz und Vollständigkeit
Robustheit, Sicherheit und Nachvollziehbarkeit
Latenz, Kosten und Verfügbarkeit als Qualitätsmerkmale

Anforderungen und Testorakel

Qualitätsziele in prüfbare Eigenschaften übersetzen
Muss-Kriterien, Toleranzen und unerlaubte Eigenschaften
Referenzantworten und fachliche Referenzen
Eigenschaften statt exakter String-Vergleiche
mehrere korrekte oder teilweise korrekte Antworten bewerten
deterministische, semantische und menschliche Orakel kombinieren

Evaluationsdatensätze und Ground Truth

repräsentative, schwierige und kritische Eingaben auswählen
reale Fälle, anonymisierte Produktionsfälle und synthetische Ergänzungen
Golden Datasets mit Kontext und erwarteten Eigenschaften
fachlich geprüfte Referenzen und menschliche Annotation
Positiv-, Negativ- und unbeantwortbare Fälle
Versionierung, Herkunft und Coverage des Datensatzes

Testentwurf und Robustheit

klassische Testentwurfsverfahren auf LLM-Systeme übertragen
risikobasiertes und exploratives Testen
metamorphe Tests mit erwarteten Beziehungen
Perturbationen von Formulierung, Reihenfolge und Format
mehrdeutige, fehlerhafte und unerwartete Eingaben
Stabilität bei semantisch äquivalenten Eingaben

Halluzinationen, Abstention und Konsistenz

erfundene Fakten, Quellen und Funktionen erkennen
unbeantwortbare Fragen und fehlende Informationen testen
kontrolliertes Nichtwissen, Rückfragen und Eskalation
gleiche und semantisch gleiche Fragen wiederholt prüfen
fachliche Widersprüche und unnötige Varianz erkennen
Halluzination und Abstention messbar machen

Automatisierte Evaluation

Evaluationspipeline von Testfall bis Report
Schemas, Regeln und bekannte Fakten deterministisch prüfen
semantische Metriken gezielt einsetzen
Retrieval-, Qualitäts-, Performance- und Kostenmetriken kombinieren
Ergebnisse gegen Baselines vergleichen
Grenzen eines einzelnen Quality Scores

LLM-as-a-Judge und Human Evaluation

Bewertungsprompts, Rubriken und Referenzantworten
Scores, Klassifikation und Paarvergleich
Bias, Positionseffekte und Modellabhängigkeit
Judge-Ergebnisse gegen menschliche Bewertungen kalibrieren
Fachexperten und Stichproben gezielt einsetzen
Begründungen des Judge nicht mit Wahrheit verwechseln

Regression und Reproduzierbarkeit

Prompt-, Modell-, Provider- und Kontextänderungen absichern
Modellversion, Parameter und Promptversion protokollieren
Retrieval-, Tool- und Testumgebung reproduzierbar erfassen
nichtdeterministische Regressionen statistisch bewerten
Promptvarianten und Modelle unter gleichen Bedingungen vergleichen
Qualitätsverlust gegenüber einer Baseline erkennen

RAG-Systeme testen

Ingestion, Chunking, Retrieval und Ranking getrennt prüfen
Precision, Recall, Hit Rate und Ground Truth für Retrieval
unbeantwortbare Queries und fehlendes Wissen
Groundedness und Faithfulness der Antwort
Quellenbezug, widersprüchliche Quellen und erfundene Belege
End-to-End-Regression über Retrieval, Kontext und Generierung

Tool Use, Function Calling und MCP testen

Tool-Auswahl, Parameter und erwartete Aufrufe
unnötige oder unerlaubte Tool-Nutzung erkennen
Fehler, ungültige Werte und Ergebnisverarbeitung
Modelloutput und tatsächliche Ausführung getrennt prüfen
MCP Tool Discovery, Schemas und Berechtigungen
manipulierte Tool-Ergebnisse und Serverfehler

Agentische Systeme testen

Zielerreichung, Planung und Aktionsfolgen
Zwischenzustände und erlaubte Wege zum Ergebnis
Abbruch, Eskalation und Recovery
Schleifen, Kontextverlust und unnötige Aktionen
Delegation, Übergaben und Fehlerfortpflanzung in Multi-Agent-Systemen
Erfolg nicht nur am Endergebnis bewerten

Threat Modeling für LLM-Anwendungen

Assets, Akteure und Trust Boundaries
Datenflüsse und Eingabekanäle
externe Dokumente, Webseiten, APIs und Tools als Angriffsfläche
Memory und andere Agenten berücksichtigen
Abuse Cases und mögliche Auswirkungen
konkrete Security-Tests aus Bedrohungen ableiten

Prompt Injection und Datenexfiltration

direkte Prompt Injection und Umgehung von System Instructions
indirekte Injection über Dokumente, Webseiten und Tool-Ausgaben
RAG-Inhalte und andere untrusted Inputs
System Prompt, vertraulichen Kontext und Secrets schützen
Exfiltrationspfade über Tools und externe Kanäle
Angriffsvarianten als Regressionstests erhalten

Berechtigungen, Tools und Memory absichern

Rollen, Mandanten und erlaubte Aktionen
Least Privilege und serverseitige Autorisierung
gefährliche Parameter und Injection in nachgelagerte Systeme
unzulässige Schreibzugriffe und Tool-Komposition
Benutzertrennung, Persistenz und Löschung im Memory
Memory Poisoning und manipulierte gespeicherte Informationen

Adversarial Testing und Red Teaming

Angriffshypothesen aus dem Threat Model ableiten
widersprüchliche Instruktionen und ungewöhnliche Formate
mehrsprachige Angriffe, Encoding und Kontextmanipulation
manuelle Exploration mit automatisierten Varianten verbinden
Findings klassifizieren und in Regressionstests überführen
Datenschutz, Logging und Provider-Nutzung mitprüfen

Performance, Kosten und Resilience

Antwortzeit und Time-to-first-token
lange Kontexte, parallele Nutzer und Rate Limits
Token-, Retrieval-, Reranking- und Agentenkosten
Timeouts, Provider- und Tool-Ausfälle
Retry, Backpressure, Fallback und Degraded Mode
Performance- und Kostenregressionen erkennen

Observability, Quality Gates und CI/CD

Prompt-, Modell-, Retrieval- und Tool-Versionen nachvollziehbar erfassen
Produktionsfehler und Benutzerfeedback in neue Tests überführen
Testpyramide aus deterministischen Tests, Evals und End-to-End-Tests
kritische Qualitäts-, Security-, Performance- und Kostenkriterien
Evals bei Prompt-, Modell- und Retrievaländerungen ausführen
Quality Gates für Pull Requests und Releases

Praxis: eine belastbare Teststrategie entwickeln

Qualitätsmerkmale und Risiken eines Praxisfalls bestimmen
Evaluationsdatensatz und geeignete Orakel festlegen
deterministische Checks und modellbasierte Bewertung kombinieren
RAG-, Tool- oder Agentenanteile gezielt absichern
Security- und Robustheitstests priorisieren
Regression, Observability und Quality Gates zusammenführen

03 Durchführung

Rahmen und Organisation

Dauer

3 Tage

Durchführung

Präsenz oder Live Online, vorzugsweise als Inhouse-Schulung

Schwerpunkt

Inhouse-Schulungen für Unternehmen und Teams

Sprache

Deutsch, englische Fachbegriffe und Dokumentation

Unterlagen

Kursunterlagen, Beispiele und Übungsaufgaben

Technik

Eigener Rechner mit Entwicklungsumgebung und Zugang zu einem aktuellen Sprachmodell

Inhouse-Schulungen

Geeignete eigene Use Cases, Qualitätsanforderungen, RAG-Systeme oder agentische Anwendungen können als Grundlage für Evaluationsdatensätze, Security-Tests und die gemeinsame Teststrategie verwendet werden.

04 Zielgruppe

Für wen ist der Kurs gedacht?

Der Kurs richtet sich an Test Engineers, Test Automation Engineers, Quality Engineers, Softwareentwickler, AI Engineers, Softwarearchitekten und Security-affine technische Consultants, die für die Qualität und Absicherung von LLM-basierten Anwendungen verantwortlich sind.

Er eignet sich insbesondere für Teams, die LLM-Anwendungen, RAG-Systeme oder AI Agents nicht nur funktional ausprobieren, sondern systematisch testen, evaluieren und für einen produktiven Einsatz absichern wollen.

Voraussetzungen

Praktische Erfahrung in Softwaretest, Qualitätssicherung oder Softwareentwicklung wird vorausgesetzt. Grundlegendes Verständnis von generativer KI und LLM-Anwendungen sollte vorhanden sein; Programmierkenntnisse sind für die praktischen Automatisierungsübungen hilfreich. Spezielle Kenntnisse in RAG, MCP oder Agentenarchitekturen werden nicht vorausgesetzt und aus Sicht des Testens so weit erläutert, wie es für die Übungen erforderlich ist.

05 Lernziele

Was Sie nach dem Kurs können

Nach dem Kurs können die Teilnehmer:

Qualitätsmerkmale für LLM-Anwendungen operationalisieren
testbare Anforderungen und Akzeptanzkriterien formulieren
geeignete Testorakel für probabilistische Systeme auswählen
Evaluationsdatensätze und Ground Truth entwickeln
klassische Testentwurfsverfahren auf LLM-Systeme übertragen
metamorphe und Robustheitstests entwickeln
Halluzinationen und Abstention systematisch testen
automatisierte Evaluationspipelines aufbauen
deterministische, semantische und modellbasierte Bewertungen kombinieren
LLM-as-a-Judge kritisch und kontrolliert einsetzen
Regressionen bei Prompt- und Modelländerungen erkennen
RAG-Systeme auf Retrieval- und Antwortqualität testen
Tool-, MCP- und Agentenverhalten prüfen
Prompt-Injection- und Datenexfiltrationsszenarien entwickeln
Berechtigungen und Tool-Grenzen verifizieren
Threat Modeling und Red Teaming in die Teststrategie integrieren
Performance-, Kosten- und Resilience-Anforderungen testen
Produktionsbeobachtungen in neue Tests überführen
Evals und Quality Gates in CI/CD integrieren
eine vollständige Teststrategie für eine LLM-Anwendung entwickeln

06 FAQ

Häufige Fragen

Was unterscheidet diesen Kurs von KI in Qualitätssicherung und Testautomatisierung?

Jener Kurs betrachtet das gesamte Quality Engineering unter dem Einfluss generativer KI. Dazu gehört sowohl der Einsatz von KI für Testanalyse, Testdesign und Testautomatisierung als auch ein Überblick über das Testen AI-basierter Systeme.

Dieser Kurs spezialisiert sich vollständig auf LLM-basierte Systeme als Testobjekt. Evaluation, RAG-Qualität, Tool Use, Agenten, Prompt Injection, Red Teaming, Regression und Quality Gates werden deshalb wesentlich tiefer behandelt.

Was unterscheidet ihn von der LLM-Anwendungsentwicklung mit Python?

Der Entwicklungskurs behandelt den Aufbau einer LLM-Anwendung einschließlich grundlegender Tests und Evaluation. Dieser Kurs setzt auf dieser Systemklasse auf und konzentriert sich vollständig auf deren Verifikation, Qualitätssicherung, Robustheit und Security.

Ist der Kurs nur für Tester?

Nein. Auch Entwickler, AI Engineers und Architekten profitieren davon, insbesondere wenn sie für die Qualität eigener LLM-Systeme verantwortlich sind. Kenntnisse klassischer Testmethoden sind hilfreich, die relevanten Verfahren werden aber auf LLM-Systeme übertragen und eingeordnet.

Werden klassische Softwaretests durch Evals ersetzt?

Nein. Deterministische Softwarekomponenten sollten weiterhin mit klassischen Unit-, Integrations- und Systemtests geprüft werden. Evals ergänzen diese Verfahren dort, wo probabilistisches Modellverhalten bewertet werden muss.

Was ist der Unterschied zwischen Test und Eval?

Die Begriffe überschneiden sich in der Praxis. Im Kurs steht Eval insbesondere für wiederholbare Bewertungen probabilistischer AI-Ausgaben anhand definierter Datensätze und Kriterien. Diese Evals sind Bestandteil einer umfassenderen Teststrategie.

Wird LLM-as-a-Judge behandelt?

Ja, einschließlich seiner Schwächen. Ein zweites Sprachmodell ist kein objektives Testorakel. Deshalb wird modellbasierte Bewertung mit deterministischen Prüfungen, Referenzdaten und menschlicher Evaluation kombiniert.

Werden RAG-Systeme praktisch getestet?

Ja. Retrieval und Generierung werden zunächst getrennt und anschließend End-to-End bewertet. Dadurch lässt sich feststellen, ob eine schlechte Antwort durch fehlendes Retrieval, falschen Kontext oder die eigentliche Generierung verursacht wurde.

Werden AI Agents getestet?

Ja. Dabei wird nicht nur geprüft, ob ein Agent am Ende das gewünschte Ergebnis erreicht. Auch Aktionsfolge, Tool-Nutzung, Berechtigungen, Abbruchbedingungen und unerlaubte Nebenwirkungen werden als Testgegenstände betrachtet.

Wird Prompt Injection praktisch behandelt?

Ja. Direkte und indirekte Prompt-Injection-Szenarien gehören zum praktischen Teil. Der Schwerpunkt liegt darauf, Sicherheitsannahmen tatsächlich zu testen und nicht nur Schutzanweisungen in einen System Prompt zu schreiben.

Ist das eine Penetration-Testing-Schulung?

Nein. Security Testing und Red Teaming von LLM-Anwendungen sind wichtige Bestandteile, der Kurs ist aber eine Quality-Engineering-Schulung für das Gesamtsystem. Klassisches Infrastruktur- oder Web-Penetration-Testing ist nicht Gegenstand des Kurses.

Kann ich Evals in eine CI/CD-Pipeline integrieren?

Ja. Automatisierte Regressionsevaluation und Quality Gates sind ein eigener Bestandteil des Kurses. Dabei wird auch berücksichtigt, dass probabilistische Ergebnisse andere Freigabekriterien benötigen können als klassische Unit Tests.

Warum dauert der Kurs drei Tage?

LLM-Qualität lässt sich nicht sinnvoll auf einige Prompt-Tests reduzieren. Testorakel, Evaluationsdatensätze, Halluzinationen, RAG, Tool Use, Agenten, Security, Regression, Performance und CI/CD bilden gemeinsam ein eigenständiges Quality-Engineering-Gebiet. Drei Tage erlauben, diese Bereiche praktisch zu verbinden, ohne den Kurs zu einer bloßen Übersicht zu reduzieren.

Kann der Kurs an unsere eigene LLM-Anwendung angepasst werden?

Ja. Bei Inhouse-Schulungen können geeignete eigene Use Cases, Qualitätsanforderungen, RAG-Systeme oder agentische Anwendungen als Grundlage für Evaluationsdatensätze, Security-Tests und die gemeinsame Teststrategie verwendet werden.

Schulung anfragen