Evaluierung eines KI-Agenten: Tests, Golden Set und Benchmarks vor der Produktion

Ein Unternehmen hat einen Kundenservice-Agenten aufgebaut. Der Agent läuft seit einer Woche, die Anzahl der Eskalationen zu Beratern sinkt. In der dritten Woche stellt sich heraus, dass der Agent drei Tage lang get_order_status mit einer falschen Bestell-ID aufgerufen hat, was für die Hälfte der Anfragen falsche „Bestellung unterwegs“-Meldungen generierte. Niemand hatte vor der Einführung die Genauigkeit der Tool-Aufrufe überprüft, da sich die Metriken auf Latenz und die Anzahl der bearbeiteten Gespräche beschränkten. Dies ist ein Ausschnitt eines realen Musters, das bei der ersten Agenten-Einführung in polnischen und europäischen Unternehmen auftritt.

Die Evaluierung eines KI-Agenten vor der Produktion ist eine eigenständige Disziplin, die sich vom laufenden Monitoring unterscheidet. Im Folgenden wird beschrieben, wie man sie Schritt für Schritt aufbaut.

Ein Agent ist nicht nur ein Sprachmodell. Er besteht aus einem Modell, einem Satz von Tools (Tool-Use), einer Entscheidungs-Schleife und oft einer RAG-Wissensbasis. Jedes dieser Elemente kann unabhängig von den anderen versagen. Guardrails können korrekt funktionieren, während der Agent dennoch das falsche Tool mit den richtigen Berechtigungen aufruft.

Die Evaluierung von RAG misst, ob das Modell eine Antwort generiert, die dem Quelldokument treu ist. Die Evaluierung eines Agenten misst drei zusätzliche Dimensionen:

• Genauigkeit der Tool-Auswahl – Hat der Agent das richtige Tool für die jeweilige Anfrage aufgerufen?
• Korrektheit der Aufrufparameter – Hat er die richtigen Argumente an das Tool übergeben?
• Task Success Rate – Wurde die mehrstufige Aufgabe mit dem erwarteten Ergebnis abgeschlossen?

Diese drei Dimensionen können vor der Produktion überprüft werden, aber nur, wenn ein Golden Set mit kodierten Erwartungen für jede von ihnen vorhanden ist.

Ein Golden Set ist eine Sammlung von Paaren: (Benutzeranfrage, erwartetes Verhalten des Agenten). Das erwartete Verhalten kann auf verschiedenen Detailebenen vorliegen:

• Antwort-Ebene – Erwarteter Text oder Fragment für den semantischen Vergleich
• Tool-Ebene – Erwartetes Tool, das der Agent aufrufen sollte
• Parameter-Ebene – Erwartete Aufrufargumente (z. B. {"order_id": "{{order_id}}", "locale": "pl"})
• Aufgaben-Ebene – Erwarteter Endzustand nach einer mehrstufigen Sequenz

Für einen Kundenservice-Agenten, der Bestellstatus und Rückgabepolitik abdeckt, beträgt das minimale Golden Set 200-300 Beispiele. Eine grobe Aufteilung: 40 % decken typische Anfragen ab (hohe Frequenz), 30 % decken Edge Cases ab (Ausnahmen der Politik, fehlende Daten), 30 % decken Anfragen außerhalb des Bereichs ab (der Agent sollte eskalieren oder ablehnen).

Fallstricke beim Aufbau eines Golden Sets:

Überrepräsentation von Beispielen aus der Dokumentation. Wenn das Golden Set hauptsächlich aus FAQs oder Anleitungen stammt, die das Modell während des Fine-Tuning oder im RAG gesehen hat, werden die Ergebnisse im Vergleich zur Produktion überschätzt. Ergänze es um echte anonymisierte Meldungen aus früheren Kanälen.

Fehlende Beispiele für Tool-Fehler. Das Golden Set muss Szenarien enthalten, in denen das Tool einen Fehler zurückgibt (Timeout, kein Datensatz, falsches Format). Überprüfe, ob der Agent diese gracefully behandelt und nicht halluziniert.

Auslassung mehrsprachiger Beispiele. Wenn der Agent Kunden in mehreren Sprachen bedient, benötigt jede Sprache eine separate Abdeckung. Modelle verhalten sich bei Anfragen in Minderheitensprachen unterschiedlich.

