Agent-Eval-Rubriken, die über Stacks hinweg funktionieren

Definition einer reisebereiten Rubrik

Ich beginne damit, die Rubrik zu schreiben, bevor ich mir die Ausgabe des Modells ansehe. Die Rubrik muss drei unabhängige Achsen enthalten: Aufgabenerfolg, Werkzeugkorrektheit und Wahrhaftigkeit. Jede Achse erhält ihre eigene Bewertungsanleitung, die nicht den Modellnamen, die Framework-Version oder die genaue Prompt-Formulierung erwähnt. Ich halte die Anleitungen in einer einfachen Textdatei, die neben dem Test-Set gespeichert ist, damit jeder sie überprüfen kann.

Kern-Eigenschaften

- Vorab registrierte Kriterien - die Erfolgsbedingungen werden vor dem ersten Lauf festgelegt. - Achsen-Trennung - die Bewertungen für eine Achse beeinflussen nie eine andere. - Versionsunabhängige Sprache - Phrasen wie "ab GPT-4" oder "bei Verwendung von LangChain 0.1" vermeiden.

Wenn ich diesen Eigenschaften folge, liefert die gleiche Rubrik mir vergleichbare Zahlen, egal ob ich den Agenten mit OpenAI's GPT-4o, Anthropic's Claude 3 oder einem lokalen Llama-3-Modell ausführe.

Warum Aufgabenerfolg auf Ergebnis basieren muss

Aufgabenerfolg beantwortet die einfache Frage: Hat der Agent das Geforderte erledigt? Ich beurteile dies anhand einer Checkliste, die den Endzustand der Welt überprüft, nicht die Formulierung der Antwort. Zum Beispiel, wenn die Aufgabe "Benutzer-E-Mail-Adresse auf alice@example.com aktualisieren" lautet, überprüfe ich den Datenbankeintrag nach dem Lauf. Ich interessiere mich nicht dafür, ob der Agent "Ich habe Ihre E-Mail-Adresse aktualisiert" oder "Ihre E-Mail-Adresse lautet jetzt alice@example.com" gesagt hat.

Konkrete Checkliste

- Vorbedingung überprüft (z.B. Benutzer existiert). - Nachbedingung überprüft (z.B. E-Mail-Feld entspricht alice@example.com). - Keine zusätzlichen Nebeneffekte (z.B. keine anderen Felder geändert). - Optional: Latenz unter einem Schwellenwert (z.B. 2 Sekunden).

Ich erfasse ein binäres Erfolg-/Misserfolgs-Ergebnis für jede Traektorie. Wenn der Agent die Nachbedingung nicht erfüllt, ist der Aufgabenerfolg null, unabhängig davon, wie flüssig die Antwort aussieht.

Werkzeugkorrektheit als separate Achse

Werkzeugkorrektheit überprüft die Aufrufe, die der Agent an externe APIs, Funktionen oder Datenbanken macht. Ich behandle jeden Aufruf als ein Mini-Experiment: Hat der Agent das richtige Werkzeug gewählt, hat er die richtigen Argumente übergeben und hat er es die richtige Anzahl von Malen aufgerufen? Ich folge den Richtlinien der OWASP-Cheat-Sheets für sichere Werkzeugnutzung, zum Beispiel dem LLM-Prompt-Injection-Prevention-Cheat-Sheet und dem SQL-Injection-Prevention-Cheat-Sheet, um unbeabsichtigte Injektionen zu vermeiden.

Bewertungsrubrik

- Richtiges Werkzeug ausgewählt - 1 Punkt. - Alle Argumente entsprechen dem Schema - 1 Punkt pro Argument. - Keine zusätzlichen Aufrufe - 1 Punkt, wenn die Anzahl der Aufrufe der erwarteten entspricht. - Keine verbotenen Nebeneffekte (z.B. Schreiben in ein Log, das nur gelesen werden sollte) - 1 Punkt.

Die Achsen-Bewertung ist die Summe der Punkte geteilt durch die maximale mögliche. Ich halte diese Achse separat, damit ein Fehler in der Werkzeugnutzung nicht einen Erfolg in der Aufgabenerfüllung verdeckt.

Wahrhaftigkeit: Nachverfolgung jeder Behauptung

Wahrhaftigkeit fragt, ob jede Aussage in der Ausgabe des Agents auf die Werkzeug-Ergebnisse oder den Kontext zurückgeführt werden kann, der dem Modell gegeben wurde. Ich behandle die Ausgabe als eine Menge von Behauptungen und überprüfe jede gegen die Beweise. Wenn eine Behauptung nicht unterstützt werden kann, markiere ich sie als Halluzination. Diese Achse ist am wichtigsten, wenn der Agent Dokumente zusammenfasst, Quellen zitiert oder Fragen beantwortet, die externe Daten erfordern.

Schritt-für-Schritt-Überprüfung

