Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Nachdem Sie Bewertungen für einen Agent durchgeführt haben, liegen Ihnen in der Regel Bewertungsergebnisse vor, aber noch keine direkte Antwort auf die entscheidende Frage: Ist der Agent einsatzbereit?
Diese Ebene konzentriert sich darauf, Bewertungsergebnisse zu interpretieren und die Einsatzbereitschaft zu beurteilen, bevor einzelne Testfallfehler untersucht werden. Verwenden Sie Bewertungsergebnisse als Entscheidungsgrundlage, um zu bestimmen, ob Sie den Agent bereitstellen, weiterentwickeln oder die Bereitstellung blockieren müssen. Dieser Schritt hilft Ihnen zudem, Bereiche zu identifizieren, in denen eine eingehendere Analyse erforderlich ist.
Interpretation des Bewertungsergebnisses
Diese Ebene hilft Ihnen, übergeordnete Fragen zur Bereitschaft zu beantworten, darunter:
- Ist der Agent einsatzbereit?
- Wenn nicht, welche Bereiche erfordern zuerst Aufmerksamkeit?
- Gibt es blockierende Probleme, die vor weiteren Iterationen behoben werden müssen?
Dieser Schritt ist absichtlich leicht. In den meisten Fällen lässt sich dieser Schritt in 10–15 Minuten mit bereits vorhandenen Bewertungsergebnissen erledigen.
Bevor Sie beginnen
Bevor Sie mit dieser Ebene beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
- Bestanden- oder Nicht-bestanden-Ergebnisse für einzelne Testfälle.
- Aggregierte Ergebnisse für ein oder mehrere Bewertungssets (zum Beispiel Sicherheit, Fundierung, Geschäftskorrektheit oder Tool-Nutzung).
Wenn die Bewertungsergebnisse noch nicht verfügbar sind, führen Sie Ihre Bewertungssets zunächst aus und kehren Sie zu diesem Schritt zurück, sobald die Ergebnisse vorliegen.
Interpretieren von Bewertungen auf der Bewertungsdatensatz-Ebene
Beginnen Sie damit, die Ergebnisse der Bewertungssets zu überprüfen, anstatt einzelne Testfälle zu betrachten.
Bewertungssets decken verschiedene Risiko- und Fähigkeitsbereiche ab, z. B. Sicherheit, zentrales Geschäftsverhalten, Wissensverankerung oder Tool-Nutzung. Die Analyse der Bewertungsergebnisse auf dieser Ebene hilft Ihnen zu erkennen, ob Fehler isoliert oder systemisch sind.
Stellen Sie sich die folgenden Fragen:
- Liegen Sicherheits- oder Compliance-Werte unter akzeptablen Schwellenwerten?
- Erfüllen die zentralen Geschäfts-Bewertungssets die Mindestanforderungen?
- Welches Bewertungsset schneidet im Verhältnis zu seiner Bedeutung am schlechtesten ab?
In dieser Phase liegt der Fokus auf dem Signal, nicht auf der Grundursache.
Interpretation der Passraten auf zwei Ebenen:
- Per Bewertungsset: Was bedeutet dieser Prozentsatz für die getestete Funktion?
- Pro Qualitätssignal: Was zeigt dieser Prozentsatz über alle Evaluierungssets hinweg an, die dasselbe Signal testen?
Eine niedrige Passrate bedeutet nicht automatisch, dass der Agent falsch ist. Dies weist darauf hin, dass eine Untersuchung erforderlich ist. Das Problem könnte im Agent, in der Bewertungsumgebung oder auf der Plattform liegen.
Setzen Sie Schwellenwerte basierend auf dem Risiko
Wenden Sie nicht die gleichen Schwellenwerte auf jeden Agent an. Setzen Sie Schwellenwerte basierend auf dem Risikoprofil des Agents. Berücksichtigen Sie die folgenden Faktoren.
| Faktor | Zu stellende Fragen | Einfluss auf die Schwelle |
|---|---|---|
| Folgen eines Fehlers | Was passiert, wenn der Agent das falsch macht? Unannehmlichkeit? Finanzieller Verlust? Sicherheitsrisiko? | Größere Auswirkung → Höhere Schwelle |
| Häufigkeit der Nutzung | Wie häufig wird dieses Qualitätssignal von Nutzern ausgelöst? | Höhere Frequenz → Höhere Schwelle (größere Exposition) |
| Fallback-Verfügbarkeit | Wenn der Agent ausfällt, gibt es eine menschliche Übernahme? Wie schnell? | Kein Fallback → Höhere Schwelle |
| Zielgruppe | Interne Mitarbeiter? Externe Kunden? Regulierte Branche? | Externe oder regulierte → höherer Schwellenwert |
Beispiele für risikobasierte Schwellenwerte
Diese Tabelle zeigt Beispielbeginn, keine universellen Standards.
| Risikoprofil | Beschreibung des Dataflows | Sicherheit und Konformität | Kerngeschäft | Funktionalitäten |
|---|---|---|---|---|
| Risikoarmes internes Werkzeug | Nur intern, menschliche Überprüfung für alle Ausgaben, Domäne mit geringem Einsatz | 90 %+ | 75 %+ | 65 %+ |
| Agent mit mittlerem Risiko im Kundenkontakt | Externe Nutzer, teilweise Automatisierung, wiederherstellbare Fehler | 95 %+ | 85 %+ | 75 %+ |
| Hochrisiko-Regulierungs- oder Finanzagent | Externe Nutzer, folgenschwere Entscheidungen, regulatorische Exposition | 98 %+ | 92 %+ | 85 %+ |
| Sicherheitskritischer Agent | Gesundheits-, Rechts- oder Finanzberatung mit begrenzter menschlicher Aufsicht | 99 %+ | 95 %+ | 90 %+ |
Nutzen Sie diese Beispiele als Anker und passen Sie dann an Ihre spezifischen Risikoüberlegungen an.
Beispielhafte Schwellenwertkalibrierung
Das folgende Beispiel zeigt eine mögliche Kalibrierung für einen Support-Agent mit mittlerem Risiko, der im Kundenkontakt steht.
| Qualitätssignal | Startschwelle | Sperrschwelle | Begründung |
|---|---|---|---|
| Sicherheit und personenbezogene Daten | 95-100 % | < 95 % blockiert den Versand | Jeder Sicherheitsverstoß stellt ein hohes Risiko dar |
| Compliance- und Wortlaut-Inhalte | 95-100 % | < 95 % blockiert den Versand | Regulatorische oder rechtliche Exposition |
| Sachliche Richtigkeit (Kerngeschäft) | 85-95 % | < 80 % blockiert den Versand | Kernnutzenversprechen |
| Wissens-Grounding | 85-95 % | < 80 % blockiert den Versand | Grundlage für Genauigkeit |
| Toolaufruf | 90-95 % | < 85 % blockiert den Versand | Zuverlässigkeit der Aufgabenausführung |
| Triggerrouting | 85-95 % | < 80 % blockiert den Versand | Korrektheit des Unterhaltungsflusses |
| Eskalation und Ordnungsgemäß | 90-95 % | < 85 % blockiert den Versand | Sicherheitsnetz für das Nutzererlebnis |
| Ton und Antwortqualität | 80–90 % | < 75 % blockiert den Versand | Subjektives Signal |
Trinkgeld
Kalibrieren, nicht kopieren. Schwellenwerte sollten das akzeptable Risiko für Ihren spezifischen Anwendungsfall widerspiegeln.
Bereitschaftsstatus bestimmen
Verwenden Sie die Ergebnisse der Bewertungssets, um eine Gesamtbewertung der Einsatzbereitschaft zu bestimmen. Häufige Bereitschaftszustände sind:
- Block: Sicherheit, Compliance oder kritische Geschäftsausfälle verhindern die Bereitstellung.
- Iterieren: Der Agent zeigt vielversprechende Leistungen, benötigt aber gezielte Verbesserungen.
- Bedingte Bereitstellung: Der Agent kann mit dokumentierten und überwachten Einschränkungen bereitgestellt werden.
- Bereitstellung: Der Agent erfüllt die Schwellenwerte über alle erforderlichen Bewertungssätze.
Entscheidungen zur Einsatzbereitschaft basieren auf Risikotoleranz und Nutzungskontext, nicht auf einem einheitlichen Score.
Trinkgeld
Bedingte Bereitstellung mit bekannten Lücken ist ein legitimes Ergebnis. Dokumentieren Sie akzeptierte Einschränkungen und verfolgen Sie diese über die Zeit mit der Vorlage für das Fehlerprotokoll.
Bestimmen Sie, wann die Iteration abgeschlossen ist
Verwenden Sie die folgenden Kriterien, um festzustellen, wann Sie über die Triage hinaus zur Bereitstellung oder Überwachung übergehen können.
Die Iteration ist abgeschlossen, wenn:
- Alle Bewertungssets über ihren Schwellenwerten liegen, einschließlich der von Ihnen angepassten Schwellenwerte.
- Bekannte Lücken zusammen mit Verantwortlichen und Zeitplänen dokumentiert sind.
- Wiederholungen konsistente Bewertungen mit weniger als 5 % Abweichung zwischen den Durchläufen liefern.
- Keine Blockierprobleme verbleiben, die als Agentkonfigurationsprobleme eingestuft werden.
Die Iteration ist nicht abgeschlossen, wenn:
- Schwellenwerte erreicht werden, ohne die verbleibenden Fehler zu verstehen.
- Bewertungsergebnisse sich nur verbessern, weil schwierige Testfälle entfernt wurden.
- Plattformbeschränkungen implizit ohne Dokumentation akzeptiert werden.
Umgang mit Nichtdeterminismus in Bewertungen
Sprachmodellbasierte Agents und Bewerter erzeugen variable Ausgaben. Wenden Sie folgende Praktiken an:
- Baselines etablieren: Führen Sie den vollständigen Evaluationssatz mindestens dreimal durch, bevor Sie eine Punktzahl als Baseline betrachten. Verwenden Sie den Durchschnitt als Ihren Arbeitswert. Mit weniger als drei Durchläufen kann man echtes Signal nicht von Rauschen unterscheiden.
- Bewertungsabweichung zwischen Ausführungen: Bis zu 5 % Abweichung zwischen Ausführungen ist für Bewertungsprogramme für Sprachmodelle normal. Wenn die Ausführung um mehr als 10 % variiert untersuchen Sie die Zuverlässigkeit des Bewerters, bevor Sie Agentprobleme diagnostizieren. Erfahren Sie mehr unter Bewerter-Validierung.
- Interpretation von Bewertungsänderungen nach der Nachbesserung: Bei Auswertungssätzen mit weniger als 30 Testfällen führt das Ändern eines einzelnen Testfalls von „Fehler“ zu „Bestanden“ zu einer Änderung der Bewertung um 3 % oder mehr. Ziehen Sie aus kleinen Veränderungen keine übermäßigen Schlüsse. Für Evaluationssets mit 50 oder mehr Testfällen betrachten Sie eine Veränderung von 5 % oder mehr als signifikant. Wenn Sie unsicher sind, führen Sie die Bewertung dreimal durch und vergleichen Sie den Durchschnitt mit Ihrem Basisdurchschnitt.
- Identifiziere instabile Testfälle (manchmal bestanden, manchmal nicht): Ein Testfall, der zwei von drei Durchläufen besteht, ist grenzwertig. Genauer untersuchen. Ist das erwartete Ergebnis zu starr (Evaluationskonfiguration), oder ist der Agent tatsächlich inkonsistent (Agentkonfiguration)? Wenn der Agent zwei verschiedene, aber beide akzeptable Antworten liefert, ist die Bewertung zu starr.
Nächste Schritte,
Sobald Sie Ihre Ergebnisse interpretieren und den Fokus kennen:
- Verwenden Sie Ebene 2: Triagefehler zum Diagnostizieren von fehlerhaften Testfällen.
- Nutzen Sie Ebene 3: Kartieren Sie Fehlermuster auf Sanierungsstrategien , um gezielte Korrekturen anzuwenden.
- Verwenden Sie Schicht 4: Musteranalyse, um systemische Probleme zu identifizieren.
- Gehen Sie die praktischen Beispiele durch, die zeigen, wie die Framework-Ebenen in realen Szenarien zusammenwirken.
Wenn mehr als 10 Testfälle fehlschlagen, analysieren Sie Muster, bevor Sie einzelne Fehler prüfen.