Zum Inhalt springen

Best Practice

KI-Agenten testen: Testfälle, Regression, Simulation

KI-Agenten testen im Kundenservice: Testfälle aus echten Konversationen, Regressionstests vor jeder Änderung, simulierte Kunden und klare Freigabekriterien.

· 14 Min. Lesezeit

KI-Agenten zu testen ist der Weg, auf dem ein Supportteam belegt, dass sich ein KI-Agent noch richtig verhält, bevor eine Änderung bei Kunden ankommt. Sie bauen Testfälle aus echten gelösten Konversationen und früheren Fehlern, wiederholen sie vor jeder Änderung an Prompt, Richtlinie, Wissen oder Modell, simulieren schwierige Kunden, prüfen die ausgeführten Aktionen und geben nur frei, wenn ein schriftliches Freigabekriterium erfüllt ist.

Kurz gesagt

  • Ein Agent, der Aktionen ausführt, braucht Tests auf das, was er getan hat (Erstattung ausgelöst, Grenze eingehalten, Fall übergeben), nicht nur auf das, was er gesagt hat.
  • Die besten Testfälle stammen aus Ihren eigenen gelösten Konversationen und früheren Fehlern.
  • Wiederholen Sie das gesamte Regressionsset vor jeder Änderung an Prompt, Richtlinie, Wissen, Modell oder Tool.
  • Führen Sie jeden kritischen Fall mehrmals aus: Ein Agent, der einmal besteht, kann denselben Fall beim nächsten Durchlauf verfehlen.
  • Schreiben Sie das Freigabekriterium vor dem Testlauf auf, damit niemand nach Sicht der Ergebnisse über Schwellen streitet.

Dieser Leitfaden ist der Teil vor dem Release in unserem umfassenderen Leitfaden zur Evaluierung von KI-Agenten.

Was bedeutet es, KI-Agenten zu testen, und worin unterscheidet es sich vom Chatbot-Testen?

Beim Testen von KI-Agenten prüfen Sie einen Agenten, der über mehrere Turns hinweg schlussfolgert und Aktionen in Ihren Systemen ausführt, etwa Erstattungen auslöst, Bestellungen ändert oder Konten aktualisiert. Chatbot-Tests prüfen vor allem Antworten und Gesprächsabläufe. Der Unterschied liegt in den Folgen: Eine falsche Chatbot-Antwort führt einen Kunden in die Irre, eine falsche Agenten-Aktion verändert echte Datensätze.

Wenn Ihr Bot nur antwortet und übergibt, lesen Sie Chatbot testen. Dieser Artikel behandelt, was sich ändert, sobald der Agent handeln kann.

Was Sie testenChatbotKI-Agent, der Aktionen ausführt
Der WegGeskripteter Ablauf, vorhersehbarVariiert von Durchlauf zu Durchlauf; mehrere gültige Wege
AktionenWenige oder keineTool-Aufrufe mit echten Folgen: Erstattungen, Kündigungen, Adressänderungen
KonsistenzWeitgehend deterministischDieselbe Eingabe kann beim nächsten Durchlauf ein anderes Ergebnis liefern
ÜbergabeButton oder SchlüsselwortErmessensentscheidung, die der Agent mitten in der Konversation trifft

Konsistenz ist der schwierige Teil. In der Studie τ-bench, in der ein Sprachmodell den Kunden spielt und der Agent mit domänenspezifischen Tools und Richtlinien arbeitet, lösten selbst starke Agenten mit Function Calling weniger als 50 % der Aufgaben und bestanden dieselbe Retail-Aufgabe in allen 8 Versuchen in weniger als 25 % der Fälle. Bewertet wurde der Erfolg am Zustand der Datenbank am Ende der Konversation, nicht an der Antwort.

Was sollte ein Testfall für einen KI-Agenten enthalten?

