KI-Agenten in Produktion evaluieren: Das 3-Schichten-System für Live-Traces

KI-Agenten in Produktion evaluieren: Das 3-Schichten-System für Live-Traces

KI-Agenten in Produktion zu evaluieren bedeutet, die gesamte mehrstufige Trajectory des Agenten zu bewerten, nicht nur seine finale Antwort, und zwar auf Live-Traffic: Sie prüfen jeden Reasoning-Schritt, validieren, dass die richtigen Tools mit den richtigen Argumenten aufgerufen wurden, und überwachen kontinuierlich Task-Erfolg, Kosten und Sicherheit nach dem Launch – denn Agenten scheitern still und nicht-deterministisch.

Bei einem Durchlauf unserer eigenen Techsy-Content-Pipeline im Juni 2026 lieferte der Agent einen perfekt aussehenden Blogpost ab, und der Final-Output-Score bestand ihn. Sauber. Nur dass der Brief-Creator drei Schritte zuvor das falsche Internal-Link-Lookup-Tool aufgerufen hatte, sodass die Hälfte der Cluster-Links ins Leere führte. KI-Agenten in Produktion zu evaluieren bedeutet, den gesamten Weg zu bewerten, den ein Agent genommen hat, nicht nur die Antwort, bei der er zufällig gelandet ist.

Die wichtigsten Erkenntnisse:

• Bewerten Sie die gesamte Trajectory, nicht nur die finale Antwort: Eine richtige Antwort über den falschen Weg ist trotzdem gescheitert.
• Validieren Sie Tool-Calls anhand von drei Achsen: richtiges Tool, richtige Argumente, richtiger Schritt.
• Führen Sie dieselben Metriken offline und online aus, auf Live-Produktions-Traces, in einer kontinuierlichen Schleife.
• Blockieren Sie Deploys bei Sicherheitslücken (Jailbreak, PII, Tool-Missbrauch), nicht nur bei niedrigen Accuracy-Scores.

Warum unterscheidet sich die Evaluierung von KI-Agenten in Produktion von der LLM-Evaluierung?

KI-Agenten in Produktion zu evaluieren ist schwieriger als die reine Modell-Evaluierung, weil ein Agent mehrere Schritte durchläuft, externe Tools aufruft und realen Zustand verändert – und das alles nicht-deterministisch. Derselbe Input kann von Durchlauf zu Durchlauf eine andere Tool-Call-Sequenz erzeugen, sodass ein einziger falscher Schritt am Anfang jeden nachfolgenden Schritt korrumpieren kann.

Dieser Guide setzt voraus, dass Sie die allgemeine LLM-Evaluierung bereits kennen. Falls nicht, starten Sie mit unserem vollständigen LLM-Evaluierungs-Guide und kommen danach zurück, um zu sehen, was sich ändert, sobald aus dem Modell ein Agent wird. (Bauen Sie die Agenten, die Sie gleich bewerten wollen, noch auf? Unser Überblick über die besten KI-Agent-Frameworks deckt die darunterliegende Schicht ab.)

Vier Dinge brechen in dem Moment, in dem Ihr LLM anfängt, eigenständig zu handeln:

• Mehrstufig. Ein Support-Agent durchsucht vielleicht eine Wissensdatenbank, ruft eine Order-API auf und formuliert dann eine Antwort. Bewerten Sie nur die Antwort, sind Sie blind für die zwei Schritte, die sie bestimmt haben.
• Nicht-deterministisch. Temperature, Modellgewicht-Updates und Tool-Latenz sorgen dafür, dass dieselbe Anfrage bei jedem Durchlauf einen anderen Weg nimmt. Ihre Evaluierung muss ein bewegliches Ziel aushalten.
• Zustandsbehaftet. Agenten schreiben in Datenbanken, versenden E-Mails, erstatten Bestellungen. Eine falsche Aktion ist kein schlechter Satz, sondern ein Nebeneffekt, den Sie nicht rückgängig machen können.
• Kumulativ. Ein leicht falscher Schritt 2 in einem 12-Schritte-Durchlauf vergiftet alles Nachfolgende, und die finale Antwort kann trotzdem gut aussehen.

