Entwickelt für die Überprüfung durch Unternehmenseinkauf — jedes Ergebnis ist nachverfolgbar, reproduzierbar und dauerhaft gespeichert.
Funktionsweise
Jede Evaluierungslauf führt eine dreistufige Pipeline für jeden Testfall aus:Agent-Ausführung
Ein echter ReActAgent führt die Testfall-Eingabeaufforderung aus. Gleiche Engine wie Chat: gleiches Modell, gleiche Tools, gleiche Anweisungen. Kein Mocking, keine Abkürzungen.Erzeugt: Antwort, Latenz, Token-Nutzung.
LLM-Bewertung
Ein separates “Bewerter”-LLM (schnelles Modell) bewertet die Antwort gegen das erwartete Verhalten und Assertions.Eingabe: Eingabeaufforderung + erwartetes Verhalten + Assertions + Antwort. Ausgabe:
{ verdict: "pass"|"fail", reasoning: "..." }.Wichtige Designentscheidungen
| Entscheidung | Grund |
|---|---|
| Real ReActAgent (kein Mock) | Testet das tatsächliche Verhalten des Agenten, einschließlich Tool-Aufrufe und mehrstufiges Reasoning |
| Separates Grader-LLM (schnelles Modell) | Kostengünstig und schnell; das Agent-LLM hat bereits Token während der Ausführung verbraucht |
asyncio.Semaphore(5) | Begrenzt die Parallelität auf 5, um zu vermeiden, dass der LLM-Anbieter mit Rate-Limit-Fehlern überlastet wird |
| Jeder Fall ist unabhängig | Keine Gesprächshistorie zwischen Fällen; jeder erhält eine neue Agent-Instanz |
| Ausführung im Hintergrund | Die Ausführung wird als asynchrone Aufgabe gestartet — die API gibt sofort zurück, das Frontend fragt alle 3 Sekunden ab |
Arbeitsablauf
1. Datensatz erstellen
Navigieren Sie zu Eval Center → Datasets und klicken Sie auf New Dataset. Ein Datensatz ist eine benannte Sammlung von Testfällen. Geben Sie ihm einen aussagekräftigen Namen (z. B. „Customer Support — Tier 1 Questions”) und eine optionale Beschreibung.2. Testfälle hinzufügen
Klicken Sie in Ihren Datensatz und fügen Sie Testfälle hinzu. Jeder Fall hat drei Felder:| Feld | Erforderlich | Beschreibung |
|---|---|---|
| Prompt | Ja | Die genaue Frage oder Anweisung, die an den Agenten gesendet wird |
| Erwartetes Verhalten | Ja | Eine natürlichsprachige Beschreibung, wie eine korrekte Antwort aussieht |
| Assertions | Nein | Eine Liste spezifischer Überprüfungen (z. B. „Antwort erwähnt die Rückgabepolitik”, „Antwort ist unter 200 Wörtern”) |
3. Starten Sie eine Bewertung
Gehen Sie zur Registerkarte Eval Runs und klicken Sie auf New Evaluation. Wählen Sie:- Agent — einen beliebigen Agent, den Sie besitzen
- Dataset — einen beliebigen Datensatz mit mindestens einem Testfall
4. Ergebnisse lesen
Die Ergebnisseite zeigt:- Header: Name des Agenten, Name des Datensatzes, Statusabzeichen, Erfolgsquote, durchschnittliche Latenz, Gesamttoken
- Fortschrittsbalken: Füllt sich auf, wenn Fälle abgeschlossen werden (grün = Erfolgsanteil)
- Ergebnistabelle: Eine Zeile pro Testfall mit:
- Eingabeaufforderung (gekürzt — zum Erweitern anklicken)
- Urteil: Bestanden (grün), Fehlgeschlagen (rot) oder Fehler (orange)
- Antwort des Agenten (gekürzt — zum Erweitern anklicken)
- Begründung des Bewerters (warum es bestanden oder fehlgeschlagen ist)
- Latenz (ms) und Token-Anzahl
Was wird getestet
Enthalten
- Integrierte Werkzeuge: calculator, web_search, web_fetch, python_exec, file_ops, etc.
- Agent-Anweisungen: Das Feld
extra_instructionsdes Agenten wird weitergeleitet - Konfiguriertes Modell des Agenten: Wenn der Agent eine benutzerdefinierte Modellkonfiguration hat, wird dieses Modell verwendet
Nicht enthalten (absichtlich)
- Konnektoren: Externe HTTP-Konnektoren erfordern Live-Services von Drittanbietern — werden in der Evaluierung übersprungen, um instabile Tests zu vermeiden
- MCP-Server: Aus demselben Grund — externe Prozessabhängigkeiten
- Gesprächsverlauf: Jeder Fall läuft isoliert ohne vorherigen Kontext
- Wissensdatenbanken: KB-Abruefwerkzeuge werden im Evaluierungsmodus nicht geladen
Dies bedeutet, dass Evaluierungsergebnisse die Reasoning- und Werkzeugnutzungsfähigkeit des Agenten widerspiegeln, nicht seine Integration mit externen Services. Testen Sie Konnektoren separat über die Connector-Test-Funktion.
Der Grader
Der Grader ist ein LLM (das „schnelle” Modell des Systems), das vier Informationen erhält und ein strukturiertes JSON-Urteil zurückgibt: Systemaufforderung:You are an impartial AI evaluator. Your job is to judge whether an AI agent’s answer meets the expected behavior for a given prompt. Be strict but fair. A “pass” requires the answer to genuinely address the prompt according to the expected behavior. A “fail” means the answer is wrong, incomplete, off-topic, or misses key requirements.Benutzernachricht enthält:
- Die ursprüngliche Aufforderung
- Das erwartete Verhalten
- Die Liste der Assertions (oder „None specified”)
- Die tatsächliche Antwort des Agenten
structured_llm_call mit Function Calling, um das Schema durchzusetzen. Wenn der Grader selbst fehlschlägt (Netzwerkfehler, fehlerhafte Antwort), wird der Fall als error gekennzeichnet.
Best Practices
Datensatz-Design
- Klein anfangen: 5–10 Fälle, die die Kernfunktionen des Agenten abdecken
- Edge Cases berücksichtigen: Mindestens 2–3 adversarische oder außerhalb des Geltungsbereichs liegende Prompts einbeziehen
- Spezifisch bei erwartetem Verhalten: Vage Erwartungen führen zu inkonsistenter Bewertung
- Assertions für harte Anforderungen verwenden: „Muss den Preis erwähnen” ist zuverlässiger als zu hoffen, dass der Bewerter es erfasst
Ergebnisse interpretieren
- 80%+ Erfolgsquote ist ein guter Richtwert für einen gut konfigurierten Agenten
- Niedrige Erfolgsquote mit hoher Latenz deutet darauf hin, dass der Agent Schwierigkeiten mit mehrstufigem Reasoning hat
- Fehlerstatus bedeutet, dass der Agent oder die Bewertung abgestürzt ist — überprüfen Sie die Server-Logs auf Details
- Bewertungsabweichungen: Wenn Sie denken, dass die Bewertung falsch ist, lesen Sie deren Begründung. Möglicherweise müssen Sie Ihre Beschreibung des erwarteten Verhaltens verfeinern
Wann neu bewerten
- Nach Änderung der Agent-Anweisungen
- Nach Wechsel des LLM-Modells des Agenten
- Nach Hinzufügen oder Entfernen von Tool-Kategorien
- Vor jeder Produktionsbereitstellung (CI/CD-Integration kommt in einer zukünftigen Version)