- Teile die Ausgabe in atomare Sätze auf. - Für jeden Satz liste die Fakten auf, die er behauptet. - Ordne jedem Fakt ein Werkzeug-Ergebnis oder einen Kontext-Snippet zu. - Wenn ein Fakt keine Übereinstimmung hat, zähle ihn als Misserfolg. - Wahrhaftigkeits-Bewertung = (Anzahl der unterstützten Fakten) / (Gesamtzahl der Fakten).

Ich erfasse die rohen Zahlen, damit ich sehen kann, ob ein Rückgang der Wahrhaftigkeit von einigen großen Halluzinationen oder vielen kleinen Fehlern kommt.

Was dies nicht ist

Ich möchte klarstellen, was die Grenzen einer reisebereiten Rubrik sind. Sie garantiert nicht, dass der Agent sicher, billig oder schnell ist. Sie verspricht nicht 100%ige Genauigkeit bei jedem möglichen Eingabe. Sie ersetzt nicht eine dedizierte Sicherheitsprüfung, eine Kostenanalyse oder eine Latenz-Benchmark. Die Rubrik misst nur die drei Achsen, die ich oben definiert habe. Wenn Sie wissen müssen, ob der Agent private Schlüssel leckt, müssen Sie eine separate Geheimnis-Verwaltungs-Prüfung durchführen, zum Beispiel mit dem Secrets-Management-Cheat-Sheet. Wenn Sie wissen müssen, ob der Agent innerhalb eines Budgets bleibt, müssen Sie Token-Nutzung oder API-Aufruf-Kosten außerhalb dieser Rubrik verfolgen.

Kurz gesagt, die Rubrik ist ein Werkzeug zum Vergleichen der Agenten-Qualität über Stacks hinweg, nicht ein silberner Pfeil für alle Produktions-Bedenken.

Erstellung vergleichbarer Traektorien

Eine Traektorie ist der vollständige Log von dem, was während eines Laufs passiert: der anfängliche Prompt, jeder Werkzeug-Aufruf mit seinen Argumenten und Ergebnissen und die endgültige Modell-Ausgabe. Ich speichere jede Traektorie als JSON-Objekt mit einem festen Schema, damit ich Läufe automatisch vergleichen kann. Unten ist ein Beispiel für das Schema, das ich verwende.

Feld | Typ | Beschreibung prompt | string | Der genaue Benutzer- oder System-Prompt, der an das Modell gesendet wird. calls | array | Geordnete Liste von Werkzeug-Ausführungen. calls[].tool | string | Name des Werkzeugs oder der API. calls[].args | object | Argumente, die an das Werkzeug übergeben werden. calls[].result | any | Roh-Ergebnis vom Werkzeug. output | string | Endgültiger Text, der vom Modell zurückgegeben wird. metadata | object | Optional: Tags wie Modell-Name, Framework-Version, Zeitstempel.

Da das Schema nie ändert, kann ich die drei Achsen-Bewertungen für jede Traektorie mit den gleichen Skripten berechnen. Ich halte einen Master-Satz von Traektorien, der die Kern-Aufgaben abdeckt, die ich ausliefere, und die häufigen Fehler-Modi, die ich gesehen habe. Wenn ich das Modell ändere, führe ich die gleichen Traektorien erneut aus und vergleiche die neuen Bewertungen mit dem Baseline.

Ausführen von Bewertungen bei jedem Änderung

Ich integriere den Bewertungsschritt in meine kontinuierliche-Integration-Pipeline. Die Pipeline führt bei jedem Commit, der das Verhalten beeinflussen kann, folgendes aus:

- Überprüfe den neuesten Code. - Installiere die Agenten-Abhängigkeiten. - Führe den Agenten gegen den festen Traektorie-Set aus. - Parse die Logs und berechne Aufgabenerfolg-, Werkzeugkorrektheit- und Wahrhaftigkeits-Bewertungen. - Teile die Ergebnisse auf einem Dashboard mit und markiere jede Achse, die um mehr als fünf Prozent im Vergleich zum vorherigen grünen Build abfällt.

Diese Praxis fängt Rückgänge früh. Zum Beispiel, als ich die zugrunde liegende Abruf-Bibliothek wechselte, fiel die Werkzeugkorrektheit von 0,96 auf 0,82, weil die neue Bibliothek Ergebnisse in einer anderen Reihenfolge zurückgab, was den Agenten dazu veranlasste, zusätzliche Aufrufe zu machen. Der Rückgang erschien im CI-Bericht, bevor ein Benutzer ein Problem bemerkte.

Ich halte auch einen menschlich bewerteten Hold-out-Satz von zwanzig Traektorien. Jeden Monat bewerte ich diese mit einer Person und vergleiche den Durchschnitt mit den automatischen Bewertungen. Wenn der automatische Richter abdriftet, kalibriere ich die Rubrik oder trainiere das Richter-Modell erneut.

Bediener-Checkliste für Agent-Eval-Rubriken, die über Stacks hinweg funktionieren

Ich halte eine geschriebene Checkliste neben jedem Release, der dieses Thema berührt. Die Liste ist absichtlich langweilig: Namen des Eigentümers, Namen des Beweis-Artikels und Namen des Rollbacks. Wenn ein Schritt keine Datei, kein Ticket oder keine Log-Zeile produzieren kann, ist es kein Schritt - es ist ein Wunsch.

