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

## Veille

Articolo **Playbooks** di **Lance Martin**, pubblicato sul blog claude.dev il **28 settembre 2026** (12 minuti di lettura, nove figure). Presenta due sottocomandi aggiunti allo skill **claude-api** di Claude Code, `/claude-api build-eval` e `/claude-api hillclimb`, dopo aver esposto i principi che essi applicano. Tre contributi. **(A)** Quattro proprietà di una buona valutazione: compiti rappresentativi della produzione, punteggi che aumentano con il modello e con l'impegno, margine di miglioramento sotto il **100%** al vertice, bassa varianza da un'esecuzione all'altra; più l'*adversarial sampling*: un caso difficile viene conservato perché un umano può spiegare perché, non perché il modello odierno lo fallisce. **(B)** Hillclimbing disciplinato: una modifica per round, insieme **train/test** separato, patch annullata se il train aumenta mentre il test resta stabile. **(C)** Due esempi misurati: un benchmark di assistenza clienti (**44** ticket) il cui costo scende da circa **4,6 a 1 centesimo** per ticket, e la valutazione dello stesso skill claude-api, dal **66%** a circa **88%**. Una frase del testo: *"è importante leggere un campione di trascrizioni valutate prima di fidarsi del proprio valutatore."* Collegato all'articolo dell'autore sul 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, insiemi train e test, overfitting della valutazione, LLM-as-judge, valutatore programmatico, varianza, intervallo di confidenza, margine di miglioramento, riduzione dei costi, impegno, 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

**Profilo**: una guida pratica di ingegneria, scritta da un professionista Anthropic per i team che costruiscono un'applicazione o uno skill sull'API Claude. Pubblico: sviluppatori e responsabili qualità per sistemi basati su LLM.

**Stile**: due parti simmetriche (progettazione della valutazione, poi hillclimbing), ciascuna che espone prima i principi e poi il comando che li applica, seguita da due esempi misurati. Elenchi numerati, figure schematiche, definizioni fornite lungo il percorso (harness, rumore). Il testo presenta i propri strumenti come l'implementazione dei principi che enuncia.

**Posizione epistemica**: le cifre in entrambi gli esempi provengono da benchmark interni ad Anthropic (assistenza clienti, valutazione dello skill claude-api) e non sono riproducibili a partire dall'articolo. Il risultato di riferimento è quello dell'insieme di test tenuto da parte (90,5% contro 78,6%), con punteggi sull'insieme di ricerca usati per la calibrazione.

## Pense-betes

