Anthropic описала evals для ИИ-агентов: три типа грейдеров и SWE-bench с 40% до 80%

Anthropic опубликовала инженерное руководство по оценке ИИ-агентов, и главная мысль в нём приземлённая: без evals команда после первого выхода в продакшен начинает чинить одно и ломать другое. Агент вызывает инструменты, меняет состояние среды и подстраивается под промежуточные результаты на протяжении многих шагов, поэтому ошибки накапливаются. Оценка такой системы требует комбинации методов. Для иллюстрации авторы приводят цифры: на SWE-bench Verified модели прошли путь с 40% до более чем 80% за один год, а Bolt собрала рабочую систему оценок за три месяца.

Из чего состоит eval агента

Anthropic начинает с терминов, потому что в индустрии их используют вразнобой. Задача (task) — один тест с входными данными и критериями успеха. Каждая попытка называется trial, и их запускают несколько раз: выдача модели от прогона к прогону меняется. Грейдер (grader) — логика, которая оценивает отдельный аспект работы, в одной задаче их может быть несколько. Transcript — полный след попытки: сообщения, вызовы инструментов, рассуждения. Outcome — итоговое состояние среды.

Разница между последними двумя принципиальна. Агент бронирования может написать «Ваш рейс забронирован», но засчитывать нужно только наличие записи в SQL-базе. Ещё одно уточнение касается объекта измерения: оценивая агента, вы оцениваете связку модели и обвязки (harness), а не саму модель. В качестве примера авторы приводят случай с Opus 4.5 в тесте τ2-bench. Модель нашла лазейку в правилах бронирования рейса и по формальным критериям «провалила» задачу, хотя для пользователя придумала решение лучше.

Три типа грейдеров

Агентные evals обычно собирают из трёх видов проверок:

• Грейдеры на коде: строковые и regex-проверки, fail-to-pass тесты, статический анализ, проверка итогового состояния и вызовов инструментов. Быстрые, дешёвые, воспроизводимые, но хрупкие к корректным вариациям ответа. • Грейдеры на моделях: рубрики, утверждения на естественном языке, попарное сравнение, консенсус нескольких судей. Гибкие и масштабируемые, но недетерминированные, дороже и требуют калибровки по людям. • Человеческие грейдеры: экспертная проверка, краудсорсинг, выборочный контроль, A/B-тесты. Это золотой стандарт качества, но он медленный и дорогой.

Итоговая оценка задачи может быть взвешенной, бинарной (все грейдеры обязаны пройти) или гибридной. Вторая развилка: capability-evals и regression-evals. Первые должны стартовать с низкого pass rate и задавать команде склон, на который нужно подниматься. Вторые должны проходить почти на 100% и ловить откаты. Когда capability-набор насыщается, его задачи «выпускаются» в регрессионный пакет.

Кодинг и диалоговые агенты

Для кодинг-агентов естественны детерминированные проверки: код запускается, тесты проходят. SWE-bench Verified выдаёт агенту GitHub-issues из популярных Python-репозиториев и засчитывает решение, только если падавшие тесты починены, а существующие не сломаны. Terminal-Bench проверяет сквозные технические задачи вроде сборки ядра Linux из исходников или обучения ML-модели. Поверх тестов Anthropic советует оценивать transcript: эвристики качества кода и рубрики для поведения агента. В иллюстративном YAML для задачи «исправить обход аутентификации» собраны сразу все типы проверок, включая тесты, ruff, mypy, bandit и метрики числа ходов, токенов и задержек. На практике, оговаривают авторы, хватает юнит-тестов и LLM-рубрики по качеству кода.

Диалоговые агенты (поддержка, продажи, коучинг) отличаются тем, что качество самого взаимодействия входит в предмет оценки. Здесь опираются на проверяемое конечное состояние и рубрики, которые покрывают и выполнение задачи, и качество общения.

С чего начать

Аргументы в пользу evals у Anthropic практические. На ранней стадии они заставляют зафиксировать, что считается успехом: два инженера по одной спецификации по-разному поймут поведение в пограничных случаях. Позже они дают базовые линии по задержке, расходу токенов, стоимости задачи и доле ошибок. Они же ускоряют переход на новые модели: команды с evals оценивают сильные и слабые стороны за дни, остальные тестируют неделями.

Примеры из практики такие. Claude Code сначала развивался на обратной связи, затем получил evals по лаконичности и правке файлов, а потом по переусложнению решений. Descript оценивает агента по трём критериям: не ломай, делай что просили, делай хорошо. Команда перешла от ручной проверки к LLM-грейдерам с периодической человеческой калибровкой. Bolt начала поздно, когда агент уже был в массовом использовании.

Практический вывод: не ждите идеального набора. Возьмите задачи, на которых агент сейчас ошибается, и оформите их как capability-eval. Добавьте код-грейдеры на итоговое состояние среды. Подключайте LLM-судью только для того, что код проверить не может, и сверяйте его с оценками людей. Прогоняйте каждую задачу несколько раз, а прошедшие стабильно переносите в регрессионный пакет.