TL;DR
Hallucination Escape («утечка галлюцинаций») — это находка о том, как ведут себя агенты с инструментами. У модели есть собственные привычки: какой инструмент вызвать на такой запрос и как назвать аргументы. Если ваш список инструментов с этими привычками совпадает, ошибок мало. Если нет, модель тянет к «привычному» инструменту, даже когда в списке лежит правильный, но с другим именем.
На практике это выглядит так. Агент отлично работает на стандартной конфигурации, вы переименовали инструмент или переписали его описание, и доля неверных выборов подскакивает с ~20% до ~50%. Причина проста: модель «в голове» уже решила, что на этот запрос нужен инструмент с таким-то именем, и описание перед ней отходит на второй план. Все пять существующих методов защиты (дообучение и вмешательство во внутренности модели) чинят ошибки на конфигурации, под которую их настраивали. На остальных конфигурациях они усиливают привычки модели и добавляют ошибок. В среднем по всем конфигурациям они не лучше обычной модели.
Авторы предлагают EscapeGuard, который определяет конфликт по внутренним сигналам модели и усиливает внимание к текущему списку инструментов. Для читателя он недоступен: нужен доступ к активациям модели. Полезны два других результата: вы узнаёте, когда агент ломается, и получаете простой способ проверить, не конфликтуют ли ваши имена инструментов с привычками модели.
⚠️ В присланном тексте раздел 5 (описание EscapeGuard) обрывается. Метод разобран только по тому, что сказано во введении и аннотации.
Схема метода
Диагностика привычек модели (closed-book elicitation, «проверка без списка инструментов») — единственная часть, которую можно повторить без доступа к модели. Она взята из раздела 4.1.
ШАГ 1: Дай модели запрос БЕЗ списка инструментов → «какой инструмент ты бы вызвал?»
Повтори ~10 раз (температура ~0.7)
ШАГ 2: Посчитай, как часто повторяется самый частый ответ → сила привычки
(0.7+ = сильная привычка, ~0.2 = её почти нет)
ШАГ 3: Дай модели тот же запрос + имя инструмента БЕЗ схемы → «какие аргументы?»
Сравни наборы аргументов между прогонами
ШАГ 4: Сравни привычные имена и аргументы с вашими
→ есть расхождение = зона риска
Шаги 1–3 выполняются отдельными запросами. Шаг 4 делается вручную, или попросите саму модель составить таблицу расхождений.
Пример применения
Задача: Вы настраиваете ИИ-агента для отдела продаж в Битрикс24. Инструмент для создания сделки внутренне назван bx_deal_upsert_v2, аргументы — crm_entity_payload и assignee_ref. Агент то создаёт сделку, то пытается вызвать несуществующий create_deal. Нужно понять, виновато ли именно ваше нестандартное именование.
Промпт (запускается 10 раз в новых чатах, без списка инструментов):
Ты — ИИ-ассистент менеджера по продажам. У тебя есть доступ к CRM.
Запрос клиента: «Заведи сделку на ООО "Ромашка", 450 000 ₽, ответственный — Марина, дедлайн 20 июня».
Не вызывай никакие инструменты. Ответь одной строкой в формате:
ИНСТРУМЕНТ: <имя функции, которую ты бы вызвал>
АРГУМЕНТЫ: <список имён аргументов>
Результат: Вы получите 10 коротких ответов. Если модель в большинстве случаев называет что-то вроде create_deal с аргументами title, amount, responsible, привычка сильная. Ваши bx_deal_upsert_v2 и crm_entity_payload с ней конфликтуют: по данным статьи, именно такие случаи дают самый высокий рост ошибок. Если ответы разбросаны, привычка слабая и имена, скорее всего, не главная причина сбоев. Дальше сверяйте результат с вашим списком инструментов.
Почему это работает
Слабость. Модель не читает список инструментов «с нуля». У неё есть заученный образ: на такой запрос — такой-то вызов. Чем он устойчивее, тем сильнее тянет к привычному имени. Когда конфигурация с привычкой совпадает, всё хорошо. Когда нет, ошибок кратно больше, и чем сильнее привычка, тем хуже.
Что умеет модель. Её привычки можно измерить без доступа к внутренностям: достаточно задать вопрос без списка инструментов и посмотреть, насколько ответы повторяются. Авторы показали, что у шести разных моделей средняя сила привычки выбора инструмента составляет 0,61–0,78.
Как это даёт рычаги.
- Имена инструментов → чем ближе к «привычным» (create_deal, get_weather), тем меньше конфликт.
- Имена аргументов → то же самое, и здесь эффект сильный. Выбор значений аргументов привычками почти не затронут.
- Описание → в статье изменение описания дало рост ошибок поменьше, чем смена имени.
- Проверка при каждом изменении → ошибки не перетекают сами. Любая правка списка инструментов требует нового прогона на тестовых запросах.
Шаблон промпта
Готовых промптов в статье нет. Ниже — шаблон проверки привычек из шагов 1–3. Он повторяет методику авторов, но формулировка моя.
Ты — {роль_агента}. У тебя есть доступ к системе {название_системы}.
Запрос пользователя: «{типичный_запрос}».
Не вызывай никакие инструменты и не проси список. Ответь строго в формате:
ИНСТРУМЕНТ: <имя функции, которую ты бы вызвал>
АРГУМЕНТЫ: <имена аргументов через запятую>
Подставьте:
- {роль_агента} — как в вашем системном промпте;
- {типичный_запрос} — реальный запрос из вашего потока;
- запустите ~10 раз в новых чатах, лучше с температурой около 0,7 (в API или настройках автоматизации).
Проверку можно сделать и в обычном чате. Нужно только каждый раз начинать новый диалог.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки привычек модели по именам инструментов. Адаптируй под мою задачу: {опиши своего агента и его инструменты}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про роль агента, типичные запросы и список инструментов с аргументами. Это нужно, чтобы запрос был похож на реальный поток, а после прогонов можно было сравнить «привычные» имена с вашими. Саму проверку запускайте в новых чатах. Один чат с десятью повторами не покажет разброс ответов.
Ограничения
⚠️ Основной метод недоступен: EscapeGuard работает через внутренние сигналы модели и усиление внимания. В ChatGPT, Claude, Gemini и готовых агентах до этого не добраться.
⚠️ Практические советы не проверены: авторы показали, что конфликт имён повышает ошибки. Но «переименуй инструмент» или «добавь строку в системный промпт» как способы исправления они не тестировали. Это вывод из их данных, а не результат их эксперимента.
⚠️ Малые модели: основные эксперименты — на двух открытых моделях 8–9 млрд параметров. Крупные современные модели (Claude, GPT, Gemini) могут быть устойчивее. Шесть моделей участвовали только в проверке привычек.
⚠️ Аргументы почти не лечатся: выдуманные имена аргументов и неверные значения существующие методы не меняют. Рост ошибок при смене аргументов связан в основном с выбором инструмента.
⚠️ Корреляции: связь «сильная привычка → больше ошибок» показана корреляцией и внутренними пробами, а не прямым вмешательством.
Как исследовали
Идея была простой: проверить, держатся ли заявленные улучшения, если чуть поменять условия. Команда взяла пять известных методов снижения «галлюцинаций инструментов» и прогнала их на шести конфигурациях. Это оригинальные имена, замена имени, переписанное описание, переименованные аргументы, всё сразу и добавленные похожие инструменты-«двойники». Каждый вариант сохранял правильное решение. Тесты шли на ~1000 примеров из BFCL и Seal-Tools, с тремя запусками. Дополнительно составили 120 пар запросов под один и тот же список инструментов, чтобы понять, не ломает ли починка одного запроса соседний.
Результат оказался неожиданным. Методы снижали ошибки на стандартной конфигурации в среднем на 7,5 п. п., но на остальных пяти повышали их суммарно на 13,0 п. п. Среднее по конфигурациям у каждого метода оказалось хуже, чем у базовой модели. По запросам: примерно 40% починенных запросов тут же порождали новую ошибку на парном запросе.
Чтобы объяснить причину, авторы спросили модели без списка инструментов, что те вызвали бы. Ответы оказались устойчивыми, то есть привычки есть. Потом сопоставили привычки с конфигурацией и увидели закономерность: при совпадении ошибок мало независимо от силы привычки, при конфликте ошибки растут вместе с ней. Потом это подтвердили по внутренним сигналам модели: пробы определяли конфликт с точностью около 85%. Наконец показали, что существующие методы усиливают привычки и тем самым растят «утечку». Для практики главный вывод в том, что успех на одном наборе инструментов не гарантирует успеха на другом.
Адаптации и экстраполяции
🔧 Техника: добавить сверку в системный промпт → ориентир на текущий список
Идея повторяет логику EscapeGuard («вернуть внимание к текущей конфигурации»), но реализована текстом. Это не метод статьи и не проверено. Перед запуском нужно сравнить с базовым промптом на 20–30 реальных запросах.
Перед каждым вызовом сверься со списком инструментов ниже. Используй ТОЛЬКО имена и аргументы из этого списка, даже если привычное тебе имя отличается. Если подходящего инструмента нет — напиши об этом, не придумывай.
🔧 Техника: добавить в описание инструмента «привычное» название → меньше конфликта
Тоже мой вывод из данных статьи, не проверенный авторами. Если переименовать нельзя, можно упомянуть привычное имя в описании: «Создаёт сделку в CRM (аналог create_deal)».
Ресурсы
- Работа: Understanding and Mitigating Hallucination Escape in Tool-Using LLM Agents (Preprint)
- Авторы: Peigui Qi, Kunsheng Tang, Yide Song, Weiming Zhang, Nenghai Yu (University of Science and Technology of China; University of Washington)
- Бенчмарки: BFCL V3, Seal-Tools, Glaive Function Calling V2
- Сравнивали с методами: Relign, PALADIN, Gorilla, LinSteer, PRISMS