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

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

Главный сдвиг для меня в том, что зрелую оценку агента бессмысленно сводить к leaderboard. Это скорее инженерная система качества, и считать в ней надо не отдельные вопросы и финальные ответы, а целые воспроизводимые эпизоды работы.

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

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

Но и этого мало. У агента надо фиксировать не только финальный patch, но и всю траекторию — как именно он к нему пришёл. GitHub в разборе offline evaluation для MCP Server отдельно оценивает выбор инструментов и корректность аргументов. Звучит как техническая мелочь, но именно здесь прячется куча риска: агент может дёрнуть не тот tool, вызвать его с опасными параметрами, случайно угадать правильный ответ или потратить десяток лишних шагов на элементарную задачу.

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

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"

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

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

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

Скрытым остаётся judge. Для кода это hidden tests, полный прогон и static/security-проверки; для workflow-агентов — ожидаемые tool calls и конечное состояние; для архитектуры — policy checks, полнота решения, traceability и downstream usefulness. Чем больше в judge исполняемого, тем меньше места для красивой, но ничем не подтверждённой риторики.

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

Остаётся свежесть. Статичные публичные наборы быстро загрязняются: задачи утекают в обучающие данные, вокруг них нарастает обвязка, подсказки, неявная подгонка. Поэтому нужны time split, project split и живой rolling set. SWE-bench Live решает это для coding-задач, а Microsoft в работе про continuous benchmark generation формулирует тот же принцип шире, для enterprise-агентов: бенчмарк должен обновляться вместе с рабочей средой.

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

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

Дальше — feature coding, и тут схема ближе всего к FEA-Bench: issue или spec, pre-PR commit, скрытые functional/integration-тесты и safety на полном прогоне. С багфиксами тоньше: нужен buggy commit, issue, stack trace или падающее поведение, а проверка обязана показать, что баг воспроизвёлся и исчез, а соседние сценарии не поехали. И тут опасно подменять качество одним публичным regression-тестом — слабый oracle почти неизбежно начинает пропускать неверные patch'и.

Code review — отдельная история. Оценивать надо не красоту комментария, а то, ловит ли агент дефекты, которые реально влияют на merge quality. SWE-PRBench строит такую оценку вокруг настоящих PR и human-annotated findings. А внутри компании ещё полезнее превращать часть review findings в исполняемые проверки: если замечание можно зафиксировать тестом, policy check или static rule, оно перестаёт быть вкусовщиной.

Генерация тестов хорошо ложится на принцип fail-to-pass: агент должен написать тест, который падает до фикса и проходит после. Ровно так устроен Microsoft TestExplora. Для обычной unit-test generation одного покрытия мало — нужны compile/pass rate, branch coverage, mutation score и способность ловить реальные классы дефектов.

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

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

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

Публичный рынок бенчмарков здесь ещё молодой. Систематический обзор по LLM в software architecture нашёл всего 18 релевантных работ и отдельно отметил, как слабо покрыты cloud-native, архитектура и conformance checking. ArchBench авторы позиционируют как единую платформу для архитектурных задач: генерация ADR, восстановление traceability-связей, сборка serverless- и dynamic-компонентов, вывод микросервисов прямо из требований. R2ABench ближе к связке requirements → architecture: настоящие PRD, экспертные PlantUML-диаграммы, метрики на структурных графах, multi-dimensional scoring и детект антипаттернов.

Но как только речь заходит про сценарий «feature idea → целевое архитектурное решение выше уровня репозитория → downstream work items», готового открытого бенчмарка почти наверняка не хватит. Внешние наборы годятся как seed, но основной eval set придётся собирать из своих внутренних решений.

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

• —feature idea и бизнес-цель;
• —NFR и ограничения продукта;
• —текущая архитектура;
• —каталог approved managed services;
• —org guardrails и требования security/compliance;
• —доменный словарь;
• —интеграционные ограничения;
• —текущие ADR и reference patterns.

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

Judge тут удобно делать трёхслойным. Нижний слой — жёсткие policy checks: разрешённые managed services, data residency, auth pattern, границы PII, SLO/SLA, владельцы, обязательные observability-контролы. Над ним — структурное качество: полнота, антипаттерны, traceability от требований к компонентам, покрытие quality attributes, trade-offs и sensitivity points. И самый верхний слой — downstream executability: можно ли по этому решению нарезать repo-level задачи, которые потом реально реализуются и проходят проверки.

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

С data platform картина зрелее. Тут уже есть бенчмарки на open-ended analysis, multi-step-аналитику, ELT, governance и full-lifecycle data intelligence. Если нужен один внешний ориентир, я бы начинал с DAComp — он удобен именно разделением на repository-level data engineering и open-ended data analysis: DE-Architecture, DE-Implementation, DE-Evolution и отдельно аналитические задачи на отчёты, инсайты и рекомендации.

