TL;DR
Модели обучены выдавать результат, а не признавать неопределённость. Когда задача неполная или противоречивая, LLM не спрашивает — она строит самое правдоподобное предположение и уверенно его выполняет. Выглядит хорошо, но по сути неправильно. Это не баг конкретной модели — это системное поведение, одинаковое у GPT, Claude и Gemini.
Главная находка: разрыв между «могу» и «делаю» огромен. Когда задача полностью описана, топовые модели справляются на 75–89%. Когда задача та же, но с пробелами — и с инструментом «спроси человека» — лучший результат падает до 4–38%. Причина не в том, что модель не умеет. Причина — в том, что модель не распознаёт момент, когда нужно остановиться и уточнить вместо того, чтобы угадать.
Проблема особенно коварна потому что пробелы в задаче часто не видны сразу. Они вылезают в процессе работы — когда модель уже идёт по неправильному пути с полной уверенностью. Именно поэтому бесполезно ждать, что модель сама спросит в начале — нужно встраивать «контрольные точки» по ходу.
Схема проблемы и решения
ОБЫЧНАЯ СИТУАЦИЯ (без вмешательства):
Вы даёте задачу с пробелами
↓
Модель строит предположение (молча)
↓
Модель уверенно выдаёт результат
↓
Результат плохой, но выглядит убедительно
С FORCE-ASK ПРОМПТОМ:
Вы даёте задачу + инструкцию спрашивать
↓
ШАГ 1: Модель сканирует задачу на пробелы → список вопросов
ШАГ 2: Вы отвечаете на вопросы
ШАГ 3: Модель начинает работу, фиксирует новые пробелы → ещё вопросы
ШАГ 4: Только когда все пробелы закрыты → финальный результат
Шаги 1-3 — в одном или нескольких запросах, зависит от сложности задачи
Пример применения
Задача: Вы хотите, чтобы Claude написал оффер для найма первого менеджера по продажам в стартап. Задача звучит просто, но внутри — десятки допущений, которые модель сделает за вас молча: грейд, рынок компенсаций, тип продаж, воронка, отчётность.
Промпт:
Мне нужен job offer — оффер для первого менеджера по продажам в B2B SaaS стартап.
Прежде чем писать — пройди два шага:
ШАГ 1: СКАНИРОВАНИЕ
Изучи задачу и составь список всего, что тебе неясно или не указано.
Для каждого пробела укажи: что именно неизвестно и почему это влияет на результат.
ШАГ 2: ВОПРОСЫ
Задай мне уточняющие вопросы по списку из шага 1.
Группируй по приоритету: критичные (без ответа сделаю неправильно) → важные → второстепенные.
Не начинай писать оффер, пока я не отвечу на вопросы из критичной группы.
После моих ответов — повтори шаги для любых новых пробелов, которые вскрылись.
Результат:
Модель не бросится писать — вместо этого покажет структурированный список допущений, которые она обычно делает молча. Например: «не указан диапазон зарплаты — без этого оффер будет либо нерыночным, либо завышенным»; «непонятно, какой цикл сделки — это влияет на KPI и систему мотивации». После ваших ответов — возможно, ещё один раунд вопросов, уже более точечных. Финальный оффер будет сделан под вашу конкретную ситуацию, а не «типовой B2B SaaS оффер из интернета».
Почему это работает
Слабость LLM: модели обучены на примерах с полными условиями — задача дана чётко, нужно выполнить. Это создаёт привычку к «уверенному выполнению». Когда условия неполные, модель применяет ту же стратегию: берёт самый правдоподобный вариант и идёт дальше. Останавливаться и признавать неопределённость — не тот паттерн, которому обучали.
Сильная сторона LLM: модель умеет перечислять возможные интерпретации, замечать противоречия и формулировать уточняющие вопросы — когда её явно попросить это сделать. Это не новая способность, а использование существующего умения в нужный момент.
Как метод обходит слабость: принудительный двухшаговый цикл «сначала обнаружить пробелы → потом задать вопросы» ломает автоматическую цепочку «пробел → молчаливое предположение». Модель получает явное задание остановиться перед принятием решения. Ключевой рычаг — фраза «не начинай делать, пока я не отвечу». Без неё модель часто выполняет оба шага сама с собой и сразу выдаёт результат.
Рычаги управления промптом: - «Критичные / важные / второстепенные» — приоритизация вопросов. Уберите если хотите получить все вопросы сразу без сортировки - «Повтори шаги для новых пробелов» — включает прогрессивное уточнение. Уберите если задача простая и хватит одного раунда - «Не начинай, пока» — жёсткий стоп перед выполнением. Смягчите до «предупреди если делаешь допущения» для менее критичных задач - Добавьте роль: «ты — опытный HR-директор» → вопросы станут более предметными и специфичными
Шаблон промпта
Задача: {описание задачи}
Прежде чем выполнять — пройди два шага:
ШАГ 1: СКАНИРОВАНИЕ
Изучи задачу. Составь список всего неясного или неуказанного.
Для каждого пробела: что неизвестно → почему это влияет на результат.
ШАГ 2: ВОПРОСЫ
Задай уточняющие вопросы по списку из шага 1.
Группируй: критичные (без ответа сделаю неправильно) → важные → второстепенные.
Не начинай {выполнять/писать/анализировать}, пока я не отвечу на критичные вопросы.
После моих ответов — проверь, появились ли новые пробелы, и задай новые вопросы если нужно.
Что подставлять:
- {описание задачи} — ваша задача, как вы её обычно формулируете
- {выполнять/писать/анализировать} — глагол под вашу задачу: писать текст, строить план, делать расчёт
🚀 Быстрый старт — вставь в чат:
Вот шаблон Force-Ask промпта. Адаптируй под мою задачу и задавай вопросы,
чтобы заполнить поле {описание задачи}. Моя задача: [твоя задача в двух словах].
[вставить шаблон выше]
LLM спросит о контексте задачи, желаемом результате и критичных параметрах — потому что без этого не сможет правильно настроить «что считать пробелом» для вашего конкретного случая.
Почему это работает: три профиля провала
Исследование выявило, что разные модели по-разному молчат о пробелах. Это практически важно — вы работаете с разными моделями:
GPT (4, 5, Codex): не замечает пробелы вообще. Берёт первое правдоподобное предположение и уверенно его реализует. Инструмент «можно спросить» почти не использует. Что делать: с GPT особенно важно требовать явного перечисления допущений — он не спросит сам.
Claude: замечает, что застрял. Иногда даже пишет это в рассуждениях. Но не спрашивает и не останавливается — продолжает исследовать и в итоге всё равно выдаёт результат. Что делать: Claude нужен явный «стоп» — «не двигайся дальше, пока я не отвечу». Иначе он отработает неопределённость сам с собой.
Gemini: ситуативен. На хорошо структурированных задачах легко замечает пробелы и спрашивает много (иногда слишком много). На сложных творческих или инженерных задачах теряется так же, как GPT. Что делать: добавьте «задавай только вопросы, без ответа на которые результат будет неправильным» — иначе завалит вопросами.
Ограничения
⚠️ Простые задачи: Если задача хорошо описана и однозначна — Force-Ask промпт создаёт лишний шаг. Модель будет честно писать «пробелов не обнаружено» и просить подтверждения начать. Применяйте для задач с реальной неопределённостью.
⚠️ Не заменяет думание: Модель спросит о пробелах, которые видит. Она не знает о пробелах, которые вы не знаете что не знаете — так называемые unknown unknowns. Если вы сами не понимаете задачу — вопросы помогут, но не решат проблему полностью.
⚠️ Прогрессивные пробелы: Исследование показало, что многие пробелы вылезают только в процессе работы — не видны на старте. Force-Ask промпт помогает, но не устраняет этот эффект полностью. Для длинных задач добавляйте явные контрольные точки по ходу.
⚠️ Исследование про агентов, не про чаты: Тестировали автономных агентов, которые самостоятельно пишут код или SQL-запросы. В чате вы сами на связи, что снижает остроту проблемы. Но механика та же: без явного запроса спрашивать — модель будет угадывать.
Как исследовали
Команда Scale.AI создала 300 задач — 150 на написание кода (реальные GitHub-баги) и 150 на SQL-запросы. В каждую задачу вручную «зашили» 3–5 блокеров — специально убранных или сделанных противоречивыми кусков информации, без которых задачу нельзя решить правильно. Блокеры трёх типов: отсутствующие данные (нет нужного параметра), неоднозначные требования (несколько одинаково правдоподобных интерпретаций), противоречивые условия (два требования взаимно исключают друг друга).
Интересный дизайн: блокеры специально не были видны при первом прочтении задачи. Они вылезали только в процессе работы — когда агент начинал исследовать кодовую базу или схему базы данных. Это называется прогрессивное обнаружение и воспроизводит реальную инженерную работу. Проверку организовали элегантно: специальный инструмент ask_human() возвращал нужный ответ только если вопрос точно попадал в зарегистрированный блокер — иначе «нерелевантный вопрос». Никакого субъективного судьи, только точное совпадение.
Метрика ASK-F1 — гармоническое среднее точности вопросов (не спамишь?) и охвата блокеров (нашёл всё?). Хитрость в том, что нельзя накрутить результат, закидав модель сотней вопросов: при 50 вопросах на 5 блокеров точность падает до 10%, и F1 обваливается до ~18%, даже при 100% охвате. Это техническое решение, которое сделало результаты честными.
Протестировали GPT, Claude Opus и Gemini Pro. Каждая модель прошла три условия: задача без инструмента вообще → задача с инструментом ask_human() → задача с полной информацией упрощена. Разрыв между «полная информация» и «нужно самому решить, когда спросить» оказался катастрофическим.
Адаптации и экстраполяции
🔧 Контрольные точки вместо только стартового сканирования → ловит прогрессивные пробелы
Исследование показало: большинство пробелов не видны в начале. Они вылезают по ходу. Добавьте явные точки остановки:
После каждого крупного шага — останавливайся и проверяй:
— Появились ли новые неопределённости, которых не было в начале?
— Есть ли допущения, которые я сделал(а) молча?
Если да — сообщи мне перед продолжением.
🔧 Режим «аудит допущений» для уже готового текста → ретроспективный Force-Ask
Если модель уже выдала результат — попросите её вскрыть, что она подразумевала:
Прочитай свой ответ выше. Перечисли все допущения, которые ты сделал(а) молча —
то, что не было указано в моём запросе, но ты выбрал(а) вариант самостоятельно.
Для каждого — укажи, какой другой вариант мог быть и как он изменил бы результат.
Это не Force-Ask, а ретроспективное вскрытие. Полезно когда результат «что-то не то», но непонятно где именно пошло не так.
🔧 Настройка под модель
Зная профили провала разных моделей:
- Для GPT: добавьте в промпт «я знаю, что у тебя есть соблазн угадать — не делай этого, лучше спроси»
- Для Claude: добавьте жёсткий стоп: «если видишь, что застрял — это сигнал спросить, не продолжать»
- Для Gemini: ограничьте: «задавай только критичные вопросы, не более 3 за раз»
Ресурсы
HIL-BENCH: Do Agents Know When to Ask for Help? Mohamed Elfeki, Tu Trinh, Kelvin Luu, Guangze Luo, Nathan Hunt, Ernesto Montoya, Nandan Marwaha, Yannis He, Charles Wang, Fernando Carabedo, Alessa Castillo, Bing Liu Scale.AI, 2025 GitHub с данными
Смежные работы упомянутые в статье: SWE-Bench (Jimenez et al., 2024), BIRD-SQL (Li et al., 2024), работы Andukuri et al. (2024) по обучению моделей задавать уточняющие вопросы.