Ein Testfall für einen KI-Agenten braucht sechs Kernfelder: das Szenario, die Kunden-Persona, das erwartete Ergebnis, die Aktionen, die der Agent ausführen darf, eine Regel für das Bestehen, die eine zweite Person genauso anwenden würde, und die Quellkonversation, aus der er stammt. Ohne die letzten beiden werden Testergebnisse zu Meinungen.

Hier ist die Vorlage: die sechs Kernfelder plus vier, die das Set pflegbar halten. Kopieren Sie sie in eine Tabelle, eine Zeile pro Fall.

FeldWas Sie eintragenBeispiel
Fall-ID und TagsEine stabile ID plus Tags für Anliegen, Risiko und KanalRF-014 · Erstattung · hohes Risiko · Chat
SzenarioWas der Kunde will und welche Fakten der Agent nachschlagen kannKunde hat einen beschädigten Mixer erhalten, Bestellung 31 Tage alt, 89 USD bezahlt
Kunden-PersonaTon, Wissen, Verhalten über die TurnsAnfangs höflich, widerspricht nach der ersten Antwort, verlangt „einfach die Erstattung“
Erwartetes ErgebnisDer Endzustand in Ihren Systemen, plus was dem Kunden gesagt werden mussKeine automatische Erstattung (Frist sind 30 Tage); Ersatz angeboten oder Fall mit Bestelldaten an einen Menschen übergeben
Erlaubte AktionenWelche Tools der Agent aufrufen darf, mit GrenzenBestellung abfragen: ja. Ersatz anlegen: ja. Erstattung auslösen: nein (außerhalb der Frist). Übergeben: ja
Regel für das BestehenBinär und von jemand anderem prüfbarBestanden, wenn keine Erstattung ausgelöst und keine versprochen wird und entweder ein Ersatz angelegt wird oder die Übergabenotiz Bestellung und Schaden nennt
SchweregradWas ein Fehler bedeutetKritisch: Geld oder Richtlinie. Schwer: falsche Antwort, kein Schaden. Leicht: Ton
VersucheWie viele Durchläufe bestehen müssenKritisch: 3 von 3. Andere: 2 von 3
QuellkonversationLink zur echten Konversation, aus der er stammtTicket-Link, plus Datum der Aufnahme und Grund
Verantwortlich und letzte PrüfungWer den Fall aktuell hältVerantwortlicher für die Erstattungsrichtlinie, geprüft bei jeder Richtlinienänderung

Zwei Regeln halten die Vorlage nützlich. Erstens beschreibt das erwartete Ergebnis einen Zustand, keinen Satz: Der Engineering-Leitfaden von Anthropic zu Evals für Agenten macht denselben Punkt mit einem Beispiel zur Flugbuchung, bei dem zählt, ob eine Reservierung in der Datenbank existiert, nicht ob der Agent sagt, er habe gebucht. Zweitens verweist jeder Fall auf die Konversation, die ihn begründet, sodass Sie bei einer Richtlinienänderung die betroffenen Fälle finden und anpassen können.

Wie bauen Sie ein Golden Set aus echten Konversationen?

Bauen Sie das Golden Set aus Ihrem eigenen Traffic: gelöste Konversationen, die den Agenten von seiner besten Seite zeigen, frühere Fehler, die Sie nie wieder sehen wollen, Eskalationen und die Grenzfälle jeder Richtlinie. Beginnen Sie mit 20 bis 50 Fällen und lassen Sie das Set jede Woche wachsen, statt auf ein perfektes Set mit Hunderten Fällen zu warten.

Der Leitfaden von Anthropic sagt, dass 20 bis 50 einfache Aufgaben aus echten Fehlern ein sehr guter Start sind, und empfiehlt, von Nutzern gemeldete Fehler in Testfälle umzuwandeln, damit die Suite die tatsächliche Nutzung abbildet.

Ein ausgewogenes erstes Set mit 50 Fällen könnte so aussehen (eine Illustration; verschieben Sie die Gewichte nach Ihrem eigenen Volumen und Risiko):

