Бенчмарки не скажут, почему тупит ваш ИИ-агент. Google показала, как тестировать правильно

Команда Google Cloud Tech опубликовала разбор, который стоит прочитать всем, кто собирает агентов для программирования. Авторы, Тейлор Маллен и Крис Гандерман, начинают со знакомой боли: разработчик прогоняет агента через Terminal-Bench или DeepSWE, видит, что итоговый балл сдвинулся на пару процентов, и понятия не имеет, почему.

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

Большинство команд оценивают агента как студента на экзамене. Дают большой репозиторий, ставят ограничение по времени и считают, сколько тестов прошло. Балл упал, и что дальше? Модель стала слишком самоуверенной на расплывчатых запросах? Забыла прогнать тесты перед отправкой? Выдумала несуществующий флаг CLI? Итоговая оценка на эти вопросы не отвечает.

Поведенческие оценки работают как интеграционные тесты для обвязки агента, того самого harness. Вместо вопроса «справился ли агент с рефакторингом на десяток файлов» они проверяют конкретные наблюдаемые действия. Задаёт ли агент уточняющий вопрос, когда запрос сформулирован размыто, или начинает угадывать. Запускает ли локальный валидатор после правки файла сборки, прежде чем объявить задачу выполненной. Даёт ли канонические ссылки на репозиторий, когда пишет документацию. Если таких проверок набирается достаточно, у вас появляется эталон нужного поведения, и промпт можно улучшать итерациями, видя эффект каждой правки.

Больше экспертных разборов про ИИ и технологии, без воды и пересказов пресс-релизов, я публикую в своём Telegram-канале. Подписывайтесь, чтобы не пропустить следующий!

Интересная мысль авторов: не нужно строить сложную систему оценок в первый же день. На старте агент развивается за счёт инженерной интуиции и dogfooding, когда команда сама пользуется своим инструментом. Пока агент не умеет работать с собственной кодовой базой, генерировать шаблонный код, написать свой markdown-рендерер и закрывать рутинные задачи разработчика, запускать эвалы рано.

Их место на втором этапе, когда важно двигаться вперёд и не откатываться назад. Главная задача набора оценок не в том, чтобы радоваться плюс двум процентам. Она в том, чтобы дать железную уверенность: новая правка промпта, смена схемы инструментов или переход на свежую модель не сделали агента хуже в целом.

Надёжная система выносит поведенческие проверки в быстрые детерминированные тесты в духе юнит-тестов, которые запускаются локально. Проверяется не итоговая строка ответа, а промежуточные шаги: конкретные вызовы инструментов или изменения файлов. Пример такого теста Google написала для Antigravity SDK, код лежит в открытом репозитории на GitHub.

Самое любопытное начинается дальше. Когда проверок много, промпт-инжиниринг можно автоматизировать. Запускаете цикл, в котором LLM сама правит свой системный промпт, пока упавший тест не станет зелёным, а остальной набор тестов работает как защитный барьер в CI/CD и не даёт сломать то, что уже работало.

Авторы советуют начинать с малого и описывают цикл из трёх шагов. Сначала выберите один конкретный сбой. Например, агент недавно пометил задачу выполненной, не запустив юнит-тесты. Это и есть ваша цель.

Затем подберите строгость проверки под сложность задачи. Если у задачи одно оптимальное решение, достаточно жёсткого утверждения, что агент вызвал тест-раннер. В сложных задачах модель может пойти неожиданным, но вполне корректным путём, поэтому фиксированную последовательность вызовов лучше не навязывать. Здесь выручают более мягкие проверки по результату, например LLM-as-a-judge, которая оценивает, решил ли агент проблему правильно и безопасно.

И наконец, гоняйте оценки пачками. Модели недетерминированы, единичный прогон легко даёт шум, поэтому блокировать пулл-реквесты по одному запуску плохая идея. Гораздо полезнее следить за агрегированным процентом прохождения во времени. Такой сигнал позволяет спокойно менять промпты и обновлять модели, не останавливая разработку из-за ожидаемого разброса.

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

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

Оригинал статьи: Google Cloud Tech в X