TL;DR
LLM смотрит на форму запроса, а не на смысл. Если поля задачи можно заполнить — модель их заполнит, даже если выбранный инструмент или подход не решает вашу цель. Исследователи назвали это структурным смещением: модель сопоставляет атрибуты запроса с параметрами инструмента и считает это достаточным основанием для действия. Пример: пользователь спрашивает про PlayStation, а модель вызывает инструмент Nintendo Switch — потому что поля совпадают. Она игнорирует, что инструмент делает не то.
Это объясняет конкретную боль: вы даёте ChatGPT/Claude сложное задание, получаете красивый структурированный ответ — и только потом замечаете, что ответ мимо. Модель «заполнила шаблон», но вашу реальную цель не проверяла. Не «немного неточно» — а прямое промахивание: вы просили одно, получили другое в правильном формате.
Внутри модели работают два конкурирующих механизма: проверка смысла («действительно ли это решает цель?») и сопоставление структуры («можно ли заполнить параметры?»). Структурный механизм выигрывает почти всегда. Исправить это можно одним способом — явно добавить в промпт шаг семантической проверки: заставить модель сначала спросить «это решает мою цель?», и только потом действовать.
Схема метода
ПРОБЛЕМА (что происходит сейчас):
Запрос → "Структура совпадает?" → ДА → Выполнить
→ [проверка цели пропущена]
ИСПРАВЛЕНИЕ (что добавить в промпт):
Запрос → "Это действительно решает {цель}?" → ДА → Выполнить
→ НЕТ → Отказ + Объяснение
Всё выполняется в одном промпте — добавляется один шаг-проверка.
Пример применения
Задача: Вы ведёте Telegram-канал и просите Claude написать разбор конкурента — сервиса «СберМаркет». Ваша реальная цель — понять, стоит ли с ним конкурировать по цене или нет. Без семантической проверки модель выдаст красивый SWOT-анализ с заполненными полями: сильные стороны, слабые, возможности, угрозы. Структура — идеальная. Ответ на вашу цель — нет.
Промпт:
Я хочу понять: стоит ли мне конкурировать с СберМаркетом по цене
на доставку продуктов в Москве в сегменте до 1500 рублей?
Моя цель: принять решение ДА или НЕТ с коротким обоснованием.
Прежде чем начать анализ — одним предложением скажи:
этот анализ действительно поможет принять решение о ценовой конкуренции,
или он охватывает что-то другое?
Если да — продолжай. Если нет — скажи что именно не так
и уточни задачу.
Результат: Модель сначала явно подтвердит (или нет), что её анализ бьёт в цель. Если вопрос сформулирован расплывчато — она это скажет до того, как потратит 500 слов на нерелевантный SWOT. Вы получаете либо точный ответ на цель, либо уточняющий диалог — вместо красивого но бесполезного текста.
Почему это работает
LLM генерирует следующий токен по паттернам. Когда в промпте есть структура (поля, параметры, шаблон) — у модели есть сильные паттерны как её заполнять. Это «дешёвый» путь: атрибуты есть, параметры совпадают — действуй. Проверять смысловое соответствие дороже: нужно удерживать цель, сопоставлять с функцией, принимать решение об отказе.
Структура бьёт смысл, потому что она видна в тексте. «Название игры» + «регион» — конкретные, явные, легко сопоставляемые. «Это действительно для PlayStation, а не Nintendo» — требует суждения, а не сопоставления. Модель скользит по поверхности формы, не ныряя в суть.
Явный вопрос-проверка перед действием перестраивает порядок генерации. Когда вы просите модель сначала ответить «это решает мою цель?» — вы буквально вставляете семантический барьер перед структурным заполнением. Модель вынуждена сгенерировать суждение о соответствии раньше, чем приступит к исполнению. Это работает как стоп-сигнал: дай ответ на вопрос о смысле — потом действуй.
Рычаги управления: - Явность цели → чем точнее вы формулируете ЗАЧЕМ (не ЧТО), тем сильнее семантический якорь - Позиция проверки → вопрос «это решает цель?» должен быть ДО, не После инструкций - Формат ответа на проверку → попросите дать ответ одним предложением — это не даёт модели «проскочить» проверку косвенно - Явный отказ как ОК → скажите «если нет — так и скажи», иначе модель будет искать способ ответить «да» в любом случае
Шаблон промпта
Моя цель: {конкретная цель — что должно произойти в результате}.
Задача: {что нужно сделать}.
Прежде чем начать — одним предложением ответь:
эта задача действительно ведёт к цели "{конкретная цель}",
или она решает что-то другое?
Если да — выполняй.
Если нет — объясни несоответствие и предложи что изменить в задаче.
Что подставлять:
- {конкретная цель} — итоговое решение или результат, который нужен: «принять решение о найме», «написать текст для конкретной аудитории», «выбрать поставщика»
- {что нужно сделать} — конкретная задача: «сравни три кандидата», «напиши пост», «проанализируй условия»
🚀 Быстрый старт — вставь в чат:
Вот шаблон для защиты от структурного смещения в LLM.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит о вашей реальной цели и задаче — потому что без разделения «зачем» и «что» шаблон не работает. Она возьмёт паттерн и встроит семантическую проверку в ваш конкретный промпт.
Ограничения
⚠️ Сложные цепочки задач: Чем длиннее инструкция и больше шагов — тем сложнее удерживать цель через все шаги. Для многоходовых задач проверку нужно добавлять на каждый значимый шаг отдельно.
⚠️ Работает хуже с расплывчатой целью: Если вы сами не можете чётко сформулировать цель одним предложением — проверка не поможет. Модель согласится с чем угодно. Сначала уточните цель для себя.
⚠️ Не панацея для агентных систем: Если вы строите автоматизированные цепочки с реальными инструментами (коды, API, базы данных) — одного промпта недостаточно. Там нужны технические решения, описанные в исследовании. Статья для чата решает только «поверхностный» слой проблемы.
⚠️ Модели по-прежнему склонны говорить «да»: Даже с явным вопросом-проверкой некоторые модели стараются найти способ ответить положительно. Добавьте: «Лучше честный отказ, чем неточное выполнение» — это снижает давление на «согласие».
Ресурсы
Do LLMs Know Tool Irrelevance? Demystifying Structural Alignment Bias in Tool Invocations https://github.com/along-l/irrelevant-tool
Авторы: Yilong Liu, Xixun Lin, Pengfei Cao, Ge Zhang, Fang Fang, Yanan Cao Организации: Institute of Information Engineering (Chinese Academy of Sciences), School of Cyber Security (UCAS), Institute of Automation (CAS), Donghua University