Zum Hauptinhalt springen

Bedingungen

Kurz gesagt: Sie wissen, was Ihr Bot tun soll, aber nicht genau, was er sagen wird. Bedingungen ermöglichen es Ihnen, das gewünschte Ergebnis zu überprüfen — die richtigen Daten wurden extrahiert, der korrekte Ablauf wurde ausgelöst, die Antwort hatte die richtige Absicht — ohne sich auf die genaue Wortwahl zu verlassen.

Wenn ein Bot antwortet, hängt seine Ausgabe vom LLM, dem Gesprächskontext, externen APIs und davon ab, wie der Benutzer seine Eingabe formuliert hat. Sie können — und sollten — in den meisten Fällen nicht den genauen Antworttext festlegen. Was Sie festlegen können, ist, ob der Bot den richtigen Zustand erreicht hat.

Bedingungen sind diese Feststellungen. Jede Bedingung ist an eine Runde angehängt und wird nach der Antwort des Bots ausgewertet. Wenn eine Bedingung in einer Runde fehlschlägt, schlägt die Runde fehl. Sofern keine Wiederholungen konfiguriert sind, schlägt auch der gesamte Testfall fehl.

Bedingungstypen​

Äußerungsbedingung​

Validiert den Text der Antwort des Bots. Dies umfasst alles von der Überprüfung, ob ein bestimmter Satz vorhanden ist, bis hin zur Bewertung, ob der Ton angemessen ist.

Übereinstimmungstypen:

ÜbereinstimmungstypFunktionsweise
Semantisch (LLM)Ein LLM beurteilt, ob die Antwort ein Kriterium der natürlichen Sprache erfüllt
ExaktDie Antwort muss genau mit dem erwarteten String übereinstimmen
EnthältDie Antwort muss den erwarteten Teilstring enthalten
RegexDie Antwort muss einem regulären Ausdrucksmuster entsprechen

Der semantische Übereinstimmungstyp ist besonders nützlich für subjektive Qualitäten — Ton, Empathie, Klarheit — die nicht mit einem einfachen String-Match ausgedrückt werden können. Sie geben ein Bewertungskriterium in natürlicher Sprache an (z.B. „Hat der Bot die Frustration des Benutzers anerkannt?“) und das LLM gibt eine Pass/Fail-Entscheidung mit Begründung zurück.

Slot-Bedingung​

Validiert, dass ein Extraktionsfeld (Slot) nach der Runde den erwarteten Wert enthält. Dies ist nützlich, um zu überprüfen, ob Ihr Bot Informationen aus dem Gespräch korrekt erfasst hat — zum Beispiel, dass die Stadt eines Benutzers extrahiert und mit dem richtigen Wert gespeichert wurde.

LLM-Richter-Bedingung​

Verwendet einen KI-Richter, um die Gesprächsqualität anhand benutzerdefinierter Kriterien zu bewerten. Im Gegensatz zur semantischen Äußerungsübereinstimmung verweist eine LLM-Richter-Bedingung immer auf einen gespeicherten LLM-Richter — einen wiederverwendbaren globalen Agenten, der die LLM-Konfiguration, die Standardbewertungsanweisungen und benutzerdefinierte Variablen kapselt.

Wenn Sie einer Runde eine LLM-Richter-Bedingung hinzufügen, wählen Sie aus, welchen LLM-Richter Sie verwenden möchten. Sie können optional die Standardanweisungen für diesen speziellen Testfall überschreiben, ohne den zugrunde liegenden LLM-Richter zu ändern. Dies erleichtert die Wiederverwendung desselben Richters in vielen Tests, während die Bewertung pro Test dennoch angepasst werden kann.

Der Richter erhält den Gesprächsverlauf und die Antworten des Bots und gibt dann eine Pass/Fail-Entscheidung zusammen mit seiner Begründung zurück.

Gute LLM-Richter-Anweisungen sind spezifisch und messbar. Vergleichen Sie:

  • Vage: „War die Antwort gut?“
  • Klar: „Hat der Bot die Beschwerde des Benutzers anerkannt und mindestens einen spezifischen nächsten Schritt angeboten?“

Siehe Globale Agenten unten, um zu erfahren, wie Sie LLM-Richter erstellen und verwalten.

Werkzeugaufruf-Bedingung​

Überprüft, ob ein bestimmtes Werkzeug oder eine Funktion während der Runde vom Bot aufgerufen wurde. Dies ist der primäre Weg, um die Orchestrator-Routing zu validieren — zu bestätigen, dass der Bot den richtigen Ablauf oder die richtige Aktion als Antwort auf die Benutzereingabe aufgerufen hat.

Sie geben den genauen Werkzeugnamen an, den Sie überprüfen möchten. Optional können Sie auch die Argumente validieren, die an das Werkzeug übergeben wurden, indem Sie die erwarteten Argumentwerte als JSON-Objekt bereitstellen.

Benutzerdefinierte Skript-Bedingung​

Führt ein Python-Skript aus, um alles zu validieren, was die anderen Bedingungstypen nicht ausdrücken können. Das Skript hat Zugriff auf den vollständigen Gesprächszustand, alle während der Runde emittierten Ereignisse, die Äußerungen des Bots und alle benutzerdefinierten Variablen, die Sie definieren.

