Иллюзия авторского бенчмарка
Большинство наборов оценки агентов начинаются как список задач, которые команда уже имеет в виду: забронировать рейс, суммировать документ, решить тикет поддержки. Эти задачи полезны для дымового тестирования, но у них есть структурный изъян. Они взяты из того же воображения, которое породило агента. Задачи, которые команда придумала, почти по определению — это задачи, с которыми агент уже справляется. Бенчмарк, который никогда не проваливается, — не бенчмарк; это зеркало.
Важные сбои живут в хвосте: порядки вызовов инструментов, которые никто не предсказал, штормы повторных попыток, вызванные нестабильным upstream, частичные записи, оставляющие состояние несогласованным, версия модели, которая молча меняет интерпретацию схемы. Эти композиции не проектируются. Они обнаруживаются. И единственный надёжный источник обнаруженных сбоев — продакшн.
Вот почему оценка агентов должна быть воспроизведением инцидентов. Регрессионный корпус — это не курированный набор воображаемых сценариев; это растущий архив реальных траекторий, каждая из которых является фикстурой, кодирующей сбой, который система действительно проявила. Этот сдвиг культурный в той же мере, что и технический: набор оценки становится побочным продуктом эксплуатации, а не отдельным упражнением по написанию.
Что на самом деле содержит воспроизведение инцидента
Продакшн-трейс богаче пары промпт-ответ. Воспроизводимый инцидент содержит как минимум четыре слоя:
- Входное состояние: запрос пользователя, история диалога, извлечённый контекст и любое окружающее состояние (фича-флаги, конфигурация тенанта, метаданные сессии).
- Последовательность вызовов инструментов: упорядоченный список вызовов инструментов, включая аргументы, идентичность вызывающего и цель egress.
- Промежуточные наблюдения: результаты инструментов, полезные нагрузки ошибок, задержка и любые повторные попытки или fallback.
- Терминальные побочные эффекты: финальный ответ, но также записи, письма, тикеты или мутации состояния, вызванные агентом.
Захват этих слоёв необходим, но недостаточен. Воспроизведение должно быть детерминированным. Внешние эндпоинты заглушаются записанными ответами; часы замораживаются или инжектируются; версии модели привязываются к точному снимку, который породил трейс. Без детерминизма воспроизведение — это реконструкция, а его сигнал прохождения/провала — шум.
Таким образом, точность воспроизведения — это проблема конвейера данных прежде, чем проблема оценки. Команды, которые относятся к трассировке как к запоздалой мысли, обнаруживают, что их инциденты невоспроизводимы: ответы инструментов не были залогированы, версия модели не была записана, часы не были захвачены. Исправление находится выше по потоку: инструментируйте агента так, чтобы каждая траектория была первоклассным, версионированным артефактом.
Минимальный регрессионный харнесс
Описанный здесь харнесс намеренно мал. Он предполагает три компонента: хранилище трейсов, раннер воспроизведения и шлюз слияния.
Храните трейсы как версионированные артефакты
Трейсы хранятся рядом с кодом, который их породил, а не в отдельной базе данных, которая дрейфует. Артефакт трейса включает входное состояние, последовательность инструментов, наблюдения и терминальные побочные эффекты, плюс версию модели и хеш конфигурации агента. Версионирование артефакта означает, что изменение в агенте можно оценить против точного исторического контекста.
# trace-2025-03-14-001.yaml
trace_id: 2025-03-14-001
agent_config_hash: 9f2c...
model_version: gpt-4.1-2025-04-14
input_state:
user_request: "reconcile invoice 8842"
conversation: [...]
tool_sequence:
- name: fetch_invoice
args: {id: 8842}
result: {status: 200, body: {...}}
- name: post_ledger_entry
args: {amount: 120.00, account: "AR"}
result: {status: 500, error: "timeout"}
terminal_side_effects:
- type: ledger_entry
status: not_written
Оценивайте по свойствам траектории, а не только по финальному ответу
Точность финального ответа — слабый сигнал для агентов. Правильный ответ, который потребовал опасного вызова инструмента, несанкционированного egress или шторма повторных попыток, не является прохождением. Харнесс оценивает свойства траектории:
- Набор инструментов: какие инструменты были вызваны и были ли какие-либо вне разрешённого набора.
- Порядок: соблюдает ли последовательность зависимости и ограничения идемпотентности.
- Цели egress: какие внешние эндпоинты были задействованы и соответствуют ли они allowlist.
- Поведение повторных попыток: сколько повторных попыток произошло и были ли они ограничены.
- Согласованность побочных эффектов: является ли терминальное состояние когерентным с учётом промежуточных сбоев.
Эти свойства проверяемы без модели-судьи. Они детерминированы, быстры и объяснимы. Воспроизведение, которое проваливается на наборе инструментов или egress, — это инцидент безопасности или надёжности, а не регрессия качест
Харнесс запускается на каждом pull request. Шлюз — это не единый балл, а процент прохождения по корпусу, с политикой для регрессий: любой трейс, который проходил на базовой ветке и проваливается на головной ветке, блокирует слияние, если только явно не отклонён с записанной причиной. Новые инциденты рассматриваются как обязательные новые фикстуры. Когда инцидент разрешён, трейс, который его воспроизвёл, добавляется в корпус в том же pull request, что и исправление.
Это механизм, который превращает эксплуатацию в оценку. Корпус растёт вместе с фактической поверхностью сбоев системы, а не с воображением команды.
Затраты и ограничения
Корпус воспроизведений растёт монотонно. Каждый инцидент добавляет фикстуру, а фикстуры дешевы в хранении, но дороги в запуске. Честный компромисс — между покрытием и временем выполнения. Корпус, воспроизведение которого занимает час, будет пропущен; корпус, который занимает минуту, будет недостаточно выбран. Прагматичный ответ — политика сокращения, а не удаление. Трейсы многоуровневые: быстрый уровень запускается на каждом коммите (небольшое, высокосигнальное подмножество), полный уровень запускается ночью, а архивный уровень сохраняется для форензики. Сокращение — это политическое решение о том, какие сбои всё ещё репрезентативны, а не проблема сборки мусора.
Некоторые сбои невоспроизводимы по построению. Состояние гонки, зависящее от живого состояния третьей стороны, одноразовое повреждение данных, поведение модели, которое нельзя привязать, потому что провайдер не предоставляет снимки. Их нельзя воспроизвести достоверно. Искушение — отбросить их. Лучшая практика — записать их как фикстуры известных неизвестных: трейс с владельцем, описание предполагаемого механизма и маркер, что он не является частью шлюза прохождения/провала. Тогда корпус различает то, что тестируется, и то, что просто запоминается.
Второе ограничение — воспроизведение измеряет точность по отношению к прошлому, а не корректность для будущего. Корпус, построенный полностью из инцидентов, будет чрезмерно индексировать режимы сбоев, которые уже произошли. Это приемлемо, потому что альтернатива — корпус, построенный из воображаемых задач — чрезмерно индексирует режимы сбоев, которые никогда не произойдут. Дисциплина — относиться к корпусу как к живому архиву, а не как к спецификации.
Операционный сдвиг
Аргумент не в том, что авторские бенчмарки бесполезны. Они полезны для онбординга, для дымовых тестов и для передачи намерения. Аргумент в том, что они недостаточны как основная поверхность оценки для агентов. Важные сбои обнаруживаются в продакшне, и единственный способ не допустить их повторения — воспроизводить их.
Это требует сдвига в том, как команды относятся к трейсам: как к версионированным артефактам, а не логам. Это требует сдвига в том, как команды относятся к инцидентам: как к обязательным фикстурам, а не разовым пожарам. И это требует сдвига в том, как команды относятся к оценке: как к растущему архиву реальных траекторий, а не статическому набору воображаемых задач.
Результат — регрессионный корпус, отражающий фактическое поведение системы. Он никогда не будет полным. Он всегда будет отставать от следующего инцидента. Но он будет честным, и он будет полезным.