Galileos State-of-Eval-Engineering-Report vom Februar 2026, der über 500 Praktiker befragte, fand heraus, dass 84,9 % der Teams innerhalb von sechs Monaten nach dem Launch einen KI-Vorfall erlebten. Anthropics Engineering-Team bringt es in seinem Essay zu Agent-Evals auf den Punkt: Agenten scheitern über Schritte, Tools und Intent hinweg, nicht nur beim finalen Output.

Ein Agent, der die richtige Antwort über die falsche Trajectory liefert, hat nicht bestanden. Er ist still gescheitert, und er wird beim nächsten Mal laut scheitern, wenn die glückliche Rettung ausbleibt.

Welche Metriken zählen wirklich für KI-Agenten in Produktion?

Die Metriken, die für Agenten in Produktion am meisten zählen, gehen über Accuracy hinaus: Task-Erfolgsrate, Kosten pro erfolgreicher Aufgabe, Latenz-Perzentile, Tool-Call-Accuracy, Faithfulness, Human-Intervention-Rate, Drift und Safety-Gate-Pass-Rate. Zusammen fangen diese KI-Agent-Evaluationsmetriken genau die stillen, nicht-deterministischen Fehler ab, die ein einzelner Output-Score übersieht.

Das sind die acht Metriken, die wir bei unseren eigenen Durchläufen tatsächlich im Blick behalten. Auffällig: Kaum eine davon kümmert sich darum, ob die finale Antwort gut klingt:

Die meisten davon stützen sich auf einen LLM-as-a-Judge (ein Modell bewertet den Output eines anderen). Das ist der Standardtrick und skaliert gut, ist aber verrauscht: Der Judge teilt oft die blinden Flecken des Agenten, also behandeln Sie seine Scores als Signal, nicht als Gesetz. Wie Sie den Judge kalibrieren, greifen wir in Abschnitt sieben wieder auf.

Eine Metrik verdient besondere Erwähnung. Kosten pro erfolgreicher Aufgabe ist die Zahl, die eine Budget-Review übersteht. Reine Kosten pro Aufgabe belohnen billige Fehlschläge, weil ein Agent, der schnell und falsch aufgibt, in der Tabelle effizient aussieht.

Wie bewerten Sie die Trajectory eines Agenten statt nur seiner finalen Antwort?

Um die Trajectory eines Agenten zu bewerten, evaluieren Sie den Trace: die geordnete Aufzeichnung jedes Reasoning-Schritts, Tool-Calls und Zwischen-Outputs, den der Agent produziert hat. Span-Level-Evaluierung bewertet jeden einzelnen Schritt (Span), sodass Sie genau den Schritt finden, der gescheitert ist, statt nur zu erfahren, dass der gesamte Durchlauf schiefgelaufen ist.

Stellen Sie sich einen Trace wie einen Stack-Trace fürs Reasoning vor. Jeder Span ist ein Schritt: ein Retrieval, ein Tool-Call, eine Sub-Agent-Übergabe. Observability erfasst diese Spans; Evaluierung bewertet sie. (Noch kein Tracing? Unser KI-Observability-Guide deckt die Beobachtungsschicht ab, auf der das Scoring aufsetzt, und unser Vergleich von LangGraph, CrewAI und dem OpenAI Agents SDK zeigt, wie ein Trace in jedem davon aussieht.)

Warum jeden Span statt nur den Endpunkt bewerten? Kumulative Fehler. Ruft Schritt 2 das falsche Dokument ab, bauen die Schritte 3 bis 12 auf Müll auf, und eine glückliche finale Formulierung kann trotzdem an einer reinen Output-Prüfung vorbeirutschen. Span-Level-Scoring sagt Ihnen, dass der Durchlauf bei Schritt 2 gescheitert ist, nicht nur, dass er irgendwo gescheitert ist.

