Как оценивать AI-агентов: от красивого ответа к воспроизводимому инженерному эпизоду

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

Главный сдвиг для меня в том, что зрелую оценку агента бессмысленно сводить к таблице лидеров. Это скорее инженерная система качества, и считать в ней надо не отдельные вопросы и финальные ответы, а целые воспроизводимые эпизоды работы.010101Ровно про это был эфир Research Insights #21 — оценка кодинговых агентов в диалоге, SWE-Together против SWE-INTERACT. Анонс с тезисами — в «Книжном кубе», там же после эфира появились материалы.Книжный куб · Research Insights #21

Хороший сценарий оценки агента — это, по сути, маленькая замороженная копия реальной работы. В нём есть исходное состояние, контракт агента и набор разрешённых инструментов, скрытая проверка, трейс действий и измеримая цель.

В бенчмарках разработки эта логика давно стала почти стандартом. SWE-bench берёт реальные задачи GitHub и смотрит, может ли модель починить репозиторий так, чтобы прошли тесты. FEA-Bench сдвигает фокус с ошибок на реализацию функций: не просто починить, а реализовать функцию из реальной истории PR. Шаг важный, потому что в рабочей среде работа агента почти никогда не выглядит как изолированная задачка — обычно это задача плюс весь контекст репозитория: ограничения, тесты, локальные команды, проверка и несколько итераций поверх.

Но и этого мало. У агента надо фиксировать не только финальное изменение, но и всю траекторию — как именно он к нему пришёл. GitHub в разборе офлайн-оценивания MCP Server отдельно оценивает выбор инструментов и корректность аргументов. Звучит как техническая мелочь, но именно здесь прячется куча риска: агент может дёрнуть не тот инструмент, вызвать его с опасными параметрами, случайно угадать правильный ответ или потратить десяток лишних шагов на элементарную задачу.020202Google в аналитическом докладе про новый SDLC формулирует это же различие: тесты — для детерминированных выходов, оценивание — для траекторий и выбора инструментов, а верификация — новое бутылочное горлышко. Разбирал в двух частях.Книжный куб · Google New SDLC, часть 1Книжный куб · Google New SDLC, часть 2

Минимальный эпизод оценки я бы описал примерно так:

episode_id: "feature-checkout-discount-014"
start_state: "repo commit, tickets, docs, fixtures, test environment"
input_bundle: "business goal, acceptance criteria, constraints"
agent_contract: "allowed tools, permissions, time budget, write policy"
hidden_judge: "tests, policy checks, expected state, review rubric"
trace_checks: "tool choice, arguments, unsafe calls, unnecessary steps"
release_gate: "pass threshold, repeatability, cost ceiling, safety stop"

За этим скелетом — несколько свойств, без которых эпизод оценки разваливается.

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

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

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

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

Остаётся свежесть. Статичные публичные наборы быстро загрязняются: задачи утекают в обучающие данные, вокруг них нарастает обвязка, подсказки, неявная подгонка. Поэтому нужны разбиения по времени и проектам и живой обновляемый набор. SWE-bench Live решает это для задач по коду, а Microsoft в работе про непрерывное обновление бенчмарков формулирует тот же принцип шире, для корпоративных агентов: бенчмарк должен обновляться вместе с рабочей средой.030303Хороший свежий заход на ту же проблему — SWE-rebench от Nebius: свежие задачи GitHub против загрязнения, обнаружение подгонки под награду и стабильность по сериям прогонов. Разбирал в канале.Книжный куб · SWE-rebench

В SDLC удобно начинать с кода — там проще всего сделать исполняемую проверку. Но если агент претендует на автономность в разработке, мерить придётся весь путь, от требований до эксплуатации.

Начнём с требований. Единица оценки здесь — не команда «напиши PRD», а цепочка прослеживаемости: бизнес-описание, заметки исследования, разговор с заинтересованными сторонами, утверждённые требования, критерии приёмки, нефункциональные требования и то, что из всего этого затем собирается в реализацию. Хорошая проверка смотрит на полноту, корректность, тестируемость, выдуманные требования, покрытие нефункциональных требований и на то, годится ли результат следующему агенту или живой команде.

