# lancemartin-anthropic-automating-eval-design-hillclimbing-2026-09-28

## Veille

**Playbooks**-Artikel von **Lance Martin**, veröffentlicht im claude.dev-Blog am **28. September 2026** (12 Minuten Lesezeit, neun Abbildungen). Er stellt zwei Subcommands vor, die dem **claude-api**-Skill von Claude Code hinzugefügt wurden, `/claude-api build-eval` und `/claude-api hillclimb`, nachdem die Prinzipien dargelegt wurden, die sie anwenden. Drei Beiträge. **(A)** Vier Eigenschaften einer guten Evaluation: für die Produktion repräsentative Aufgaben, Scores, die mit dem Modell und dem Aufwand steigen, Spielraum unter **100%** an der Spitze, geringe Varianz von einem Durchlauf zum nächsten; dazu *adversarial sampling*: ein schwieriger Fall wird beibehalten, weil ein Mensch begründen kann, warum, nicht weil das heutige Modell daran scheitert. **(B)** Disziplinierte Hillclimbing-Praxis: eine Änderung pro Runde, getrennte **Train/Test**-Menge, Patch wird zurückgenommen, wenn Train steigt, während Test stagniert. **(C)** Zwei gemessene Beispiele: ein Customer-Support-Benchmark (**44** Tickets), dessen Kosten von etwa **4,6 auf 1 Cent** pro Ticket sinken, und die Evaluation des claude-api-Skills selbst, von **66%** auf etwa **88%**. Ein Satz aus dem Text: *„es ist wichtig, eine Stichprobe bewerteter Transkripte zu lesen, bevor man seinem Evaluator vertraut.“* Steht in Zusammenhang mit dem Beitrag des Autors zum Prompt-Caching, [[lancemartin-anthropic-prompt-auto-caching-claude-2026-02]].

## Titre Article

Automating eval design and hillclimbing with Claude

## Date

2026-09-28

## URL

https://claude.dev/blog/automating-eval-design-and-hillclimbing/

## Keywords

Evaluation, Eval-Design, Hillclimbing, claude-api, build-eval, hillclimb, Claude Code, Skill, Adversarial Sampling, Train- und Test-Sets, Overfitting der Evaluation, LLM-as-Judge, programmatischer Grader, Varianz, Konfidenzintervall, Spielraum, Kostensenkung, Aufwand, Prompt-Caching, Harness, Reward Hacking, Opus 5.5, Sonnet 5

## Authors

Lance Martin (Anthropic), blog claude.dev, avec remerciements à Misha Khalman pour le développement de la skill.

## Ton

**Profil**: ein praktischer Engineering-Leitfaden, verfasst von einem Anthropic-Praktiker für Teams, die eine Anwendung oder einen Skill auf der Claude API entwickeln. Zielgruppe: Entwickler und Qualitätsverantwortliche für LLM-basierte Systeme.

**Stil**: zwei symmetrische Teile (Evaluationsdesign, dann Hillclimbing), jeweils zunächst mit Darlegung der Prinzipien und dann des Befehls, der sie anwendet, gefolgt von zwei gemessenen Beispielen. Nummerierte Listen, schematische Abbildungen, im Verlauf gegebene Definitionen (Harness, Rauschen). Der Text präsentiert seine eigenen Tools als Umsetzung der dargelegten Prinzipien.

**Epistemische Position**: Die Zahlen in beiden Beispielen stammen aus internen Anthropic-Benchmarks (Customer Support, Evaluation des claude-api-Skills) und sind aus dem Artikel nicht reproduzierbar. Das Referenzergebnis ist jenes aus dem zurückgehaltenen Test-Set (90,5% gegenüber 78,6%), wobei die Scores auf dem für das Tuning verwendeten Recherche-Set liegen.

## Pense-betes