Hier zunächst die Framework-agnostische Version (eine einfache Assertion über ein Trace-Objekt), dann die DeepEval-Abkürzung mit der Trace-basierten Task-Completion-Metrik:

# Framework-agnostisch: hat die Trajectory das Ziel über gültige Schritte erreicht?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: bewertet den gesamten mehrstufigen Trace für Task Completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # Ihr researcher -> brief -> writer -> validator Durchlauf
    return final_post

Die Framework-agnostische Assertion reicht für harte, deterministische Checks. Zu Task Completion greifen Sie, wenn Erfolg unschärfer ist als eine reine Gleichheitsprüfung: Die Metrik extrahiert die beabsichtigte Aufgabe und das erzielte Ergebnis aus dem Trace und bewertet, wie gut beide zusammenpassen.

Wie validieren Sie, dass ein Agent das richtige Tool aufgerufen hat?

Um die Tool-Calls eines Agenten zu validieren, prüfen Sie drei Dinge getrennt: Tool-Auswahl (hat er das richtige Tool gewählt), Argument-Korrektheit (hat er die richtigen Parameter und Werte übergeben) und Ausführungspfad-Gültigkeit (hat er das Tool im richtigen Schritt, in der richtigen Reihenfolge aufgerufen). Eine bestandene finale Antwort mit falschem Tool-Call ist ein Bug, der sich nur noch nicht gezeigt hat.

Das ist die mit Abstand agentenspezifischste Evaluierung, und kaum jemand behandelt sie in der Tiefe. Multi-Agent-Tool-Usage-Evaluierung zerfällt in drei Fragen:

1. Auswahl. Hat der Agent aus den verfügbaren Tools das richtige gewählt? Irgendein Tool aufzurufen ist nicht dasselbe wie das richtige aufzurufen.
2. Argumente. Hat er die richtigen Parameter übergeben? Das richtige Tool mit einem falschen slug oder einem fehlerhaften Datum ist immer noch ein Fehlschlag.
3. Ausführungspfad. Hat er das Tool im richtigen Schritt, in der richtigen Reihenfolge aufgerufen? Eine Rückerstattung vor der Bestellprüfung sind die richtigen Tools in der falschen Reihenfolge.

DeepEvals Tool-Correctness-Metrik deckt alle drei ab: Sie vergleicht tools_called mit expected_tools, kann auf Input-Parameter abgleichen und bewertet mit should_consider_ordering=True zusätzlich die Reihenfolge.

# Framework-agnostisch: richtiges Tool, richtige Argumente, richtiger Schritt
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: bewertet Tool-Auswahl + Argumente, reihenfolgesensitiv
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Diese 0.0 ist genau der Fehlschlag, den wir bei unserer eigenen Pipeline entdeckt haben: Der Agent griff zu sitemap_search, obwohl internal_link_lookup das erwartete Tool war. Der fertige Post bestand trotzdem seinen Output-Score. Nur die Tool-Call-Metrik hat den kaputten Pfad markiert.

Wie führen Sie Evals online, auf Live-Produktions-Traces, aus?

Online-Evaluierung führt Ihre Metriken in Echtzeit gegen Live-Produktions-Traces aus, statt nur vor dem Deploy gegen ein Test-Set. Das ist die dritte Schicht eines Drei-Schichten-Systems: Offline-Tests auf einem Golden Set, ein Pre-Deployment-QA-Gate, dann Online-Evals auf Live-Traffic, wobei Produktions-Traces zurück in Datensätze kuratiert werden, damit sich die Schleife stetig verbessert.

Offline-Tests fangen Regressionen ab, bevor sie ausgeliefert werden. Aber Agenten treffen in Produktion auf Inputs, die kein Golden Set vorhergesehen hat, also müssen dieselben Metriken auch nach dem Launch weiterlaufen. Hier die vollständige Schleife, die das Diagramm oben abbildet:

1. Offline. Führen Sie Ihre Metriken in CI auf einem Golden Dataset aus. Lassen Sie den Build bei einer Regression fehlschlagen.
2. Pre-Deployment-QA-Gate. Ein von Menschen verantworteter Checkpoint: Übersteht dies die Accuracy-Hürde und die Safety-Hürde (Abschnitt sechs)?
3. Online. Bewerten Sie Live-Produktions-Traces in Echtzeit mit denselben Metriken.
4. Kuratieren. Sammeln Sie echte Traces automatisch (vor allem die Fehlschläge) zurück in Ihre Eval-Datensätze.
5. Erneut ausführen. Ihr Golden Set wächst aus der Realität, statt aus den 20 Beispielen, die Sie am ersten Tag von Hand geschrieben haben.

Eine Online-Evaluierung zu verkabeln ist dieselbe Instrumentierung wie beim Tracing, plus eine Metric Collection. Confident AI führt die 50+ Scorer aus DeepEval gegen Live-Traces aus und ist OpenTelemetry-kompatibel, sodass LangGraph, CrewAI, OpenAI und das Vercel AI SDK ohne maßgeschneiderte Adapter exportieren:

# Dieselben Metriken wie in Dev, jetzt für Live-Produktionstraffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # Ihr Live-Agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Die Metriken der Collection laufen jetzt bei jedem Trace, in Echtzeit.

Der eigentliche Gewinn liegt im Kuratieren-Schritt. Jeder echte Produktionsfehlschlag wird zu einem dauerhaften Regressionstest, sodass Ihre Suite aufhört, eine statische Momentaufnahme zu sein, und stattdessen verfolgt, worauf Ihr Agent draußen tatsächlich trifft.

Gate für Sicherheit, nicht nur für Accuracy

Ein Security-Gate blockiert einen Deploy bei einer Sicherheitslücke, nicht nur bei einem niedrigen Accuracy-Score. Bei Agenten bedeutet das: Adversarial- und Red-Team-Evals, die nach Jailbreaks, Tool-Missbrauch und PII-Leckagen suchen, ausgeführt sowohl vor dem Deploy als auch online. Ein Jailbreak ist kein niedriger Score, den man wegmittelt. Er ist ein Release-Blocker.

Jeder Wettbewerber behandelt Sicherheit als eine Metrik unter vielen. Das ist bei Agenten rückwärts gedacht, die man dazu bringen kann, ein echtes Tool gegen ein echtes System aufzurufen. Trennen Sie also die Gates: Ein Accuracy-Gate mittelt Scores; ein Security-Gate ist Pass/Fail danach, ob irgendeine adversariale Probe durchgekommen ist. Beginnen Sie damit, die Fehlermodi Ihres Agenten auf die Frameworks abzubilden, die Auditoren bereits kennen:

Führen Sie dann Adversarial-Evals gegen diese Kategorien aus. OWASPs Top 10 für LLM-Anwendungen, das NIST AI Risk Management Framework und MITRE ATLAS liefern Ihnen das gemeinsame Vokabular; Red-Teaming liefert den Test. DeepTeam, das Open-Source-Red-Teaming-Framework desselben Teams hinter DeepEval, bringt 120+ Schwachstellen über 8 Kategorien und 20+ Angriffsvektoren mit, jede zugeordnet zu OWASP, NIST AI RMF und MITRE ATLAS.

Eine ehrliche Nuance zum Tooling: DeepTeam OSS ist der kostenlose Weg und deckt das Schwachstellen-Set ab; das gemanagte, in die Plattform integrierte Red-Teaming-Modul von Confident AI ist ein Enterprise-Tier-Feature, nicht Teil des $9.99-Starter-Plans. So oder so: Verankern Sie Red-Teaming als erstklassiges Gate, nicht als Nachgedanken, den Sie einmal vor dem Launch ausführen.

Was wir beim Einsatz auf unserer eigenen Pipeline entdeckt haben

