KI-Agenten-Metriken: Erfolgsquote und Abdeckung

Wähle die Einheit, bevor du eine Quote berechnest

Ein Trace ist eine aufgezeichnete Interaktion. Ein Testergebnis bewertet ein Szenario anhand einer Ausführung. Eine Assertion prüft eine Erwartung innerhalb dieses Tests. Ein Trace kann zu mehreren Szenarien passen und ein Test mehrere Assertions enthalten. Diese Zählgrößen sind nicht austauschbar.

Die folgenden Berechnungen sind synthetische Beispiele für deinen Evaluierungsbericht, keine gemessenen Mibo-Ergebnisse und kein Versprechen, dass jede Metrik als Dashboard-Widget verfügbar ist. Halte Verhaltensergebnisse, Anwendbarkeit und Belegqualität in getrennten Spalten fest.

Berechne die Assertion-Bestehensquote, ohne übersprungene Prüfungen als bestanden zu zählen

Angenommen, ein Bericht enthält 50 Assertion-Datensätze: 15 bestanden, 5 fehlgeschlagen und 30 übersprungen, weil eine Abhängigkeit die Auswertung verhindert hat. Die bewertete Gruppe umfasst 20 Assertions.

• Bestehensquote: 15 / (15 + 5) = 75 %.
• Fehlerquote: 5 / (15 + 5) = 25 %.
• Übersprungen: 30 / 50 = 60 % der Datensätze. Untersuche, warum diese Prüfungen nie ausgewertet wurden.

Würdest du 5 / 50 = 10 % als Fehlerquote angeben, würdest du die Fehler durch nicht ausgewertete Prüfungen verwässern. Berichte neben dem Score „15 bestanden, 5 fehlgeschlagen, 30 übersprungen“. Eine übersprungene abhängige Prüfung ist außerdem etwas anderes als ein nicht anwendbares Szenario.

Mibos Ausführungsscore teilt bestandene Assertions durch bewertbare Assertions und schließt wegen Abhängigkeiten übersprungene Assertions aus. Die aggregierte Qualitätsmetrik mittelt die aufgezeichneten Ergebnisscores. Das sind unterschiedliche Aggregationen: Ein Ergebnis mit 1/1 bestandenen Assertions und eines mit 1/9 ergeben im Mittel 55,6 %, während das Zusammenfassen ihrer Assertions 2/10 = 20 % ergibt. Gib an, welche Aggregation du verwendest.

Wenn keine Assertion bewertbar ist, gibt die aktuelle Auswertung einen Score von 1,0 zurück. Das gilt auch, wenn alle Assertions übersprungen werden. Prüfe die Anzahl bestandener, fehlgeschlagener und übersprungener Assertions, bevor du den Score als Beleg einer erfolgreichen Bewertung deutest.

Definiere Ergebnis- und Tool-Metriken anhand konkreter Anforderungen

• Szenario-Erfolgsquote: Läufe, die alle erforderlichen Ergebnisse erreichen / anwendbare Läufe mit ausreichenden Belegen. Definiere die erforderlichen Ergebnisse im Voraus und berichte ausgeschlossene Läufe separat. Ein durchschnittlicher Assertion-Score entspricht nicht automatisch dieser Quote.
• Routing-Genauigkeit: korrekt geroutete Anfragen / annotierte Anfragen mit beobachtbarem Routing. Leite die erwarteten Pfade aus der Eingabe ab; wenn du nur bereits korrekt geroutete Traces auswählst, verbirgst du Routing-Fehler.
• Korrektheit der Tool-Argumente: Aufrufe mit den erforderlichen validierten Argumenten / geprüfte Aufrufe, die diese Argumente benötigen. Zähle zusätzlich Läufe, in denen der erforderliche Aufruf nie stattfand; diese fehlen in einem Nenner, der nur Aufrufe berücksichtigt.
• Quote unbelegter Abschlussbehauptungen: ausgewertete Antworten, die den Erfolg einer Aktion ohne Belege behaupten / ausgewertete Antworten mit Abschlussbehauptungen. Verwende konkrete semantische Kriterien und prüfe strittige Bewertungen.
• Anzahl unbefugter Aktionen: beobachtete verbotene Zustandsänderungen, gruppiert nach Szenario und Schweregrad. Halte diese Zahl auch bei einer hohen Gesamtbestehensquote sichtbar.

Nutze den Testablauf mit sechs Fällen, um diese Anforderungen vor dem Sammeln von Scores festzulegen. Ein erfolgreicher HTTP-Status allein belegt keine davon.

Messe Szenarioabdeckung getrennt von Qualität

Stell dir 100 erfasste Produktions-Traces vor: 60 passen zu mindestens einem konfigurierten Szenario, 25 zu keinem, 10 haben keine verwertbare Eingabe und 5 können nicht klassifiziert werden. In diesem Beispiel schließen sich diese Trace-Gruppen gegenseitig aus.