У аналитиков самый частый сценарий — business question поверх semantic layer или нескольких баз. Пользователь спрашивает «почему упала метрика», «какой сегмент просел», «сколько клиентов задело». И judge должен проверять не столько финальное число, сколько то, как оно получено: правильные ли joins, откуда взяты источники, что показывает tool trace, воспроизводится ли SQL/Python на повторном прогоне, сходится ли provenance. DAB полезен тем, что честно формализует боль production data agents: multi-database integration, кривые join keys, превращение неструктурированного текста в данные и доменное знание.

Иначе устроен exploratory analysis: агент получает данные и должен выдать insight memo, графики, рекомендации. Детерминированного ответа тут часто просто нет. Поэтому judge смотрит на groundedness к данным, корректность вычислений, покрытие ключевых аналитических шагов, воспроизводимость артефактов и качество самих рекомендаций. Хорошо ложатся идеи BLADE: open-ended-анализ с экспертным ground truth и с поправкой на то, что допустимых подходов обычно несколько.

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

У data-инженеров набор совсем другой. Business requirement → data blueprint: сначала grain и ключевые сущности, потом keys и data contracts, а сверху lineage, DAG и маппинг на платформу. Дальше — сборка ELT/dbt-пайплайна по спецификации, где важны корректные модели, tests, contracts и hidden regression checks. Отдельная задача — эволюция: поменять существующий pipeline и не сломать downstream-отчёты. Governance добавляет очистку, стандартизацию и policy compliance. А анализ lineage impact требует прикинуть blast radius по upstream/downstream-зависимостям.

ELT-Bench тут хорошо отрезвляет. Авторы собрали 100 пайплайнов с сотнями source-таблиц и моделей — и по их замерам даже сильные агенты корректно генерируют лишь небольшую долю моделей. Отказываться от data-агентов из-за этого не стоит, но и выпускать их без скрытых проверок нельзя: как минимум schema, row counts, value distributions, инварианты, lineage и контроль, не поехали ли downstream-отчёты.

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

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

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

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

Operations. Сколько это стоило и сколько заняло — latency, cost, token burn, build minutes; сколько раз агент дёргал tools и уходил в retry; держится ли всё это стабильно от прогона к прогону. Агент, который решает задачу за непредсказуемые деньги и с огромной дисперсией, бывает исследовательски любопытным и совершенно неудобным в проде.

Safety. Нарушение прав, доступ к PII, попытка тронуть не те файлы, небезопасный remediation, обход политик, лишние операции записи, отсутствие плана отката. Для SRE, security, data platform и архитектуры это должен быть стоп-критерий, а не мелкий штраф в общем балле.

Human acceptance. Приняли PR, приняли review-комментарии, архитектурное решение прошло board, RCA пригодился on-call, аналитик подтвердил вывод, data owner согласился с remediation. Каким бы автономным агент ни был, PR в конце концов принимает человек.

Индустрия сходится примерно к тому же. Snowflake в Cortex Agent Evaluations описывает оценку Goal-Plan-Action — с tool selection, tool execution и answer correctness на traced-прогонах. Databricks в coSTAR выстраивает цикл Scenario → Trace → Assess → Refine и гоняет одни и те же evals в разработке, в CI/CD и на сэмплированном production-трафике. По-моему, это и есть правильная форма: eval не живёт отдельно от эксплуатации, а становится её регрессионным контуром.

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

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

Теперь про то, на чём eval'ы чаще всего ломаются.

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

Вторая ловушка — слепо верить одному gold answer. Для кода иногда есть чёткий oracle, но в архитектуре, аналитике и incident response допустимых решений обычно много. Значит, нужны reference solution families, рубрики и hard negatives.

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

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

И последнее — не различать offline и online. Offline-eval нужен как быстрый release gate. Online нужен, чтобы увидеть реальный эффект: приняли ли PR, сократилось ли время расследования, стало ли меньше переделок, доверяют ли команды ответам агента. Порознь они дают только половину картины.

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

Дальше — два набора. Static holdout, который не трогаем и гоняем для регрессии между версиями агента. И rolling live set, который регулярно пополняем свежими PR, инцидентами, аналитическими запросами и архитектурными решениями. А метрик держим сразу пять слоёв: outcome, trace, operations, safety и human acceptance.

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

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

На демке это, конечно, скучнее, чем история «агент сам взял и всё сделал». Зато именно так — через каталог замороженных эпизодов — агент перестаёт быть красивой демкой и становится инструментом, которому можно доверить прод.