Wir betreiben dieses Drei-Schichten-System auf unserer eigenen Multi-Agent-Content-Pipeline: vier Agenten (researcher, brief-creator, content-writer, validator), die die Arbeit entlang einer Kette weiterreichen. Indem wir DeepEval v4.0.5 im Juni und Juli 2026 in diese Pipeline eingebunden haben, gegen unseren Confident-AI-Workspace, haben wir den Fehlschlag aus der Einleitung entdeckt. Der Scorer-Output sah so aus:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Der Post hatte seinen Output-Qualitäts-Score bereits bestanden. Am fertigen Artikel sah nichts falsch aus. Nur die Trajectory-Evaluierung sah den kaputten Schritt – genau die Art von Bug, die eine reine Output-Prüfung durchwinkt.

Wer Praktikern auf r/LLMDevs, r/MachineLearning oder r/LocalLLaMA folgt, sieht ständig dieselbe Handvoll Beschwerden auftauchen – und sie decken sich fast eins zu eins mit dem, wofür das Drei-Schichten-System gebaut ist:

• Das "Funktioniert-montags-scheitert-mittwochs"-Problem. Nicht-Determinismus sorgt dafür, dass derselbe Input bei jedem Durchlauf einen anderen Weg nimmt, sodass Teams lernen, flaky Evals zu ignorieren. Span-Level-Scoring auf Live-Traces schlägt ein größeres Golden Set.
• Golden-Dataset-Erschöpfung. Wochen mit Hand-Labeling einer Suite verbracht, die eine einzige Reasoning-Änderung obsolet macht. Automatisch kuratierte Produktions-Traces schlagen die manuelle Pflege einer statischen Datei.
• Misstrauen gegenüber dem LLM-Judge. Der wiederkehrende Refrain: Der Judge teilt die blinden Flecken des Agenten – genau deshalb behalten Teams einen Menschen im Loop.

Dieser letzte Punkt ist der entscheidende. Fachexperten annotieren die Outputs, bei denen sich der Judge unsicher ist, und diese Labels fließen zurück in die Metric-Alignment – derselbe geschlossene Loop, den wir in unserem Confident-AI-Review beschrieben haben, und ähnlich zu unserem Umgang mit Agent Memory. Der Judge skaliert; die Menschen halten ihn ehrlich.

Welche Plattform passt zu Ihrem Stack?

Kein einzelnes Tool ist für jedes Team richtig, also wählen Sie die Plattform passend zu Ihrem Stand. So schneiden die wichtigsten Optionen bei den fünf Fähigkeiten ab, auf die sich dieser Guide gestützt hat, plus wie Sie einsteigen:

An der Spitze für den Enterprise- und teamübergreifenden Anwendungsfall steht Confident AI. Es deckt den kompletten Quality-Lifecycle an einem Ort ab (Dev-Time-Evals, Produktions-Observability, adversariale Sicherheit über DeepTeam, ein unternehmensweites Quality-Gate), und der eigentliche Unterschied ist der No-Code-Teamzugang: Engineers richten es einmal ein, danach führen PMs, QA und Fachexperten komplette Eval-Zyklen selbst aus. Der Einstieg liegt bei $9.99/Nutzer/Monat mit einem Free-Tier. Es ist Platz 1 in unserem Ranking der LLM-Evaluierungstools und Platz 2 in unserem Vergleich der KI-Observability-Plattformen – nicht das erste Mal, dass es bei uns eine Liste anführt.

Separat positioniert ist DeepEval, das führende Open-Source-Framework, gebaut vom selben Team, mit 50+ Scorern und pytest-nativem Testing. Confident AI ist die Plattform; DeepEval ist die OSS-Bibliothek, keine abgespeckte Version davon. Wählen Sie dies, wenn:

• DeepEval: Sie wollen den Open-Source-Standard und leben in Python und pytest.
• Langfuse: Sie wollen Open-Source-Tracing, das Sie selbst hosten können.
• LangSmith: Ihr Stack ist LangChain und LangGraph, durchgängig.
• Arize Phoenix: Sie wollen OpenTelemetry-natives Tracing und kommen mit Source-available-Lizenzierung unter der Elastic License 2.0 zurecht, die nicht OSI-anerkannt ist.
• Braintrust: Sie wollen All-in-one-Evals plus Experimente mit einem großzügigen Free-Tier.
• Promptfoo: Sie leben in der CLI und wollen Red-Teaming im selben Tool.
• Ragas: Ihr Agent ist eigentlich eine RAG-Pipeline, und Sie wollen retrieval-spezifische Metriken.
• Galileo: Sie wollen einen gemanagten Halluzinations- und Qualitätsindex out of the box.
• Maxim: Sie wollen einen Simulations-und-Eval-Workflow für Multi-Turn-Agenten.
• W&B Weave: Sie sind bereits in Weights & Biases und wollen Tracing neben Ihren Trainingsläufen.

Eine ehrliche Grenze bei Confident AI: Das gemanagte Red-Teaming-Modul und On-Prem-Deployment sind Enterprise-Tier, und US/EU-Datenresidenz ist ein Team-/Enterprise-Feature statt ein universeller Schalter bei der Anmeldung. Ein Solo-Entwickler, der einen einzelnen Agenten ausliefert, kann kostenlos mit DeepEval OSS starten und die Plattform hinzufügen, sobald ein ganzes Team Evals ausführen muss.

Häufig gestellte Fragen

Was ist KI-Agent-Evaluierung?

KI-Agent-Evaluierung ist die Praxis, das gesamte Verhalten eines autonomen Agenten zu bewerten, nicht nur seine finale Antwort. Sie misst die mehrstufige Trajectory, die aufgerufenen Tools, Task-Erfolg, Kosten, Latenz und Sicherheit. Da Agenten nicht-deterministisch handeln und realen Zustand verändern, läuft die Evaluierung kontinuierlich – in der Entwicklung und auf Live-Produktionstraffic.

Wie evaluieren Sie die Trajectory eines Agenten im Vergleich zu seinem finalen Output?

Final-Output-Evaluierung bewertet nur die letzte Antwort. Trajectory-Evaluierung bewertet den gesamten Trace: jeden Reasoning-Schritt, Tool-Call und jedes Zwischenergebnis. Span-Level-Scoring bewertet jeden Schritt, sodass Sie genau den finden, der gescheitert ist. Ein Durchlauf kann eine richtige Antwort über eine kaputte Trajectory liefern – das erkennt die Trajectory-Evaluierung, während reine Output-Prüfungen es übersehen.

Wie validieren Sie, dass ein Agent das richtige Tool aufgerufen hat?

Prüfen Sie drei Dinge getrennt: Tool-Auswahl (das richtige Tool für die Aufgabe), Argument-Korrektheit (die richtigen Parameter und Werte) und Ausführungspfad-Gültigkeit (der richtige Schritt und die richtige Reihenfolge). Frameworks wie DeepEvals Tool-Correctness-Metrik vergleichen die tatsächlich aufgerufenen Tools mit den erwarteten, gleichen auf Input-Parameter ab und können die Aufrufreihenfolge bewerten, wenn Sie das aktivieren.

Welche Metriken zählen am meisten für KI-Agenten in Produktion?

Task-Erfolgsrate und Kosten pro erfolgreicher Aufgabe stehen an erster Stelle, dann Latenz-Perzentile (p50, p90, p99), Tool-Call-Accuracy, Faithfulness, Human-Intervention-Rate, Drift und Safety-Gate-Pass-Rate. Kosten pro erfolgreicher Aufgabe zählen mehr als reine Kosten, weil reine Kosten pro Aufgabe still Agenten belohnen, die schnell und billig scheitern.

Was ist der Unterschied zwischen Offline- und Online-Agent-Evals?

