Warum KI-Agenten mehr brauchen als Unit-Tests – ein Praxisbeispiel

Ein Softwareentwickler entdeckte einen kritischen Fehler in seinem KI-Agenten – obwohl alle Unit-Tests bestanden. Das Problem: Der Agent gab finanzielle Empfehlungen, obwohl er explizit angewiesen war, keine solchen Ratschläge zu erteilen. Erst ein umfassendes Evaluierungsframework mit 131 Tests zeigte das Versagen auf. Kein Exception, keine rote Log-Meldung, nur eine saubere Antwort mit HTTP-Statuscode 200. Dieser Fall verdeutlicht, warum herkömmliche Unit-Tests bei KI-Systemen oft versagen.

Unit-Tests decken keine semantischen Lücken ab

Unit-Tests prüfen deterministische Verträge: Ein definierter Input führt zu einem vorhersehbaren Output. Doch bei KI-Agenten, die auf Large Language Models (LLMs) basieren, ist diese Logik nicht anwendbar. Ein und derselbe Prompt, dieselbe Temperatur und dieselbe Modellversion können unterschiedliche Ausgaben erzeugen. Noch komplexer wird es, wenn der Agent zwischen verschiedenen LLMs wie Groq (Llama 3.3 70B) und Claude wechselt – jede Kombination führt zu unterschiedlichen Codepfaden und potenziellen Fehlerquellen.

Viele Entwickler reagieren auf diese Unvorhersehbarkeit mit zwei unzulänglichen Ansätzen: Entweder sie verzichten komplett auf Tests im Modell-Layer, indem sie den Prompt als reine Konfiguration betrachten – ein Fehler, der im beschriebenen Fall zu gefährlicher Finanzberatung führte. Oder sie setzen auf bruchanfällige String-Vergleichstests wie assert "Ich kann nicht" in Antwort, die sofort versagen, sobald das Modell seine Ablehnung anders formuliert. Beide Methoden scheitern an der Kernherausforderung: KI-Agenten benötigen Tests, die nicht die exakte Ausgabe prüfen, sondern die Erfüllung semantischer Eigenschaften sicherstellen.

Die vier Ebenen des Evaluierungsframeworks

Das entwickelte Framework besteht aus vier aufeinander aufbauenden Ebenen, die jeweils spezifische Fehlerklassen abdecken. Die Struktur entstand nicht durch theoretische Planung, sondern durch praktische Notwendigkeit: Jede neue Fehlerart erforderte eine zusätzliche Ebene.

Ebene 1: Deterministische Verträge (ca. 40 Tests, Millisekunden, kostenlos)

Diese Ebene entspricht klassischen Unit-Tests und prüft keine LLM-Aufrufe. Beispiele:

• Wird eine korrekte Intent-Klassifizierung vorgenommen?
• Leitet der Router die Anfrage an das richtige Modell (z.B. Claude für komplexe Anfragen, Groq für schnelle Antworten)?
• Werden Tool-Argumente korrekt serialisiert?

Diese Tests sind extrem schnell und kostenlos, weshalb sie bei jedem Commit ausgeführt werden. Sie fangen einfache, aber häufige Fehler ab und bilden die Grundlage für das gesamte Framework.

Ebene 2: Strukturvalidierung (ca. 35 Tests, echte Modellaufrufe, günstig)

Hier werden echte LLMs aufgerufen, jedoch nur die strukturelle Korrektheit der Antwort geprüft. Typische Prüfungen:

• Enthält die Antwort valides JSON?
• Wird ein Tool aus der erlaubten Menge ausgewählt?
• Sind alle Pflichtfelder vorhanden?

Ein konkreter Fall aus der Praxis: Llama 3.3 auf Groq umschloss gelegentliche JSON-Tool-Aufrufe mit Markdown-Codeblöcken, während Claude dies nicht tat. Der Parser verarbeitete Claudes saubere Ausgabe problemlos, während die Groq-Ausgabe stumm ignoriert wurde. Erst Ebene 2 entdeckte diesen Unterschied durch echte Modellaufrufe.

