Insight ·

Evals vor Features: Woran ein schlechterer Agent erkennbar wird

Eine plausible Antwort ist kein bestandener Test. Golden Sets, paarweiser Vergleich und Fehlerslices machen Agentenqualität releasefähig.

Evals vor Features: Woran ein schlechterer Agent erkennbar wird

Eine Promptänderung machte die Antworten eines Agenten kürzer und ruhiger. Im Review bevorzugte das Team jedes neue Beispiel. In Production liess dieselbe Änderung eine Währungsbedingung aus Erstattungsantworten verschwinden. Das Ergebnis klang besser und arbeitete schlechter.

Das ist die zentrale Schwierigkeit bei Agent Evals. Es kann mehrere akzeptable Antworten geben, aber weiterhin unzulässige Auslassungen, Aktionen und Behauptungen. Kein einzig richtiger Satz bedeutet nicht, dass Verhalten untestbar ist.

Das Golden Set kommt vor dem nächsten Feature

Ein Golden Set ist eine stabile Sammlung repräsentativer Eingaben mit Belegen und Erwartungen für die Bewertung. Es enthält normale Arbeit, schwierige Grenzen und bekannte Fehler. Synthetische Fragen, die bequem zum Prompt passen, sind schwaches Material. Production Traces, Supportkorrekturen und abgelehnte Tool Calls sind besser.

Pro Fall wird gespeichert, was zählt: Quellkontext, erlaubte Tools, notwendige Fakten, verbotene Aktionen und ein akzeptables Ergebnis. Einige Prüfungen sind deterministisch. Eine Summe muss zur Quelle passen. Eine zitierte Kennung muss existieren. Ein Write Tool darf ohne Freigabe nicht laufen. Andere Kriterien brauchen menschliche oder modellbasierte Bewertung anhand einer Rubric.

OpenAIs Evals API Dokumentation beschreibt Evals als wiederverwendbare Testkriterien zusammen mit einer Datenquelle, ausführbar über Modelle und Parameter hinweg. Diese Wiederverwendbarkeit ist wichtiger als das Dashboard.

Ausgaben paarweise vergleichen

Absolute Bewertung verlangt vom Reviewer eine stabile innere Skala. Pairwise Comparison stellt eine engere Frage: Ist bei gleicher Eingabe und Evidenz Kandidat A besser, Kandidat B besser oder sind beide gleichwertig? Dabei bleiben Reviewer meist konsistenter.

Die erzeugende Version bleibt verborgen, die Reihenfolge wird gemischt und die Rubric kommt vor den Beispielen. Eine kurze Begründung muss sich auf beobachtbares Verhalten stützen, nicht nur auf Ton. Pairwise Siege zeigen eine Richtung, deterministische Checks bleiben Gates. Eine hilfreichere Antwort kann weder unzulässige Aktion noch erfundenen Fakt ausgleichen.

Model Grader werden erst nach Kalibrierung gegen menschliche Entscheidungen für Volumen eingesetzt. Weicht der Grader in einem geschäftskritischen Slice systematisch ab, misst er das Falsche.

Fehler in Slices statt im Durchschnitt betrachten

Ein Gesamtscore kann steigen, während ein wichtiger Workflow schlechter wird. Ergebnisse werden nach Aufgabe, Sprache, Kundentyp, Toolpfad, Datenquelle und Risikoklasse zerlegt. Eine unnötige Ablehnung trotz vorhandener Antwort wird getrennt von sicher klingenden Antworten ohne Evidenz verfolgt.

Der kleinste Slice kann kommerziell entscheidend sein. Eine seltene Erstattungsausnahme, Berechtigungsgrenze oder ein deutsches Kompositum in der Suche verschwindet leicht im Mittelwert. Release Gates schützen benannte kritische Slices auch bei gesundem Gesamtergebnis.

Das Set lebendig halten

Golden bedeutet nicht für immer eingefroren. Ein neuer Production Fehler wird zum neuen Fall. Duplikate dürfen verschwinden, die Geschichte darf aber nicht zugunsten des aktuellen Systems umgeschrieben werden. Dataset, Rubric, Modell, Prompt, Tools und Retrieval Konfiguration werden gemeinsam versioniert. Sonst ist kein Ergebnis reproduzierbar.

Die Suite läuft vor Änderungen an Modell, Prompt, Toolbeschreibung, Retrieval oder Antwortformat. Nach dem Release braucht es Samples aus echtem Traffic für Verteilungen ausserhalb des Sets.

Diese Woche ein Release Gate einrichten

Kürzlich korrigierte Antworten und fehlgeschlagene Runs bilden den Anfang. Ein kompaktes Set deckt Workflows ab, die Geld, Vertrauen oder Daten betreffen. Zuerst kommen deterministische Assertions, danach eine kurze Pairwise Rubric für Relevanz, Vollständigkeit und Groundedness.

Aktuelle Production Konfiguration und Vorschlag laufen gegeneinander. Jede Regression in einem kritischen Slice wird geprüft. Ein Release erfolgt erst, wenn bekannte harte Fehler blockiert bleiben und jeder Tradeoff offenliegt. "Es wirkte in Ordnung" hält eine Stimmung fest. Ein Eval zeigt, was sich wo geändert hat und ob das Unternehmen diesen Unterschied akzeptiert.