Die folgende Tabelle zeigt die Evaluierungsdimensionen eines Agenten, die empfohlene Messmethode und die minimale Schwelle vor der Freigabe für die Produktion. Die Schwellen sind ein Ausgangspunkt, keine Garantie – sie hängen von der Kritikalität des Prozesses und dem Fehlerrisiko in deiner Branche ab.

Eine Genauigkeit der Tool-Auswahl unter 90 % vor der Produktion ist ein Signal zur Überarbeitung des Prompt-Systems oder der Few-Shot-Beispiele, nicht zur Einführung mit der Hoffnung auf Verbesserung. Agenten mit fehlerhaftem Tool-Use haben reale Auswirkungen (Datenoperationen, Reservierungen, Zahlungen) und es gibt keinen Mechanismus zur Rückgängigmachung, wie bei einer fehlerhaften Textantwort.

LLM-as-Judge ist eine Methode, bei der ein zweites Modell die Qualität der Antworten des ersten bewertet. Es beschleunigt die Bewertung großer Volumina (1.000+ Paare pro Tag), hat jedoch Grenzen, die man kennen sollte, bevor man sich darauf verlässt.

Wann es gut funktioniert:

• Bewertung der Faithfulness (ob die Antwort dem Quelldokument treu ist) für RAG-Systeme mit klaren Fakten
• Erkennung offensichtlicher Halluzinationen und komplett themenfremder Antworten
• Vergleich zweier Agenten-Versionen (A/B) auf demselben Fragen-Set

Wann es versagt:

• Bewertung der Korrektheit von Tool-Parametern (erfordert deterministische Schema-Validierung, keine sprachliche Bewertung)
• Aufgaben, die domänenspezifisches Wissen erfordern, über das das Richter-Modell nicht verfügt (Recht, Medizin, spezifische Unternehmensrichtlinien)
• Erkennung systematischer Fehler des eigenen Anbieters (wenn Agent und Richter dasselbe Basismodell verwenden, erkennt der Richter den Fehler möglicherweise nicht)

Kalibrierung ist Pflicht. Bevor LLM-as-Judge automatisch eingesetzt wird, bewerten Sie 50-100 Paare manuell, vergleichen Sie mit den Ergebnissen des Richters und berechnen Sie die Pearson-Korrelation oder Cohens Kappa. Eine Korrelation unter 0,75 mit der menschlichen Bewertung disqualifiziert den Richter für diese Dimension. Ein Muster zur Kalibrierung von LLM-as-Judge beschreibt der Artikel zur Evaluierung der RAG-Qualität.

Der Wechsel des Basismodells (z. B. auf eine neuere Version) oder eine Änderung des System-Prompts sind die häufigsten Ursachen für unerwartete Regressionen in produktiven Agenten. Modellanbieter garantieren kein identisches Verhalten zwischen Versionen.

Regressionstests bedeuten, dass das Golden Set mit der neuen Version ausgeführt und die Ergebnisse mit einem Baseline-Snapshot verglichen werden. Drei Schritte, damit es in der Praxis funktioniert:

1. Baseline einfrieren – Nach der Evaluierung vor der Produktion die Ergebnisse (Faithfulness Score, Tool Accuracy, Task Success Rate) als Versionsartefakt speichern. Dies ist Ihr Vergleichspunkt bei jeder Änderung.

2. Ausführung des Golden Sets automatisieren – Integrieren Sie den Regressionstest in die CI/CD-Pipeline oder führen Sie ihn manuell vor jedem Versions-Upgrade aus. Für produktive Agenten ist eine wöchentliche Ausführung des Grundsets (50-100 Paare) das Minimum.

3. Degradationsschwellen definieren – Nicht jede Verschlechterung um 1 Prozentpunkt erfordert eine Blockade. Legen Sie Schwellen fest: Ein Rückgang der Faithfulness um mehr als 3 Prozentpunkte oder eine Tool Accuracy unter der PASS-Schwelle blockiert das Upgrade. Ein Drift zwischen aufeinanderfolgenden Tests – nicht ein einmaliges Ergebnis – ist ein Signal für ein Audit.

Ein Muster zur Erkennung von Qualitätsdrift im Zeitverlauf beschreibt der Artikel zum Monitoring von KI-Agenten. Der Einfluss von Prompt-Änderungen auf die Qualität wird im Artikel zum Prompt Engineering für Unternehmen behandelt.

Ein Agent kann nicht nur in der Textantwort halluzinieren, sondern auch in den Parametern des Tool-Aufrufs. Beispiel: Der Agent ruft create_refund(order_id="ORD-12345") für eine Bestellung auf, die nicht im System existiert, weil er die ID aus dem Gesprächsverlauf interpretiert hat und nicht aus einem echten Datensatz.