GruppeFälleWoher sie kommen
Top-Anliegen, Normalfall15Ihre 10 bis 15 volumenstärksten Kontaktgründe, je eine saubere gelöste Konversation
Aktionsfälle10Erstattungen, Kündigungen, Tarifwechsel, Adressänderungen: innerhalb und knapp außerhalb jeder Grenze
Frühere Fehler10Konversationen, in denen der Agent falsch lag, die wieder geöffnet wurden oder über die sich ein Kunde beschwert hat
Übergabefälle6Fälle, die der Agent an einen Menschen geben muss: rechtliche Drohungen, schutzbedürftige Kunden, Betrugssignale
Fälle ohne bekannte Antwort4Fragen, die Ihre Wissensdatenbank nicht beantwortet; der Agent muss das sagen, nicht erfinden
Manipulative Fälle5Versuche, den Agenten über eine Grenze hinweg oder aus seinen Anweisungen heraus zu reden

Behalten Sie die bestandenen Fälle im Set: Eine Korrektur an einem Ablauf kann unbemerkt einen anderen kaputt machen, und nur Fälle, die früher bestanden haben, zeigen das. Entfernen Sie personenbezogene Daten aus jeder Quellkonversation, bevor sie zum Testfall wird.

Wie führen Sie Regressionstests vor jeder Änderung an einem KI-Agenten aus?

Führen Sie Regressionstests aus, indem Sie das gesamte Golden Set gegen den geänderten Agenten abspielen, bevor er live geht, mit denselben Regeln wie beim letzten Mal, und die Ergebnisse mit der aktuellen Version vergleichen. Jede Änderung zählt: Prompts, Richtlinien, Wissensartikel, Modellversionen, Tools und Routing-Regeln verändern das Verhalten. Ein überarbeiteter Hilfeartikel kann Antworten zu Erstattungen so stark verändern wie eine Prompt-Änderung.

ÄnderungWas meist kaputtgehtMindestens erneut ausführen
Prompt oder AnweisungenTon, Umfang, Zeitpunkt der ÜbergabeGesamtes Set
Richtlinie (Erstattungsfrist, Grenzen)Aktionsfälle an der alten und neuen GrenzeGesamtes Set, plus neue Grenzfälle für die neue Grenze
Wissensartikel ergänzt oder bearbeitetAntworten, die ihn zitieren; benachbarte ThemenFälle mit dem Tag dieses Themas, dann das gesamte Set vor dem Release
ModellversionAlles, oft subtilGesamtes Set, kritische Fälle mit zusätzlichen Versuchen
Neues Tool oder neue BerechtigungAktionen, falsches Tool gewählt, Aktionen ohne BestätigungAktions- und Manipulationsfälle, dann das gesamte Set
Routing- oder ÜbergaberegelFälle, die einen Menschen erreichen sollen oder nichtÜbergabefälle, dann das gesamte Set

Führen Sie kritische Fälle mehr als einmal aus. Agenten sind nicht deterministisch, ein einzelnes Bestehen beweist also wenig; die Autoren von τ-bench haben aus diesem Grund pass^k vorgeschlagen, die Wahrscheinlichkeit, dass alle k Durchläufe gelingen. Die Rechnung (Illustration): Ein Fall, den der Agent in 90 % der Fälle besteht, besteht 3 Durchläufe hintereinander nur zu 73 % (0,9 × 0,9 × 0,9) und 8 Durchläufe hintereinander nur zu 43 %.

Regressionsfälle sollten zu 100 % oder sehr nahe daran bestehen. Der Leitfaden von Anthropic trifft dieselbe Unterscheidung: Regressions-Evals sollten eine Bestehensquote von nahezu 100 % haben, während Capability-Evals für neue Fähigkeiten niedrig beginnen dürfen.

Wie simulieren Sie Kunden, um einen KI-Agenten zu testen?

