Lance Martin von Anthropic veröffentlicht im claude.dev-Blog einen Leitfaden zum Entwerfen von Evaluationen und zum Verbessern einer Anwendung oder eines Skills gegen diese, ohne sich selbst zu täuschen. Er kündigt die Erweiterung des claude-api-Skills von Claude Code um zwei Subcommands an: /claude-api build-eval baut eine Evaluation im Repository auf, /claude-api hillclimb verbessert die Anwendung dagegen, eine Änderung nach der anderen, mit einer zurückgehaltenen Menge von Beispielen, um Overfitting zu erkennen.
Der erste Teil nennt vier Eigenschaften einer guten Evaluation. Die Aufgaben spiegeln die Produktion wider. Die Scores steigen mit einem leistungsfähigeren Modell und höherem Aufwand; andernfalls sind mehrdeutige Aufgaben oder ein falsch kalibrierter Grader die Ursache. Das beste Modell bleibt deutlich unter 100%, ohne dass die Lücke auf unmögliche Aufgaben zurückzuführen ist: Eine Aufgabe, die bei jedem Durchlauf scheitert, ist verdächtig, und eine gute Aufgabe ist eine, bei der zwei Experten zum gleichen Urteil kommen. Schließlich ist die Varianz gering, was einen stabilen Grader, konsequent angewendeten Aufwand und eine von Altzuständen freie Umgebung erfordert. Der Autor fügt eine Warnung zum adversarial sampling hinzu: Die Auswahl der Fälle, bei denen das aktuelle Modell scheitert, misst dessen Schwächenprofil und nicht die tatsächliche Schwierigkeit. Er empfiehlt Fälle, die von einem Menschen als schwierig eingestuft werden, reale Fehlschläge aus Tickets oder Bugs, und weist darauf hin, dass roher Traffic zu den leichten Fällen hin verzerrt sein kann.
build-eval befragt den Nutzer und baut die Evaluation dann mit Freigabepausen auf. Die Eingaben stammen in dieser Reihenfolge aus Produktionstranskripten, Tickets, fünf bis zehn handgeschriebenen Fällen, dann synthetisierten Fällen. Der Grader ist der günstigste, der passt: programmatisch, wenn die Ausgaben eingeschränkt sind, andernfalls ein Judge-Modell mit einer Checkliste überprüfbarer Aussagen. Claude bewertet einige Fälle und fragt, ob der Nutzer sie anders beurteilt hätte, führt dann die Baseline mit einem Konfidenzintervall und drei Prüfungen aus: Stabilität des Graders, Plumbing, Spielraum.
Der zweite Teil behandelt Hillclimbing. Es eignet sich für Oberflächen, die günstig zu ändern sind, deren Score zuordenbar ist, mit einem begrenzten Ziel; Kosten sind ein gutes Beispiel dafür. Gegen Overfitting gibt es drei Schutzmaßnahmen: Train und Test trennen, Fehlschläge nie in den Prompt einfügen, Antworten außerhalb der Reichweite halten. Der Befehl teilt die Evaluation auf, prüft, dass das Rauschen geringer ist als der angestrebte Gewinn, schlägt einen Patch pro Runde vor und nimmt ihn zurück, wenn nur Train steigt. Bei Stagnation klassifiziert er die Fehlschläge nach Ursache, bevor er etwas ändert.
Zwei Beispiele veranschaulichen dies. Bei einem Support-Benchmark mit 44 Tickets ergibt der Wechsel von Opus 4.8 zu Opus 5.5 und dann zu Sonnet 5 bei niedrigem Aufwand, mit einem verbesserten Prompt, 90,5% gegenüber 78,6% bei den zurückgehaltenen Tickets, bei etwa einem Fünftel der Kosten. Beim claude-api-Skill steigt die Evaluation von 66% auf etwa 88%: fehlende Abschnitte, Typtabellen, eine Tabelle veralteter API-Formen sowie Korrekturen an fehlerhaften Aufgaben und Gradern.