Оценка агентов по траекториям, а не по ответам

Пробел в оценке

Большинство бенчмарков для агентов по-прежнему оценивают как экзамен с множественным выбором: запустить агента, сравнить его финальный ответ с эталоном, выдать оценку. Это сводит всю многошаговую траекторию к одному биту. Два агента могут оба получить 1.0, при этом один выполнил чистую, обратимую операцию, а другой удалил продакшн-таблицу, сделал четыре повторные попытки и случайно пришёл к правильному ответу. Если бенчмарк не видит разницы, её не увидит и команда, выпускающая агента.

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

Почему оценка по финальному ответу не работает

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

Три свойства, важные в продакшене, невидимы для оценки только по результату:

Стоимость. Использование токенов, вызовы инструментов и задержка в реальном времени. Агент, решающий задачу за один вызов инструмента, и агент, решающий её за девять, — не эквивалентные продукты, даже если ответы совпадают.
Побочные эффекты. Каждая затронутая внешняя система и в каком конечном состоянии. Бенчмарк, который это не фиксирует, не может отличить агента только для чтения от того, который изменил состояние, а затем всё откатил.
Воспроизводимость. Воспроизводит ли тот же агент на той же задаче ту же траекторию при разных seed. Один успешный запуск — это анекдот, а не измерение.

Что фиксировать

Единицей оценки должна быть траектория, а не ответ. Это означает инструментирование агента для выдачи структурированной трассы действий. Как минимум каждый шаг должен фиксировать:

Имя инструмента и его полные аргументы, а не только имя. write_file неинформативен; write_file(path="/etc/hosts", mode="append") — информативен.
Наблюдение, возвращённое инструментом, включая полезную нагрузку ошибок.
Временные метки и количество токенов на шаг.
Конечное состояние каждой внешней системы, затронутой запуском: созданные или изменённые файлы, вставленные строки, отправленные сообщения, выделенные ресурсы.

Минимальная схема трассы может выглядеть так:

Fiber optic cables patch panel

{
  "run_id": "...",
  "task_id": "...",
  "seed": 7,
  "steps": [
    {
      "index": 0,
      "tool": "read_file",
      "args": {"path": "data/input.csv"},
      "observation": {"status": "ok", "bytes": 4096},
      "tokens_in": 812,
      "tokens_out": 44
    },
    {
      "index": 1,
      "tool": "write_file",
      "args": {"path": "out/summary.md", "mode": "create"},
      "observation": {"status": "ok"},
      "tokens_in": 921,
      "tokens_out": 130
    }
  ],
  "terminal_state": {
    "files_created": ["out/summary.md"],
    "files_modified": [],
    "external_calls": []
  },
  "retries": 0,
  "backtracks": 0
}

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

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

Оценка траекторий

Как только траектории зафиксированы, оценка становится вектором, а не скаляром. Четыре измерения покрывают большинство продакшн-забот:

Результат. Достиг ли агент условия успеха задачи? Это привычная бинарная или градуированная оценка.
Валидность пути. Соблюдала ли траектория ограничения задачи? Были ли использованные инструменты уместны, были ли аргументы корректно сформированы, были ли промежуточные шаги связными?
Гигиена побочных эффектов. Остались ли непреднамеренные внешние системы нетронутыми? Были ли предполагаемые изменения применены ровно один раз, идемпотентно, в правильном порядке?
Стоимость. Токены, задержка и вызовы инструментов, нормализованные относительно эталонной траектории или бюджета.

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

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

Отложенные среды и дисперсия

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

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

Fiber optic cables

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

Конкретный механизм: песочница для воспроизведения

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

Поскольку среда эфемерна, побочные эффекты наблюдаемы и локализованы. Поскольку сервер API — mock, ответы можно рандомизировать по seed. Поскольку сетевая политика явна, непреднамеренные внешние вызовы записываются, а не молча разрешаются. Затем песочница оценивает запуск по вектору, описанному выше.

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

Что сообщать

Отчёт бенчмарка с учётом траекторий должен включать по каждой задаче:

Оценку результата с явно указанным условием успеха.
Флаги валидности пути с перечислением конкретных нарушений.
Diff побочных эффектов, суммированный как количество созданных, изменённых и удалённых ресурсов.
Стоимость с разбивкой по токенам и вызовам инструментов.
Счётчики повторных попыток и откатов.
Дисперсию по seed, сообщаемую как распределение, а не как одно число.

Агрегированный по задачам, это даёт профиль, а не ранг. Профили сложнее продавать. Они также полезнее для решения о том, безопасно ли развёртывать агента.

Заключение

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

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

Оценка агентов по траекториям, а не по ответам: заметка о дизайне бенчмарка