Оценки агентов: как понять, что агент справился

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

Итог работы — это состояние среды: изменённый файл, созданная бронь, выполненные условия задачи. Траектория сохраняет действия, вызовы инструментов и промежуточные ответы. Она помогает понять причину неудачи, но убедительное финальное сообщение не заменяет проверки результата. В примере с MCP-сервером важно увидеть не только чтение документации и запуск тестов, но и то, что получившееся решение удовлетворяет задаче.

Внутри обвязки для оценивания работает агент: модель вместе с инструментами, контекстом, планированием и ограничениями. Внешняя система запускает задачи, собирает траектории, вызывает проверяющих и сводит результаты. Сравнивать следует зафиксированные конфигурации целиком. Смена модели, инструкции или способа сжатия контекста может изменить поведение, даже если остальные части остались прежними.

Набор состоит из задач с исходными данными и критериями успеха. У задачи может быть несколько попыток и несколько проверяющих. Ведущий иллюстрирует различие ста запусков: двадцать задач по пять попыток показывают разброс внутри задачи, а сто разных задач по одной — разнообразие работы. Эти схемы отвечают на разные вопросы. Для недетерминированного агента один удачный прогон не устанавливает стабильность, а одинаковое число запусков не означает одинакового покрытия.

Программные проверки быстры и удобны там, где условие можно выразить точно. Их слабость — хрупкость при допустимых вариациях результата. Модельный судья позволяет оценить открытый ответ, ясность или качество объяснения, но добавляет собственную недетерминированность и требует калибровки. Экспертная оценка помогает проверить такую систему, однако стоит времени и денег; нужный специалист может быть недоступен. Практический порядок — код для формальных условий, модели для остальных необходимых критериев и люди для проверки качества оценивания.

Одного числа часто мало. В поддержке агент может определить проблему и проверить пользователя, но не выполнить возврат. Частичная оценка показывает, где остановилась работа. Отдельно полезны затраты токенов, вызовы инструментов и длительность. Для диалогового агента важен ход взаимодействия с пользователем; для исследовательского — обоснованность тезисов, полнота и качество источников. Эти требования нельзя заменить одной универсальной проверкой финального текста.

Здесь ведущий возвращается к выпуску №26 с Евгением Сергеевым об оценках и к №21 о SWE-Interact и SWE-Together: диалог с разработчиком меняет условия проверки кодингового агента. Пример среды, в которой агент не видит окно или не слышит звук, продолжает обсуждение автономной разработки приложений из №36.

Метрика pass@k отвечает, удалась ли хотя бы одна из k попыток. Она полезна, когда повторные запуски допустимы, а правильный результат можно достаточно дёшево распознать. Метрика pass^k требует успеха во всех k попытках и характеризует стабильность. Вторая особенно важна там, где каждую ошибку трудно обнаружить до того, как результат будет использован.

В иллюстрации при вероятности успеха одной попытки 75% три независимых запуска дают около 98% вероятности хотя бы одного успеха, но лишь около 42% вероятности трёх успехов подряд. Независимость — условие примера, а не установленное свойство реальных прогонов. Ведущий отдельно оговаривает эту границу. Поэтому красивый рост pass@k нужно соотносить со стоимостью повторов и надёжностью отбора: без проверяющего дополнительные ответы сами по себе не решают проблему доверия.

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

Нужны и отрицательные случаи. Если поощрять веб-поиск только в задачах, где он требуется, система может вознаграждать поиск повсюду. Примеры, в которых искать не нужно, делают критерий содержательным. Каждая попытка должна начинаться с чистого состояния, без следов соседних прогонов и доступа к ответам через историю репозитория. Среда должна также давать агенту нужную обратную связь: невидимое браузерное окно или недоступный звук ограничивают то, что он способен проверить.

Критерии модельного судьи полезно разделять: эмпатия, ясность ответа и соблюдение политики компании — разные свойства. Затем следует читать траектории и сопоставлять действия агента с решением проверяющего. Причина провала может находиться в агенте, ограничениях обвязки, нестабильной среде, неоднозначной задаче или ошибочном эталоне. Исправлять нужно обнаруженную причину, а не только добиваться роста общего показателя.

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

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

Эпилог расширяет вопрос доверия. В обсуждении Petri v2 возникает риск изменения поведения моделью, распознавшей проверку. Исследование автономности переносит внимание на реальные сессии, где результат зависит также от пользователя и устройства продукта. А разбор регрессий Claude Code напоминает, что настройки рассуждений, очистка истории и инструкция о краткости могут ухудшать работу. Даже развитые оценки не находят все проблемы заранее: их нужно постоянно сопоставлять с происходящим у пользователей.

В финале замыкается цепочка разборов обвязки: №33 — интерфейс SWE-agent; №34 — передача работы между сессиями; №35 — среда репозитория; №36 — роли планировщика, исполнителя и оценщика; №38 — эксперименты с планом, инструментами и сжатием контекста; №41 — архитектура по исходному коду. Текущий выпуск добавляет к устройству системы проверку её результата. Ссылки на упомянутые выпуски собраны ниже; отметки времени относятся к аудиозаписи Podster.