Ebene 3: Verhaltens- und semantische Eigenschaften (ca. 45 Tests, teuerste Ebene)

Diese Ebene prüft die inhaltliche Bedeutung der Antworten gegen definierte Eigenschaften. Einige Tests nutzen einfache Heuristiken wie Sprachenerkennung, um sicherzustellen, dass die Antwort in der Sprache des Nutzers erfolgt. Komplexere Prüfungen erfordern einen LLM-as-Judge-Ansatz – ein separates Modell (z.B. Claude) bewertet, ob eine Antwort gegen Vorgaben verstößt.

Im beschriebenen Fallbeispiel fragte ein Nutzer nach einer konkreten Empfehlung für die Geldanlage. Obwohl das System explizit angewiesen war, keine Finanzberatung zu erteilen, gab der Agent eine Empfehlung ab. Erst Ebene 3 deckte dies auf: Ein unabhängiger LLM-Judge bewertete die Antwort als spezifische Finanzberatung und löste damit den Test aus.

Ebene 4: Dialogebene und Mehrfach-Turns (ca. 11 Tests, langsamste Ebene)

Einzelne Turn-Tests übersehen Fehler, die sich erst über mehrere Interaktionen zeigen:

• Wird Kontext zwischen Nutzern übertragen (Cross-User-Kontamination)?
• Behält der Agent Constraints bei, die vor drei Turns genannt wurden?
• Geht bei Agenten-Wechsel Kontext verloren, insbesondere bei Sicherheitseinstellungen?

Diese Tests sind aufwendig in der Erstellung und Ausführung, decken aber die teuersten Produktionsfehler ab – insbesondere solche mit Auswirkungen auf echte Nutzerdaten oder Sicherheitslücken.

Wirtschaftlichkeit: Warum 3 Cent pro Lauf entscheidend sind

Ein vollständiger Durchlauf aller 131 Tests kostet aktuell etwa drei Cent pro Ausführung. Diese scheinbar geringe Summe ist kein Zufall, sondern das Ergebnis gezielter Designentscheidungen, die die Praxistauglichkeit sicherstellen.

Ohne diese Kosteneffizienz würde das Framework vermutlich nur einmal täglich ausgeführt – mit der Folge, dass Fehler erst spät entdeckt werden. Bei drei Cent pro Lauf lässt sich das Framework bei jedem signifikanten Prompt- oder Routing-Update ausführen, was eine schnelle Feedbackschleife ermöglicht. Die Aufteilung der Kosten:

• Ebene 1 und 2 tragen den Großteil der Last und sind extrem günstig. Die deterministischen Tests sind kostenlos; die Strukturtests nutzen günstige Modelle wie Groq, deren Kosten im Cent-Bereich liegen.
• Ebene 3 treibt die Kosten durch die LLM-as-Judge-Aufrufe in die Höhe. Hier kommt es auf kompakte Prompts und kurze Antworten an. Der Einsatz teurer Modelle wie Claude Opus als Judge wäre unwirtschaftlich.

Fazit: Evals sind kein Luxus, sondern Notwendigkeit

Die Fallstudie zeigt, dass herkömmliche Unit-Tests bei KI-Agenten systematisch versagen. Sie prüfen nur, ob der Code das tut, was programmiert wurde – nicht, ob das System das tut, was beabsichtigt war. KI-Systeme benötigen stattdessen ein mehrschichtiges Evaluierungsframework, das semantische Eigenschaften, mehrfache Modellaufrufe und dialogbasierte Kontextprüfungen abdeckt. Die Investition in ein solches System zahlt sich aus: Es verhindert kostspielige Produktionsfehler, schützt vor regulatorischen Risiken und sichert die Nutzererfahrung. Angesichts der rasanten Entwicklung von LLM-basierten Agenten wird der Aufbau robuster Evaluierungsframeworks zu einer zentralen Fähigkeit für jedes KI-Entwicklungsteam.