Evaluation durchführen

Eval (kurz für Evaluation, die messbare Qualitätsprüfung) beantwortet eine Frage objektiv statt aus dem Bauch heraus: Liefert das Feature die erwartete Ausgabe? Ein Eval-Run führt das Feature gegen bekannte Quellen aus und vergleicht das Ergebnis mit der hinterlegten Erwartung. Alle Eval-Funktionen liegen im Feature-Detail im Tab Eval.

Öffne ein Feature über Features, klicke die Feature-Karte an und wechsle in der Tab-Leiste auf Eval. Der Tab gliedert sich in eine ausklappbare Einstellungs-Leiste oben und darunter zwei Unter-Tabs: Eval-Runs und Offene Reviews.

Was bewertet wird

Grundlage eines Eval-Runs sind die Source+Label-Paare des Features (eine Quelle plus die dazu erwartete Ausgabe). Diese Test-Paare verwaltet der Tab Sources (Quellen). Pro Feld im Output-Schema (das stabile Interface der Ausgabe) legt der Modus fest, wie bewertet wird:

exact_match — ein deterministischer Code-Grader vergleicht den Wert eins zu eins mit dem Label.
llm_judge — ein Bewertungsmodell (LLM-as-Judge) gibt dem Feld eine Note von 0 bis 100 Prozent.
human_review — ein Mensch bewertet das Feld manuell (Human-Review).

Die Auswahl des Graders ist also nichts, was beim Start abgefragt wird; sie ergibt sich aus dem Output-Schema.

Eval-Run starten

Im Unter-Tab Eval-Runs oben rechts auf Eval-Run starten klicken. Der Dialog Eval-Run starten zeigt unter So läuft der Run ab die drei Phasen:

Inference — pro Quelle läuft der Feature-Prompt gegen das Default-Modell.
LLM-as-Judge — alle llm_judge-Felder werden vom Judge-Modell bewertet.
Human-Review (optional) — human_review-Felder setzen den Run auf den Status pending_review, bis ein Reviewer speichert.

Felder mit exact_match laufen parallel über den Code-Grader. Bewertet wird immer die aktuell veröffentlichte Contract-Version gegen alle aktiven Source+Label-Paare; eine manuelle Auswahl gibt es nicht. Fehlt ein Default-Modell, erscheint der Hinweis Default-Modell fehlt mit Verweis auf den Tab Models (Modelle); der Knopf bleibt gesperrt. Mit Eval-Run starten läuft der Run im Hintergrund an, während der Verarbeitung erscheint Eval-Run läuft ….

Den Run-Trigger sehen nur Rollen mit Schreibrecht (platform_engineer, admin, developer, domain_expert); für andere Rollen ist der Knopf ausgeblendet.

Ergebnisse lesen

Über der Run-Liste liegt der Eval-Trend (Pass-Rate und Cost über Zeit). Er braucht mindestens zwei abgeschlossene Runs; vorher steht dort Noch keine Trend-Daten — fahre 2+ Eval-Runs für Drift-Detection.

Ein Klick auf einen Run in der Liste öffnet rechts den Eval-Run-Visualizer. Der Kopf zeigt Status, Pass-Rate, Cases (bestanden/gesamt), Kosten sowie das verwendete Inferenz- und Judge-Modell. Darunter:

Failure-Distribution — ein Donut mit der Verteilung der Fehlerklassen.
Cases — eine Tabelle mit den Spalten Case-ID / Source, Judgement (pass/fail/partial), Failure-Class, pass@k, Cost, Duration und Tags. Filtern nach Judgement, Failure-Class und Tag; sortieren nach Cost oder Duration. Mehr laden holt weitere Zeilen nach.

Verletzt ein Run einen Schwellwert, erscheint im Kopf das Banner ⚠ Threshold verletzt mit den betroffenen Werten und einem Knopf Re-Run starten. Mit Zurück zur Übersicht schließt sich der Visualizer.

Ein Klick auf eine Zeile öffnet den Eval-Case Drill-Down: die Karten Erwartet und Tatsächlich nebeneinander, Abweichende Felder, bei Bedarf eine Diagnose-Box (Schema-Failure, Timeout, Provider-Fehler), die Karte Judge-Begründung und ein Editor für Failure-Tags.

Offene Reviews freigeben

Enthält das Output-Schema human_review-Felder, bleibt der Run nach Inference und Judge im Status pending_review. Der Unter-Tab Offene Reviews listet unter Offene Human-Reviews alle wartenden Runs mit einer Zähler-Marke. Ein Klick auf eine Zeile springt in den Visualizer.

Im Bewertungs-Dialog Human-Review für Eval-Result stehen drei Spalten: Quelle, Modell-Output und Bewertung. Pro Feld einen Schieberegler von 0 bis 100 Prozent setzen (vorbelegt mit der LLM-Bewertung, falls vorhanden) und eine kurze Begründung im Feld Rationale eingeben — die Begründung ist Pflicht. Speichern + Nächster Case sichert die Bewertung; sind alle human_review-Felder bewertet, wechselt der Run auf completed.

Eval-Einstellungen

Oben im Tab Eval sitzt die ausklappbare Leiste Eval-Bewertung (Judge-Prompt + Thresholds). Dort wird die Bewertung pro Feature konfiguriert:

Bewertungs-Prompt — der System-Prompt für den LLM-Judge. Verfügbare Variablen sind {output_schema_json}, {source_input_text}, {feature_prompt}, {model_output_json} und {label_expected_text}.
Judge-Modell (Provider-Model-ID) — das Modell, das bewertet. Leer bedeutet Tenant-Default.
Min. Single-Score (%) und Min. Avg-Score (%) — die Schwellwerte (Eval-Baseline). Unterschreitet ein Run diese Werte, gilt der Schwellwert als verletzt.

Mit Speichern werden die Werte übernommen. Bearbeiten dürfen domain_expert, platform_engineer und admin; andere Rollen sehen die Felder schreibgeschützt. Das Speichern kann eine Bestätigung per Mehrfaktor-Authentifizierung (MFA) verlangen.

Synthetische Test-Fälle

Fehlen Test-Paare für Randfälle, lassen sich Vorschläge generieren. Der Dialog Synthetische Cases generieren liegt im Tab Sources und erzeugt Edge-Case-Vorschläge auf Basis bestehender Source-Labels. Anzugeben sind die Anzahl, die zugrunde liegenden Source-Label-IDs und mindestens ein Variation-Type. Die Vorschläge werden im Hintergrund erstellt und müssen anschließend im Tab Sources durchgesehen und übernommen werden, bevor sie in einen Eval-Run einfließen.

Voraussetzung zum Veröffentlichen

Eine Version lässt sich erst veröffentlichen, wenn die Reife-Kriterien erfüllt sind. Dazu gehört eine bestandene Eval-Baseline: Fehlt sie, meldet die Production-Readiness-Leiste Eval-Baseline fehlt und das Veröffentlichen bleibt gesperrt. Ablauf und übrige Kriterien stehen unter Veröffentlichen.