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.