Offline-Evaluation vs. Online-Überwachung für KI-Agents

Definition der Offline-Evaluation

Traektorienzusammensetzung

Eine Traektorie ist eine geordnete Liste von Schritten, die der Agent ausführen soll, wenn er eine bestimmte Eingabe erhält. Jeder Schritt enthält:

- die Benutzereingabe oder Systemereignis, das den Agenten auslöst - die Gedanken oder Überlegungen, die der Agent produzieren soll (wenn Sie die Chain-of-Thought protokollieren) - den Tool-Aufruf oder API-Anfrage, den der Agent ausführen soll - die erwartete Tool-Antwort oder Umgebungsfeedback - die endgültige Agenten-Ausgabe, die dem Benutzer oder dem nachgelagerten System angezeigt werden soll

Wenn Sie Traektorien sammeln, beginnen Sie normalerweise mit einem kleinen Satz von repräsentativen Benutzerstories und erweitern sie dann um Randfälle, die Sie in Protokollen gesehen haben oder die Sie aus Anforderungsdokumenten ableiten können.

Bewertungsrubrik

Die Offline-Evaluation vergleicht die tatsächliche Traektorie des Agenten mit der goldenen Traektorie mithilfe einer Rubrik, die mehrere unabhängige Dimensionen enthalten kann:

- Exakte Übereinstimmung – produziert der Agent die gleiche Sequenz von Tool-Aufrufen und -Antworten? - Semantische Ähnlichkeit – sind die Eingaben oder Ausgaben sinnvoll äquivalent, auch wenn die Formulierung unterschiedlich ist? - Treue – bleibt die Argumentation des Agenten in den bereitgestellten Tool-Ausgaben verwurzelt? - Aufgabenerfolg – erfüllt die endgültige Ausgabe die Erfolgskriterien, die für die Story definiert sind?

Jede Dimension erhält eine Punktzahl zwischen 0 und 1. Die Gesamtpunktzahl der Offline-Evaluation ist oft ein gewichteter Durchschnitt, aber Sie können auch jede Dimension als separate Schwelle behandeln.

Ausführen der Offline-Evaluation in CI

Da der Satz von Traektorien statisch ist und die Rubrik deterministisch ist, können Sie die Evaluation als Schritt in Ihrer Continuous-Integration-Pipeline ausführen. Der Schritt überprüft normalerweise:

- überprüft den Agenten-Code und die Traektorien-Fixtures - installiert alle erforderlichen Abhängigkeiten - führt den Agenten auf jeder Traektorie aus und erfasst die tatsächliche Spur - wendet die Rubrik an und schreibt einen JSON-Bericht - schlägt den Build fehl, wenn eine Punktzahl unter einem vordefinierten Schwellenwert fällt

Dies gibt Ihnen schnelles Feedback zu Regressionsfehlern, die Sie reproduzieren können.

Definition der Online-Überwachung

Was Sie in der Produktion beobachten

Die Online-Überwachung vergleicht nicht mit einem vorher geschriebenen Skript. Stattdessen überwacht sie Live-Signale vom laufenden Agenten und sucht nach Abweichungen von etablierten Baselines. Typische Signale umfassen:

- Verteilung der Länge oder Tokenanzahl der Benutzereingaben - Häufigkeit jedes Tool-Aufrufs - Fehlerquoten, die von externen APIs zurückgegeben werden - Latenz jedes Schritts in der Agenten-Schleife - Rate von Fallback- oder Wiederholungsverhalten - semantische Drift in der endgültigen Ausgabe (gemessen mit der Embedding-Distanz zu einem aktuellen Referenzset)

Da der Produktionsverkehr unbegrenzt ist, sammeln Sie diese Signale über Zeitfenster (z. B. fünfminütige Schiebefenster) und vergleichen sie mit historischen Quantilen.

Instrumentierungsstellen

Um die erforderlichen Daten zu erhalten, müssen Sie den Agenten an einigen Schlüsselstellen instrumentieren:

- am Eingangspunkt – erfassen Sie die rohe Benutzereingabe und einen Zeitstempel - vor jedem Tool-Aufruf – protokollieren Sie den beabsichtigten Aufruf und die Argumente - nach jeder Tool-Antwort – protokollieren Sie die Erfolgsflagge, Fehlercode und Payload-Größe - nachdem der Agent seine endgültige Ausgabe produziert hat – protokollieren Sie die Ausgabebeschriftung und eventuelle Sicherheitsscores - in regelmäßigen Abständen – senden Sie ein Herzschlagssignal, das die Speicherbelegung und CPU-Last enthält

Diese Protokolle werden an eine Observability-Backend (Prometheus, Loki oder ein benutzerdefiniertes Zeitreihen-System) gesendet, wo Sie Dashboards und Warnungen erstellen können.

Beispiel-Warnregel

Eine nützliche Regel ist, eine Warnung auszulösen, wenn der Anteil von Aufrufen einer bestimmten externen API, die einen 5xx-Fehler zurückgeben, den 99. Percentil der letzten zwei Wochen für drei aufeinanderfolgende Fenster überschreitet. Dies erkennt eine plötzliche Verschlechterung einer Abhängigkeit, die das Offline-Set nie abgedeckt hat, weil der Fehlermodus nur unter realer Last auftritt.

Gängige Fallstricke, wenn man sich nur auf eine Schicht verlässt

- Veröffentlichung mit nur Offline-Punktzahlen – Sie können die Schwelle passieren, aber dennoch einen Agenten veröffentlichen, der auf seltene Benutzereingaben oder auf ein Tool-Verhalten, das nur unter hoher Konkurrenz auftritt, fehlschlägt. - Veröffentlichung mit nur Dashboards – Sie können ein Problem erst Tage nach dem Merge des fehlerhaften Changes erkennen, was den Rollback schwieriger macht und die Benutzerbeeinträchtigung erhöht. - Vergleichen von Produktionszahlen über einen Zeitraum, in dem auch das Modell, die Aufforderung oder die Tool-Liste geändert wurde – die beobachtete Drift könnte auf die beabsichtigte Aktualisierung und nicht auf eine Regression zurückzuführen sein, was zu falschen Alarmen führt. - Verwenden der gleichen Schwelle für Offline- und Online-Signale – Offline-Punktzahlen sind normalerweise eng (Sie erwarten nahezu perfekte Übereinstimmungen), während Online-Metriken laut sind; die Anwendung einer einzigen Schwelle kann zu vielen falschen Positiven oder verpassten Erkennungen führen. - Vernachlässigen der Versionierung des Traektorien-Satzes – wenn Sie die goldenen Traektorien aktualisieren, ohne die Änderungen zu dokumentieren…

Erstellen eines Regressions-Tores in CI

Unten finden Sie ein konkretes Beispiel dafür, wie Sie das Tor für einen Kunden-Support-Agenten strukturieren könnten, der ein Sprachmodell, ein Abruf-Tool und eine Ticket-Erstellungs-API verwendet.

Schritt | Tool oder Skript | Ausgabe | Häufigkeit Checkout-Code und Fixtures | git clone + git checkout | sauberes Arbeitsverzeichnis | einmal pro Pipeline-Lauf Installieren von Abhängigkeiten | pip install -r requirements.txt | isolierte Umgebung | einmal pro Pipeline-Lauf Ausführen des Agenten auf jeder Traektorie | python run_agent.py --trajectories data/trajectories.jsonl | JSONL-Datei mit tatsächlichen Spuren | einmal pro Pipeline-Lauf Anwenden der Rubrik | python score_traces.py --rubric config/rubric.yaml | Punktzahlen pro Dimension und Gesamtpunktzahl | einmal pro Pipeline-Lauf Überprüfen der Schwellenwerte | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | Bestätigungs-/Fehlschlag-Status | einmal pro Pipeline-Lauf Veröffentlichen des Berichts | curl -X POST -d @report.json https://metrics.example.com/ingest | Eintrag in der Zeitreihe | einmal pro Pipeline-Lauf

