TL;DR
Метод учит LLM различать два разных вида неуверенности прежде, чем начать что-либо делать. На каждом шаге модель сначала оценивает, насколько ясна сама задача (ut — неопределённость запроса), и только потом — насколько она уверена в конкретном действии (ct — уверенность в действии). Если задача недостаточно ясна, модель спрашивает, а не угадывает.
Боль, которую это чинит. Дашь Claude расплывчатое задание — «сделай мне презентацию для инвесторов» — и он с энтузиазмом начнёт делать. Только через три слайда выяснится, что у него была другая целевая аудитория, другой тон и не тот раунд. Модель не различает «я не знаю размер аудитории» (неясная задача) и «не уверен, какой цвет схемы лучше» (сложность исполнения) — и уверенно едет в неверном направлении.
Метод добавляет в промпт обязательную точку остановки перед действием: сначала оцени задачу по шкале 0–0.5–1, объясни что непонятно, и только если задача достаточно ясна — действуй. Оба сигнала сохраняются в истории диалога, чтобы более поздние шаги могли их учитывать.
Схема метода
Всё происходит в одном промпте, каждый шаг — поочерёдно:
ШАГ 1: Оцени неопределённость задачи (ut)
→ 0 (всё ясно) / 0.5 (есть пробелы) / 1 (критически не хватает)
ШАГ 2: Маршрутизация
→ если ut ≥ 0.5: задай уточняющий вопрос (стоп)
→ если ut < 0.5: переходи к действию
ШАГ 3: Выполни действие + оцени уверенность в нём (ct)
→ 0-1, насколько уверен что движешься к цели
ШАГ 4: Запиши оба сигнала в историю
→ следующий шаг их учтёт
Ключевое: ut оценивается ДО того, как модель генерирует действие — так неясность задачи не успевает «заразить» само решение.
Пример применения
Задача: Ты — основатель небольшого EdTech-стартапа, поднимаешь деньги. Просишь Claude помочь с питчем для Сколково.
Промпт:
Ты — помощник, который работает по шагам и всегда проверяет ясность задачи перед действием.
Перед каждым ответом обязательно используй этот формат:
<думаю>
[рассуждения о задаче и что нужно сделать]
думаю>
<неопределённость_задачи>
[одно значение: 0, 0.5 или 1]
0 — задача полностью ясна, единственно верная интерпретация
0.5 — есть пробелы, у пользователя скорее всего есть предпочтение, которое не озвучено
1 — критически не хватает деталей, слишком много равноценных интерпретаций
неопределённость_задачи>
<объяснение_неопределённости>
[что именно непонятно — или почему задача считается ясной]
объяснение_неопределённости>
<действие>
[если неопределённость_задачи ≥ 0.5 → задай уточняющий вопрос, не выполняй задачу]
[если неопределённость_задачи < 0.5 → выполняй задачу]
действие>
<уверенность>
[0.0–1.0, насколько уверен что действие движет к цели]
уверенность>
<объяснение_уверенности>
[почему такой уровень уверенности — что помогает, что беспокоит]
объяснение_уверенности>
Задача: Помоги мне написать питч для конкурса Сколково.
Результат:
Модель не начнёт писать питч сразу. В блоке <неопределённость_задачи> появится значение 1 или 0.5. В <объяснение_неопределённости> — список конкретных пробелов: что за продукт? на каком этапе стартап? какой трек конкурса? чего ожидает жюри Сколково? В <действие> — уточняющий вопрос по самому критичному из них. Только после ответов модель перейдёт к реальной помощи — с <уверенность> в диапазоне 0.7–0.9 и объяснением что учтено.
Если задать конкретный запрос («напиши слайд о проблеме рынка для EdTech B2B, аудитория — технологические эксперты Сколково, у нас 3 минуты на питч») — модель поставит ut = 0 и сразу приступит.
Почему это работает
Слабость LLM. Модель — генератор следующего токена. Когда задача размытая, она не замирает и не спрашивает. Она заполняет пробелы самостоятельно — выбирает самую вероятную интерпретацию и едет дальше. В коротком диалоге это незаметно, в длинных многошаговых задачах одно раннее допущение тянет за собой цепочку неверных решений.
Сильная сторона LLM. Если явно попросить модель оценить ясность инструкции — она делает это хорошо. Модель умеет находить пропущенные детали и формулировать вопросы. Проблема не в способности, а в том, что без явной инструкции она пропускает этот шаг и сразу генерирует ответ.
Как метод использует это. XML-структура превращает «оцени ясность» из пожелания в обязательный шаг перед действием. Модель не может перешагнуть через <неопределённость_задачи> и <объяснение_неопределённости> — они стоят в тексте раньше <действие>. Порядок тегов задаёт порядок мышления.
Рычаги управления:
- Порог срабатывания (
≥ 0.5) → снизь до≥ 0.3если хочешь больше уточнений, подними до≥ 0.8если задачи обычно ясные и не хочешь лишних вопросов - Шкала 0/0.5/1 → можно расширить до 0/0.25/0.5/0.75/1 для более тонкой градации
- История → убери блоки
<уверенность>и<неопределённость>из истории если экономишь токены; добавь обратно когда задачи длинные и многошаговые - Имена тегов → переименуй на своём языке, это не синтаксис, а подсказки модели о структуре
Шаблон промпта
Ты — помощник, который работает по шагам и проверяет ясность задачи перед действием.
На каждый запрос отвечай строго в следующем формате:
<думаю>
[рассуждения: что за задача, что ясно, что нет, как планирую действовать]
думаю>
<неопределённость_задачи>
[одно значение: 0, 0.5 или 1]
0 — задача полностью ясна, одна верная интерпретация
0.5 — есть пробелы, у пользователя скорее всего есть предпочтение
1 — критически не хватает деталей, слишком много интерпретаций
неопределённость_задачи>
<объяснение_неопределённости>
[что конкретно непонятно или почему задача считается ясной]
объяснение_неопределённости>
<действие>
[если неопределённость_задачи ≥ 0.5:
— задай один уточняющий вопрос по самому критичному пробелу
— не выполняй основную задачу]
[если неопределённость_задачи < 0.5:
— выполняй задачу]
действие>
<уверенность>
[число от 0.0 до 1.0: насколько уверен что действие движет к цели]
уверенность>
<объяснение_уверенности>
[что помогает быть уверенным, что беспокоит, чего не хватает]
объяснение_уверенности>
Задача: {задача}
Плейсхолдеры:
- {задача} — твой запрос, вставь как есть, даже расплывчатый — метод сам найдёт пробелы
🚀 Быстрый старт — вставь в чат:
Вот шаблон Uncertainty Decomposition. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой тип задач ты обычно решаешь и насколько они обычно конкретны — потому что от этого зависит оптимальный порог срабатывания (0.5 по умолчанию, но для творческих задач лучше ниже).
Ограничения
⚠️ Простые однозначные задачи: Метод создаёт лишние шаги без выгоды. Если просишь «переведи это предложение на английский» — проверка ясности бессмысленна, токены тратятся впустую.
⚠️ Перегрузка токенов: Шесть тегов на каждый шаг ощутимо удлиняют разговор. Для коротких задач лучше упростить — оставить только
<неопределённость_задачи>и<действие>.
⚠️ Систематическая самоуверенность LLM: Модели склонны занижать
ut— ставить 0 там, где реально 0.5. Это известная проблема всех prompt-based методов оценки уверенности. Если замечаешь что модель редко спрашивает — снизь пороговое значение.
⚠️ Максимальный эффект — в длинных цепочках: Главная ценность метода проявляется в многошаговых задачах (агент, который делает 10+ действий подряд). Для одного вопроса — одного ответа выгода меньше.
Как исследовали
Команда из ИТМО (Санкт-Петербург) столкнулась с реальной проблемой: существующие методы оценки уверенности LLM-агентов либо требуют доступа к внутренним вероятностям токенов (недоступно в API), либо запускают модель несколько раз (дорого и медленно), либо нуждаются в обучении на размеченных данных. Осталась только одна жизнеспособная ниша — промпт-методы.
Идея была простая: что если разделить один сигнал неуверенности на два? Чтобы проверить это, исследователи создали два новых бенчмарка — WebShop-Clarification (агент покупает товары онлайн) и ALFWorld-Clarification (агент выполняет бытовые задачи в симуляции). В обоих ровно половина задач намеренно написана размыто: агент должен либо распознать пробел и спросить, либо неверно угадать. Это позволило измерить не просто «насколько агент уверен», а «насколько точно агент распознаёт что задача неясна».
Тестировали пять разных моделей — GPT, DeepSeek, Qwen, GLM — и сравнивали три подхода: простое добавление уверенности в конец промпта (ReAct+UE), уверенность с памятью (UAM) и предложенный метод с двумя сигналами. Прирост оказался значительным — на одном из бенчмарков новый метод превзошёл простую baseline на 73% по F1, что для prompt-only метода без дообучения выглядит неожиданно. Показательно: метод выиграл на четырёх из пяти моделей, то есть эффект не случайный и не «заточен» под один LLM.
Интересная деталь: исследователи специально исключили из сравнения все методы, требующие кода или дообучения — не из лени, а потому что в реальных условиях они недоступны. Это делает результаты честнее: сравниваются вещи, которые реально можно применить.
Оригинал из исследования
Вот точный формат вывода агента из работы (Appendix A.3, формула 11):
rt
ut ∈ [0, 1]
пояснение что неясно
at
ct ∈ [0, 1]
пояснение уверенности
С маршрутизацией из Algorithm 1:
if ut ≥ θ (default θ = 0.5):
at* ← request_clarification
else:
at* ← at
Обе переменные — ut, ct — и оба объяснения записываются в историю агента, чтобы следующие шаги могли на них ссылаться.
Контекст: Это точный промпт-формат, который авторы тестировали на пяти LLM. Шкала ut намеренно трёхточечная (0/0.5/1), а не непрерывная — так модели лучше калибруются и реже застревают на промежуточных значениях.
Адаптации и экстраполяции
1. Адаптация: Краткая версия для чата (без агента)
Если не нужна память через шаги, а нужна просто защита от «уверенного неправильного ответа» на один сложный вопрос:
💡 Адаптация для разовых задач: Убираем историю и многошаговость, оставляем только ключевую проверку.
Перед ответом на задачу:
<неопределённость>
0 — задача ясна / 0.5 — есть пробелы / 1 — критически мало деталей
неопределённость>
<если_неясно>
[при ≥ 0.5: задай один вопрос, стоп]
[при < 0.5: отвечай]
если_неясно>
Задача: {задача}
2. Техника: Персонажи вместо безликого агента → острее критика
🔧 Замена «агент» на конкретную роль → модель играет её точнее
Вместо безликого «ты — помощник» добавь роль:
Ты — опытный продакт-менеджер из Яндекса, который видел сотни размытых ТЗ.
Прежде чем браться за задачу, ты всегда проверяешь — а вы вообще одинаково поняли задачу?
Это меняет поведение: модель начинает задавать более острые и профессиональные уточняющие вопросы, потому что «продакт из Яндекса» знает что именно обычно не уточняют.
3. Экстраполяция: Комбо с Chain-of-Thought
Принцип «сначала оцени ясность, потом действуй» можно встроить в любой CoT-промпт как нулевой шаг:
Прежде чем думать о решении:
Шаг 0: Есть ли в задаче неоднозначности?
[да/нет + что именно, если да] → [если да: уточни]
Шаг 1: [обычный CoT...]
Это работает даже без XML-структуры — просто пронумерованные шаги с нулевым шагом на проверку ясности.
Ресурсы
Работа: Matsnev, G. (2026). Uncertainty Decomposition for Clarification Seeking in LLM Agents. Preprint.
Код: github.com/PE51K/udcs-in-llm-agents
Автор: Gregory Matsnev, AI Talent Hub, ИТМО, Санкт-Петербург
Связанные методы из статьи: ReAct (Yao et al.), UAM — Uncertainty-Aware Memory (Zhang et al.), Self-Consistency (Wang et al.), Semantic Entropy
