Ein Entscheidungsmodell arbeitet bei Bewertungen anders als ein Modell, das freien Text erzeugt. Es wählt aus einer festgelegten Menge von Optionen und liefert kalibrierte Konfidenzwerte oder eine Wahrscheinlichkeitsverteilung über vordefinierte Antworten. Diese Struktur eignet sich für enge, wiederholbare Bewertungsfragen, weil jede Ausgabe eine bekannte Bedeutung besitzt und in ein einheitliches Ergebnis überführt werden kann.

Der AWS-Beitrag beschreibt die Einbindung dieses Ansatzes in Amazon Bedrock AgentCore Evaluations. AgentCore Evaluations unterstützt bedarfsgesteuerte Bewertungen während der Entwicklung, Batch-Bewertungen gespeicherter Sitzungen sowie Online-Bewertungen des Produktionsverkehrs. Zur Verfügung stehen 15 integrierte Evaluatoren. Eigene Evaluatoren lassen sich als LLM-as-a-Judge oder als codebasierte Evaluatoren definieren.

Eine Lambda-Brücke zu Entscheidungsmodellen

Ein codebasierter Evaluator führt eigene Logik in AWS Lambda aus. Diese Logik kann ein externes System, ein Modell oder eine API aufrufen, darunter auch ein Entscheidungsmodell. Der Beitrag nutzt diese Möglichkeit für zwei Backends: das gehostete Jev-Modell von TypeSafe und das selbst gehostete Open-Source-Modell Strands Decider 2B.

Jev und Strands Decider unterstützen noul-Fragen mit Ja-oder-Nein-Antwort, Auswahlfragen mit bis zu 255 Optionen und Bewertungsfragen mit zwei bis zehn geordneten Stufen. Mit diesen Formaten wird ein Bewertungskriterium als klar begrenzte Entscheidung formuliert und nicht als uneingeschränkte Textantwort.

Das Beispiel mit dem HR Assistant

Das Beispiel bewertet einen mit Strands Agents erstellten und in der AgentCore Runtime bereitgestellten HR Assistant. Die Konfiguration kombiniert deterministische Prüfungen, integrierte LLM-as-a-Judge-Evaluatoren und Entscheidungsmodell-Evaluatoren, deren Backend entweder Jev oder Strands Decider 2B ist.

Das Skript evaluate.py aus dem Beispiel stellt zwei deterministische Lambda-Evaluatoren bereit und registriert sie als codebasierte Evaluatoren. Anschließend führt es eine bedarfsgesteuerte Bewertung über fünf gekennzeichnete Szenarien mit drei benannten integrierten Evaluatoren aus. Zusätzlich erstellt das Skript eine Online-Konfiguration, die 100 Prozent der laufenden Sitzungen erfasst.

Die Prüfungen durch Entscheidungsmodelle sind optional. Die Option --with-jev registriert JevGroundedness, JevHelpfulness und JevGoalCompletion. Mit --with-decider werden dieselben drei Evaluator-Rollen registriert, wobei Strands Decider 2B als Backend dient.

Von Telemetriedaten zum AgentCore-Ergebnis

Der codebasierte Evaluator empfängt OpenTelemetry-Spans, normalisiert sie und formatiert die relevanten Inhalte für das Entscheidungsmodell. Bei einer Bewertung auf Trace-Ebene sendet er den betreffenden Dialogschritt zusammen mit einer kurzen vorherigen Historie. Bei einer Bewertung auf Sitzungsebene übermittelt er die vollständige Unterhaltung. Danach wird die Modellausgabe auf ein AgentCore-Ergebnis abgebildet.

Die Abbildung richtet sich nach dem Fragetyp. Bei einer noul-Frage entspricht der Wert der Wahrscheinlichkeit für wahr; als Label dient die wahrscheinlichste Antwort. Bei einer Bewertungsfrage wird die mit den Wahrscheinlichkeiten gewichtete erwartete Stufe berechnet und auf das Intervall von null bis eins skaliert. Bei einer Auswahlfrage wird der gewichtete Durchschnitt der zuvor definierten Optionswerte verwendet.

Damit fließt nicht nur das siegreiche Label in das Ergebnis ein. Der numerische Wert berücksichtigt die vom Entscheidungsmodell gelieferte Verteilung und passt sie zugleich an die von AgentCore Evaluations erwartete Ergebnisstruktur an.

Validierung vor einem Release-Gate

Die technische Anbindung allein reicht nicht aus. Das beschriebene Validierungsverfahren beginnt mit einer gekennzeichneten Stichprobe aus realem Datenverkehr. Drei unabhängige Kennzeichner beurteilen die Stichprobe; die Referenzlabels entstehen durch Mehrheitsentscheidung. Danach werden der Entscheidungsmodell-Evaluator und die passenden integrierten Evaluatoren auf identischen Eingaben ausgeführt.

Die Analyse untersucht Übereinstimmung, Kalibrierung und die einzelnen Fälle, in denen Ergebnisse voneinander abweichen. Nach einer Änderung der Frageformulierung oder der Modellversion soll die Prüfung wiederholt werden. Frage und Modellversion werden somit als Bestandteile der validierten Konfiguration behandelt.

Die empfohlene Einrichtung behält integrierte Evaluatoren als breite Basis bei. Ergänzt wird sie durch validierte Entscheidungsmodell-Prüfungen und exakte deterministische Kontrollen. Fehlgeschlagene oder nahe an einem Schwellenwert liegende Sitzungen können per Batch-Bewertung genauer untersucht werden. Release-Gates sollen sich nur auf integrierte Evaluatoren und auf Entscheidungsmodell-Evaluatoren stützen, die anhand gekennzeichneter Daten validiert wurden.