TL;DR
Автоматические метки в оценке агентов (верный ответ, проверил результат, ошибка не распространилась) — это показания приборов, а не факты. Метку ставит парсер или детектор: простое правило, которое смотрит в трассу (полный лог: рассуждения, вызовы инструментов, ответы). Авторы предлагают к каждой метке прикладывать доказательство из трассы, отмечать, был ли вопрос детектора вообще применим, и сохранять ручные поправки рядом с автометкой.
Главная находка — тихая подмена результата инструмента. Калькулятор вернул испорченное число (29 вместо 30). Агент молча продолжил с правильным (30) и не вызвал инструмент повторно. Детектор «перепроверки» ищет только явный повторный вызов и пишет «не проверял». При этом модель фактически исправила ошибку. Бывает и наоборот: агент застрял в цикле и десять раз вызвал калькулятор, а детектор записал это как «усердную проверку». Обе ошибки теряются, когда лог сворачивается в одну цифру на дашборде.
Решение — не отказ от автооценки, а прозрачность измерения. К каждой метке прилагаются: - цитата из трассы, на которой она держится; - отметка, применим ли вопрос к этой трассе; - отметка, не оборвался ли прогон на лимите шагов или токенов; - ручная поправка, если она была.
Отдельное правило: оборванный прогон — это не «неправильный ответ», а «нет данных».
Схема метода
ШАГ 1: Берёшь автометку (верно / проверил / ошибка не прошла дальше)
ШАГ 2: Находишь в трассе доказательство → цитата из лога
ШАГ 3: Проверяешь применимость → вопрос метки вообще имеет ответ в этой трассе?
ШАГ 4: Проверяешь цензуру → прогон дошёл до конца или упёрся в лимит шагов/токенов?
ШАГ 5: Выносишь вердикт → метка подтверждена / оспорена / неприменима + поправка рядом с оригиналом
Шаги 2–5 можно выполнить в одном запросе к LLM на одну трассу. Для всего корпуса понадобится цикл из таких запросов или ручная выборка.
Пример применения
Задача: Ты собрал в n8n агента, который считает клиенту итоговую цену заказа с НДС 20% и скидкой. Для расчёта он вызывает калькулятор через API. Ты прогнал 30 тестовых заказов, а LLM-судья выставил метки. Дашборд показывает: «перепроверил расчёт — 5 из 30». Выглядит так, будто агент почти не проверяет себя. Прежде чем переписывать системный промпт, нужно проверить, что за этими пятью стоит.
Промпт:
Ты аудитор автоматических меток для агента. Тебе даны трасса одного прогона и метка, которую поставил детектор. Не доверяй метке. Проверь её по трассе.
<Метка>
Детектор «перепроверка»: НЕ ПРОВЕРЯЛ (калькулятор вызван 1 раз).
Детектор «распространение ошибки»: ошибка не распространилась.
<Контекст>
Агент считает итоговую цену заказа с НДС 20% и скидкой 10%.
Известно, что в этом прогоне калькулятор намеренно вернул неверное значение (тестовая порча).
Лимит прогона: 50 шагов, 1024 токена на ответ.
<Трасса>
{полный лог прогона: рассуждения агента, вызовы калькулятора, их ответы, финальный ответ}
Выполни по порядку:
1. ДОКАЗАТЕЛЬСТВО: процитируй из трассы фрагменты, на которых держится каждая метка. Если цитаты нет — так и напиши.
2. СРАВНЕНИЕ ЗНАЧЕНИЙ: выпиши три числа: что вернул калькулятор, какое значение агент использовал дальше, какое значение правильное. Они совпадают?
3. ПРИМЕНИМОСТЬ: имеет ли вопрос детектора ответ в этой трассе? Если ни порченое, ни исправленное значение больше не встречается, ответь «неопределённо».
4. ЦЕНЗУРА: закончился ли прогон финальным ответом или оборвался на лимите шагов или токенов? Оборванный прогон нельзя считать неправильным ответом.
5. ВЕРДИКТ по каждой метке: «подтверждена» / «оспорена» / «неприменима» / «неопределённо». Если оспорена, напиши поправку. Не заменяй оригинальную метку, а выведи обе рядом.
6. ПАТТЕРН: если ошибка метки типовая, назови её. Например: тихое исправление без повторного вызова; зацикленные вызовы, принятые за проверку; словесное признание ошибки без пересчёта.
Результат: Модель выдаст аудит по шести пунктам. Там будут цитаты из лога, таблица из трёх значений (что вернул инструмент / что использовал агент / как правильно) и вердикт по каждой метке. Если агент тихо исправил число, метка «не проверял» будет оспорена: восстановление видно в трассе, но явного повторного вызова не было. Если прогон оборван лимитом, модель отметит цензуру и не станет засчитывать его как ошибку.
Почему это работает
Слабость: агрегированная цифра прячет, что стоит за ней. Детектор отвечает на узкий вопрос («был ли повторный вызов?»), а читатель дашборда слышит широкий («проверял ли агент себя?»). Детектор может работать ровно как задумано и всё равно вводить в заблуждение.
Сильная сторона: LLM хорошо сопоставляет текст с утверждением. Если дать ей трассу и метку, она находит нужные фрагменты, выписывает три числа и сравнивает их. Для человека это рутина на полчаса на трассу, для модели — один запрос.
Как метод использует это: он заставляет сначала достать цитату и только потом судить. Метка без цитаты считается недоказанной. Дополнительные вопросы про применимость и цензуру отсекают целый класс ошибок: «ответа на вопрос в логе нет» и «прогон не закончился».
Рычаги управления:
- Число проверяемых трасс: сначала смотри сомнительные (подозрительные метки, оборванные прогоны, много вызовов подряд), потом случайную выборку.
- Список паттернов в пункте 6: добавь свои типовые ошибки детекторов, и модель будет искать именно их.
- Лимиты в <Контекст>: указывай реальные, чтобы модель отличала оборванный прогон от завершённого.
- Требуй «три значения» для любого инструмента, чей результат агент может молча заменить: калькулятора, поиска, API курсов.
Шаблон промпта
В статье готового промпта нет. Шаблон собран по принципу прозрачности измерения (C1) и по четырём типам ошибок, которые авторы нашли в ручной проверке.
Ты аудитор автоматических меток для агента. Не доверяй метке, проверь её по трассе.
<Метка>
{название детектора и его вердикт, например «перепроверка: НЕ ПРОВЕРЯЛ»}
<Контекст>
Задача агента: {что агент делает}
Инструмент: {какой инструмент вызывает}
Известные факты о прогоне: {например, была ли намеренная порча ответа инструмента}
Лимиты прогона: {шаги, токены}
<Трасса>
{полный лог одного прогона}
Выполни по порядку:
1. ДОКАЗАТЕЛЬСТВО: процитируй фрагменты трассы, на которых держится метка. Нет цитаты — напиши «доказательства нет».
2. СРАВНЕНИЕ ЗНАЧЕНИЙ: что вернул инструмент / какое значение агент использовал дальше / какое значение правильное.
3. ПРИМЕНИМОСТЬ: имеет ли вопрос детектора ответ в этой трассе? Если нет — «неопределённо».
4. ЦЕНЗУРА: прогон закончился финальным ответом или оборвался на лимите? Оборванный прогон — «нет данных», а не «неверно».
5. ВЕРДИКТ: «подтверждена» / «оспорена» / «неприменима» / «неопределённо». Если оспорена — поправка. Выведи оригинальную метку и поправку рядом.
6. ПАТТЕРН: если ошибка типовая, выбери из списка или назови свой:
- зацикленные вызовы приняты за проверку;
- словесное признание ошибки без пересчёта;
- повтор выражения внутри одного шага рассуждения принят за проверку;
- тихое исправление без повторного вызова;
- парсер не вытащил ответ из-за формата.
Подставь в {...} данные своего агента: задачу, инструмент, лимиты, лог и метку.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита автоматических меток по трассе агента. Адаптируй под мою задачу: [твоя задача и агент].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что агент делает, какие инструменты вызывает, какие метки или метрики ты получаешь и какие лимиты стоят. Эти ответы нужны, чтобы настроить пункты «ЦЕНЗУРА» и «ПАТТЕРН» под твой случай. Остальную структуру она возьмёт из шаблона.
Ограничения
⚠️ Один узкий домен: все эксперименты — школьная арифметика с калькулятором. В задачах со свободным текстом, категориями или субъективным результатом те же правила детекторов могут не работать, и типы ошибок будут другие.
⚠️ Малая выборка и один рецензент: по 30 трасс на модель, вручную разобрана половина (90 из 180), разбирал в основном один человек. Цифры по отдельным моделям — ориентир, не точная оценка.
⚠️ Правила детекторов переписывались после ручного просмотра: итоговое «совпадение с людьми» относится к уже исправленной версии. Первая версия ошибалась сильнее.
⚠️ Правила для лимитов нет: абляция сделана на двух моделях. Она показывает, что лимиты меняют результат (у одной модели от 21 до 27 из 30), но не говорит, какой лимит выбирать.
⚠️ Нет проверенного промпта: предложенный принцип прозрачности авторы не тестировали как отдельный приём. Они показали, где метки врут, и описали, что к ним приложить. Шаблон выше — наша сборка по этому принципу.
⚠️ Просмотрщик трасс требует кода: собственный интерфейс авторов для вашей задачи придётся заменять ручным разбором или цепочкой запросов.
Как исследовали
Исследователи взяли шесть современных моделей и дали каждой по 30 арифметических задач из GSM8K. Агент мог пользоваться калькулятором, но калькулятор иногда подсовывал правдоподобное неверное число: чуть сдвинутое или с переставленными цифрами. Модель об этом не знали. Так у авторов появились четыре независимые точки: что калькулятор должен был вернуть, что вернул, что модель использовала и что ответила.
Дальше авторы проверили три автоматических детектора: верен ли ответ, была ли перепроверка, распространилась ли порча. Половину трасс (90 из 180) разобрали вручную. Детекторы «верно» и «распространилась ли порча» совпали с человеком в 100% разобранных случаев. Детектор перепроверки совпал только в 67 из 81 (около 83%). Все 14 расхождений укладываются в четыре повторяющихся паттерна: зацикленные вызовы, словесное признание без пересчёта, повтор внутри одного шага и тихое исправление. Это и есть главный результат: ошибки не случайны, а систематичны.
Неожиданные находки. У nemotron-3-ultra 10 из 30 прогонов оборвались на лимите шагов, а все 20 завершённых были верными. Обычный подсчёт точности записал бы ему 67%, хотя на деле это «нет данных» по трети задач. Абляция лимитов показала, что у одной модели результат гуляет от 21 до 27 из 30, а у другой держится на 27–29. Для практики это значит, что «модель А лучше модели Б» может зависеть от лимитов запуска.
Адаптации и экстраполяции
🔧 Техника: добавить обязательную цитату в промпт LLM-судьи → судья не ставит метки «из головы».
В любой промпт судьи, который выдаёт «верно / неверно / проверил», добавь:
Каждый вердикт сопровождай дословной цитатой из лога. Если цитату найти нельзя, ставь «недостаточно данных», а не угадывай.
🔧 Техника: отдельная метка «обрыв» → оборванные прогоны не портят статистику.
В списке вердиктов судьи предусмотри третий вариант:
Вердикт: «верно» / «неверно» / «обрыв (лимит шагов или токенов)».
Экстраполяция: инструкция агенту — показывать подмену результата инструмента. Авторы предупреждают, что в задачах с реальными данными (сенсор, анализ, финансовая запись) тихая подмена может незаметно изменить весь процесс. В статье такой инструкции агенту не проверяли. Это идея для самостоятельной проверки, а не результат исследования.
Если результат инструмента кажется тебе неверным и ты хочешь использовать другое значение, не подменяй его молча. Напиши: «Инструмент вернул {X}. Я использую {Y}, потому что {причина}». Затем повторно вызови инструмент или явно сообщи, что не смог перепроверить.
Ресурсы
- Работа: What the Trace Shows and What the Label Says: Auditing Behavioral Detectors in Agent Evaluation
- Авторы: Idunnuoluwa A. Adeniji, Shilpika, Michael E. Papka — University of Illinois Chicago; Argonne National Laboratory (Argonne Leadership Computing Facility)
- Связанные работы в статье: Harness-Bench (Yao et al., 2026) — результат зависит от связки модель + среда запуска; AgentProp-Bench (Gurram, 2026) — распространение ошибок и сверка судей с людьми; Bhat et al. (2026) — аудит бенчмарков вызова инструментов; Tool-Memory Conflict (Cheng et al., 2025) — конфликт между знаниями модели и ответом инструмента.
- Бенчмарк: GSM8K (Cobbe et al., 2021)