TL;DR
TRACE — протокол из четырёх шагов, который превращает фразу «скор упал» из приговора в проверяемую гипотезу. Сначала делают парные прогоны: одна и та же задача идёт до и после изменения. Затем сравнивают траектории (записи действий агента). Потом пересчитывают оценку на тех же траекториях по исправленному правилу, не запуская агента заново. Параллельно ставят два контроля: повтор без изменений (сколько результат шумит сам по себе) и заведомо вредное изменение (видит ли вообще ваша проверка реальный эффект).
Главная находка: скор может упасть, хотя агент делает ровно то же самое. В контрольном опыте инструментам агента переименовали названия. Операции остались прежними, но проверяющий код сверял имена, а не действия, и оценка упала на 0,25. Вторая находка: одиночный прогон почти ничего не доказывает. Идентичный перезапуск меняет «прошёл/не прошёл» у 15–36% задач. Ещё один неприятный факт: два сильных LLM-судьи стабильны сами с собой, но на 57% одних и тех же записей спорят друг с другом. Один из них оценивает порядок действий, а не результат.
Метод решает это разделением вопросов. «Изменился ли общий скор?», «изменилось ли поведение агента?» и «изменилось ли суждение проверяющего на той же записи?» — это три разных вопроса, и отвечать на них нужно разными данными. Для практика это чек-лист: не сравнивай по одному прогону, смотри, что именно делал агент, и перепроверяй подозрительное правило пересчётом.
Схема метода
ШАГ 0: Контроли → (а) повтор без изменений = фон шума
(б) заведомо вредное изменение = «видит ли проверка эффект»
ШАГ 1: Парные прогоны → те же задачи, до и после изменения (несколько раз)
ШАГ 2: Сравнение скоров → разница, доля прохождений, сравнение с шумом повтора
ШАГ 3: Просмотр траекторий → поведение/результат изменились или нет?
ШАГ 4: Пересчёт оценки → те же траектории, исправленное правило
разрыв исчез → виновато правило проверки
разрыв остался → виновато поведение агента
Каждый шаг — отдельная операция над данными. Это не один промпт, а процесс из нескольких запросов или ручных проверок.
Пример применения
Задача: Команда продавца на маркетплейсе (условный Ozon) запустила агента для обработки возвратов. Его проверяют на 20 тестовых обращениях, оценка «прошёл/нет» выставляется автоматически. Разработчик переименовал инструменты в понятные: get_order стал fetch_order_details, refund стал issue_refund_to_customer. Доля успехов упала с 80% до 65%. Начальник уже просит откатить промпт.
Промпт (передаётся в чат вместе с выгрузкой логов):
Ты — аналитик качества агентов. Твоя задача — выяснить, чем вызвано падение оценки:
изменением поведения агента или особенностями самой проверки.
Не делай вывод по одной цифре.
Агент: обработка возвратов на маркетплейсе.
Что изменили: переименовали инструменты (get_order → fetch_order_details,
refund → issue_refund_to_customer). Логика и аргументы инструментов не менялись.
Проверка: автоматический скрипт, ставит «прошёл/не прошёл».
Таблица А: 20 задач × 3 прогона ДО изменения (результат + трасса действий).
Таблица Б: 20 задач × 3 прогона ПОСЛЕ изменения (результат + трасса действий).
Таблица В: те же 20 задач, повторный прогон ДО изменения без правок.
[вставить таблицы]
Шаг 1. Шум. По таблицам А и В посчитай, у какой доли задач результат
«прошёл/не прошёл» отличается между двумя идентичными прогонами.
Шаг 2. Разница. Посчитай изменение доли успехов между А и Б.
Сравни его с шумом из шага 1. Скажи: разница больше шума или нет.
Шаг 3. Поведение. Для задач, где результат изменился, сравни трассы
до и после: те же ли вызовы, те же ли аргументы, тот же ли итог для клиента?
Раздели задачи на три группы: «поведение то же», «поведение изменилось», «неясно».
Шаг 4. Подозрение на проверку. Для группы «поведение то же, а оценка упала»
опиши, какое правило проверки могло сработать иначе (например, сверка по имени инструмента).
Предложи исправленное правило и покажи, как бы изменилась оценка
при пересчёте на тех же трассах.
Шаг 5. Вывод. Раздели падение на две части:
сколько объясняет проверка, сколько — реальное поведение.
Напиши, какой дополнительный контроль нужен, чтобы утверждать это уверенно.
Результат: Модель пройдёт по шагам. Сначала даст оценку фонового шума: насколько сами повторы расходятся. Затем сравнит с падением и скажет, выходит ли оно за пределы шума. Потом разложит задачи на группы по поведению и укажет, где подозрительно правило проверки. В конце модель разделит падение на «виновата проверка» и «изменилось поведение», с оговорками, где данных мало.
Почему это работает
Слабость: оценка — это всегда «агент + среда + проверяющий». Когда скор меняется, непонятно, кто виноват. К тому же мы склонны читать любое изменение как изменение способностей. Простая проверка по именам, формату или шаблону делает вид, что измеряет результат, а на деле измеряет форму.
Сильная сторона: траектория — это улика. Если у агента те же действия и тот же исход, а оценка разная, значит, виновата проверка. Это можно показать, не запуская ничего заново. Пересчёт на тех же записях дешёв и однозначен: если после исправления правила разрыв исчез, причина найдена.
Контроли делают вывод осмысленным. Повтор без изменений показывает, что 15–36% исходов меняются сами по себе. Без этого фона любое «упало на 5 пунктов» может быть шумом. Положительный контроль нужен для обратной ситуации. Если вы сделали заведомо вредное изменение и скор не отреагировал, ваша проверка слепа, и вывод «ничего не изменилось» ничего не стоит.
Рычаги управления: - Число повторов — больше повторов, точнее оценка шума. Для быстрой проверки хватит трёх на задачу. - Порог «прошёл» — меняйте его и смотрите, держится ли вывод при 0,55, 0,65 и 0,75. - Допуск эквивалентности — авторы взяли ±0,10. Для критичных задач берите уже. - Подозреваемое правило — подставьте своё (формат даты, регистр, порядок вызовов), и пересчёт покажет его вклад.
Шаблон промпта
Ты — аналитик качества агентов (или автоматизации с LLM).
Твоя задача — разделить причины изменения оценки: поведение агента или правило проверки.
Никаких выводов по одной цифре.
Система: {что_за_агент_или_процесс}
Что изменили: {изменение}
Как оценивают: {правило_проверки_или_судья}
Что ожидалось: {изменение_должно_влиять_на_результат_или_нет}
До изменения: {данные_до}
После изменения: {данные_после}
Повторный прогон без изменений: {данные_повтора}
Трассы действий (если есть): {трассы}
Шаг 1. Посчитай шум: доля задач, где два идентичных прогона дали разный итог.
Шаг 2. Посчитай изменение оценки до/после и сравни с шумом.
Шаг 3. Для задач с изменившимся итогом сравни трассы: вызовы, аргументы, результат для пользователя.
Шаг 4. Для случаев «поведение то же, оценка другая» назови правило проверки, которое могло сработать по-разному.
Предложи исправленное правило и пересчитай оценку на тех же трассах.
Шаг 5. Раздели падение: доля, объяснённая проверкой / доля, объяснённая поведением.
Назови, каких данных не хватает.
- Считай «средний балл» вместе с долей прохождений: низкий разрыв может означать провал в обоих случаях.
- Не называй причину доказанной, если разница не выходит за пределы шума.
- Если данных мало, скажи это прямо.
Что подставлять: {изменение} — одно конкретное изменение за раз (имена инструментов, формат вывода, формулировка задачи). {правило_проверки_или_судья} — как именно ставится оценка: скрипт, чек-лист, LLM-судья. {данные_*} — выгрузка результатов в виде таблицы. {трассы} — логи действий агента.
🚀 Быстрый старт — вставь в чат:
Вот шаблон диагностики изменения оценки (TRACE). Адаптируй под мою задачу: [опиши, что у тебя за агент/автоматизация и что изменилось].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно вы изменили, как устроена проверка и какие данные у вас есть. Это нужно, чтобы метод мог разделить виновников: ему важно знать, чем проверяется результат, и есть ли записи действий для пересчёта. Модель возьмёт структуру из шаблона и адаптирует под вашу систему.
Ограничения
⚠️ Нужны данные прогонов: без нескольких повторов и записей действий (трасс) вы получите только гипотезу. Для шума и пересчёта нужны сами материалы, а не память о «примерно так было».
⚠️ Мало задач — широкие интервалы: на 30 задачах в первом исследовании почти все интервалы включали ноль. Отсутствие эффекта там не означало, что его нет: данных просто не хватало. Единственный «явный» эффект при расширении выборки исчез.
⚠️ Проверено на узком наборе: основная часть опыта — один публичный бенчмарк (магазин и авиакомпания), четыре агента и синтетическая среда. Выводы про «переименование безопасно» нельзя переносить на любые инструменты и промпты.
⚠️ Оговорка по самим проверкам: дефект «сверка по имени» найден в простом самописном скрипте. Это не вывод про обученные модели-оценщики.
⚠️ Вводящие в заблуждение названия вредят: если имя инструмента противоречит тому, что он делает, награда падает у всех агентов. Нейтральные переименования безвредны, а ложные — нет.
⚠️ Судью нельзя проверять только на стабильность: повторяемость не равна валидности. Судья может стабильно оценивать не то (например, порядок шагов вместо результата).
Как исследовали
Идея была простой: чтобы доверять диагностике, надо сначала проверить её там, где причина известна заранее. Автор собрал синтетический мир из 25 исследовательских задач (например, исправить learning rate или предотвратить утечку данных) и трёх агентов-«актёров» с заданным поведением: аккуратный, «заучивающий ответ» и жулик. Одно и то же переименование инструментов дало разный результат. У аккуратного агента оценка упала на 0,25, но после обратной подстановки имён разрыв стал нулём, то есть виновата проверка. У «заучивающего» разрыв остался (0,13): он реально выдавал неудачный отчёт. Разрыв у жулика был почти нулевой (0,006). Но это не «надёжность»: он одинаково плохо проходил оба варианта.
Затем перешли на реальные LLM-агенты в публичном τ²-bench: четыре агента, 30 задач, три условия (оригинал, переименование, переформатирование ответов). Увидели «эффект»: у Laguna оценка при переименовании выросла на 0,267. Авторы не поверили и перепроверили на 88 новых задачах по три прогона. Эффект исчез, и в 7 из 8 пар разница уложилась в ±0,10. Чтобы нули что-то значили, добавили положительный контроль: названия инструментов нарочно перемешали, но задачи остались решаемыми. Награда упала у всех агентов на 0,20–0,44, так что установка эффект видит.
Самое неожиданное — шум. Идентичный повтор менял результат у 14,7–16,3% задач и у 35,6% для Laguna. Значит, любые одиночные сравнения в таких бенчмарках ненадёжны. Судьи (GPT-6.1 Sol и Claude Opus 5.5) на 118 фиксированных траекториях были устойчивы к форме подачи: разница укладывалась в их собственный шум. Но друг с другом расходились на 57% записей. Claude согласился с эталоном в 95% случаев, GPT — в 38%, и в основном придирался к процедуре, например к нескольким вызовам инструментов за один ход. Вывод для практики: контролируйте шум, смотрите на траектории и не путайте стабильность с правильностью.
Адаптации и экстраполяции
🔧 Техника: добавить в рубрику судьи фразу про исход → меньше придирок к процедуре
Авторы не проверяли это сами, но их находка подсказывает ход. Один судья наказывал за процедуру, хотя бенчмарк засчитывал успех. Если вы используете LLM-судью, явно пропишите, что оценивается:
Оценивай только итоговый результат для пользователя:
решена ли задача и корректны ли итоговые данные.
Не снижай оценку за порядок действий, число вызовов инструментов
и стиль, если результат верный.
Если порядок действий критичен (безопасность, необратимые операции), отметь это отдельным пунктом.
Это гипотеза, её нужно проверить на своей выборке: возьмите 20 записей, пропустите через старую и новую рубрику и сравните с человеческой оценкой.
Экстраполяция: проверка описаний инструментов в инструкции агенту
Авторы показали, что вводящие в заблуждение имена инструментов вредят всем агентам. Из этого можно собрать самопроверку для файла инструкций (CLAUDE.md, AGENTS.md):
Перед тем как использовать инструмент, сверь его название с описанием.
Если название и описание расходятся (например, «delete» делает архивацию),
остановись и сообщи об этом, не выбирай по названию.
Это вывод по мотивам статьи, а не её результат. Авторы тестировали именно перемешанные имена, но не такую инструкцию.
Ресурсы
- Работа: «TRACE: Diagnosing Verifier Brittleness in Agentic Evaluation», AI Measurement Science Workshop at COLM 2026.
- Автор: Radhika Gaonkar, Prime Intellect.
- Бенчмарки и среды: τ²-bench (Barres et al., 2026), ResearchOpsEnv (синтетическая среда из 25 задач, созданная авторами).
- Связанные работы: Krakovna et al. (2020) о specification gaming, Gao et al. (2023) о переоптимизации моделей награды, Zhu et al. (2025) об аудите бенчмарков агентов, Ribeiro et al. (2020) о поведенческом тестировании.