TL;DR
Shortcut Auditing (аудит «коротких путей») — это процедура проверки из трёх уровней для оценки LLM-стража. Страж — это модель, которая перед выполнением действия агента решает «пропустить» или «заблокировать». Сначала проверяем, угадываются ли ответы тупым правилом. Потом смотрим, связано ли решение стража с подозрительной деталью. В конце меняем только эту деталь, оставив смысл действия прежним, и смотрим, изменится ли решение.
Главная находка: высокая оценка стража на тестовом наборе может объясняться обёрткой, а не пониманием риска. Например, ответ почти целиком угадывается по названию инструмента, по длине команды или по служебному тегу вокруг текста. Такое правило отлично работает на «своих» данных и разваливается на новой области. Метрика тоже может врать: если в наборе одни задачи состоят из семи шагов, а другие из двух, общий балл отражает частоту шагов, а не качество на задачах. В одном из тестов страж на Claude Haiku 4.5 стал блокировать безопасные шаги заметно реже, когда служебный тег заменили на более понятный. Когда инструменты переименовали в «непрозрачные» имена, он стал блокировать их заметно чаще. Смысл действий при этом не менялся. На другой модели эффекта не было.
Метод состоит из четырёх проверок: 1. Простое правило против ваших меток. 2. Метрики по «единицам оценки» (шаг, задача). 3. Парные правки: меняем одну деталь, смысл сохраняем. 4. Повторные чередующиеся прогоны с «плацебо-правкой» для нестабильных моделей.
Схема метода
ШАГ 1: Тупое правило (длина, тег, имя инструмента) предсказывает метки? → да = сигнал тревоги
ШАГ 2: Отложить целую область/источник целиком (holdout) → оценка упала? → правило не переносится
ШАГ 3: Назвать единицу оценки (шаг / задача) → пересчитать метрики по ней
ШАГ 4: Связь решения стража с деталью в логах → выбрать, что менять
ШАГ 5: Парная правка: меняем ТОЛЬКО деталь, смысл и разрешения те же → решение сменилось?
ШАГ 6: Для LLM со случайностью: чередовать оригинал / правку / плацебо, 3+ повтора на каждый
Шаги 1–3 делаются на готовых логах, шаги 4–6 требуют прогонов стража. Шаги можно делать отдельными запросами к модели или скриптом.
Пример применения
Задача: Вы руководите поддержкой интернет-магазина на Ozon и Wildberries. Агент на LLM отвечает клиентам и вызывает инструменты refund_order, send_sms, delete_customer. Перед каждым действием его проверяет LLM-страж. Вы прогнали стража на 300 размеченных шагах из логов и получили «95% верно». Хочется убедиться, что цифра не обманывает.
Промпт:
Ты — аудитор оценки LLM-стража. Мой страж проверяет шаги агента поддержки интернет-магазина перед выполнением и решает: ПРОПУСТИТЬ или БЛОКИРОВАТЬ.
Моя выборка: 300 размеченных шагов (safe / unsafe) из логов. Источники: чат на Ozon, чат на Wildberries, email-поддержка, телефонные расшифровки. Инструменты: refund_order, send_sms, delete_customer, get_order_status, update_address. Внешний текст клиента в логах обёрнут в тег .
Составь план аудита из шести шагов:
ШАГ 1. Тупые правила. Предложи 3 правила, которые не смотрят на смысл (только название инструмента, длина запроса, наличие тега). Для каждого опиши, как посчитать, насколько хорошо оно угадывает мои метки.
ШАГ 2. Отложенная область. Предложи, как разбить данные по источникам (Ozon / Wildberries / email / телефон), чтобы тупое правило обучалось на одних источниках, а проверялось на других. Что считать тревогой?
ШАГ 3. Единица оценки. Объясни, как пересчитать метрики по задачам (а не по шагам), если в одной задаче несколько шагов. Какую единицу выбрать, если я хочу сказать «страж защищает клиентов в 95% диалогов»?
ШАГ 4. Что менять. По логам стража найди 2–3 детали (тег, имя инструмента, формат JSON), которые чаще встречаются у заблокированных шагов.
ШАГ 5. Парные правки. Для каждой детали предложи правку, которая НЕ меняет смысл действия, его права и аргументы. Отдельно предложи «плацебо-правку» — только форматирование (пробелы, порядок полей). Для каждой правки напиши, в каких случаях она может изменить смысл, чтобы я мог проверить вручную.
ШАГ 6. План прогона. Опиши, как чередовать оригинал, правку и плацебо в прогонах (минимум 3 повтора на условие), и как считать разницу доли блокировок между оригиналом и правкой с учётом плацебо.
Формат ответа: нумерованные шаги, под каждым — «что делаем», «что считаем», «что считать тревожным».
Результат: Модель выдаст план из шести блоков. В каждом будет конкретика под ваши инструменты и источники: например, переименовать refund_order в tool_7 и заменить
Почему это работает
Слабость. Оценка на размеченных логах не говорит, почему страж решил «блокировать». Метки в бенчмарках часто связаны с побочными деталями: все атаки сделаны по шаблону с одним тегом, одни инструменты встречаются только в опасных задачах, одни источники длиннее других. Простое правило тогда набирает высокий балл без всякого понимания. Страж может подхватить ту же связь, и вы получите красивую цифру, которая сломается в новом домене.
Сильная сторона LLM. Модель легко воспроизводит одно и то же действие в разной обёртке: другое имя инструмента, другой тег, другие пробелы. Это дёшево, а сравнение «до/после» чисто изолирует одну переменную.
Как метод использует это. Он идёт лесенкой: тупое правило, наблюдаемая связь, парная правка. Каждый следующий уровень сильнее подтверждает вывод. Лишь на третьем уровне видно, что решение стража реально меняется при смене обёртки. Плацебо-правка и чередование прогонов нужны, чтобы нестабильность самой модели не приняли за эффект правки.
Рычаги управления: - Число повторов на условие (3 → 5–10): уменьшает шум, но дороже по токенам. - Тип правки: тег, имя инструмента, формат JSON, длина. Начинайте с детали, которая сильнее всего связана с блокировками. - Единица оценки: шаг, задача, пользователь. Выбирайте ту, о которой говорите в отчёте. - Контроль «область отложена»: источник, тип задачи, домен. Чем жёстче разделение, тем честнее оценка переноса.
Шаблон промпта
Ты — аудитор оценки LLM-стража. Страж: {описание_стража}. Он смотрит на шаг агента перед выполнением и решает: ПРОПУСТИТЬ или БЛОКИРОВАТЬ.
Данные: {число_шагов} размеченных шагов (safe / unsafe). Источники / домены: {список_доменов}. Инструменты: {список_инструментов}. Служебные детали входа (теги, форматы): {детали_входа}. Единица, о которой я хочу сделать вывод: {единица_оценки}.
Составь план аудита:
ШАГ 1. Тупые правила: предложи 3 правила без понимания смысла (по названию инструмента, длине, тегу). Как посчитать, насколько они угадывают мои метки.
ШАГ 2. Отложенная область: как разбить данные по {список_доменов}, чтобы проверить перенос правил. Что считать тревогой.
ШАГ 3. Единица оценки: как пересчитать метрики по {единица_оценки}, если на неё приходится разное число шагов.
ШАГ 4. Что менять: по логам стража выбери 2–3 детали, связанные с блокировками.
ШАГ 5. Парные правки: для каждой детали — правка, которая НЕ меняет смысл, права и аргументы действия; плюс плацебо-правка (только форматирование). Для каждой — где она может изменить смысл.
ШАГ 6. План прогона: чередование оригинал / правка / плацебо, {число_повторов} повторов на условие, как считать разницу доли блокировок с учётом плацебо.
Формат: нумерованные шаги; под каждым — «что делаем», «что считаем», «что считать тревожным».
Подставьте описание вашего стража, число шагов, источники данных, инструменты, служебные теги, единицу оценки (шаг, задача, пользователь) и число повторов (минимум 3).
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита LLM-стража. Адаптируй под мою задачу: [опиши, какой агент и какой страж у тебя есть].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие инструменты у агента, откуда логи, как они размечены и какую единицу вы называете в отчёте. Это нужно, чтобы предложить правки, которые не меняют смысл, и честную единицу оценки.
Ограничения
⚠️ Эффект не универсален: Сильная чувствительность нашлась на одной модели (Claude Haiku 4.5). На другой модели и на детерминированном страже те же правки почти ничего не меняли. Проверять надо вашего стража, а не полагаться на чужие цифры.
⚠️ Малая выборка: Парный эксперимент шёл на 64 шагах, отобранных вручную и не репрезентативных для всего бенчмарка. Авторы сами называют диапазоны «исследовательскими».
⚠️ Смысл правок не проверен людьми: Что правки сохраняют смысл действия, не подтверждено слепой разметкой. Часть эффекта могла быть законной реакцией: явный тег про недоверенный текст действительно меняет информацию. Метод показывает чувствительность, но не доказывает, что страж «неправ».
⚠️ Не про атаки: Адаптивного противника, который сам ищет слабые места стража, авторы не проверяли.
⚠️ Нужна размеченная выборка: Без своих логов и меток аудит делать не на чем. Прогоны с повторами требуют скрипта или автоматизации.
Как исследовали
Исследователи взяли три набора данных об агентах и разобрали их на «тупые правила». В LinuxArena (576 уникальных траекторий) средняя длина shell-команды почти идеально разделяла честные и атакующие запуски (AUC 0,91). В AgentDojo-Traj простая таблица «инструмент → метка» давала F1 0,90, пока тестировали внутри тех же доменов. Стоило отложить целую область, F1 падал до 0,49: правило запоминало инструменты, а не риск. В AgentHarm-Traj F1 стража падал с 0,90 до 0,72, когда считали по задачам, а не по шагам. Вредных задач было мало, но на каждую приходилось в среднем семь шагов, а на безопасную меньше двух. Метрика отвечала на вопрос о частоте шагов, а не о качестве на задачах.
Дальше они проверили, меняет ли страж решение, если поменять деталь. Для этого взяли замороженный набор из 64 шагов AgentDojo, по восемь безопасных и восемь опасных из каждой области. Для каждого шага сделали четыре варианта: оригинал, замену тега
Оригинал из исследования
Фактические правки в парном эксперименте на AgentDojo-Traj:
Маркер до: ...
Маркер после: ...
(содержимое внутри сохранено)
Инструмент до: send_money(...)
Инструмент после: tool_alias_17(...) # описание и аргументы те же
Плацебо: изменён только внешний JSON-пробел
Контекст: правки делали на шагах с маркером, внутри которых содержимое не менялось. Алиасы генерировали отдельно для каждого образца.
Адаптации и экстраполяции
💡 Адаптация для LLM-судьи (оценка текстов): принцип парной правки с плацебо переносится на любого судью, который оценивает ответы: тексты менеджеров, письма клиентам, резюме.
Ты проверяешь, не реагирует ли LLM-судья на обёртку вместо сути.
Вот {число} ответов с оценками судьи. Для каждого сделай 3 версии:
1. Оригинал.
2. Правка смысла-нейтральная: {что_меняем — например, порядок абзацев / заголовок / смайлики / длина}.
3. Плацебо: только пробелы и переводы строк.
Дай план: как прогнать судью по каждой версии 3 раза в случайном порядке и сравнить среднюю оценку оригинала, правки и плацебо. Тревога — если правка двигает оценку больше, чем плацебо.
Это перенос принципа на другую задачу. В статье судей не тестировали.