Claude automatiza evals y hill-climbing
ClaudeAI evalshill-climbing
Dos comandos cierran el ciclo de evaluación y mejora
El cambio principal es sencillo: Claude integra el diseño de evals y la optimización de aplicaciones en un único ciclo repetible. La publicación oficial de Claude, Automating eval design and hillclimbing with Claude, describe dos comandos: /claude-api build-eval y /claude-api hillclimb.
El primero crea un conjunto de evaluaciones dentro de la base de código. La documentación de Claude menciona comprobaciones de coincidencia exacta, validación mediante código y evaluación con LLM, además de respuestas de referencia y métricas como precisión y latencia. Así, un eval no es una hoja de cálculo separada que se consulta antes del lanzamiento, sino una parte del proyecto activo.
El segundo comando modifica la aplicación de forma iterativa y mide el resultado con las pruebas ya creadas. Según los materiales de Claude Platform, la búsqueda puede abarcar prompts de sistema, elección de modelo, nivel de esfuerzo y otros parámetros de API. No se entrenan los pesos del modelo: se automatiza la búsqueda de la mejor configuración a su alrededor.
Hay un detalle decisivo: los datos se dividen entre train y test, y el resultado final se valida en una muestra reservada. Sin esta protección, hill-climbing podría aprender rápidamente a ganar en ejemplos concretos sin mejorar el comportamiento global del sistema.
A 30 de septiembre de 2026, interpreto esta publicación como una explicación de una metodología de ingeniería, no como un lanzamiento fechado, porque la descripción original no indica una fecha de anuncio. La idea, sin embargo, ya es práctica a nivel de arquitectura de procesos.
Optimizar prompts se convierte en un problema de búsqueda
La consecuencia principal es que mejorar una aplicación de IA puede pasar de una serie de retoques subjetivos a un ciclo medible. El enfoque encaja especialmente bien en tareas con entradas reproducibles, resultados verificables y una función de evaluación estable.
Yo revisaría primero tres puntos: la fuga de ejemplos entre train y test, la inestabilidad del evaluador LLM y la relación entre la métrica y la calidad real. Si la rúbrica es débil, hill-climbing optimizará con gran disciplina lo equivocado. También es esencial incluir coste, latencia y errores; de lo contrario, ganará una configuración buena en un único indicador.
No es un botón mágico para mejorar Claude, sino una forma de hacer los experimentos reproducibles y menos dependientes del gusto de quien escribe el prompt. El componente más difícil sigue siendo el mismo: el sistema solo será tan inteligente como lo sea la formulación honesta de su eval.