• Anteil passender Traces an allen erfassten Traces: 60 / 100 = 60 %. Das beschreibt die erfasste Stichprobe, nicht den gesamten Produktionsverkehr, wenn Export oder Sampling Interaktionen ausgelassen haben.
• Anteil passender Traces an klassifizierbaren Traces: 60 / (60 + 25) = 70,6 %. Benenne diesen engeren Nenner ausdrücklich.
• Ohne Zuordnung: Prüfe die 25 Anfragen auf fehlende Szenarien oder Klassifizierungsfehler. Sie sind keine 25 bestandenen Tests.
• Nicht klassifizierbar: Untersuche die 10 Traces mit fehlender Eingabe und die 5 mit nicht verfügbarer Klassifizierung getrennt. Zähle sie nicht als bestanden und entferne sie nicht stillschweigend.

Mibo unterscheidet die Klassifizierungsergebnisse matched, no_match, empty_input und unavailable. Invariante Prüfungen können auch ohne Zuordnung zu einem bedingten Szenario laufen. Da ein Trace zu mehreren Szenarien passen kann, können addierte Szenariozahlen Traces mehrfach zählen; entferne Duplikate, bevor du die Verkehrsabdeckung angibst.

Behandle fehlende Belege und Evaluatorfehler als getrennte Probleme

Ein fehlender Span kann bedeuten, dass eine Aktion nie stattfand oder dass die Instrumentierung sie verloren hat. Stelle die Vollständigkeit des Traces sicher, bevor du negative Assertions interpretierst. Das Verhalten bei fehlenden Daten variiert je nach Prüfung; ein fehlendes Feld erhält nicht immer einen separaten Instrumentierungsstatus.

Halte für semantische Prüfungen eine kleine Beispielsammlung bereit, die das Engineering-Team als akzeptabel oder nicht akzeptabel annotiert hat. Vergleiche den Evaluator mit diesen Labels, untersuche Abweichungen und präzisiere mehrdeutige Kriterien. Prüfe diese Kalibrierung erneut, wenn sich Modell oder Prompt des Evaluators ändern.

Mibos Halluzinationsquote basiert auf Fehlern unter den konfigurierten hallucination_check-Assertions. Ohne solche Assertions gibt es keine gemessene Quote. Sie misst nicht jede mögliche unbelegte Aussage im gesamten Verkehr.

Vergleiche Latenz und Kosten bei derselben Arbeitslast

Berichte die Ende-zu-Ende-Latenz getrennt von Modell- und Tool-Dauern. Wähle eine Konvention zur Perzentilberechnung, gib die Stichprobengröße an und lege Timeouts sowie fehlende Zeitmessungen offen. Ein niedrigeres p95 bedeutet keine bessere Qualität, wenn der Agent nun erforderliche Tools überspringt.

Tokens sind eine Nutzungsgröße, kein Geldbetrag. Kostenschätzungen benötigen die geltenden Modellpreise, Token-Kategorien, Wiederholungen und Tool-Gebühren. Vergleiche Kosten pro abgeschlossener Aufgabe, wenn der Aufgabenabschluss dein Ziel ist, und halte die Kosten fehlgeschlagener Versuche sichtbar.

Halte bei einem Versionsvergleich Szenariomix, Testdaten, Evaluator und Messzeitraum möglichst konstant. Andernfalls kann eine Verschiebung zu leichteren Anfragen wie eine Verbesserung wirken. Prüfe die Ergebnisse je Szenario, bevor du einen aggregierten Gewinn akzeptierst.

Schreibe einen Release-Bericht, der eine Entscheidung ermöglicht

• Umfang: Agenten-, Suite- und Evaluator-Version, Szenarien, Anzahl der Läufe und Bedingungen der Testdaten.
• Verhalten: Anzahl bestandener und fehlgeschlagener Prüfungen, Aggregationsregel, kritische Fehler und Links zu den relevanten Trace-Belegen.
• Blinde Flecken: übersprungene Prüfungen, unvollständige Traces, Verkehr ohne Szenariozuordnung und nicht verfügbare Klassifizierung.
• Betrieb: Latenzverteilung, Timeouts, Nutzungs- oder Kostenannahmen und Stichprobengrößen.
• Entscheidung: welches Szenario das Release blockiert, was behoben werden muss und was weitere Läufe oder menschliche Prüfung benötigt.

Fünf erfolgreiche Läufe belegen keine Erfolgswahrscheinlichkeit von 100 % in Produktion. Berichte „5/5 mit diesen Testdaten“ und erweitere die Tests rund um wichtige Fehler. Wähle Grenzwerte nach den Folgen eines Fehlers, nicht nach einem willkürlichen Branchenscore.

Verbinde Metriken mit einem nachvollziehbaren Test

Beginne mit einem Szenario aus der Bibliothek für Agenten-Testfälle, definiere seine Prüfungen und untersuche sowohl eine bestandene als auch eine fehlgeschlagene Ausführung. Mibos Evaluierungsablauf verbindet konfigurierte Prüfungen mit Ausführungsbelegen, damit das Ergebnis zu einer konkreten Korrektur führen kann.

Nutze für die Implementierung die Assertion-Referenz und die Anleitung zur OpenTelemetry-Ingestion. Wähle Metriken erst aus, nachdem du bestätigt hast, dass deine Instrumentierung die benötigten Felder liefert.