Der Schutz vor diesem Fehlertyp erfordert eine Validierung auf der Tool-Seite (nicht nur auf der Agenten-Seite):

• Das Tool gibt einen Fehler 404 oder einen Fehlercode zurück, wenn der Datensatz nicht existiert
• Der Agent hat eine Anweisung im System-Prompt: „Wenn das Tool einen Fehler zurückgibt, versuche es nicht erneut mit anderen Parametern. Eskaliere zum Menschen.“
• Komplexe Structured-Outputs mit JSON-Schema-Validierung vor der Übergabe an das Tool

Der Artikel zum Sicherheitsaudit von KI-Assistenten behandelt den vollen Umfang der Sicherheitstests vor der Produktion, einschließlich Injection-Tests und übermäßiger Tool-Berechtigungen.

Beschreibe den Agenten, den du vor der Produktion testen möchtest, und das Modell zeigt die Struktur des Golden Sets, die Metriken für deinen Bereich und die PASS-Schwellen an, die an das Prozessrisiko angepasst sind (Playground: PII maskiert, keine Speicherung):

Für einen Agenten mit engem Umfang (2-3 Tools, ein Prozess) sind mindestens 150-200 Paare erforderlich. Für vielseitige Agenten (5+ Tools, mehrere Prozesse) liegt der optimale Bereich bei 400-600 Paaren. Unter 150 Paaren ist die Abdeckung von Edge Cases zu gering, um aussagekräftige Ergebnisse zu liefern. Wichtiger als die Größe ist die Zusammensetzung des Sets: 30 % Beispiele außerhalb des Bereichs und 30 % Edge Cases sind notwendig, damit das Golden Set reale Probleme erkennt und nicht nur den Happy Path bestätigt.

Nein. Ohne Kalibrierung ist unklar, ob der Richter dasselbe misst wie ein Mensch. In Projekten, die auf unkalibriertes LLM-as-Judge setzten, waren die Bewertungen um 8-15 Prozentpunkte höher als die von Domänenexperten. Die Kalibrierung erfordert 50-100 manuell bewertete Paare und einen Vergleich mit den Richter-Ergebnissen. Liegt die Pearson-Korrelation unter 0,75, ändere das Richter-Modell oder die Messmethode für diese Dimension.

Isoliere zunächst, in welchem Schritt der mehrstufigen Sequenz der Fehler auftritt: Genauigkeit der Tool-Auswahl, Korrektheit der Parameter oder Interpretation des Tool-Ergebnisses. Ist die Genauigkeit der Tool-Auswahl stabil, aber die Parameter haben sich verschlechtert, liegt das Problem in der Art und Weise, wie das neue Modell Daten aus der Gesprächsstruktur extrahiert. Die Lösung besteht meist darin, Few-Shot-Beispiele zum Prompt hinzuzufügen oder eine strengere Validierung des Structured-Outputs vor dem Aufruf durchzuführen. Der Artikel Warum KI-Projekte scheitern beschreibt systemische Ursachen für Regressionen nach Konfigurationsänderungen.

Ohne historische Meldungen baust du das Golden Set aus drei Quellen auf: (1) Prozessdokumentation und Produkt-FAQ, (2) Interviews mit Kundenservice-Beratern über typische und schwierige Anfragen, (3) synthetische Daten, die aus der Prozessbeschreibung generiert werden. Synthetische Daten müssen vor der Aufnahme in das Golden Set von einem Domänenexperten überprüft werden, da LLM Beispiele aus eigenen Prioritäten generiert, die möglicherweise nicht der realen Anfrageverteilung entsprechen. Der Agenten-Blueprint hilft, den Umfang der Tools und Szenarien zu definieren, die abgedeckt werden müssen.

Wöchentlich für Implementierungen mit einem Volumen von über 500 Anfragen pro Tag, alle zwei Wochen für kleinere. Obligatorisch vor jeder Änderung: des Basismodells, des System-Prompts, des Tool-Sets und der RAG-Wissensbasis. Die automatische Ausführung des Golden Sets in CI/CD bei jedem Pull Request, der die Agenten-Konfiguration ändert, ist Standard für produktive Systeme. Ein Muster für kontinuierliches Monitoring beschreibt der Artikel zum Monitoring der Qualität von KI-Agenten.