- **Vier Merkmale einer guten Evaluation.** Aus der Produktion stammende Aufgaben; ein Score, der mit einem stärkeren Modell und mehr Aufwand steigt; bestes Modell deutlich unter 100%; geringe Varianz. Warnsignal: Eine Aufgabe, die bei jedem Durchlauf scheitert, unabhängig davon, wie oft sie wiederholt wird, ist wahrscheinlich mehrdeutig oder schlecht bewertet.
- **Kriterium für eine gute Aufgabe.** Zwei Fachexperten kommen zum gleichen Urteil, und alles, was der Grader prüft, ist in der Aufgabe angegeben. Varianz kann auch aus der Konfiguration (falsch angewendeter Aufwand) oder der Umgebung (Altzustände, Git-Historie, die die Antwort preisgibt) stammen.
- **Adversarial Sampling.** Die Auswahl der Fälle, bei denen das aktuelle Modell scheitert, läuft darauf hinaus, die Schwachstellen eines einzelnen Modells abzutasten. Beibehalten werden die Fälle, die von einem Menschen als schwierig eingestuft werden, sowie solche aus Bugs oder Tickets. Roher Nutzer-Traffic kann zu den leichten Fällen hin verzerrt sein, da Nutzer tendenziell das versuchen, womit sie Erfolg erwarten.
- **`build-eval`, Reihenfolge der Quellen.** Produktionstranskripte (nach einer Frage zu Aufbewahrung und sensiblen Daten), Bug-Reports und Tickets, fünf bis zehn handgeschriebene Fälle, aus dem Code synthetisierte Fälle. Eine generierte Seite zeigt alle Eingaben und wartet auf die Bestätigung des Nutzers.
- **Wahl des Graders.** Der günstigste, der passt: programmatische Prüfung, wenn die Ausgaben eingeschränkt sind; andernfalls LLM-as-Judge mit einer Checkliste überprüfbarer Aussagen (keine Skala von 1 bis 5), ein Judge-Modell, das sich vom getesteten Modell unterscheidet, und ein blinder Vergleich in zufälliger Reihenfolge gegen eine Referenz.
- **Diagnostische Prüfungen der Baseline.** Grader zweimal auf dieselbe Ausgabe angewendet; Plumbing (Timeouts, API-Fehler, abgeschnittene Antworten); Spielraum, mit einer Warnung, wenn die Baseline etwa 95% übersteigt — in diesem Fall stattdessen Kosten oder Latenz als Ziel wählen.
- **Wo Hillclimbing angewendet wird.** Eine Oberfläche, die günstig zu ändern ist (Prompts, Skills statt Harness-Code), ein dieser Oberfläche zuordenbarer Score (die Trigger-Rate eines Skills und seine Beschreibung), ein begrenztes Ziel. Kosten sind ein robustes Ziel, selbst bei einer gesättigten Evaluation.
- **Drei Schutzmaßnahmen gegen Overfitting.** Train und Test trennen; den Inhalt von Fehlschlägen nie in den Prompt einfügen; Antworten strukturell außerhalb der Reichweite des Modells halten. Beispiele für Leakage: ein OCR-Tool, das hinzugefügt wird, weil die Evaluation zufällig davon profitiert, oder ein öffentliches Repository, aus dem der Harness die Lösung abruft.
- **`hillclimb`-Schleife.** Wahl der veränderbaren Oberfläche (System-Prompt, Skills, Tool-Beschreibungen, Modell und Aufwand, Harness-Code), ein Ziel, eine zufällige Train/Test-Aufteilung, eine vorherige Prüfung, dass das Rauschen geringer ist als der kleinste nützliche Gewinn. Jede Runde liest die Train-Transkripte und schlägt einen Patch vor; er wird beibehalten, wenn Train und Test beide steigen, andernfalls zurückgenommen. Liefert die Version, die auf Test am besten abschneidet, mit Konfidenzintervallen; liegt der Gewinn innerhalb des Rauschens, lautet die Empfehlung, nicht zu mergen.
- **Reflexionsschritt.** Stagniert der Score über zwei oder drei Runden, wird nicht bearbeitet: Jeder verbleibende Fehlschlag wird nach Ursache klassifiziert. Dieser Schritt deckte Skill-Inhalte auf, die vorhanden, aber ignoriert wurden, Claude, das veraltete, aus dem Training stammende API-Formen schrieb (ein festes Thinking-Budget statt adaptivem Reasoning), sowie fehlerhafte Aufgaben und Grader.
- **Kostenbeispiel (Customer Support).** 44 Tickets, 30 für die Recherche und 14 für den Test zurückgehalten. Ausgangspunkt: Opus 4.8 bei hohem Aufwand, 74,4% Genauigkeit, 4,6 Cent pro Ticket. Prompt-Audit, dann Opus 5.5 bei niedrigem Aufwand (87,8%, 1,9 Cent), dann Sonnet 5 bei niedrigem Aufwand (88,9%, 1 Cent), schließlich ein verbesserter Prompt (98,9%). Bei den 14 zurückgehaltenen Tickets: 90,5% gegenüber 78,6%, bei etwa einem Fünftel der Kosten.
- **Leistungsbeispiel (claude-api-Skill).** Von 66% auf 74% durch Hinzufügen acht fehlender Funktionen, 77% nach Korrektur der Typtabellen für C# und Java, 80% mit einer Zuordnungstabelle von alten zu neuen API-Formen, etwa 88% nach Korrektur zweier fehlerhafter Aufgaben und Grader.

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Lance Martin —travaille_chez→ Anthropic (ORGANISATION, 0.95)
- Anthropic —publie→ article Automating eval design and hillclimbing (DOCUMENT, 0.95)
- claude-api —fait_partie_de→ Claude Code (TECHNOLOGIE, 0.93)
- claude-api build-eval —fait_partie_de→ claude-api (TECHNOLOGIE, 0.96)
- claude-api hillclimb —fait_partie_de→ claude-api (TECHNOLOGIE, 0.96)
- claude-api build-eval —utilise→ LLM-as-judge (METHODOLOGIE, 0.92)
- Échantillonnage adversarial —s_applique_à→ conception d'évaluation (METHODOLOGIE, 0.9)
- Lance Martin —recommande→ choisir les cas difficiles parce qu'un humain sait dire pourquoi ils le sont (AFFIRMATION, 0.93)
- Lance Martin —recommande→ lire un échantillon de transcriptions notées avant de croire l'évaluateur (AFFIRMATION, 0.92)
- Hillclimbing —utilise→ jeu train/test séparé (CONCEPT, 0.94)
- Jeu train/test séparé —résout→ surapprentissage de l'évaluation (CONCEPT, 0.9)
- Surapprentissage de l'évaluation —observé_dans→ outil d'OCR ajouté au harnais parce que l'évaluation en profite (AFFIRMATION, 0.88)
- claude-api hillclimb —recommande→ annuler un patch quand le train monte et que le test reste plat (AFFIRMATION, 0.93)
- Hillclimbing —réduit→ coût par ticket à performance constante (AFFIRMATION, 0.9)
- Claude Opus —mesure→ 74,4 % de précision à 4,6 centimes par ticket (Opus 4.8, effort élevé, départ) (MESURE, 0.93)
- Claude Sonnet —mesure→ 90,5 % contre 78,6 % sur 14 tickets tenus à l'écart, pour environ un cinquième du coût (MESURE, 0.93)
- Claude Opus —améliore→ coût des tokens : 20 % de moins en entrée et sortie, 60 % de moins en lecture de cache (Opus 5.5 face à 4.8) (MESURE, 0.9)
- claude-api —mesure→ 66 % de réussite au départ, environ 88 % après hillclimbing (MESURE, 0.93)
- claude-api —observé_dans→ Claude écrit d'anciennes formes d'API issues de ses acquis malgré le contenu présent (AFFIRMATION, 0.9)
- Étape de réflexion sur les échecs —permet→ de détecter des tâches ou graders défectueux (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/de/fiches/lancemartin-anthropic-automating-eval-design-hillclimbing-2026-09-28/