Bevor Sie die Produktion ändern

- Friere den Branch oder die Konfigurations-Revision ein, gegen die Sie messen werden. - Erfasse den aktuellen Fehler-Modus mit einem konkreten Eingabe und einem konkreten Ausgabe. - Bestätige, welche Identität der Job ausführt, und ob diese Identität auf Daten zugreifen kann, die sie nicht sollte. - Öffne die primären Referenzen, die Sie zitieren werden: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Während Sie den Check ausführen

- bevorzuge einen reproduzierbaren Pfad gegenüber zehn anekdotischen Screenshots. - Schreiben Sie das erwartete sichere Ergebnis, bevor Sie das Werkzeug oder die Abfrage auslösen. - Erfassen Sie den genauen Befehl, Prompt, Schema oder Regex, der getestet wird - nicht eine Paraphrase. - Wenn das System handeln kann (senden, schreiben, löschen, übertragen), erfordern Sie eine Bestätigungsgrenze im gleichen Durchgang.

Nachdem Sie fertig sind

- Datei des Rest-Risikos mit einem Eigentümer und einem Datum, auch wenn der Scan sauber ist. - Konvertieren Sie kein grünes Häkchen in Verkaufssprache, die Vollständigkeit beansprucht. - Führen Sie die gleiche Checkliste erneut aus, wenn das Modell, das Werkzeug-Schema oder die Validierungs-Regeln geändert werden.

Signal | Was zu erfassen ist | Stop-Ship? Unerwartetes Schreiben oder Senden | Werkzeug-Name, Argumente, Identität | Ja, bis es gesperrt ist Fehlende Bestätigung bei destruktiver Aktion | Aufruf-Pfad und Umgehung | Ja Nicht vertrauenswürdiger Text als Anweisung behandelt | Quell-Oberfläche und resultierende Aktion | Ja für Agenten-Reichweite Scanner sauber, Urteil offen | Aufgeschobene Artikel + Eigentümer | Nur, wenn der Kern-Pfad sicher ist

agenteval hilft bei der messbaren ersten Runde. Architektur-Entscheidungen, rechtliche Absegnung und kundenorientierte Behauptungen benötigen immer noch einen menschlichen Eigentümer. Behandeln Sie jede Checkliste-Zeile als Entscheidungs-Unterstützung, nicht als Zertifikat.

Wie ich Grenzen gegenüber Käufern erkläre

Wenn ein Interessent fragt, ob das Produkt "alles abdeckt", antworte ich mit der Grenze: Automatisierte Checks erfassen bekannte Muster; neue Ketten und politische Urteile benötigen immer noch eine Überprüfung. Diese Ehrlichkeit hält die Support-Last niedrig und hält den Blog im Einklang mit dem, was das Produkt tatsächlich tut.

Wenn Sie eine zweite Meinung benötigen, kombinieren Sie diesen Artikel mit den Referenzen unten und mit Ihrer eigenen Staging-Reproduktion. Überspringen Sie den Reproduktions-Schritt nicht, nur weil ein Modell eine zuversichtliche Zusammenfassung geschrieben hat.

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

Wie viele Testfälle benötigen wir?

Genug, um die Aufgaben abzudecken, die Sie tatsächlich ausliefern, und die Wege, auf denen sie fehlschlagen. Eine Handvoll gut ausgewählter Traektorien schlägt eine große Menge einfacher.

Können wir Ausgaben mit einem anderen Modell bewerten?

Sie können, aber erfassen Sie, dass der Richter ein Modell ist, und halten Sie eine feste Stichprobe, die von Menschen bewertet wurde, damit Sie sehen können, ob der Richter selbst abgedriftet ist.

Was ist Wahrhaftigkeit, konkret?

Ob jede Behauptung in der Ausgabe durch die Werkzeug-Ergebnisse oder den Kontext unterstützt wird, den der Agent erhalten hat, und nicht durch die eigenen Priors des Modells produziert wurde.

Sollten wir nur die endgültige Antwort bewerten?

Nein. Bewerten Sie die Traektorie auch - die Werkzeug-Aufrufe sind der Ort, an dem die meisten Agenten-Fehler entstehen.

Wie oft sollten Bewertungen ausgeführt werden?

Bei jeder Änderung, die das Verhalten beeinflussen kann: Prompt, Modell, Werkzeug-Liste oder Abruf-Konfiguration.

Bedeutet ein guter Score, dass der Agent sicher ist?

Nein. Es bedeutet, dass er gut auf den Aufgaben abgeschnitten hat, die Sie getestet haben. Sicherheit, Kosten und Fehler-Handling sind separate Bewertungen.

Referenzen

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

Probieren Sie das Produkt: AgentGrade

2026-09-20 · nur primäre Quellen · keine erfundenen Traffic-Metriken · Entscheidungs-Unterstützung nur

Verwandte Artikel

- Offline-Eval vs. Online-Überwachung für AI-Agents - Erkunden Sie die vollständige AI-micro-SaaS-Themen-Matrix →