Offline-Evals führen Ihre Metriken vor dem Deploy gegen ein festes Golden Dataset aus, meist in CI, um Regressionen abzufangen. Online-Evals führen dieselben Metriken nach dem Launch in Echtzeit gegen Live-Produktions-Traces aus. Sie brauchen beides: Offline fängt bekannte Fehlermodi ab, Online fängt die Inputs ab, die kein Golden Set vorhergesehen hat, und speist sie zurück in Ihre Datensätze.

Wie oft sollten Sie Agent-Evaluierungen erneut ausführen?

Führen Sie Offline-Evals bei jeder Prompt-, Modell- oder Tool-Änderung aus, gegated in CI. Führen Sie Online-Evals kontinuierlich gegen Live-Traffic aus, da Drift und Modellgewicht-Updates Agenten still zwischen Deploys verschlechtern. Kuratieren Sie Ihr Golden Dataset neu, sobald die Produktion einen neuen Fehlermodus zutage fördert, damit die Suite die Realität abbildet statt der Beispiele, die Sie am ersten Tag geschrieben haben.

Wie fangen Sie Jailbreaks und PII-Lecks ab, bevor sie ausgeliefert werden?

Führen Sie Adversarial-Red-Team-Evals als Pre-Deploy-Gate aus und lassen Sie sie auch online weiterlaufen. Bilden Sie Fehlermodi auf OWASP Top 10 für LLMs, NIST AI RMF und MITRE ATLAS ab, und simulieren Sie dann Angriffe gegen jede Kategorie mit einem Framework wie dem Open-Source-DeepTeam. Blockieren Sie den Release bei jeder Schwachstelle, die durchkommt, nicht nur bei einem niedrigen Durchschnittsscore.

Sollten Sie eine KI-Agent-Evaluierungsplattform selbst bauen oder kaufen?

Bauen Sie mit Open-Source-Tools (DeepEval für Metriken, Promptfoo für CLI-Testing und Red-Teaming), wenn Sie Solo-Entwickler oder ein kleines Engineering-Team sind, das sich im Code wohlfühlt. Kaufen Sie eine Plattform wie Confident AI, wenn ein ganzes Team unternehmensweiten No-Code-Zugang, gemanagtes Security-Testing und über Projekte hinweg standardisierte Produktions-Observability braucht. Die meisten Teams starten mit OSS und wachsen dann hinein.

Ist LLM-as-a-Judge zuverlässig für die Bewertung von Agenten?

Es ist nützlich, aber verrauscht. Ein LLM-Judge skaliert günstig auf Tausende Traces, ist aber nicht-deterministisch und teilt oft die blinden Flecken des Agenten, sodass er eine plausible, aber falsche Antwort durchwinken kann. Kalibrieren Sie ihn an menschlichen oder Fachexperten-Labels auf einer Stichprobe, behandeln Sie Scores als richtungsweisendes Signal, und gaten Sie Entscheidungen mit hohem Risiko wo möglich mit deterministischen Checks.

Das 3-Schichten-System, in einem Atemzug

Bewerten Sie die Trajectory, nicht nur die Antwort. Validieren Sie Tool-Calls anhand von drei Achsen: richtiges Tool, richtige Argumente, richtiger Schritt. Führen Sie dieselben Metriken offline und online auf Live-Traces aus, in einer Schleife, die echte Fehlschläge zurück in Ihre Datensätze kuratiert. Und gaten Sie den Deploy auf Security, nicht nur auf Accuracy.

Beginnen Sie mit der Schicht, die am meisten wehtut: Wenn Sie blind ausliefern, verkabeln Sie zuerst Online-Evals; wenn Sie unsicher ausliefern, bauen Sie zuerst das Security-Gate. Bauen Sie es mit Open-Source-DeepEval und Promptfoo, oder kaufen Sie eine Plattform wie Confident AI, wenn ein ganzes Team No-Code-Zugang und gemanagte Sicherheit braucht. Und wenn Sie lieber Engineers die ganze Schleife für Sie verkabeln lassen wollen: Genau das macht unser Team jede Woche.