TL;DR
Исследователи из Universiti Malaya измерили три подозрительных поведения LLM: "лень" (модель даёт меньше, чем просили), субоптимальность декодирования (выбирает не лучший ответ) и деградацию контекста (забывает факты в длинных диалогах). Провели три эксперимента на GPT-4o и DeepSeek, чтобы проверить эти гипотезы с цифрами.
Главная находка: "лень" – это системная проблема. Попросишь 1000 слов – получишь 300. Попросишь 8 пунктов – получишь 5, и модель спокойно закончит на пятом. GPT-4o в одном тесте выдал 326 слов вместо запрошенной тысячи (33% от цели), DeepSeek ещё хуже – 130 слов (13%). Причём это происходит даже при явных инструкциях типа "напиши ровно 1000 слов" или "дай мне 8-10 примеров". Модель способна написать больше (когда её сильно попросить, она выдаёт почти тысячу), но по умолчанию выбирает краткость. Это след RLHF-тренировки: модели учили быть лаконичными, чтобы не болтать лишнего, и они переусердствовали.
Неожиданно: субоптимальность декодирования не подтвердилась (модель выбирает именно то, что считает лучшим по своим вероятностям), и деградация контекста оказалась мифом для простых задач – модели удержали 12 ключевых фактов через 200 реплик, заполненных мусорным текстом. Проблема не в памяти, а в комплаенсе со сложными многосоставными инструкциями.
Схема экспериментов
ЭКСПЕРИМЕНТ A: "Лень"
ШАГ 1: Дать промпт с чёткими требованиями (длина/количество пунктов/список тем)
ШАГ 2: Получить ответ в двух режимах:
• Greedy (обычный) → короткий ответ
• Detailed (с доп. инструкцией "будь максимально подробен") → длиннее, но всё равно часто неполный
ШАГ 3: Измерить:
• Слов в ответе vs запрошено
• Сколько пунктов/тем упомянуто vs запрошено
• Semantic coverage (доля покрытых тем)
ЭКСПЕРИМЕНТ B: Субоптимальность
ШАГ 1: Дать задачу (логическая задача про поезда)
ШАГ 2: Получить ответ модели A (greedy)
ШАГ 3: Дать модели эталонное решение B' и попросить его воспроизвести
ШАГ 4: Сравнить log-вероятности: если log P(B') > log P(A), значит модель "знала" лучший ответ, но не выбрала его
ЭКСПЕРИМЕНТ C: Деградация контекста
ШАГ 1: В начале диалога дать 12 ключевых фактов ("кодовое имя проекта – AlphaStarFish", "любимый цвет – зелёный")
ШАГ 2: Провести 200 реплик, где каждая содержит 400-800 слов мусорного текста (случайные статьи, противоречивые данные)
ШАГ 3: На каждом шаге проверять:
• Сколько из 12 фактов модель помнит
• Когерентность ответов (оценка 1-10)
• Embedding similarity (насколько "уехали" от оригинала)
Пример применения
Задача: Ты готовишь материал для клиента – нужен контент-план на месяц для Telegram-канала про инвестиции. Просишь ChatGPT дать 20 идей постов с описанием каждой.
Промпт (типичный):
Создай контент-план на месяц для Telegram-канала про инвестиции.
Дай мне 20 идей постов. Для каждой идеи напиши:
1. Заголовок
2. Краткое описание (2-3 предложения)
3. Какую боль аудитории закрывает
Аудитория: начинающие инвесторы 25-35 лет, доход от 80к/мес, хотят разобраться в инструментах.
Результат: Модель выдаст 10-12 идей вместо 20, причём к концу списка описания станут короче ("9. Как выбрать брокера. Критерии выбора." – без развёрнутого описания и про боль забудет). Просто остановится после 12-го пункта, как будто задание выполнено.
Промпт (с учётом "лени"):
Создай контент-план на месяц для Telegram-канала про инвестиции.
КРИТИЧЕСКИ ВАЖНО: мне нужно РОВНО 20 идей. Не 10, не 15 – именно 20.
Для КАЖДОЙ из 20 идей обязательно напиши все три пункта:
1. Заголовок
2. Краткое описание (2-3 предложения)
3. Какую боль аудитории закрывает
Аудитория: начинающие инвесторы 25-35 лет, доход от 80к/мес, хотят разобраться в инструментах.
После того как дашь все 20, напиши: "✓ Все 20 идей готовы"
Результат: Модель с большей вероятностью выдаст все 20 пунктов. Явное числовое требование + условие финализации ("напиши что готово") работают как якоря, которые удерживают модель от преждевременного завершения.
Почему это работает
Слабость LLM: Модели обучены через RLHF быть лаконичными и "полезными". Во время тренировки их штрафовали за многословие и излишние детали (чтобы не болтали воду). Выработался сильный bias к краткости – модель предпочитает закончить раньше, чем рисковать быть слишком длинной. Это конфликтует с инструкциями пользователя: ты говоришь "дай 10 пунктов", а внутренняя политика модели шепчет "5 достаточно, он поймёт".
Эффект многосоставных инструкций: Когда в промпте несколько требований (длина + список тем + формат), вероятность выполнить все одновременно падает экспоненциально (это "проклятие инструкций" из исследования Harada et al.). Модель жонглирует требованиями и роняет часть из них. Не потому что не понимает, а потому что её reward model не оптимизирован под "выполни ВСЕ 10 пунктов до конца".
Как обойти: - Явный числовой якорь ("ровно 20", "минимум 1000 слов") работает лучше, чем "подробно" или "много" - Разбивка на части: "Сначала дай пункты 1-10, потом я попрошу 11-20" – меньше шансов, что модель бросит на полпути - Self-refinement: попросить модель после ответа проверить: "Выполнил ли ты все требования? Если нет – доделай" - Контрольная точка в конце: "После выполнения напиши '✓ Готово'" – создаёт цель, до которой модель должна дойти
Рычаги управления: - Меняй числовые требования (20 → 10) для баланса между полнотой и скоростью - Добавляй чекпоинты ("После каждых 5 пунктов делай паузу и спрашивай: продолжить?") для контроля выполнения - Используй self-refinement ("Проверь сам: все ли пункты есть?") как второй проход
Шаблон промпта
{задача}
КРИТИЧЕСКИ ВАЖНО: мне нужно {точное_число} {элементов} / минимум {число_слов} слов.
Для КАЖДОГО {элемента} обязательно включи:
• {требование_1}
• {требование_2}
• {требование_3}
{дополнительный_контекст}
После выполнения напиши: "✓ Все {точное_число} {элементов} готовы" – это подтверждение, что ты не остановился раньше.
Пояснение плейсхолдеров:
- {задача} – что нужно сделать ("Создай контент-план", "Напиши анализ рынка")
- {точное_число} – конкретная цифра (20, 15, 1000)
- {элементов} – единица измерения ("идей постов", "аргументов", "слов")
- {требование_1/2/3} – структура каждого элемента (заголовок, описание, вывод)
- {дополнительный_контекст} – детали задачи (аудитория, ограничения, стиль)
Ключевая деталь: Фраза "✓ Все {N} готовы" в конце – это финализирующий якорь, который удерживает модель от преждевременного завершения. Без него она может остановиться на середине.
Ограничения
⚠️ Self-refinement не панацея: Даже с проверкой "всё ли я сделал?", модель иногда отвечает "да, всё сделал", хотя пропустила пункты. Проверяй критичные задачи вручную.
⚠️ Длина ≠ качество: Модель может выдать запрошенные 1000 слов, но с повторами и водой. Фокус исследования – на комплаенсе (выполнила ли требование), не на смысловой ценности.
⚠️ Работает для объективных требований: "Дай 10 пунктов" или "напиши 500 слов" измеримо. Субъективные критерии ("будь максимально глубоким") по-прежнему интерпретируются произвольно.
Как исследовали
Команда взяла GPT-4o и DeepSeek и прогнала через три эксперимента. В первом дали модели промпты с чёткими требованиями: "напиши 1000 слов", "дай 8-10 пунктов", "объясни 5 тем". Тестировали в двух режимах – обычный (greedy) и "будь максимально подробен" (detailed) с чуть более высокой температурой. Измеряли: сколько слов выдала модель, сколько пунктов, какую долю тем покрыла. Результат оказался единообразно печальным: ни в одном тесте модель полностью не выполнила требования в обычном режиме. GPT-4o давал 33% от запрошенной длины, DeepSeek – 13%. Даже в detailed-режиме не всегда выезжали до конца.
Второй эксперимент проверял субоптимальность декодирования: дали модели логическую задачу про поезда, получили ответ A (greedy), потом заставили модель воспроизвести эталонное решение B' и сравнили log-вероятности. Если бы log P(B') > log P(A), это значило бы, что модель "знала" правильный ответ, но не выбрала его (застряла в локальном оптимуме). Но оказалось наоборот: модель присваивала своему ответу A более высокую вероятность, чем эталону. То есть она выбирала именно то, что считала лучшим – проблема не в декодировании, а в том, что она вообще считает "лучшим".
Третий эксперимент – самый жестокий: 200 реплик с мусором, чтобы проверить деградацию контекста. В начале диалога модели дали 12 ключевых фактов ("кодовое имя проекта – AlphaStarFish", "любимый цвет пользователя – зелёный"). Потом каждая реплика содержала 400-800 слов случайного текста (статьи с Википедии, ложная информация, противоречия), и на каждом шаге проверяли: сколько фактов модель помнит, насколько когерентны её ответы, как далеко она "уехала" от исходного смысла (через embedding similarity). Ожидали, что модели начнут путаться и забывать. Но нет – они удержали почти все факты даже через 200 реплик. Это удивило исследователей: оказывается, для простого удержания фактов длинные диалоги не так страшны, как думали. Проблема не в памяти, а в комплаенсе со сложными инструкциями.
Почему пришли к таким выводам: Логика простая – если модель способна выдать 1000 слов (доказано в detailed-режиме), но не выдаёт в обычном (даже при явной инструкции), значит это выбор политики, а не ограничение способностей. След RLHF-тренировки, где модель училась быть краткой. А удержание фактов через 200 реплик показывает, что transformer-архитектура справляется с поиском ключевой информации в контексте (attention mechanism работает), но выполнение множественных требований одновременно – это другая задача, которую модели решают плохо.
Ресурсы
"Quantifying Laziness, Decoding Suboptimality, and Context Degradation in Large Language Models"
Упомянутые работы: - Harada et al. (2024) – "проклятие инструкций" (curse of instructions): вероятность выполнить N инструкций падает экспоненциально с ростом N - Wang et al. (2023) – self-consistency decoding: сэмплировать несколько reasoning paths и выбрать консенсусный ответ - Holtzman et al. (2020) – nucleus sampling против вырожденного greedy-текста - Liu et al. (2024), Bai et al. (2023) – LongBench и исследования long-context performance
Yiqing Ma (Universiti Malaya, Малайзия), Jung-Hua Liu (National Chung Cheng University, Тайвань)