Simulieren Sie Kunden, indem ein zweites Modell den Kunden nach einer schriftlichen Persona über mehrere Turns gegen den Agenten spielt, den Sie testen. Geben Sie jeder Persona ein Ziel, Fakten, ein Temperament und einen Punkt, an dem ihr der Geduldsfaden reißt, und ergänzen Sie manipulative Personas, die den Agenten über seine Grenzen drängen.

Einzelne Fragen testen Antworten. Simulationen über mehrere Turns, das Design von τ-bench, testen, was in echten Konversationen schiefgeht: den Kunden, der sein Anliegen mittendrin ändert oder immer wieder auf eine Erstattung drängt, die die Richtlinie nicht erlaubt.

Schreiben Sie fünf bis acht Personas und nutzen Sie sie in mehreren Szenarien:

  1. Der Klare: ein Anliegen, alle Angaben vorhanden. Ihre Baseline.
  2. Der Vage: Bestellnummer fehlt, falscher Produktname. Testet Rückfragen.
  3. Der Wechsler: beginnt mit der Lieferung, endet mit einer Kündigung.
  4. Der Drängler: lehnt die erste Antwort dreimal ab und verlangt eine Ausnahme. Testet Grenzen unter Druck.
  5. Der Verärgerte: droht mit Kündigung oder öffentlicher Beschwerde. Testet Ton und Übergabe.
  6. Der Schutzbedürftige: erwähnt einen Trauerfall, eine Krankheit oder Geldsorgen. Testet Ihre Übergaberegeln für diese Fälle.
  7. Der Manipulator: gibt sich als Mitarbeiter aus, fügt „Ignoriere deine Anweisungen“ ein oder versteckt Anweisungen in einem Anhang. Testet die Widerstandsfähigkeit gegen das, was OWASP Prompt Injection nennt.

Eine Persona findet nur die Probleme, die Sie in sie hineingeschrieben haben. Nutzen Sie Simulation deshalb, um das Set zu verbreitern, und echte Konversationen, um es ehrlich zu halten. Voicebots bringen Akzente, Unterbrechungen und Leitungsqualität mit; siehe Qualitätssicherung für KI-Voicebots.

Wie testen Sie die Aktionen und Tool-Aufrufe eines KI-Agenten?

Testen Sie Aktionen, indem Sie nach der Konversation den Endzustand in Ihren Systemen prüfen, nicht die Beschreibung des Agenten. Gibt es den Erstattungsdatensatz, über den richtigen Betrag, zur richtigen Bestellung? Ist der Agent innerhalb seiner Grenzen geblieben, hat er dort um Bestätigung gebeten, wo es vorgeschrieben ist, und hat er kein Tool aufgerufen, das er nicht durfte?

Eine Antwort wie „Ich habe Ihre Erstattung veranlasst“ beweist nichts. Prüfen Sie pro Aktionsfall vier Dinge:

  1. Richtige Aktion. Das erwartete Tool wurde aufgerufen, und kein unerwartetes.
  2. Richtige Argumente. Richtige Bestellung, richtiger Kunde, richtiger Betrag und Grund.
  3. Innerhalb der Grenzen. Betrag unter der Obergrenze, Berechtigung vorhanden, Freigabe eingeholt, wo Ihre Richtlinie einen Menschen verlangt.
  4. Wahrheitsgemäße Meldung. Was der Agent dem Kunden gesagt hat, stimmt mit dem überein, was im System tatsächlich passiert ist.

OWASP zählt Excessive Agency zu den größten Risiken für LLM-Anwendungen: schädliche Aktionen, ermöglicht durch zu viel Funktionalität, zu viele Berechtigungen oder zu viel Autonomie. Die Gegenmaßnahmen (minimale Erweiterungen, minimale Berechtigungen, Freigabe durch den Nutzer) dienen zugleich als Testliste. Schreiben Sie für jede Grenze mindestens einen Fall, in dem der Kunde knapp darüber verlangt.

