Claude Code урезал счёт за тикет примерно до пятой части

Anthropic 29 сентября добавила в навык claude-api для Claude Code две команды. /claude-api build-eval собирает эвал прямо в вашей кодовой базе, а /claude-api hillclimb улучшает приложение на этом эвале по одному изменению за раунд и сверяется с отложенной частью примеров, которую оптимизатор не видит.

В блоге Claude показан результат на внутреннем бенчмарке поддержки. На отложенных тикетах итоговая настройка на Sonnet 5 набрала 90,5%, исходная на Opus 4.8 набирала 78,6%, а стоила новая настройка примерно пятую часть прежней цены.

Навык claude-api поставляется вместе с Claude Code и лежит в открытом репозитории навыков Anthropic, откуда его можно поставить в любую среду с поддержкой Agent Skills, говорится в документации платформы. Подкоманды под отдельные задачи у него были и раньше, например preserved-thinking-migration и managed-agents-onboard. Ещё одна команда, claude plugin eval, измеряет вклад плагина, прогоняя каждый тест с ним и без него. Новая пара нацелена на само приложение.

Что считается хорошим эвалом

Прежде чем описать команды, Anthropic формулирует четыре требования к эвалу. Задачи должны отражать то, что приложение делает в продакшене, даже если их труднее сгенерировать или оценить. Более сильная модель и более высокий effort должны набирать больше; если этого не происходит, мешают, как правило, двусмысленные задачи или плохо откалиброванный грейдер. Лучшая модель на максимальном effort должна оставаться заметно ниже 100%, иначе влияние изменений не измерить. И разброс между прогонами должен быть низким.

Запас до потолка не должен объясняться невыполнимыми задачами. Типичный признак такой задачи: она проваливается в каждом прогоне, сколько повторов ни делай. Критерий годной задачи сформулирован так: «два эксперта в предметной области пришли бы к одному вердикту, а всё, что проверяет грейдер, сказано в самой задаче».

Разброс прячется не только в задачах. Effort может применяться непоследовательно, а остатки предыдущего прогона в окружении, будь то файл или история git, способны подсказать агенту ответ.

Отдельно разобрана ловушка состязательной выборки. Способности модели неровные, и если отбирать кейсы потому, что сегодняшняя модель на них ошибается, в эвал попадают провалы одной конкретной модели. Такой эвал измеряет её «отпечаток ошибок», а не то, что действительно трудно или ценно для приложения. Совет Anthropic: брать кейсы, которые трудными признал человек, и до включения в набор уметь объяснить, чем задача трудна. Реальные сбои из продакшена, баг-репортов и тикетов тоже нужны. Но слепо доверять пользовательскому трафику не стоит: люди чаще пробуют то, что, по их ожиданиям, сработает, и набор только из трафика может оказаться слишком лёгким.

Как работает build-eval

Команда начинает с интервью, а примеры собирает в фиксированном порядке. Первыми идут транскрипты из продакшена, и перед этим Claude спрашивает о сроках хранения данных и чувствительной информации. Дальше баг-репорты и тикеты поддержки, пять-десять кейсов, которые пользователь пишет руками, и в последнюю очередь кейсы, синтезированные по кодовой базе. Синтетика возможна и на основе нескольких реальных примеров. Все входные данные Claude выводит на простую страницу и ждёт подтверждения; в качестве иллюстрации приведена такая страница для приложения, которое раскладывает входящую почту.

Грейдер выбирается самый дешёвый из подходящих. Если вариантов ответа немного, хватает проверки кодом: точное совпадение, метка из фиксированного набора, JSON по схеме, прохождение тестов. Для открытых ответов, где верных вариантов много, а критерии качества ясны, по умолчанию берётся LLM-as-judge. Вторая модель читает вход, выход и рубрику, а возвращает балл с обоснованием. Рубрика при этом состоит из проверяемых утверждений вместо шкалы от 1 до 5. Если есть базовый вариант для сравнения, судья видит оба ответа в случайном порядке и не знает, какой из них базовый. Модель-судью выбирает пользователь, и она не должна совпадать с тестируемой.

Затем Claude сам оценивает несколько кейсов и спрашивает, поставили бы вы где-то другую оценку. По словам авторов, ошибки оценивания относятся к самым частым причинам неправильно настроенного эвала, поэтому выборку оценённых транскриптов стоит прочитать до того, как верить грейдеру.

После согласования грейдера навык называет размер прогона (кейсы, повторы и модели, плюс примерное время), запускает базовый прогон и выводит балл с доверительным интервалом. На выходе получаются кейсы, грейдер, раннер, по одной строке JSON и одному полному транскрипту на кейс и страница с баллом каждого кейса и ссылкой на транскрипт. Графики и прочее Claude строит по запросу отдельными страницами; по умолчанию это статические файлы, которые открываются локально и ничего не грузят из сети.

Во время базового прогона идут три проверки. Грейдер дважды оценивает один и тот же выход, и Claude сообщает, изменился ли вердикт. Таймауты, ошибки API и обрезанные ответы отлавливаются отдельно, чтобы шум инфраструктуры не сошёл за разброс модели. А если базовый балл уже около 95% или выше, навык предупреждает, что хиллклайминг стоит направить на стоимость или задержку вместо качества.

Один патч за раунд

