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

## Veille

Artículo de **Playbooks** de **Lance Martin**, publicado en el blog claude.dev el **28 de septiembre de 2026** (lectura de 12 minutos, nueve figuras). Presenta dos subcomandos añadidos a la skill **claude-api** de Claude Code, `/claude-api build-eval` y `/claude-api hillclimb`, tras exponer los principios que aplican. Tres aportes. **(A)** Cuatro propiedades de una buena evaluación: tareas representativas de producción, puntuaciones que aumentan con el modelo y el esfuerzo, margen de mejora por debajo del **100%** en la cima, baja varianza de una ejecución a otra; además del *muestreo adversarial*: un caso difícil se conserva porque un humano puede explicar por qué, no porque el modelo actual falle en él. **(B)** Hillclimbing disciplinado: un cambio por ronda, conjunto **train/test** separado, parche revertido si train sube mientras test se mantiene plano. **(C)** Dos ejemplos medidos: un benchmark de atención al cliente (**44** tickets) cuyo costo cae de alrededor de **4.6 a 1 centavo** por ticket, y la evaluación de la propia skill claude-api, de **66%** a aproximadamente **88%**. Una frase del texto: *"es importante leer una muestra de transcripciones puntuadas antes de confiar en el evaluador".* Relacionado con el artículo del autor sobre el almacenamiento en caché de prompts, [[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

evaluación, diseño de evaluaciones, hillclimbing, claude-api, build-eval, hillclimb, Claude Code, skill, muestreo adversarial, conjuntos train y test, sobreajuste de la evaluación, LLM-as-judge, evaluador programático, varianza, intervalo de confianza, margen de mejora, reducción de costo, esfuerzo, almacenamiento en caché de prompts, 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

**Perfil**: una guía práctica de ingeniería, escrita por un practicante de Anthropic para equipos que construyen una aplicación o skill sobre la API de Claude. Audiencia: desarrolladores y responsables de calidad de sistemas basados en LLM.

**Estilo**: dos partes simétricas (diseño de la evaluación, luego hillclimbing), cada una expone primero los principios y luego el comando que los aplica, seguido de dos ejemplos medidos. Listas numeradas, figuras esquemáticas, definiciones dadas sobre la marcha (harness, ruido). El texto presenta sus propias herramientas como la implementación de los principios que enuncia.

**Posición epistémica**: las cifras de ambos ejemplos provienen de benchmarks internos de Anthropic (atención al cliente, evaluación de la skill claude-api) y no son reproducibles a partir del artículo. El resultado de referencia es el del conjunto de test reservado (90.5% frente a 78.6%), con las puntuaciones del conjunto de investigación usadas para el ajuste.

## Pense-betes

- **Cuatro marcas de una buena evaluación.** Tareas extraídas de producción; una puntuación que aumenta con un modelo más fuerte y más esfuerzo; el mejor modelo claramente por debajo del 100%; baja varianza. Señal de alerta: una tarea que falla en todas las ejecuciones sin importar cuántas veces se repita probablemente sea ambigua o esté mal evaluada.
- **Criterio para una buena tarea.** Dos expertos del dominio llegan al mismo veredicto, y todo lo que verifica el evaluador está enunciado en la tarea. La varianza también puede provenir de la configuración (esfuerzo mal aplicado) o del entorno (estado residual, historial de git que entrega la respuesta).
- **Muestreo adversarial.** Elegir los casos en que falla el modelo actual equivale a muestrear los valles de un único modelo. Los casos conservados son los que un humano juzga difíciles, y los extraídos de bugs o tickets. El tráfico de usuarios sin filtrar puede sesgarse hacia lo fácil, ya que los usuarios tienden a intentar aquello en lo que esperan tener éxito.
- **`build-eval`, orden de las fuentes.** Transcripciones de producción (tras una pregunta sobre retención y datos sensibles), informes de bugs y tickets, cinco a diez casos escritos a mano, casos sintetizados a partir del código. Una página generada muestra todas las entradas y espera la confirmación del usuario.
- **Elección del evaluador.** El más barato que se ajuste: verificación programática si las salidas están acotadas; en caso contrario, LLM-as-judge con una lista de verificación de afirmaciones comprobables (no una escala del 1 al 5), un modelo juez distinto del modelo evaluado, y una comparación ciega en orden aleatorio frente a una referencia.
- **Comprobaciones diagnósticas sobre la línea base.** Evaluador repetido dos veces sobre la misma salida; fontanería (timeouts, errores de API, respuestas truncadas); margen de mejora, con una advertencia si la línea base supera aproximadamente el 95%, en cuyo caso se apunta al costo o a la latencia en su lugar.
- **Dónde aplicar el hillclimbing.** Una superficie barata de modificar (prompts, skills en lugar de código del harness), una puntuación atribuible a esa superficie (la tasa de activación de una skill y su descripción), un objetivo acotado. El costo es un objetivo robusto incluso en una evaluación saturada.
- **Tres salvaguardas contra el sobreajuste.** Separar train y test; nunca pegar el contenido de los fallos en el prompt; mantener las respuestas estructuralmente fuera del alcance del modelo. Ejemplos de filtración: una herramienta OCR añadida porque la evaluación resulta beneficiarse de ella, o un repositorio público del que el harness recupera la solución.
- **Bucle de `hillclimb`.** Elección de la superficie modificable (prompt del sistema, skills, descripciones de herramientas, modelo y esfuerzo, código del harness), un objetivo, una división aleatoria train/test, una comprobación previa de que el ruido es menor que la ganancia útil mínima. Cada ronda lee las transcripciones de train y propone un parche; se conserva si tanto train como test suben, se revierte en caso contrario. Entrega la versión con mejor puntuación en test, con intervalos de confianza; si la ganancia está dentro del ruido, la recomendación es no fusionarla.
- **Paso de reflexión.** Cuando la puntuación se estanca durante dos o tres rondas, no se edita nada: cada fallo restante se clasifica por causa. Este paso reveló contenido de la skill presente pero ignorado, a Claude escribiendo formas de API obsoletas extraídas de su entrenamiento (un presupuesto de razonamiento fijo en lugar de un razonamiento adaptativo), y tareas o evaluadores defectuosos.
- **Ejemplo de costo (atención al cliente).** 44 tickets, 30 para investigación y 14 reservados para test. Punto de partida: Opus 4.8 con esfuerzo alto, 74.4% de precisión, 4.6 centavos por ticket. Auditoría del prompt, luego Opus 5.5 con esfuerzo bajo (87.8%, 1.9 centavos), luego Sonnet 5 con esfuerzo bajo (88.9%, 1 centavo), finalmente un prompt mejorado (98.9%). En los 14 tickets reservados: 90.5% frente a 78.6%, por alrededor de un quinto del costo.
- **Ejemplo de rendimiento (skill claude-api).** De 66% a 74% al añadir ocho funciones faltantes, 77% tras corregir las tablas de tipos de C# y Java, 80% con una tabla de correspondencia de formas de API antiguas a nuevas, aproximadamente 88% tras corregir dos tareas y evaluadores defectuosos.

## RésuméDe400mots

Lance Martin, de Anthropic, publica una guía en el blog claude.dev sobre cómo diseñar evaluaciones y mejorar una aplicación o skill frente a ellas sin engañarse. Anuncia la incorporación de dos subcomandos a la skill claude-api de Claude Code: `/claude-api build-eval` construye una evaluación en el repositorio, `/claude-api hillclimb` mejora la aplicación frente a ella, un cambio a la vez, con un conjunto de ejemplos reservado para detectar el sobreajuste.

La primera parte enuncia cuatro propiedades de una buena evaluación. Las tareas reflejan la producción. Las puntuaciones aumentan con un modelo más capaz y mayor esfuerzo; de lo contrario, la culpa recae en tareas ambiguas o en un evaluador mal calibrado. El mejor modelo se mantiene claramente por debajo del 100%, sin que la brecha se deba a tareas imposibles: una tarea que falla en todas las ejecuciones es sospechosa, y una buena tarea es aquella en la que dos expertos llegan al mismo veredicto. Por último, la varianza es baja, lo que exige un evaluador estable, un esfuerzo aplicado de forma consistente y un entorno libre de estado residual. El autor añade una advertencia sobre el muestreo adversarial: elegir los casos en que falla el modelo actual mide su huella de fallos más que la dificultad real. Recomienda casos que un humano considere difíciles, fallos reales extraídos de tickets o bugs, señalando a la vez que el tráfico sin filtrar puede sesgarse hacia lo fácil.

`build-eval` interroga al usuario y luego construye la evaluación con pausas de aprobación. Las entradas provienen, en orden, de transcripciones de producción, tickets, cinco a diez casos escritos a mano y, después, casos sintetizados. El evaluador es el más barato que se ajuste: programático cuando las salidas están acotadas, o un modelo juez con una lista de verificación de afirmaciones comprobables en caso contrario. Claude puntúa algunos casos y pregunta si el usuario los habría juzgado de otra manera, luego ejecuta la línea base con un intervalo de confianza y tres comprobaciones: estabilidad del evaluador, fontanería, margen de mejora.

La segunda parte trata el hillclimbing. Conviene a superficies baratas de modificar, cuya puntuación sea atribuible, con un objetivo acotado; el costo es uno bueno. Contra el sobreajuste, tres salvaguardas: separar train y test, nunca pegar los fallos en el prompt, mantener las respuestas fuera de alcance. El comando divide la evaluación, comprueba que el ruido sea menor que la ganancia buscada, propone un parche por ronda y lo revierte si solo sube train. Ante el estancamiento, clasifica los fallos por causa antes de editar.

Dos ejemplos ilustran todo esto. En un benchmark de soporte de 44 tickets, pasar de Opus 4.8 a Opus 5.5 y luego a Sonnet 5 con bajo esfuerzo, con un prompt mejorado, da 90.5% frente a 78.6% en los tickets reservados, por alrededor de un quinto del costo. En la skill claude-api, la evaluación sube de 66% a aproximadamente 88%: secciones faltantes, tablas de tipos, una tabla de formas de API obsoletas, y correcciones a tareas y evaluadores defectuosos.

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