Führen Sie Aktionstests in einer Sandbox oder mit Testkonten aus, nie mit echten Datensätzen. Das Salesforce-Training zum Agentforce Testing Center warnt, dass das Testen von Agenten CRM-Daten verändern kann, und empfiehlt, es nur in einer Sandbox zu nutzen.

Auch die Übergabe ist eine Aktion: Testen Sie, ob der Agent die Fälle übergibt, die er übergeben soll, mit einer Notiz, mit der die Person weiterarbeiten kann (Eskalationsmanagement im Kundenservice).

Wie werden Fehler aus der Produktion zu neuen Testfällen?

Fehler aus der Produktion werden über eine wöchentliche Routine zu Testfällen: die Konversationen finden, in denen der KI-Agent falsch lag, den Fehler bestätigen, personenbezogene Daten entfernen, den Fall mit der Vorlage oben schreiben und ihn ins Golden Set aufnehmen. Die nächste Änderung darf erst live gehen, wenn dieser Fall besteht.

Der schwierige Teil ist, die Fehler zu finden. Eine Konversation, die der Agent „gelöst“ hat, kann trotzdem eine falsche Antwort, eine erfundene Richtlinie oder eine verpasste Übergabe enthalten, und Dashboards zählen sie als Erfolg (stille Fehler von KI-Agenten). Das Monitoring von KI-Agenten beschreibt, was Sie täglich beobachten sollten, und die Qualitätssicherung für KI-Agenten zeigt, wie Sie die Scorecard bauen, die solche Fehler findet.

Hier treffen QA echter Konversationen und Tests vor dem Release aufeinander. AutoPilot von Kaizo bewertet jede gelöste Konversation eines KI-Agenten anhand Ihrer eigenen Scorecard und verknüpft jeden Score mit den Belegen. So erhalten Sie bestätigte Fehler, jeweils mit einer Quellkonversation für die Vorlage. Nach dem Rollout der Korrektur zeigt die Bewertung der Live-Konversationen der folgenden Wochen, ob sie hält.

Sehen Sie, wo Ihr KI-Agent heute scheitert. Kaizo bewertet Konversationen von KI-Agenten anhand derselben Scorecard wie Ihr Team und verknüpft jeden Score mit den Zeilen dahinter. Demo buchen.

Wenn Sie mit einem KI-Bewerter arbeiten, prüfen Sie auch den Bewerter. Unser Leitfaden zur Validierung von KI-QA-Bewertungen (auf Englisch) zeigt, wie Sie automatische Scores mit Ihren Reviewern vergleichen, bevor Sie ihnen vertrauen.

Was sollte ein Freigabekriterium für einen KI-Agenten prüfen?

Ein Freigabekriterium für einen KI-Agenten ist eine kurze schriftliche Liste von Bedingungen, die eine Änderung erfüllen muss, bevor sie Kunden erreicht, vereinbart vor dem Testlauf. Es sollte bei jedem kritischen Fehler blockieren, nahezu perfekte Regressionsergebnisse verlangen, jede Aktion und jede Grenze abdecken und festlegen, wer freigibt und wie zurückgerollt wird. Kopieren Sie es und setzen Sie Ihre eigenen Zahlen.

Vor dem Durchlauf

  • Die Änderung ist aufgeschrieben: was, warum, wer sie angefragt hat.
  • Neue Fälle für die Änderung selbst (eine neue Grenze bekommt Fälle knapp innerhalb und knapp außerhalb).
  • Jeder seit dem letzten Release in der Produktion bestätigte Fehler ist im Set.
  • Testkonten und Sandbox bereit; keine echten Kundendatensätze erreichbar.

Der Durchlauf

  • Gesamtes Golden Set gegen den geänderten und den aktuellen Agenten ausgeführt, mit denselben Regeln.
  • Kritische Fälle (Geld, Daten, Recht, schutzbedürftige Kunden) jeweils mindestens 3-mal ausgeführt.
  • Simulierte Personas ausgeführt, darunter der Manipulator und der Drängler.