Jeder Schritt wird absichtlich idempotent gehalten, damit das erneute Ausführen der Pipeline das gleiche Ergebnis liefert. Wenn ein Schritt fehlschlägt, wird die Pipeline gestoppt und die Merge-Anfrage wird blockiert.

Einrichten von Produktionswarnungen, die wichtig sind

Eine effektive Online-Überwachung konzentriert sich auf Signale, die sich schnell ändern, wenn etwas schiefgeht, und nicht auf Metriken, die nur langsam driftet.

Tool-Fehlerquote

Messung des Verhältnisses von fehlgeschlagenen Tool-Aufrufen zu Gesamt-Tool-Aufrufen für jeden externen Dienst. Ein plötzlicher Anstieg weist oft auf eine Downstream-Ausfall oder eine Änderung im Dienstvertrag hin, die der Agent nicht angepasst hat.

Schleifen-Wiederholungszähler

Einige Agents wiederholen einen Tool-Aufruf, wenn sie eine mehrdeutige Antwort erhalten. Verfolgen Sie die durchschnittliche Anzahl von Wiederholungen pro Benutzereingabe. Eine Erhöhung kann bedeuten, dass das Modell unsicherere Ausgaben produziert oder dass das Tool vage Fehler zurückgibt.

Ausgabebeschriftungs-Drift

Berechnen Sie eine Satzbeschriftung für jede endgültige Agenten-Ausgabe und vergleichen Sie die Distanz zur Median-Beschriftung der letzten stabilen Woche. Wenn die 95. Percentil-Distanz einen vordefinierten Schwellenwert überschreitet, lösen Sie eine Untersuchung aus.

Sicherheitssignal-Überwachung

Wenn Sie einen Prompt-Injektions-Detektor oder einen Obszönitäts-Filter auf der Agenten-Ausgabe ausführen, protokollieren Sie den Anteil der Anfragen, die gekennzeichnet sind. Verwenden Sie die OWASP LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), um zu entscheiden, welche Muster zu beobachten sind. Eine Erhöhung der gekennzeichneten Anfragen kann darauf hindeuten, dass das Modell anfälliger für Jailbreak-Versuche wird.

Alle diese Warnungen sollten an eine On-Call-Rotation mit einem klaren Runbook weitergeleitet werden, das beschreibt, wie man die Agenten-Version zurücksetzt, wie man einen Tool-Wrapper hot-patcht oder wie man zusätzliche Traektorien für Offline-Tests sammelt.

Schließen des Kreislaufs: Umwandeln von Überwachungsergebnissen in Offline-Tests

Die wahre Kraft der Verwendung beider Schichten wird deutlich, wenn Sie Produktionsbeobachtungen verwenden, um Ihren Test-Satz zu verbessern.

Erfassung eines neuen Fehlers

Wenn eine Warnung ausgelöst wird, ist der erste Schritt, die genaue Anfrage-Antwort-Sequenz zu extrahieren, die das Problem verursacht hat. Die meisten Observability-Systeme ermöglichen es Ihnen, eine Spur-ID herunterzuladen, die Folgendes enthält:

- die ursprüngliche Benutzereingabe - jeden Tool-Aufruf und seine Argumente - jede Tool-Antwort - die endgültige Agenten-Ausgabe

Speichern Sie diese Spur als neue Traektorien-Datei.

Beschriftung der erwarteten Verhaltensweisen

Arbeiten Sie mit dem Produktbesitzer oder dem Sicherheitsleiter zusammen, um zu entscheiden, was das korrekte Verhalten sein sollte. Wenn der Fehler aufgrund eines Fehlers im Tool auftrat, können Sie sich entscheiden, die Tool-Antwort zu simulieren, um die korrigierte Version zu simulieren. Wenn der Fehler aufgrund der Argumentation des Modells auftrat, können Sie eine Chain-of-Thought schreiben, die zur korrekten Antwort führt.

Hinzufügen zum Offline-Set

Platzieren Sie die neue Traektorie im versionierten Traektorien-Verzeichnis. Aktualisieren Sie die Dokumentation, um die Quelle zu notieren (z. B. „hinzugefügt aus Produktionsvorfall INC-2024-09-12-07“).

