98,9% на экзамене и 90,5% на вопросах, которых модель не видела. Какой из этих цифр верить про вашу AI-функцию?

У каждого, кто встроил модель в продукт, был этот момент. Поменяли промпт, прогнали пять любимых примеров, стало лучше. Выкатили. Через неделю поддержка приносит тикет, который раньше решался правильно, а теперь нет.

Только «стало лучше» никто не измерял. Пять примеров, которые вы помните наизусть, промпт проходит и так: под них его и писали.

28 сентября Anthropic выложила разбор того, как строить такой экзамен и улучшать функцию против него, не обманывая себя. И добавила в скилл claude-api две подкоманды, которые делают это за вас: build-eval и hillclimb. Самое полезное в посте пример с двумя цифрами, которые пересказы уже успели перепутать.

Кому это нужно

Eval (набор проверок) имеет смысл там, где у вызова модели есть правильный ответ или хотя бы понятный критерий качества. Например:

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

В посте Anthropic как раз разбирается роутер писем. Если ваша функция похожа на что-то из этого списка, дальше про вас.

build-eval: экзамен собирается из ваших же данных

/claude-api build-eval начинает с интервью: Claude расспрашивает вас о функции, собирает набор прямо в репозитории и в нескольких точках ждёт вашего подтверждения.

1. 1

   Примеры

   Порядок приоритета: транскрипты из продакшена (сначала Claude спросит про хранение и чувствительные данные), потом баг-репорты и тикеты поддержки, потом 5–10 кейсов, которые вы пишете руками, и только потом кейсы, синтезированные из кода. Синтетика допустима, но опирается на несколько ваших настоящих примеров.

2. 2

   Страница проверки входов

   Скилл делает простую страницу со всеми входами и ждёт, пока вы их подтвердите.

3. 3

   Проверяющий

   Claude предлагает самого дешёвого проверяющего (grader), который подходит под формат ответа. Подробнее ниже.

4. 4

   Проверка проверяющего

   Claude оценивает несколько кейсов сам и спрашивает, оценили бы вы какой-то из них иначе.

5. 5

   Размер и базовый прогон

   Скилл называет размер прогона (кейсы × повторы × модель и примерное время), запускает текущую версию и печатает результат с доверительным интервалом.

6. 6

   Диагностика

   Во время базового прогона grader запускается дважды на одном и том же ответе, проверяются таймауты, ошибки API и обрезанные ответы. Если база уже около 95% и выше, скилл предупредит, что расти по качеству некуда.

Когда базовая версия уже набирает около 95%, улучшать качество бессмысленно: любое изменение тонет в шуме. Скилл в таком случае советует целиться в цену или задержку.

Какого проверяющего выберет Claude

Если ответов немного и они ограничены, проверка пишется кодом: точное совпадение, метка из фиксированного списка, JSON по схеме, проходящие тесты. Это дёшево и не спорит само с собой.

Если верных ответов много, но критерий ясен, включается LLM-as-judge: вторая модель читает вход, выход и рубрику. Рубрика пишется проверяемыми утверждениями, а не шкалой от 1 до 5. Если есть базовая версия для сравнения, судья вслепую выбирает лучший из двух ответов, поданных в случайном порядке. Модель-судью выбираете вы, и это не должна быть та модель, которую проверяют. Тот же принцип «кто сделал, тот не принимает» мы видели в скилле аудита безопасности Cloudflare.

В репозитории после build-eval остаются кейсы, grader, скрипт прогона (runner), по одной строке JSON и одному полному транскрипту на кейс и страница report.html со списком оценок и ссылкой на транскрипт каждого кейса. Если нужен график, попросите, и Claude сделает его отдельной страницей рядом. Такие страницы по умолчанию статические: открываются локально и ничего не грузят из сети.

hillclimb: одно изменение за раунд

/claude-api hillclimb берёт готовый eval и улучшает функцию против него. Что именно можно менять, решаете вы: системный промпт, скиллы и файлы инструкций, описания инструментов, модель, effort и другие параметры API, код обвязки. Цель тоже ваша: качество или цена при том же качестве.

1. 1

   Деление на train и test

   Набор случайно делится на две части. По train Claude ищет улучшения, test он не видит.

2. 2

   Проверка шума

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

3. 3

   Раунд

   Claude читает транскрипты train прошлого раунда и предлагает одно изменение патчем. Целится в корень сбоя: переписать раздел, добавить недостающее правило, а не переставить слова в строке.

4. 4

   Решение

   Выросли и train, и test: патч остаётся. Вырос только train, а test стоит: подозрение на подгонку, откат. Стало хуже: откат.

5. 5

   Застой

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

6. 6

   Финал

   Код остаётся в версии, лучшей на test для вашей цели. Отчёт сравнивает test с базой с доверительными интервалами. Если прирост в пределах шума, Claude прямо советует не мержить.