- **Quattro segni di una buona valutazione.** Compiti tratti dalla produzione; un punteggio che aumenta con un modello più forte e più impegno; miglior modello chiaramente sotto il 100%; bassa varianza. Segnale d'allarme: un compito che fallisce in ogni esecuzione, indipendentemente da quante volte venga ripetuto, è probabilmente ambiguo o mal valutato.
- **Criterio per un buon compito.** Due esperti del dominio raggiungono lo stesso verdetto, e tutto ciò che il valutatore verifica è enunciato nel compito. La varianza può anche derivare dalla configurazione (impegno applicato in modo errato) o dall'ambiente (stato residuo, storico git che consegna la risposta).
- **Adversarial sampling.** Scegliere i casi che il modello attuale fallisce equivale a campionare le valli di un singolo modello. I casi conservati sono quelli giudicati difficili da un umano, e quelli tratti da bug o ticket. Il traffico grezzo degli utenti può propendere verso il facile, poiché gli utenti tendono a tentare ciò in cui si aspettano di riuscire.
- **`build-eval`, ordine delle fonti.** Trascrizioni di produzione (dopo una domanda su conservazione e dati sensibili), segnalazioni di bug e ticket, cinque-dieci casi scritti a mano, casi sintetizzati dal codice. Una pagina generata mostra tutti gli input e attende la conferma dell'utente.
- **Scelta del valutatore.** Il più economico che si adatti: verifica programmatica se gli output sono vincolati; altrimenti LLM-as-judge con una checklist di affermazioni verificabili (non una scala da 1 a 5), un modello giudice distinto dal modello testato, e un confronto alla cieca in ordine casuale rispetto a un riferimento.
- **Verifiche diagnostiche sulla baseline.** Valutatore rieseguito due volte sullo stesso output; funzionamento tecnico (timeout, errori API, risposte troncate); margine di miglioramento, con un avviso se la baseline supera circa il 95%, nel qual caso puntare invece su costo o latenza.
- **Dove applicare l'hillclimbing.** Una superficie economica da modificare (prompt, skill piuttosto che codice dell'harness), un punteggio attribuibile a quella superficie (il tasso di attivazione di uno skill e la sua descrizione), un obiettivo limitato. Il costo è un obiettivo solido anche su una valutazione saturata.
- **Tre salvaguardie contro l'overfitting.** Separare train e test; non incollare mai il contenuto dei fallimenti nel prompt; mantenere le risposte strutturalmente fuori portata del modello. Esempi di fuga di informazioni: uno strumento OCR aggiunto perché la valutazione ne beneficia per caso, oppure un repository pubblico da cui l'harness recupera la soluzione.
- **Ciclo `hillclimb`.** Scelta della superficie modificabile (prompt di sistema, skill, descrizioni degli strumenti, modello e impegno, codice dell'harness), un obiettivo, una divisione train/test casuale, una verifica preliminare che il rumore sia inferiore al più piccolo guadagno utile. Ogni round legge le trascrizioni del train e propone una patch; viene mantenuta se sia train sia test aumentano, altrimenti annullata. Produce la versione con il miglior punteggio sul test, con intervalli di confidenza; se il guadagno rientra nel rumore, la raccomandazione è di non integrarla.
- **Fase di riflessione.** Quando il punteggio si blocca per due o tre round, non avviene alcuna modifica: ogni fallimento rimanente viene classificato per causa. Questa fase ha rivelato contenuti dello skill presenti ma ignorati, Claude che scrive forme API obsolete tratte dal proprio addestramento (un budget di pensiero fisso invece che un ragionamento adattivo), e compiti o valutatori difettosi.
- **Esempio di costo (assistenza clienti).** 44 ticket, 30 per la ricerca e 14 tenuti da parte per il test. Punto di partenza: Opus 4.8 a impegno elevato, 74,4% di accuratezza, 4,6 centesimi per ticket. Audit del prompt, poi Opus 5.5 a basso impegno (87,8%, 1,9 centesimi), poi Sonnet 5 a basso impegno (88,9%, 1 centesimo), infine un prompt migliorato (98,9%). Sui 14 ticket tenuti da parte: 90,5% contro 78,6%, per circa un quinto del costo.
- **Esempio di prestazioni (skill claude-api).** Dal 66% al 74% aggiungendo otto funzionalità mancanti, 77% dopo la correzione delle tabelle di tipi C# e Java, 80% con una tabella di mappatura dalle vecchie alle nuove forme API, circa 88% dopo la correzione di due compiti e valutatori difettosi.

## RésuméDe400mots

Lance Martin, di Anthropic, pubblica sul blog claude.dev una guida sulla progettazione delle valutazioni e sul miglioramento di un'applicazione o di uno skill rispetto a queste senza illudersi. Annuncia l'aggiunta di due sottocomandi allo skill claude-api di Claude Code: `/claude-api build-eval` costruisce una valutazione nel repository, `/claude-api hillclimb` migliora l'applicazione rispetto a essa, una modifica alla volta, con un insieme di esempi tenuto da parte per rilevare l'overfitting.

La prima parte enuncia quattro proprietà di una buona valutazione. I compiti rispecchiano la produzione. I punteggi aumentano con un modello più capace e un impegno maggiore; in caso contrario, la causa sono compiti ambigui o un valutatore mal calibrato. Il miglior modello resta chiaramente sotto il 100%, senza che lo scarto sia dovuto a compiti impossibili: un compito che fallisce in ogni esecuzione è sospetto, e un buon compito è quello su cui due esperti raggiungono lo stesso verdetto. Infine, la varianza è bassa, il che richiede un valutatore stabile, un impegno applicato in modo costante e un ambiente privo di stato residuo. L'autore aggiunge un'avvertenza sull'adversarial sampling: scegliere i casi che il modello attuale fallisce misura la sua impronta di fallimento piuttosto che la difficoltà reale. Raccomanda casi giudicati difficili da un umano, fallimenti reali tratti da ticket o bug, pur notando che il traffico grezzo può propendere verso il facile.

`build-eval` interroga l'utente, poi costruisce la valutazione con pause di approvazione. Gli input provengono, in ordine, da trascrizioni di produzione, ticket, cinque-dieci casi scritti a mano, poi casi sintetizzati. Il valutatore è il più economico che si adatti: programmatico quando gli output sono vincolati, altrimenti un modello giudice con una checklist di affermazioni verificabili. Claude valuta alcuni casi e chiede se l'utente avrebbe giudicato diversamente, poi esegue la baseline con un intervallo di confidenza e tre verifiche: stabilità del valutatore, funzionamento tecnico, margine di miglioramento.

La seconda parte riguarda l'hillclimbing. È adatto a superfici economiche da modificare, il cui punteggio è attribuibile, con un obiettivo limitato; il costo è un buon obiettivo. Contro l'overfitting, tre salvaguardie: separare train e test, non incollare mai i fallimenti nel prompt, mantenere le risposte fuori portata. Il comando divide la valutazione, verifica che il rumore sia inferiore al guadagno ricercato, propone una patch per round e la annulla se il train aumenta da solo. In caso di stagnazione, classifica i fallimenti per causa prima di modificare.

Due esempi illustrano tutto ciò. Su un benchmark di assistenza di 44 ticket, il passaggio da Opus 4.8 a Opus 5.5 e poi a Sonnet 5 a basso impegno, con un prompt migliorato, produce 90,5% contro 78,6% sui ticket tenuti da parte, per circa un quinto del costo. Sullo skill claude-api, la valutazione passa dal 66% a circa l'88%: sezioni mancanti, tabelle di tipi, una tabella delle forme API deprecate, e correzioni a compiti e valutatori difettosi.

## 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/it/fiches/lancemartin-anthropic-automating-eval-design-hillclimbing-2026-09-28/