Дальше — реализация функции, и тут схема ближе всего к FEA-Bench: задача или спецификация, коммит до PR, скрытые функциональные и интеграционные тесты и безопасность на полном прогоне. С исправлениями ошибок тоньше: нужен коммит с ошибкой, задача, трейс стека или падающее поведение, а проверка обязана показать, что баг воспроизвёлся и исчез, а соседние сценарии не поехали. И тут опасно подменять качество одним публичным регрессионным тестом — слабая проверяющая программа почти неизбежно начинает пропускать неверные изменения.

Проверка кода — отдельная история. Оценивать надо не красоту комментария, а то, ловит ли агент дефекты, которые реально влияют на качество слияния. SWE-PRBench строит такую оценку вокруг настоящих PR и размеченных экспертами находок. А внутри компании ещё полезнее превращать часть замечаний проверки в исполняемые проверки: если замечание можно зафиксировать тестом, проверку политики или статическое правило, оно перестаёт быть вкусовщиной.040404SWE-PRBench я разбирал в двух частях: ни одна модель не нашла больше трети отмеченных людьми проблем, а главный вывод — компаниям нужны собственные бенчмарки поверх своих PR.Книжный куб · SWE-PRBench, часть 1Книжный куб · SWE-PRBench, часть 2

Генерация тестов хорошо ложится на принцип «от падения к успеху»: агент должен написать тест, который падает до исправления и проходит после. Ровно так устроен Microsoft TestExplora. Для обычной генерации модульных тестов одного покрытия мало — нужны доля успешной сборки, покрытие ветвей, мутационная оценка и способность ловить реальные классы дефектов.

Сложнее всего с инцидентами и SRE. Тут агенту нельзя скармливать один вопрос «что случилось?». Нужен пакет инцидента: оповещение на T0, топология, вся телеметрия — логи, метрики, трейсы, — плюс инструкции, временная шкала, разбор инцидента и список того, что агенту вообще позволено делать. AIOpsLab двигает как раз идею такой среды для оценки облачных агентов. И проверка должна смотреть на каждый шаг по отдельности: как агент провёл первичный разбор, оценил ли радиус поражения, дошёл ли до настоящего RCA, безопасны ли меры устранения — и, что важнее всего, аккуратно ли он передал управление человеку.

Так что оценка SDLC в конечном счёте проверяет одно: дотянул ли агент рабочий эпизод до состояния, которое реально можно проверить.

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

Публичный рынок бенчмарков здесь ещё молодой. Систематический обзор по LLM в программной архитектуре нашёл всего 18 релевантных работ и отдельно отметил, как слабо покрыты облачно-ориентированные системы, архитектура и проверка соответствия. ArchBench авторы позиционируют как единую платформу для архитектурных задач: генерация ADR, восстановление связей прослеживаемости, сборка бессерверных и динамических компонентов, вывод микросервисов прямо из требований. R2ABench ближе к связке «требования → архитектура»: настоящие PRD, экспертные PlantUML-диаграммы, метрики на структурных графах, многомерная оценка и обнаружение антипаттернов.

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

Оценивать я бы стал весь архитектурный пакет целиком. На вход кейса кладётся:

• —идея функции и бизнес-цель;
• —нефункциональные требования и ограничения продукта;
• —текущая архитектура;
• —каталог утверждённых управляемых сервисов;
• —защитные ограничения организации и требования безопасности и соответствия;
• —доменный словарь;
• —интеграционные ограничения;
• —текущие ADR и эталонные шаблоны.

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

Проверку тут удобно делать трёхслойной. Нижний слой — жёсткие проверки: разрешённые управляемые сервисы, территориальное размещение данных, аутентификация по утверждённому шаблону, границы PII, SLO/SLA, владельцы, обязательные средства наблюдаемости. Над ним — структурное качество: полнота, антипаттерны, прослеживаемость от требований к компонентам, покрытие атрибутов качества, компромиссы и точки чувствительности. И самый верхний слой — пригодность к реализации: можно ли по этому решению нарезать задачи уровня репозитория, которые затем реализуются и проходят проверки.

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

