Автоматический дизайн eval и hillclimbing — как улучшать модель, не обманывая себя
Саммари
Оценки (evals) дают сигнал о том, как приложение справляется со своими задачами, но придумать хорошую eval — и улучшаться против неё, не обманывая себя, — сложно. Anthropic описала принципы проектирования eval и hillclimbing'а и встроила их в claude-api skill: команда /claude-api build-eval строит eval прямо в кодовой базе после интервью с вами, а /claude-api hillclimb улучшает приложение по одному изменению за раз с отложенным набором примеров против переобучения. Два внутренних прогона дают цифры: бенчмарк поддержки вырос с 74,4% до 98,9% точности при падении стоимости с 4,6 цента до около 1 цента за тикет.
Из этого следует, что главный риск eval — не «плохая метрика», а незаметное измерение самой модели: набор случаев, снятый по её текущим падениям, превращается в тест на знакомые слабости, а не на ценность задачи для продукта.
На практике правило «шум eval должен быть меньше минимального заметного улучшения» экономит недели: оно переводит спор «метод работает или нет» в арифметику повторов и размера выборки — тот же приём нужен при оценке любых агентных пайплайнов, включая Revit-инструменты.
Важный нюанс: откат при «train вырос, test плоский» и отложенная выборка — дешёвая страховка от переобучения, которая не требует дополнительной инфраструктуры: случайный сплит уже встроен в команду hillclimb.
Ограничение: цифры получены на внутренних бенчмарках Anthropic и их моделях; кейс поддержки мал (44 тикета), а выигрыш частично объясняется изменением модели и прайсинга — переносить надо метод (сплит, шум, откат), а не абсолютные проценты.