Wie teste ich eigentlich meine KI-Anwendung?

Die Entwicklung und der Einsatz von KI-Anwendungen, insbesondere solcher, die auf Large Language Models (LLMs) basieren, stellt uns vor völlig neue Herausforderungen beim Testing. Die gewohnten Methoden aus der traditionellen Softwareentwicklung greifen hier nur bedingt. Warum ist das so?

Unterschiede zur traditionellen SW-Entwicklung

In der klassischen Softwareentwicklung arbeiten wir mit einem limitierten Spektrum an Inputs. Denen stehen Outputs gegenüber, die regelhaft und nachvollziehbar aus dem Input erzeugt werden.

Fehler sind meist offensichtlich: Das Programm läuft nicht, wirft eine Fehlermeldung oder liefert eindeutig falsche Ergebnisse. Wenn der Output fehlerhaft ist, kann das nur daran liegen, dass unser SW-Code, der den Output erzeugt, fehlerhaft ist, oder das wir mit diesem Input nicht gerechnet haben. Fehler im Code müssen wir korrigieren, unerwarteten (und unerwünschten) Input können wir ggf. unterbinden.

Wir behandeln also sinnvollerweise alle Fehler unabhängig voneinander. Es kann zwar passieren, dass die Behebung eines Fehlers Auswirkungen auf existierende Funktionalität hat, das hat aber i.d.R. mit Änderungen an gemeinsam genutzten Funktionen, Datenstrukturen o.ä. zu tun und bedeutet nicht, dass die Fälle untrennbar verbunden wären.

In der LLM-basierten Anwendungsentwicklung sieht die Welt anders aus. Fehler sind nicht offensichtlich, statt einer Fehlermeldung wird eine plausible Antwort generiert. D.h. wir müssen den Fehler erst einmal finden.

Schon bei einfachen Anwendungen ist das Spektrum der möglichen Eingaben praktisch unbegrenzt und kann oft auch nicht eingeschränkt werden. Und: es gibt keine punktuellen, abgegrenzten Eingriffe. Alles, was wir dem LLM in einem bestimmten Moment mitgeben, Instruktionen, Kontext, Nutzer-Input – wirken als Gesamtheit. Die Verbesserung eines Falls kann zwanzig andere verschlechtern.

Das ganze explodiert noch in der Komplexität, wenn es um Integrations- / Systemtests von Agentensystemen geht. Dann pflanzen sich möglicherweise Fehler in unvorhergesehener Weise fort.

Und schließlich kommt hinzu: Instruktionen werden nicht immer befolgt: LLMs interpretieren Anweisungen manchmal eigenwillig.

Was folgt daraus?

Es ist beim Testen und Optimieren LLM-basierter Anwendungen nicht sinnvoll, den Einzelfall zu betrachten. Wenn wir versuchen, die Qualität punktuell durch bessere Instruktionen nach oben zu treiben, müssen wir trotzdem großflächig testen – auch Fälle, die schon funktioniert haben: Regelmäßige Regressionstests für das gesamte System sowie seine Teilsysteme (falls vorhanden) sind quasi Pflicht.

Statt sich auf binäre Pass/Fail-Ergebnisse zu stützen, müssen Testprozesse für LLMs auf statistischen Kennzahlen wie Präzision, Recall oder F1-Scores basieren. Diese Metriken zeigen, wie gut das System im Durchschnitt funktioniert – allerdings verdecken sie auch Schwächen bei seltenen oder besonders kritischen Fällen. Ein pragmatischer Ansatz ist es, Schwellenwerte für Metriken zu definieren (z. B. „95% der Antworten müssen korrekt sein“) und gleichzeitig manuelle Reviews für High-Impact-Fälle vorzusehen (z. B. medizinische Ratschläge).

Wir müssen die Fehler erst einmal finden: Wir brauchen umfangreiche Testdaten mit bekannten korrekten Ergebnissen. Aber auch dann ist es nicht trivial, die Übereinstimmung des generierten Outputs mit dem der Testdaten festzustellen. Nur in den allereinfachsten ja-nein- oder multiple-Choice-Outputs liegen Übereinstimmung bzw. Abweichung auf der Hand, bei Aufgaben wie Zusammenfassung von Texten, Antworten eines Chats etc. Oft ist die Auswertung der Testergebnisse selbst eine Herausforderung, die die Unterstützung eines Sprachmodells erfordert.

Einige kritische Fragen bleiben

Es besteht dringender Bedarf an Analyse und Einblick: Ist eine Analyse möglich? Können wir feststellen, wo das LLM häufig von den Instruktionen abweicht? Wo vielleicht Instruktionen im Konflikt zueinander stehen?
Was passiert, wenn wir auf einmal mit mehr Instruktionen schlechtere Ergebnisse bekommen?
Testdaten müssen nicht nur umfangreich sein, sie müssen auch komplexe Fälle, z.B. Multiturn-Interaktionen (Gesprächsverläufe mit mehreren aufeinanderfolgenden Fragen und Antworten) abdecken
Und auch viel größere Testsets werden immer nur die Fälle (mit vielen Variationen) enthalten, die wir vorhergesehen haben. Was ist mit den Fällen, die wir nicht vorhersehen?

Neben umfangreichen automatisierten Tests braucht es also auch „Training on the job“ – das Lernen aus realen Nutzungsszenarien.

Schlussfolgerungen

Müssen wir Software zukünftig so testen wie neue Medikamente freigegeben werden – mit „präklinischen“ und „klinischen Studien“ und einer „Zulassung“?

Auch wenn wir so weit nicht gehen wollen: Wir brauchen fließende Bewertungsskalen und umfangreiche Testfälle. Wir brauchen Regressionstests und eine gute Idee wie wir Fehler als solche erkennen können.

Und wir müssen uns von der Vorstellung verabschieden, dass wir eine Anwendung einmal testen, freigeben und dann unverändert laufen lassen können. Stattdessen brauchen wir neue Methoden und Werkzeuge für kontinuierliche Qualitätssicherung und Performance-Monitoring.

Marian Rahm

Marian studied computer science in Stuttgart and Darmstadt with a focus on ML and NLP. His professional experience includes the development and evaluation of various ML systems in the automotive industry, knowledge management and the healthcare sector.