Кроме деления на train и test, у скилла есть ещё две защиты от подгонки. Содержимое провалов никогда не вставляется в промпт: иначе модель выучит ответы на экзамен. И правильные ответы держатся вне досягаемости модели, потому что модели иногда находят их напрямую.

Пример Anthropic: какая цифра настоящая

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

Путь выглядел так. Сначала аудит промпта: убраны обязательные «ритуалы» с вызовами инструментов, шаг с черновиком (scratchpad) и противоречивые правила. Затем Opus 5.5 на low effort: 87,8% и 1,9 цента. Затем ступенью ниже, Sonnet 5 на low effort: 88,9% и около цента. И наконец правила маршрутизации и перекрёстная ссылка на лимит возврата в промпте: Sonnet 5 поднялся до 98,9% примерно по той же цене.

На этой цифре пересказы и ошибаются: 98,9% это результат на тех 30 тикетах, по которым шёл поиск и которые hillclimb читал раунд за раундом.

Честный результат во второй колонке. На тикетах, которых поиск не видел, точность выросла с 78,6% до 90,5%, а цена упала примерно в пять раз. Это хороший результат. Но разрыв между 98,9% и 90,5% и есть та подгонка, ради которой test вообще существует. Подавать 98,9% как итог значит повторить ту самую ошибку, от которой скилл защищает.

Часть экономии дали сами цены: у Opus 5.5 входные и выходные токены на 20% дешевле, чем у Opus 4.8, а чтение кэша на 60%. Почему цена задачи не равна цене токена, мы разбирали в сравнении GPT-6 Sol и Opus 5.5.

Второй пример: скилл, который улучшал сам себя

Anthropic прогнала hillclimb и на самом скилле claude-api. Eval собрали из документации: он проверяет, правильно ли скилл пишет код под их API. За 24 раунда результат вырос с 66,1% до 87,9%, и находки по дороге интереснее самой цифры.

Сначала Claude нашёл, что в скилле не хватает восьми фич. Разделы про них дали 74%, исправление таблиц типов для C# и Java дало 77%. Потом балл встал на два раунда, и разбор провалов по причинам показал: нужное в скилле уже есть, но Claude пишет старые формы API по памяти. В начало скилла добавили таблицу «как ты помнишь → как сейчас», например от extended thinking с фиксированным бюджетом к adaptive thinking. Стало 80%.

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

Где это не сработает

Ограничения Anthropic называет сама, и их стоит прочитать до запуска.

• Eval не равен продакшену. Пример из поста: eval выигрывает от распознавания текста на картинках, hillclimb добавляет в обвязку OCR, балл растёт, а в продакшене OCR почти не нужен.
• Нужен запас. У самой сильной модели на максимальном effort результат должен быть заметно ниже 100%, иначе изменения не с чем сравнивать.
• Не набирайте кейсы по провалам сегодняшней модели. Так eval начнёт мерить слабые места одной модели, а не то, что трудно для вашей задачи. Пользовательский трафик тоже бывает смещён в простое: люди пробуют то, что, по их мнению, сработает.
• Шум прячется в окружении. Файл или история git, оставшиеся от прошлого прогона, могут подсказать агенту ответ.
• Открытая просьба «улучши обвязку» застревает. Hillclimb лучше работает там, где изменение дешёвое и балл можно приписать правке: промпты, скиллы, описания. Сколько вообще стоит обвязка вокруг модели, показало исследование HarnessTax.
• Цифры обоих примеров с внутренних бенчмарков Anthropic. На вашем продукте они будут другими.

Как запустить у себя

Скилл claude-api поставляется внутри Claude Code, поэтому отдельно его ставить не нужно. Обновитесь и вызовите подкоманды:

$ claude update
> /claude-api build-eval
> /claude-api hillclimb

build-eval можно направить, дав доступ к примерам, например к трейсам. hillclimb запускайте, когда eval уже есть, и сразу назовите цель: качество или цена при том же качестве.

Отдельной цены у команд нет. Платите за токены прогонов eval по обычным тарифам API, а размер прогона и примерное время скилл называет до базового запуска. Конкретную сумму за прогон Anthropic не называет: она зависит от числа кейсов, повторов и модели. С версии 2.1.285 /claude-api нельзя запускать из клиентов Remote Control. В той же версии ответы, обрезанные по max_tokens, помечаются как truncated и считаются отдельно, а не портят среднее.

Наше мнение: начинать стоит не с hillclimb, а с build-eval и честного взгляда на страницу с оценками. Если вы прочитаете десяток оценённых транскриптов и не согласитесь с проверяющим, никакие раунды после этого не помогут. Anthropic пишет то же самое: ошибки в оценке входят в число самых частых причин, по которым eval настроен неправильно.