Die besten Tools für die Evaluation von AI Agents: Phoenix, LangSmith, DeepEval

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Kein Tool für die Evaluation von Agents kann ein gutes Testdesign ersetzen. Beginnen Sie mit den Fehlern, die das Produkt erkennen muss: falsche Antworten, ungeeignete Tool-Auswahl, ungültige Argumente oder unsichere Seiteneffekte. Prüfen Sie außerdem unnötige Schritte sowie Regressionen bei Latency und Kosten. Wählen Sie anschließend das Tool danach aus, wo diese Tests ausgeführt werden müssen.

Verwenden Sie Phoenix, wenn OpenTelemetry-Tracing und Self-Hosting wichtig sind. Verwenden Sie LangSmith, wenn Datasets, Traces, Annotation und Experimente einen gemeinsamen Managed Workflow bilden sollen. Verwenden Sie DeepEval, wenn die Evaluation wie Tests in einer Python-CI-Pipeline aussehen soll. Ergänzen Sie Promptfoo für eine lokale CLI, Matrix-Tests und Red-Team-Fälle.

Zuletzt geprüft: 08.09.2026. Der Vergleich gewichtet Trace-Tiefe, die Evaluation von Trajectories und finalen Antworten, Dataset-Workflows, CI-Ergonomie, Self-Hosting und Provider-Portabilität.

Entscheidungstabelle

BedarfBester AusgangspunktWarum
OpenTelemetry-Traces und Self-HostingPhoenixOpen-Source-Tracing, Evaluations, Datasets und Experimente verwenden OpenTelemetry- und OpenInference-Konventionen.
Managed Traces, Datasets und ReviewLangSmithEs evaluiert Trajectories und finale Antworten und kann mit Agents außerhalb von LangChain arbeiten.
Python-Tests und CI GatesDeepEvalEnd-to-End- und komponentenbasierte Agent-Evaluation passen zu einem testorientierten Workflow.
Lokale Matrix-Tests und Red TeamingPromptfooDie Open-Source-CLI und -Library führen wiederholbare Evaluations und Security-Fälle in der CI aus.
Produktspezifische Policy- oder Tool-ChecksBenutzerdefinierte EvaluatorsGenerische Judges kennen Ihre Berechtigungen, irreversiblen Aktionen, Budgets oder Business-Invarianten nicht.

Schritte und Ergebnis evaluieren

Eine Trajectory ist die Folge von Model-Entscheidungen und Tool Calls in einem Run. Eine korrekte finale Antwort kann Fehler in diesen Schritten verbergen. Ein Agent kann das falsche Tool aufrufen, unnötige Retries durchführen, vertrauliche Argumente offenlegen oder ohne Belege zu einer plausiblen Antwort gelangen. Umgekehrt sollte eine andere, aber gültige Tool-Sequenz nicht allein deshalb fehlschlagen, weil sie von einem Golden Trace abweicht.

Führen Sie separate Checks durch für:

  • Korrektheit der finalen Antwort und Belegunterstützung
  • Tool-Auswahl und Gültigkeit der Argumente
  • erforderliche, verbotene oder wiederholte Aktionen
  • Policy-Entscheidungen und Freigabegrenzen
  • Effizienz der Trajectory, Latency und Kosten
  • Recovery nach Tool-Fehlern oder Teilergebnissen

Verwenden Sie nach Möglichkeit deterministische Assertions. Setzen Sie Model Judges für semantische Fragen ein, kalibrieren Sie sie anhand geprüfter Beispiele und speichern Sie Model und Prompt des Judges mit jedem Ergebnis.

Ein praktischer erster Stack

  1. Erfassen Sie im Anwendungscode, der Model und Tools ausführt, eine Request-ID, das ausgewählte Tool, redigierte Argumente, das Ergebnis und die Dauer.
  2. Machen Sie Fehler aus der Produktion zu einem kleinen Regression-Dataset.
  3. Ergänzen Sie deterministische Checks für Schemas, verbotene Aktionen, Budgets und erforderliche Belege.
  4. Ergänzen Sie einen kalibrierten semantischen Judge für Ergebnisse, die sich nicht durch Regeln bewerten lassen.
  5. Führen Sie schnelle Fälle bei jeder Änderung und eine umfassendere Suite vor dem Release aus.
  6. Sampeln Sie Production-Traces auf neue Fehlermuster und überführen Sie diese in Tests.

Weiterführende Lektüre

Referenzen