Claude автоматизирует evals и hill-climbing

Две команды замыкают цикл оценки и улучшения

Для меня главный сдвиг здесь простой: Claude сводит проектирование evals и оптимизацию приложения в один повторяемый контур. В официальной публикации блога Claude Automating eval design and hillclimbing with Claude описаны две команды: /claude-api build-eval и /claude-api hillclimb.

Первая создаёт набор проверок внутри кодовой базы. В документации Claude для таких наборов перечислены точное совпадение, проверки кодом и оценивание с помощью LLM, а также эталонные ответы и метрики вроде точности и задержки. То есть eval здесь не отдельная таблица, которую вспоминают перед релизом, а часть рабочего проекта.

Вторая команда итеративно меняет приложение и оценивает результат по уже созданным тестам. Согласно материалам Claude Platform, поиск может затрагивать системные промпты, выбор модели, уровень усилий и другие параметры API. Это не обучение весов модели, а автоматизированный перебор конфигурации вокруг неё.

Критичная деталь: данные разделяются на train и test, а финальный результат проверяется на отложенной выборке. Без этого hill-climbing быстро научился бы выигрывать конкретный набор примеров, не улучшая поведение системы в целом.

На 30 сентября 2026 года я рассматриваю эту публикацию как разбор инженерной методики, а не как датированный релиз: исходное описание не указывает дату анонса. Сама идея при этом вполне практична уже на уровне архитектуры процесса.

Настройка промптов становится задачей поиска

Главное последствие такое: улучшение AI-приложения можно превратить из серии субъективных правок в измеримый цикл. Особенно хорошо схема ложится на задачи с воспроизводимыми входами, проверяемыми результатами и стабильной функцией оценки.

Я бы первым проверил три места: утечку примеров между train и test, нестабильность LLM-грейдера и соответствие метрики реальному качеству. Если рубрика слабая, hill-climbing будет очень дисциплинированно оптимизировать не то. Добавление стоимости, задержки и ошибок в оценку тоже принципиально, иначе победит конфигурация, хорошая только по одному показателю.

Это не магическая кнопка улучшения Claude, а способ сделать эксперименты воспроизводимыми и меньше зависеть от вкуса автора промпта. Самый трудный компонент остался прежним: система становится настолько умной, насколько честно сформулирован её eval.

Ранее мы разбирали, как измерять надёжность LLM-as-a-Judge с помощью метрик IRT. Этот подход помогает проверить, отражают ли улучшения автоматических evals стабильный рост качества, а не шум оценивания.