Anpassen der Rubrik bei Bedarf

Manchmal offenbart eine neue Traektorie eine Dimension, die zuvor ignoriert wurde. Zum Beispiel können Sie entdecken, dass der Agent manchmal eine korrekte Antwort produziert, aber einen unnötigen Entschuldigungs-Satz enthält, der Benutzer stört. Sie können eine „Knappheits“-Dimension zur Rubrik hinzufügen und ihr ein Gewicht zuweisen.

Erneutes Ausführen des Tores

Führen Sie die CI-Pipeline erneut aus. Wenn die neue Traektorie die Gesamtpunktzahl unter den Schwellenwert sinken lässt, wissen Sie, dass der aktuelle Code das Tor nicht bestanden hätte – was genau das ist, was Sie vor der Veröffentlichung erkennen wollten.

Das Wiederholen dieses Zyklus schafft eine Rückkopplungsschleife, in der die Produktion dem Test-Satz beibringt, was zu testen ist, und der Test-Satz bekannte Regressionsfehler verhindert, die Benutzern erreichen.

Was dies nicht ist

Diese Diskussion verspricht nicht, dass die Offline-Evaluation jeden möglichen Fehler vor der Veröffentlichung erkennt. Sie behauptet nicht, dass die Online-Überwachung niemals einen Fehler verpasst oder dass die beiden Schichten zusammen eine 100%ige Garantie der Korrektheit bieten. Sie besagt nicht, dass die Verwendung dieser Methoden Ihren Agenten fehlerfrei macht oder dass Sie Sicherheitsprüfungen, Red-Team-Übungen oder formale Verifizierung skippen können. Sie suggeriert nicht, dass die beschriebenen Signale für die Einhaltung von Vorschriften in Hochrisiko-Bereichen ausreichen. Sie behauptet nicht, dass der Arbeitsablauf die Notwendigkeit von menschlicher Aufsicht beseitigt oder dass Sie sich ausschließlich auf automatisierte Punktzahlen für Veröffentlichungsentscheidungen verlassen können. Sie garantiert nicht, dass eine bestimmte Schwelle für jedes Team oder jede Modellarchitektur funktioniert. Sie behauptet nicht, dass die obige Tabelle die einzige Möglichkeit ist, ein CI-Tor einzurichten, oder dass die aufgeführten Warnregeln universell optimal sind. Sie…

Referenzen

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Häufig gestellte Fragen

Brauchen wir beide?

Ja, wenn der Agent etwas berührt, das einem Benutzer oder einem System wichtig ist. Sie erkennen unterschiedliche Klassen von Fehlern.

Können Offline-Tests die Überwachung ersetzen?

Nein. Ihr Test-Satz kann keine Eingaben enthalten, die Sie noch nicht gedacht haben.

Kann die Überwachung Offline-Tests ersetzen?

Nein. Die Überwachung sagt Ihnen, dass sich etwas geändert hat, nachdem der Fehler aufgetreten ist; ein Tor sagt Ihnen, bevor die Veröffentlichung erfolgt.

Worauf sollten wir in der Produktion achten?

Änderungsrate in Fehlersignalen, Tool-Fehlerquoten und ungewöhnliche Schleifen- oder Wiederholungsmuster – nicht nur Volumen.

Wie halten wir die Punktzahlen über die Zeit vergleichbar?

Fixieren Sie die Rubrik und die Traektorien und dokumentieren Sie Änderungen am Modell, der Aufforderung und den Tools zusammen mit den Punktzahlen.

Ist eine der Schichten eine Sicherheitszertifizierung?

Nein. Beide sind Ingenieurssignale. Die Sicherheitsprüfung ist eine separate Übung.

Referenzen

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Probieren Sie das Produkt: AgentGrade

2026-09-20 · nur primäre Quellen · keine gefälschten Traffic-Metriken · nur Entscheidungsunterstützung

Verwandte Artikel

- Agent-Bewertungsrubriken, die über Stacks hinweg reisen - Erkunden Sie die vollständige AI-Micro-SaaS-Themenmatrix →