С платформами данных картина зрелее. Тут уже есть бенчмарки на анализ с открытым ответом, многошаговую аналитику, ELT, управление и работу с данными на всём жизненном цикле. Если нужен один внешний ориентир, я бы начинал с DAComp — он удобен именно разделением на инженерию данных уровня репозитория и анализ данных с открытым ответом: DE-Architecture, DE-Implementation, DE-Evolution и отдельно аналитические задачи на отчёты, инсайты и рекомендации.

У аналитиков самый частый сценарий — бизнес-вопрос поверх семантического слоя или нескольких баз. Пользователь спрашивает «почему упала метрика», «какой сегмент просел», «сколько клиентов задело». И проверка должна оценивать не столько итоговое число, сколько то, как оно получено: правильны ли соединения, откуда взяты источники, что показывает трейс инструментов, воспроизводится ли SQL/Python на повторном прогоне, сходится ли происхождение данных. DAB полезен тем, что честно формализует боль агентов данных в рабочей среде: интеграцию нескольких баз данных, неверные ключи соединения, превращение неструктурированного текста в данные и доменное знание.

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

И почти всегда внутренним остаётся третий, самый неудобный случай — разрешение конфликтов семантического слоя. Агент должен выбрать между конкурирующими определениями одного KPI, объяснить расхождение, показать влияние на дашборды и предложить, что менять в семантическом слое или в документации. Публичных данных под это мало — такие конфликты завязаны на бизнес-логику конкретной компании. Лучшие кейсы лежат в истории самой аналитической команды: инциденты, постмортемы, споры в Slack и Jira.

У инженеров данных набор совсем другой. Бизнес-требование → схема данных: сначала гранулярность и ключевые сущности, затем ключи и контракты данных, а сверху происхождение, DAG и сопоставление с платформой. Дальше — сборка конвейера ELT/dbt по спецификации, где важны корректные модели, тесты, контракты и скрытые регрессионные проверки. Отдельная задача — эволюция: поменять существующий конвейер и не сломать последующие отчёты. Управление добавляет очистку, стандартизацию и соблюдение политик. А анализ влияния происхождения данных требует оценить радиус поражения по вышестоящим и нижестоящим зависимостям.

ELT-Bench тут хорошо отрезвляет. Авторы собрали 100 конвейеров, 835 исходных таблиц и 203 модели данных — и по их замерам лучший агент (Spider-Agent на Claude 3.7 Sonnet с расширенным анализом) корректно генерирует 3,9% моделей при средних 4,30 доллара и 89 шагах на конвейер. Отказываться от агентов данных из-за этого не стоит, но и выпускать их без скрытых проверок нельзя: как минимум схема, число строк, значения распределений, инварианты, происхождение и контроль, не поехали ли последующие отчёты.

Для задач управления данными стоит посмотреть на DataGovBench — он полезен не только задачами очистки и стандартизации, но и самой постановкой вопроса. Агента данных в компании надо оценивать не по тому, как складно он объяснил проблему с данными, а по простому факту: стало ли в итоге лучше и не нарушены ли политики.

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

Результат. Решена задача или нет: архитектуру приняли, ответ по данным верный, таблица собрана правильно, тесты зелёные, инцидент разобран, замечание проверки принято, политики соблюдены. Это фундамент — если тут не сошлось, на остальные метрики можно и не смотреть.

Трейс. Тот ли был план, те ли выбраны инструменты и с теми ли аргументами, были ли опасные или лишние действия, не подсмотрел ли агент будущий ответ там, где не должен. Это ровно тот слой, который отличает оценивание агента от обычной проверки текста.

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

Безопасность. Нарушение прав, доступ к PII, попытка тронуть не те файлы, небезопасное исправление, обход политик, лишние операции записи, отсутствие плана отката. Для SRE, безопасности, платформ данных и архитектуры это должен быть стоп-критерий, а не мелкий штраф в общем балле.050505Лучшая иллюстрация — SUSVIBES из CMU: лучший агент решает 61% задач, но лишь 10,5% решений оказываются без уязвимостей. Разбирал этот бенчмарк в канале.Книжный куб · SUSVIBES