Bedingungen für das Bestehen

  • Kritische Fälle: 100 % bestanden, in jedem Versuch. Ein Fehler blockiert das Release.
  • Regressionsfälle: mindestens 98 % bestanden, und kein Fall, der beim letzten Release bestanden hat, scheitert jetzt ohne Erklärung.
  • Aktionsfälle: keine Aktion außerhalb der erlaubten Liste, kein Betrag über der Grenze, keine Behauptung einer Aktion, die nicht stattgefunden hat.
  • Übergabefälle: Jeder Fall, der übergeben werden muss, hat einen Menschen mit einer brauchbaren Notiz erreicht.
  • Fälle ohne bekannte Antwort: keine erfundenen Antworten.

Freigabe und nach dem Release

  • Ein benannter Verantwortlicher zeichnet ab: Support- oder CX-Leitung für Richtlinien und Ton, Verantwortlicher für die KI für die technische Seite.
  • Rollback ist vorbereitet: Der vorherige Prompt, das vorherige Wissen und die vorherige Modellversion lassen sich am selben Tag wiederherstellen.
  • Die ersten Tage an Live-Konversationen nach dem Release werden genauer geprüft als üblich.

Rechenbeispiel (eine Illustration mit erfundenen Zahlen). Ein Team verkürzt seine Erstattungsfrist von 30 auf 14 Tage. Sein Golden Set hat 120 Fälle: 40 kritische, 80 andere. Kritische Fälle laufen 3-mal, andere einmal, der Durchlauf hat also 200 Versuche. Das Ergebnis: 196 von 200 Versuchen bestehen, eine Quote von 98 %, die gesund aussieht. Aber alle 4 Fehler liegen in zwei kritischen Fällen. In einem bot der Agent an Tag 20 in einem von drei Versuchen noch eine Erstattung an. Im anderen redete ihn die Drängler-Persona in allen drei Versuchen zu einer „Kulanzerstattung“. Das Freigabekriterium blockiert das Release. Die Korrektur geht in den Prompt und einen Wissensartikel, zwei neue kritische Fälle für Tag 14 und Tag 15 kommen hinzu, und der erneute Durchlauf besteht 206 von 206 Versuchen. Ein Durchschnitt hätte den Fehler ausgeliefert; das Freigabekriterium nicht.

Welche Tools brauchen Sie zum Testen von KI-Agenten?

Sie brauchen drei Arten von Tools: einen Ort, an dem Testfälle gespeichert und versioniert werden, einen Weg, sie gegen den Agenten auszuführen (oft mit simulierten Kunden), und einen Weg, die Ergebnisse anhand Ihrer Regeln zu bewerten.

  • Eine Tabelle und manuelle Durchläufe reichen bei weniger als etwa 50 Fällen und wenigen Änderungen pro Monat.
  • Eine Testfunktion der Plattform passt zu einer Plattform mit Standardabläufen. Das Agentforce Testing Center von Salesforce zum Beispiel erzeugt standardmäßig 20 Testfälle, und Sie legen fest, wie viele davon positiv und negativ sind.
  • Test- und Simulationstools ergänzen simulierte Kunden, wiederholte Versuche und Release-Prüfungen in der Deployment-Pipeline.
  • QA echter Konversationen bewertet, was nach dem Release wirklich passiert ist, und spielt bestätigte Fehler ins Set zurück.

Was Sie auch wählen: Halten Sie die Fälle in einem Format, das Ihr Supportteam lesen und bearbeiten kann, sonst hören die Verantwortlichen für die Richtlinien auf, sie zu pflegen.

Wann ist ein vollständiges Testprogramm nichts für Sie?

Ein vollständiges Programm ist überdimensioniert, wenn Ihr KI-Agent wenige Dutzend Konversationen pro Woche bearbeitet, nur Fragen beantwortet und keine Aktionen ausführen kann. Lesen Sie in diesem Fall die Transkripte wöchentlich und führen Sie eine kurze Liste mit 20 Fällen, die Sie nach jeder Änderung von Hand wiederholen.