Хиллклайминг, пошаговый подбор с сохранением только удачных шагов, Anthropic советует применять там, где правки дешёвые и легко откатываются. Чаще всего это текст: промпты и навыки. Свободные переделки обвязки агента, наоборот, тянут за собой много кода. Изменение балла должно объясняться той поверхностью, которую правят. Среди удачных случаев названа настройка срабатывания навыков, где метрика (как часто навык срабатывает) напрямую зависит от его описания. Открытая просьба «улучши производительность» на почти насыщенном эвале обычно буксует. Цель, которая хорошо работала в разных проектах, - стоимость: даже на насыщенном эвале можно искать, как удешевить приложение без потери качества.

Через /claude-api hillclimb Claude может менять системный промпт, навыки и файлы инструкций, описания инструментов, модель, effort и другие параметры API, а также код обвязки. Что из этого разрешено, решает пользователь. Сначала Claude спрашивает о цели (качество или стоимость при сохранении качества) и случайно делит эвал на обучающую и тестовую части. При цели на стоимость он смотрит на кэширование промптов, проверяет, подходит ли промпт выбранной модели, и подбирает модель и effort.

До первого раунда Claude сверяет шум эвала, на сколько балл может сдвинуться по чистой случайности, с минимальным улучшением, ради которого вы стали бы что-то менять. Если шум больше, он об этом говорит и предлагает добавить повторы или кейсы.

В каждом раунде Claude читает обучающие транскрипты прошлого раунда и предлагает одно изменение в виде патча. Патч должен давать эффект заметнее шума, поэтому Claude чинит причину сбоя в корне: переписывает виновный раздел или добавляет недостающее правило вместо перефразирования одной строки. Дальше правила простые:

• обучающая часть выросла, тестовая стоит на месте: подозрение на переобучение, патч откатывается;
• есть регрессия: патч откатывается;
• выросли обе части: патч остаётся.

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

Даже хорошо сделанный эвал редко точно совпадает с распределением задач в продакшене, поэтому переобучение на нём, по словам авторов, частая проблема. Пример: задачам эвала помогает OCR, а в продакшене он почти не нужен. Хиллклаймер добавит в приложение OCR-инструмент, балл вырастет, а на реальной работе ничего не изменится. Отсюда ещё два правила помимо разделения выборки: содержимое проваленных транскриптов никогда не вставляется в промпт, а ответы конструктивно держатся вне досягаемости модели, которая иначе может найти их напрямую.

44 тикета поддержки

Первый пример - внутренний бенчмарк поддержки Anthropic с целью снизить стоимость и поднять качество. Из 44 тикетов 30 ушли на поиск, а 14 были отложены. Старт: Opus 4.8 на effort по умолчанию (high), 74,4% точности решений на поисковых тикетах и 4,6 цента за тикет.

Сначала хиллклаймер провёл аудит промпта и убрал обязательные ритуальные вызовы инструментов, шаг с черновиком и противоречивые правила. Затем попробовал Opus 5.5 на low: 87,8% и 1,9 цента за тикет, меньше половины исходной цены. Часть экономии даёт сам прайс: у Opus 5.5 входные и выходные токены на 20% дешевле, чем у Opus 4.8, а чтение кэша на 60% дешевле.

Раз Opus 5.5 прошёл планку, хиллклаймер спустился на ступень ниже. Sonnet 5 на low набрал примерно столько же, 88,9%, примерно за 1 цент за тикет. Правила маршрутизации и перекрёстная ссылка на лимит возвратов в промпте подняли Sonnet 5 до 98,9% на поисковых тикетах примерно при той же цене.

На отложенных тикетах итоговая конфигурация показала 90,5% против 78,6% у исходной. Отложенная часть при этом всего 14 тикетов.

Навык на собственном эвале

Во втором примере Anthropic гоняла хиллклаймер на самом навыке claude-api, по эвалу из задач, составленных по документации: навык должен помогать писать рабочий код под API. Старт был 66%. Хиллклаймер получил доступ к документации и SDK, нашёл восемь функций, которые навык не покрывал, и после новых разделов о них балл вырос до 74%. Исправленные ошибки в таблицах типов для C# и Java дали 77%.

Потом балл два раунда стоял, и включился разбор провалов по причинам. Обычный раунд вносит одну правку под самый частый сбой, а этот шаг ничего не правит и только сортирует. Выяснилось, что нужный материал в навыке есть, но Claude по привычке из обучения пишет старые формы API. Хиллклаймер поставил в начало навыка таблицу соответствий: от extended thinking с фиксированным бюджетом токенов, который API на свежих моделях Opus теперь отклоняет, к adaptive thinking, от старых версий инструментов web search и web fetch к текущим. Предупреждения против фиксированного бюджета в разделах C# и Java переехали выше примеров с adaptive thinking. Балл поднялся до 80%.

Задачи, которые не сдвинулись даже после закрытия очевидных пробелов, указали на дефекты самого эвала. В одной задаче просили код, перехватывающий один тип ошибки, а грейдер требовал цепочку минимум из трёх, и Claude переформулировал задачу. Инструкции ещё одного грейдера противоречили документации Anthropic, и проверка на живом API показала, что права документация. После этих исправлений и новых правок навыка балл дошёл примерно до 88%.