Кто оценивает оценщика? Проверка наборов инструментов для оценки агентов перед тем, как им доверять.

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

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

Предположение, которое никто не высказывает

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

Исследования следов действий агентов начали ставить под сомнение это предположение. В одном из исследований было проанализировано 58 случаев, которые система оценки признала успешными, и выяснилось, что у 83 процентов из них скрывались нарушения процедур или правил безопасности, которые система оценки никогда не выявляла. Агент давал правильный ответ и получал идеальную оценку, однако используемый им путь на самом деле был некорректным. Разница между итоговым результатом и процессом именно та, которую и предназначена обнаруживать система оценки, но которую большинство таких систем по своей конструкции не может увидеть.

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

Смещение оценки. Любые семантические аспекты склонны оцениваться ИИ-моделью, поскольку проверка на основе правил не может определить, была ли фраза «следующая пятница» преобразована в правильную дату. Однако сама оценочная модель тоже является моделью, и они могут меняться. У команд, использующих долгосрочные решения, часто происходит резкое ухудшение показателей за одну ночь; им приходится тратить день на расследование, прежде чем они понимают, что оценки изменились из-за обновления модели оценщика, а не из-за ухудшения работы агента. Фиксация версии модели оценщика и хэша шаблона оценки снижает проблему, но не устраняет её полностью, поскольку хостинговые точки входа для оценщика постоянно меняются.

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

Приватные моди при сбоях. Публичные тест-матрицы, такие как BFCL или tau-bench, помогают сравнивать модели, но они не могут выявить сбои, возникающие внутри собственного реестра инструментов команды: значение null в необязательном поле, ошибка с часовым поясом в датном аргументе, несоответствие валют в поле с финансовыми данными. Такие сбои относятся к инструментам команды и никогда не появляются в общем рейтинге. Если покрытие тестирования полностью заимствуется из публичных тест-матриц, инструмент проверки остаётся слепым именно там, где это важно — в тех частях системы, которые никто другой не тестировал.

Узкая точка зрения на затраты. Этот аспект наименее обсуждается, но, возможно, имеет наибольшие последствия. Система оценки может считать агента точным по всем критериям, при этом совсем не учитывая, окупает ли себя его деятельность. Известен случай, когда агент соответствовал всем двенадцати показателям качества, но был устранен из эксплуатации, поскольку стоимость каждого успешного решения превышала стоимость ручного ведения дел, которое он должен был заменить. Оценки качества были точными. Однако не существовало показателя для оценки того факта, который определил его судьбу.

Агент по бронированию с идеальными показателями, но потерпевший неудачу

Представьте, что агента по бронированию просят найти рейсы на «следующую пятницу». Из реестра с десятками инструментов он выбирает подходящий, за что получает идеальную оценку 1,0. Затем он отправляет дату в виде простой строки, не обрабатывая сначала относительное выражение. API возвращает ошибку проверки, и агент четыре раза пересылает ту же некорректную строку, прежде чем извиниться и завершить работу.

Этот отчет показывает два показателя: идеальные 1,0 за выбор инструмента и 0 за выполнение задачи. Ни один из них не указывает, в чем именно была ошибка: при неправильной обработке аргументов, в ответе от API, который агент так и не прочитал, или из-за логики повторных попыток, которая продолжает работу с неизменными данными. Подробный анализ оценки вызовов инструментов показал, что проверка лишь того, был ли вызван правильный инструмент, оценивает намерение, а не факт выполнения, причем именно намерение не сработало.

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

Практики, помогающие решить проблему

Как только набор инструментов оценки начинают рассматривать как систему, требующую собственной проверки качества, структура работы меняется. Несколько определенных привычек отличают команды, которые своевременно выявляют проблемы, от тех, у которых это происходит с большими трудностями:

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

Проверка на основе выполнения вместо сравнения текста. Самые надежные тест-кейсы анализируют то, что действительно изменилось в реальном мире. tau-bench считывает состояние базы данных, SWE-Bench выполняет реальные тесты, а функция pass-at-k в tau2-bench проверяет, добивается ли агент стабильного успеха при многократных попытках. Разработанные собственными силами наборы тестов также должны следовать этому принципу и подтверждать реальные изменения, независимо от того, что сообщает агент.

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

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

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

Четыре шага для уже имеющегося у вас набора тестов

Для команды, располагающей набором инструментов для оценки, которая хочет их проверить, а не просто доверять им, четыре шага помогают преодолеть большинство проблем:

1. Возьмите от десяти до двадцати примеров работы в реальных условиях, которые набор инструментов отметил как успешные, и вручную просмотрите каждый полный ход выполнения, а не только результат. Количество таких успешных случаев, скрывающих процедурные ошибки, является достоверным показателем того, насколько можно доверять показателям на панели управления.
2. Укажите версию модели оценщика и текст критериев оценки, а также фиксируйте их вместе с каждым результатом, чтобы обновление модели оценщика проявлялось в виде отмеченного события, а не как непонятное ухудшение качества.
3. С самого начала отслеживайте стоимость каждого успешного результата, даже до того, как кто-либо об этом попросит.
4. Создайте небольшой набор данных для выявления ухудшений качества на основе реальных сбоев в работе системы, а не только синтетических случаев. Общедоступные эталоны определяют минимальные стандарты, тогда как собственная история инцидентов команды позволяет предсказать следующий неприятный сбой.

Ничто из этого не заменяет полный набор тестов. Это лишь прекращает рассматривание данного набора как единственного компонента, слишком важного для проверки.

Краткие ответы

Что означает проверка набора тестов для агентов? Это означает применение такой же строгой проверки к системе оценки, какую система применяет к агенту, с целью убедиться, что критерии оценки, шкала и алгоритм подсчёта баллов действительно отражают то, что они должны измерять.

Почему меняются баллы, присваиваемые агентам с использованием LLM в роли судьи? «Судья» — это модель. Когда её поставщик обновляет её или заменяет на новую версию, баллы могут измениться, даже если сам агент не изменился.

Могут ли публичные тестовые наборы заменить собственный набор тестов? Нет. Они помогают сравнивать модели по распространённым задачам, но не учитывают сбои, связанные с собственными инструментами, данными и специфическими случаями команды.

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

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

Причины, лежащие в основе панели управления

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

Связанные материалы

• Оценка агентов с помощью бота для бронирования поездок: результаты против траектории, шлюзы и критерии pass^k — пример использования бота для бронирования поездок для оценки агентов: оси результатов и траектории, детерминистические шлюзы перед взвешенными оценками, 2x2-матрица, а также критерии pass@k и pass^k.

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

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