TL;DR
Исследователи из Tsinghua University обнаружили парадокс: чем больше явных ограничений в промпте, тем хуже модель решает саму задачу — даже если эти ограничения абсолютно выполнимы. Они проверили необычную гипотезу: взяли успешные ответы моделей, извлекли из них характеристики (стиль, структуру, длину), превратили в явные требования и добавили обратно в промпт. Логика: модель УЖЕ делала это сама, значит справится с явным требованием. Результат оказался противоположным.
Главная находка: добавление 5 ограничений снижает успешность решения задач на 15-40% даже у топовых моделей. Claude-Sonnet-4.5 теряет 15% производительности на multi-hop вопросах, модели среднего размера (30-70B) сохраняют только 65-85% изначальной точности. Хуже всего с кодом: семь моделей просели ниже 60%. При этом модели выполняют сами ограничения на 94%+ — проблема не в следовании инструкциям, а в том, что избыток явных требований разрушает логику решения. Требование "используй 15 слов" или "начни с вопроса" оттягивает внимание модели от сути задачи.
Механизм простой: модель фокусируется на форме, теряя содержание. Анализ attention scores показал: в провальных случаях модель уделяет значительно больше внимания токенам ограничений, особенно к концу генерации. Вместо рассуждения над задачей она "вспоминает" про требования к формату — и ошибается либо в логике (reasoning error), либо в финальном выводе (output specification error). Практический вывод: меньше явных требований = лучше результат.
Схема проблемы
Стандартный подход:
Промпт = Задача + Ограничение_1 + Ограничение_2 + ... + Ограничение_5
Результат = Модель фокусируется на ограничениях → теряет фокус на задаче
Что происходит: - Модель БЕЗ ограничений → решает корректно - Та же модель С ограничениями (извлечёнными из её же ответа) → проваливает задачу - При этом ограничения выполняет (формат соблюдён), но ответ неверный
Типы ограничений (от худших к лучшим): - Length (длина) → SUSTAINSCORE 77.2% - Keyword (ключевые слова) → 77.4% - Style (стиль) → 82.3% - Method (метод решения) → 84.1% - Structure (структура) → 85.0%
Пример применения
Задача: Написать функцию на Python для парсинга объявлений с Авито — извлечь цену, название, ссылку из HTML.
❌ Промпт с избытком ограничений:
Напиши функцию на Python для парсинга объявлений с Авито.
Требования:
- Функция должна содержать ровно 25 строк кода
- Используй библиотеку BeautifulSoup
- Начни с docstring
- Добавь обработку исключений
- Стиль: подробные комментарии к каждому шагу
- Верни результат как список словарей
✅ Промпт без избыточных ограничений:
Напиши функцию на Python для парсинга объявлений с Авито.
Нужно извлечь: цену, название, ссылку из HTML-блока объявления.
Используй BeautifulSoup.
Результат:
В первом случае модель будет: - Считать строки кода вместо фокуса на логике - Раздувать комментарии для "подробного стиля" - Возможно, пропустит граничные случаи (нет цены, битый HTML) - Может нарушить логику парсинга ради соблюдения лимита строк
Во втором случае модель: - Сфокусируется на корректной логике извлечения данных - Сама выберет адекватную длину и стиль - Скорее всего, добавит нужные проверки без явного требования
Парадокс: если первый промпт сгенерирует рабочий код, и вы извлечёте из него требования (25 строк, docstring, стиль комментариев) и добавите их явно — модель может провалить задачу при повторной генерации.
Почему это работает (точнее, не работает)
Слабость LLM: Модели работают как авторегрессионные генераторы — предсказывают следующий токен на основе предыдущих. При генерации каждого токена attention-механизм распределяет "внимание" между всеми токенами контекста. Чем больше явных ограничений в промпте, тем больше токенов-требований в контексте, тем сильнее модель "отвлекается" на проверку "а соблюдаю ли я ограничение?" вместо "правильно ли я решаю задачу?".
Исследователи измерили Constraint Attention Score — долю внимания, которую модель уделяет токенам ограничений во время генерации. Обнаружили: в провальных случаях модель уделяет значительно больше внимания ограничениям, особенно на поздних стадиях генерации. Вместо завершения логической цепочки ("значит ответ = X") модель проверяет "а вписался ли я в 200 слов?", "использовал ли нужное слово?".
Два типа ошибок:
Reasoning Error — модель сбивается с правильного пути рассуждений. Пример: в математической задаче начинает подгонять решение под требование длины, пропускает шаги.
Output Specification Error — модель получает правильный ответ, но портит его при "упаковке" в требуемый формат. Пример: в коде правильный алгоритм, но пропущен граничный случай, потому что модель думала про лимит строк.
Сильная сторона LLM: Модели отлично решают задачи, когда фокусируются на сути, не на форме. Без явных ограничений модель сама выбирает адекватную длину, стиль, структуру — и это работает лучше.
Практический вывод: Чем минималистичнее промпт, тем лучше. Указывайте только критичные ограничения (например, формат вывода для парсинга). Всё остальное — стиль, длину, структуру — модель сделает сама и, скорее всего, лучше.
Принципы применения
Как НЕ надо (избыток ограничений):
{задача}
Требования:
- Длина: {число} слов/строк/абзацев
- Стиль: {описание стиля}
- Структура: {требования к структуре}
- Включи слова: {список ключевых слов}
- Метод: {конкретный подход к решению}
Как НАДО (минимум ограничений):
{задача}
{1-2 критичных требования, если они действительно необходимы}
Критичное требование — то, без которого результат бесполезен: - Формат вывода для автоматической обработки (JSON, CSV) - Технологический стек (конкретная библиотека, если важна совместимость) - Жёсткое ограничение по объёму (твит на 280 символов, title-тег на 60)
НЕкритичное требование — то, что модель сделает сама: - "Напиши в деловом стиле" — модель сама выберет адекватный стиль - "Используй 3 абзаца" — модель сама структурирует - "Добавь примеры" — если они нужны для полноты, модель добавит
Рычаги управления
1. Количество ограничений → токены и фокус
Наибольшее падение качества — при добавлении первых 5 ограничений. После плато.
Рычаг: Держите число явных требований ≤3. Каждое дополнительное ограничение — это риск потери фокуса.
2. Тип ограничений → разная токсичность
Жёсткие (hard) ограничения — длина, ключевые слова — бьют сильнее (77.2-77.4% SUSTAINSCORE).
Мягкие (soft) ограничения — структура, метод — бьют слабее (84.1-85.0%).
Рычаг: Если ограничение нужно, выбирайте soft (семантические), а не hard (синтаксические).
3. Порядок инструкций → приоритизация
Исследователи проверили разные структуры: - Constraint → Task (ограничение вперёд) - Task → Constraint (задача вперёд) - "Сначала реши правильно, потом оформи"
Результат: Все варианты показали падение. Порядок не спасает.
Рычаг: Вместо перестановки — убирайте лишнее.
4. Явная приоритизация → иллюзия помощи
Шаблон "Сначала реши задачу правильно, потом оформи по требованиям" не помог.
Рычаг: Не полагайтесь на "магические фразы". Если ограничение избыточно — удалите его.
Метапромпт для оптимизации
🚀 Быстрый старт — вставь в чат:
Вот мой промпт:
[вставь свой промпт]
Проанализируй его и удали ИЗБЫТОЧНЫЕ ограничения — те, которые модель выполнит
сама без явного указания. Оставь только КРИТИЧНЫЕ — без которых результат
будет бесполезен.
Правило: если требование касается длины, стиля, структуры или "как именно делать" —
это кандидат на удаление. Если требование касается формата данных для обработки
или технического стека — это критичное.
Выдай оптимизированный промпт и объясни что убрал и почему.
Модель проанализирует ваш промпт, уберёт лишние ограничения и объяснит логику. Вы получите минималистичный промпт, который даст лучший результат.
Ограничения
⚠️ Не для критичных форматов: Если результат должен парситься кодом (JSON, XML, CSV с точной структурой) — ограничение необходимо. Исследование про избыток НЕкритичных требований.
⚠️ Не для твёрдых лимитов: Твит на 280 символов, title-тег на 60 — это объективные ограничения среды. Их нельзя убрать.
⚠️ Математика чувствительна к методу: Требование "реши через систему уравнений" может быть критичным, если другой метод даст неверный ответ. Но требование "объясни в 3 абзаца" — избыточно.
⚠️ Код максимально чувствителен: Снижение качества на коде достигает 30-50% при 5 ограничениях. Особенно опасны keyword constraints — ограничения на использование конкретных слов/функций могут сломать логику.
⚠️ CoT-модели склонны к Output Specification Error: Модели с длинными цепочками рассуждений правильно решают задачу, но портят финальный ответ при попытке "упаковать" его в формат. Если используете o1/QwQ — давайте им свободу в финальном выводе.
Как исследовали
Команда из Tsinghua University проверила парадоксальную идею: а что если модель проваливает задачу НЕ потому что ограничения слишком сложные, а просто потому что они явные?
Дизайн эксперимента:
Взяли 1000 задач по математике (GSM8K, SVAMP, OlympiadBench, MATH500), 1200 multi-hop вопросов (HotpotQA, 2WikiMultiHop, Musique), 319 задач на код (HumanEval, MCEval).
Прогнали модели БЕЗ ограничений, собрали только успешные ответы.
Извлекли из каждого успешного ответа самоочевидные ограничения (self-evident constraints):
- Hard constraints (длина, ключевые слова) — через Python-скрипты извлекли точные параметры
- Soft constraints (метод, стиль, структура) — через GPT-5 описали характеристики
Добавили эти ограничения обратно в промпт и прогнали снова.
Ключевая логика: Модель УЖЕ делала это в успешном ответе → значит МОЖЕТ → если провалится с явным требованием, это интерференция instruction following, не неспособность.
Результаты удивили:
- Claude-Sonnet-4.5 (топ рынка) потерял 15% на multi-hop QA
- Модели 30-70B сохранили только 65-85% производительности
- GPT-4.1-MINI: 90.9% на instruction following, 77.1% accuracy на коде, но только 50.8% SUSTAINSCORE на коде
- Семь моделей просели ниже 60% на коде
Механистический инсайт: Замерили attention patterns — в провальных кейсах модель уделяет значительно больше внимания токенам ограничений, особенно на поздних стадиях генерации. График показывает: обе кривые (success/failure) растут к концу генерации, но failure-кривая растёт резко круче — модель перефокусируется на проверку ограничений вместо завершения логики.
Интересная находка: Проверили влияние post-training. RL (reinforcement learning) одновременно поднимает И task performance, И robustness. А вот supervised fine-tuning на длинных CoT-данных поднимает performance, но значительно снижает robustness — модели становятся более хрупкими к ограничениям.
Валидация: Проверили что падение качества НЕ от: - Длины промпта (перефразировали без ограничений — качество ОК) - Порядка инструкций (меняли структуру — не помогло) - Типа ограничений (все типы дают падение, разброс небольшой)
Практический вывод: Это не артефакт эксперимента, это фундаментальное свойство текущих LLM — избыток явных требований ломает фокус на задаче.
Ресурсы
On the Paradoxical Interference between Instruction-Following and Task Solving
Yunjia Qi, Hao Peng, Xintong Shi, Amy Xin, Xiaozhi Wang, Bin Xu, Lei Hou, Juanzi Li
Department of Computer Science and Technology, BNRist; Shenzhen International Graduate School, Tsinghua University
GitHub: https://github.com/kijlk/IF-Interference