Приёмка человеком. Приняли PR и замечания проверки, архитектурное решение прошло совет, RCA пригодился дежурному, аналитик подтвердил вывод, владелец данных согласился с исправлением. Каким бы автономным агент ни был, PR в конце концов принимает человек.060606Anthropic на 398 тысячах сессий Claude Code показали: «подтверждённый успех» растёт с экспертизой пользователя с 14,5% до 32,9%. В канале — разбор в двух частях, вторая про методологические ограничения.Книжный куб · 398K sessions, часть 1Книжный куб · 398K sessions, часть 2

Два поставщика платформ публично описывают похожую форму процесса — это их практика, а не независимая проверка. Snowflake в Cortex Agent Evaluations описывает оценку «цель — план — действие» — с выбором и выполнением инструментов и проверкой корректности ответа на прогонах с трейсами. Databricks в coSTAR выстраивает цикл «сценарий → трейс → оценка → уточнение» и гоняет одни и те же проверки в разработке, в CI/CD и на выборке рабочего трафика. По-моему, это и есть правильная форма: оценивание не живёт отдельно от эксплуатации, а становится её регрессионным контуром.

Если свести всё это в один рабочий формат, получается матрица scenario family × input bundle × hidden judge × metrics × release gate.

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

Теперь про то, на чём оценивание чаще всего ломается.

Самая частая ошибка — оценивать только финальный ответ. У автономного агента ответ может быть верным, а траектория — совершенно неприемлемой. Если он дошёл до решения через git log, внешний PR, слишком широкий SQL-доступ или опасный способ исправления — это не успех, как бы красиво ни выглядел итог.

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

Отдельно вредит привычка не обновлять наборы. Старый бенчмарк потихоньку превращается из измерительного прибора в учебный материал. Лечится это статической отложенной выборкой для регрессии и живым обновляемым набором свежих задач.

Ещё один провал — принимать заявления поставщиков за независимую валидацию. Заявления вендоров о росте точности, экономии времени или качестве их агентной платформы полезны как указатель направления, но читать их надо именно как заявления, а не как доказательство для вашей среды.

И последнее — не различать автономную проверку и наблюдение в рабочем контуре. Автономная проверка нужна как быстрый допуск к выпуску. Проверка в рабочем контуре нужна, чтобы увидеть реальный эффект: приняли ли PR, сократилось ли время расследования, стало ли меньше переделок, доверяют ли команды ответам агента. Порознь они дают только половину картины.070707Про реальный эффект хорошо отрезвляет свежий отчёт DORA: цена проверки, J-кривая продуктивности и совет мерить эффект на уровне системы, а не отдельного разработчика.Книжный куб · DORA про ROI

Начинал бы я не с выбора лучшей модели. Первым делом собрал бы каталог из 30–50 внутренних эпизодов: несколько PR с новыми функциями, пара-тройка исправлений ошибок, несколько случаев проверки, немного требований, несколько задач с данными, две-три архитектурные инициативы и пара инцидентов. Под каждый эпизод надо восстановить начальное состояние, спрятать финальное решение, описать контракт агента и сделать проверку настолько исполняемой, насколько вообще позволяет домен.

Дальше — два набора. Статическая отложенная выборка, которую не трогаем и гоняем для регрессии между версиями агента. И живой обновляемый набор, который регулярно пополняем свежими PR, инцидентами, аналитическими запросами и архитектурными решениями. А метрик держим сразу пять слоёв: результат, трейс, эксплуатация, безопасность и приёмка человеком.

Если совсем ужать, весь конвейер сводится к одной цепочке:

исторический рабочий артефакт → замороженное исходное состояние → контракт агента → скрытая проверка → трейс действий → повторяемость → допуск к выпуску

На демке это, конечно, скучнее, чем история «агент сам взял и всё сделал». Зато именно так — через каталог замороженных эпизодов — агент перестаёт быть красивой демкой и становится инструментом, которому можно доверить рабочую среду.080808Соседняя тема — как встроить такие проверки в сам агентный цикл: долг проверки, разделение генератора и проверяющего, «право сказать нет». Про это был эфир Loop Engineering.Книжный куб · Loop Engineering