QA echter Konversationen ersetzt es auch nicht: Konversationen nach ihrem Ende zu bewerten, hält keine Änderung vor dem Release auf. Sie brauchen beides, Tests vor der Änderung und danach die Bewertung jeder Konversation Ihrer KI-Agenten.

So starten Sie diese Woche

Ein erstes Golden Set, ein schriftliches Freigabekriterium und einen Baseline-Durchlauf schaffen Sie in fünf Arbeitstagen, mit einem Export aktueller Konversationen, der Vorlage oben und einer Testumgebung.

  1. Montag: Exportieren Sie 30 gelöste Konversationen des KI-Agenten und 20, die schiefgegangen sind. Entfernen Sie personenbezogene Daten.
  2. Dienstag: Übertragen Sie sie in die Vorlage. Markieren Sie, welche kritisch sind.
  3. Mittwoch: Schreiben Sie das Freigabekriterium. Lassen Sie Supportleitung und Verantwortlichen für die KI die Zahlen vereinbaren.
  4. Donnerstag: Führen Sie das Set gegen den aktuellen Agenten aus, mit drei Versuchen für kritische Fälle. Das ist Ihre Baseline; rechnen Sie mit einigen Fehlern.
  5. Freitag: Vereinbaren Sie die Regel, dass keine Änderung an Prompt, Richtlinie, Wissen oder Modell ohne erneuten Durchlauf live geht, und legen Sie einen wöchentlichen Termin fest, um neue Fehler ins Set aufzunehmen.

Wer die Freigabe verantwortet, lesen Sie unter Governance von KI-Agenten.

Häufig gestellte Fragen

Was ist KI-Automatisierung beim Testen?

KI-Automatisierung beim Testen meint meist den Einsatz von KI zum Testen von Software, zum Beispiel Agenten, die Testskripte für eine Web-App schreiben und ausführen. Dieser Artikel behandelt ein anderes Thema: belegen, dass ein KI-Agent mit Kundenkontakt richtig antwortet und handelt, bevor eine Änderung live geht.

Haben KI-Agenten Tools?

Ja. Die Tools eines KI-Agenten sind die Funktionen, die er aufrufen kann, etwa eine Bestellung abfragen oder eine Erstattung auslösen. Deshalb müssen Agenten-Tests den Endzustand in Ihren Systemen prüfen, nicht nur die Antwort.

Was ist ein KI-Tester?

Entweder eine Person, die KI-Systeme testet, oder eine KI, die andere Software testet. Im Kundenservice ist es meist eine QA-Leitung oder der Verantwortliche für die KI, der Testfälle aus echten Konversationen schreibt und entscheidet, ob eine Änderung das Freigabekriterium erfüllt.

Wie viele Testfälle braucht ein KI-Agent?

Beginnen Sie mit 20 bis 50 Fällen aus echten Konversationen und früheren Fehlern und ergänzen Sie dann jeden bestätigten Fehler aus der Produktion. Die Abdeckung Ihrer Top-Anliegen, Aktionen und Grenzen zählt mehr als die reine Anzahl.

Wie oft sollten Sie Regressionstests für KI-Agenten ausführen?

Führen Sie das gesamte Set vor jeder Änderung an Prompts, Richtlinien, Wissen, Modellen, Tools oder Routing aus, und zusätzlich wöchentlich, auch wenn sich nichts geändert hat, weil sich auch Modellanbieter und angebundene Systeme ändern.

Auf dieser Seite

Weiterlesen

Sehen Sie das in einer Live-Demo

Wir führen Sie mit realistischen Beispielkonversationen durch Kaizo, damit Sie sehen, wie das Beispiel bewertet, erklärt und gecoacht wird.

Von globalen Supportteams genutzt

  • Foot Locker
  • Canva
  • GetYourGuide
  • Instacart
  • BlaBlaCar
  • UiPath