Benutzerdefinierte Skript-Bedingungen werden immer als wiederverwendbare globale Agenten definiert — sie können nicht inline in einem Testfall geschrieben werden. Dies fördert die Wiederverwendbarkeit und hält komplexe Validierungslogik an einem Ort.

Verfügbarer Kontext in Skripten:

conversation_state.slots       # Alle Extraktionsfeldwerte
conversation_state.latest_message  # Die Benutzereingabe für diese Runde
bot_utterances                 # Liste der Bot-Antworten
events                         # Alle Ereignisse (Werkzeugaufrufe, Zustandsänderungen usw.)
variables                      # Benutzerdefinierte Variablen, die in der Bedingung definiert sind
llm_api                        # LLM-API, falls auf der Bedingung konfiguriert

Rückgabewerte:

return True                    # Bedingung bestanden
return False                   # Bedingung fehlgeschlagen
return True, "message"         # Bestanden, mit einer benutzerdefinierten Nachricht
return False, "reason"         # Fehlgeschlagen, mit einer Erklärung

Anwendungsfälle umfassen die Validierung der RAG-Retrieval (Überprüfung, welche Wissensstücke abgerufen wurden), die detaillierte Überprüfung von Werkzeugaufrufargumenten, die Durchsetzung von Geschäftsregeln, die mehrere Slots umfassen, oder den Aufruf eines externen Systems zum Vergleich.

Siehe Globale Agenten unten, um zu erfahren, wie Sie benutzerdefinierte Skript-Bedingungen erstellen und verwalten.

Globale Agenten​

Globale Agenten sind wiederverwendbare Testkomponenten, die einmal definiert werden und in mehreren Testfällen referenziert werden können. Es gibt zwei Typen, die für Bedingungen relevant sind: LLM-Richter und Benutzerdefinierte Skript-Bedingungen.

Der Hauptvorteil von globalen Agenten ist die Wartbarkeit: Wenn Sie einen LLM-Richter oder ein benutzerdefiniertes Skript aktualisieren, gilt die Änderung für jeden Testfall, der darauf verweist. Dies ist wichtig für gemeinsame Qualitätskriterien wie Markenstimme oder Empathie-Checks, bei denen Sie eine konsistente Bewertungslogik über alle Tests hinweg wünschen.

LLM-Richter​

Ein LLM-Richter definiert:

  • Bewertungsanweisungen — die Standardkriterien, die der Richter anwendet (können pro Test überschrieben werden)
  • LLM-Konfiguration — welcher Anbieter verwendet werden soll, Temperatur und wie viel Gesprächsverlauf einbezogen werden soll
  • Benutzerdefinierte Variablen — parametrisierte Werte, die in den Anweisungen mit Jinja2-Syntax referenziert und pro Test überschrieben werden können

LLM-Richter eignen sich gut für Qualitätskriterien, die in vielen Tests auftreten: Tonfall, Empathie, Hilfsbereitschaft, Markenkonformität.

Benutzerdefinierte Skript-Bedingungen​

Eine benutzerdefinierte Skript-Bedingung definiert:

  • Ein Python-Skript mit der Validierungslogik
  • Benutzerdefinierte Variablen — parametrisierte Werte, die im Skript über variables.get(...) zugänglich sind und pro Test überschrieben werden können
  • Optionale LLM-Konfiguration — falls das Skript ein LLM aufrufen muss

Die Verwendung von Variablen anstelle von fest codierten Werten macht benutzerdefinierte Skript-Bedingungen in verschiedenen Kontexten wiederverwendbar. Zum Beispiel kann eine Bedingung, die überprüft, welche RAG-Stücke abgerufen wurden, die erwarteten Stücknamen als Variable akzeptieren, sodass dasselbe Skript in vielen verschiedenen Testfällen funktioniert.

Beste Praktiken​

Verwenden Sie den richtigen Bedingungstyp für die Aufgabe. Slot-Bedingungen sind der zuverlässigste Weg, um extrahierte Daten zu validieren. Werkzeugaufruf-Bedingungen sind das richtige Werkzeug für Routing-Feststellungen. Reservieren Sie LLM-Richter und benutzerdefinierte Skript-Bedingungen für Logik, die anders nicht ausgedrückt werden kann — sie sind teurer und weniger deterministisch.

Schreiben Sie mehrere fokussierte Bedingungen pro Runde. Eine einzelne Bedingung, die versucht, alles zu überprüfen, ist schwer zu debuggen, wenn sie fehlschlägt. Trennen Sie die Anliegen: eine Bedingung für das Routing, eine für die Extraktion, eine für die Antwortqualität.

Halten Sie LLM-Richter-Anweisungen spezifisch. Vage Kriterien führen zu inkonsistenten Ergebnissen. Je konkreter und messbarer Ihr Kriterium ist, desto zuverlässiger wird der Richter sein.

Verwenden Sie Variablen in globalen Agenten, um sie wiederverwendbar zu halten. Vermeiden Sie es, Werte in Skripten oder Anweisungen fest zu codieren. Eine Bedingung, die Variablen verwendet, kann über Testfälle hinweg geteilt werden, die sich nur in den spezifischen Werten unterscheiden, die überprüft werden.