3,583 papers
arXiv:2606.19559 78 17 июня 2026 г. FREE

Uncertainty Decomposition: два сигнала вместо одного — разделить «задача непонятна» и «не знаю как делать»

КЛЮЧЕВАЯ СУТЬ
LLM не умеет молчать. Дал расплывчатое задание — она не замирает, не спрашивает, а уверенно заполняет пробелы и едет вперёд. В длинных цепочках одно раннее допущение тянет за собой десятки неверных шагов. Метод Uncertainty Decomposition позволяет остановить модель до первого действия и заставить её явно оценить: задача ясна или нет. Фишка: порядок XML-тегов задаёт порядок мышления<неопределённость_задачи> стоит в тексте раньше <действие>, и модель физически не может перешагнуть через оценку ясности. Итог: вместо уверенного движения не туда — конкретный уточняющий вопрос.
Адаптировать под запрос

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


📋 Дайджест исследования

Ключевая суть

LLM не умеет молчать. Дал расплывчатое задание — она не замирает, не спрашивает, а уверенно заполняет пробелы и едет вперёд. В длинных цепочках одно раннее допущение тянет за собой десятки неверных шагов. Метод Uncertainty Decomposition позволяет остановить модель до первого действия и заставить её явно оценить: задача ясна или нет. Фишка: порядок XML-тегов задаёт порядок мышления<неопределённость_задачи> стоит в тексте раньше <действие>, и модель физически не может перешагнуть через оценку ясности. Итог: вместо уверенного движения не туда — конкретный уточняющий вопрос.

Принцип работы

Два сигнала на каждом шаге, а не один. Стандартный подход: модель оценивает, уверена ли она в действии. Этот метод добавляет второй вопрос раньше — насколько ясна сама задача. Прикол: модель умеет находить пробелы в задаче, просто по умолчанию пропускает этот шаг и сразу генерирует ответ. Шкала 0/0.5/1 плюс порог срабатывания превращают абстрактное «спроси если непонятно» в конкретный маршрутизатор: ниже порога — работай, выше — один вопрос по самому критичному пробелу. Не два, не список — один.

Почему работает

LLM — генератор следующего токена. Когда задача размытая, она не останавливается. Она выбирает самую вероятную интерпретацию и продолжает. В одном коротком вопросе это незаметно. В агентных задачах на 10+ шагов одно раннее допущение тянет за собой цепочку — и к десятому шагу модель уверенно сделала что-то совсем не то. Суть: модель МОЖЕТ оценить ясность инструкции, если явно спросить. Проблема не в способности — в том, что без специального шага она этот вопрос себе не задаёт. XML-структура делает оценку ясности обязательной остановкой, а не пожеланием.

Когда применять

Агентные сценарии → для многошаговых задач, где одно допущение на первом шаге ламает весь результат. Особенно когда задача творческая, размытая или зависит от контекста, который пользователь не озвучил. Разработка → когда нужно описать функцию или архитектуру, но требования сырые. Контент и презентации → когда аудитория, тон и цель не указаны явно. НЕ подходит для простых однозначных задач — шесть XML-тегов на «переведи это предложение» это просто лишний расход токенов.

Мини-рецепт

1. Скопируй шаблон: вставь XML-структуру с шестью тегами — <думаю>, <неопределённость_задачи>, <объяснение_неопределённости>, <действие>, <уверенность>, <объяснение_уверенности> — в системный промпт или в начало разговора
2. Настрой порог срабатывания: по умолчанию ≥ 0.5 → снизь до ≥ 0.3 для открытых творческих задач, подними до ≥ 0.8 если задачи обычно довольно конкретные и лишние вопросы раздражают
3. Вставь задачу: замени {задача} на свой запрос — даже расплывчатый, метод сам найдёт пробелы
4. Контролируй длину истории: для длинных цепочек оставляй все теги в контексте — они нужны следующим шагам; для коротких убирай <уверенность> и <объяснение_уверенности>, сэкономишь токены без потери смысла

Примеры

[ПЛОХО] : Помоги мне написать питч для инвесторов Модель сразу начнёт писать. Через три абзаца выяснится: не тот раунд, не та аудитория, не тот тон.
[ХОРОШО] : Ты — помощник, который работает по шагам и проверяет ясность задачи перед действием. [XML-шаблон с шестью тегами] Задача: помоги написать питч для конкурса Сколково. Модель поставит <неопределённость_задачи> = 1, в <объяснение_неопределённости> перечислит конкретные пробелы: что за продукт, на какой стадии стартап, какой трек конкурса, что ждёт жюри. В <действие> — один вопрос по самому критичному из них. После ответов пользователя перейдёт к реальной работе с <уверенность> около 0.8 и объяснением что учтено.
Источник: Uncertainty Decomposition for Clarification Seeking in LLM Agents
ArXiv ID: 2606.19559 | Сгенерировано: 2026-06-19 04:29

Проблемы LLM

ПроблемаСутьКак обойти
Модель угадывает когда задача расплывчатаяПолучает нечёткий запрос — не останавливается и не спрашивает. Сама выбирает интерпретацию и делает. В коротком диалоге незаметно. В длинных задачах одно раннее допущение тянет цепочку неверных решенийДобавь в промпт обязательный шаг перед действием: оценить ясность задачи числом. Пока оценка не проставлена — действие не генерируется

Методы

МетодСуть
Теги ДО действия — заставить оценить задачу прежде чем делатьПомести в промпт теги <неопределённость_задачи> и <объяснение_неопределённости> раньше тега <действие>. Модель не может перепрыгнуть через них — порядок тегов = порядок рассуждений. В <неопределённость_задачи> — три значения: 0 (всё ясно), 0.5 (есть пробелы), 1 (критически не хватает деталей). Правило в промпте: если значение 0.5 задать один уточняющий вопрос, не выполнять задачу. Если < 0.5 выполнять. Почему работает: без явной структуры модель перепрыгивает этап оценки и генерирует ответ сразу. XML-тег — не украшение, а обязательная точка остановки. Когда применять: многошаговые задачи, нечёткие запросы, агенты с 10+ шагами. Когда не нужен: простые однозначные задачи — только тратит токены

Тезисы

ТезисКомментарий
Порядок тегов в промпте задаёт порядок рассужденийМодель генерирует текст последовательно. Тег стоит раньше в промпте — модель заполняет его раньше. Заполнила <оценка_ясности> — уже зафиксировала позицию до того как начала думать про <действие>. Механика: поздний тег не может повлиять на ранний. Применяй: хочешь чтобы модель сначала проверила X, потом делала Y — ставь тег X раньше тега Y в промпте
📖 Простыми словами

Uncertainty Decomposition for Clarification Seeking inLLMAgents

arXiv: 2606.19559

Проблема в том, что обычные нейронки — это патологические угодники. Когда ты даешь им кривое или неполное задание, они не переспрашивают, а начинают додумывать за тебя. На уровне архитектуры LLM просто генерирует наиболее вероятное продолжение текста, поэтому вместо того, чтобы признать «я не понимаю», она выбирает случайную интерпретацию и несется вперед. В итоге ты получаешь результат, который вроде бы похож на ответ, но по факту — полная лажа, потому что модель изначально неверно поняла контекст.

Это как если бы ты пришел к врачу и сказал: «У меня что-то болит», а он, вместо того чтобы задать уточняющие вопросы, сразу вколол бы тебе первое попавшееся обезболивающее. Формально он помог, но по факту мог сделать только хуже, потому что не разобрался в причине. Метод декомпозиции неуверенности заставляет модель сначала «провести диагностику» твоего запроса, прежде чем доставать шприц с ответами.

Суть метода в том, что мы разделяем неуверенность на два независимых слоя: неопределенность запроса (ut) и уверенность в действии (ct). Сначала модель честно оценивает, понимает ли она вообще, чего ты от нее хочешь. И только если с задачей всё ясно, она переходит к выбору конкретного шага. Если же запрос — мутный набор слов, модель обязана заткнуться и переспросить, а не гадать на кофейной гуще. В одном промпте это работает как жесткий фильтр: «Я понимаю задачу? Да/Нет. Я знаю, что делать? Да/Нет».

Представь, что ты просишь Claude помочь с питчем для инвесторов. Обычная модель сразу вывалит тебе шаблон про «инновационные инновации». Модель с этим методом сначала спросит: «А на какой стадии стартап? Кто в жюри? Какой регламент?». Принцип универсален: он одинаково круто работает и в кодинге, и в аналитике, и в управлении агентами. Это переход от тупого исполнения команд к осознанному диалогу, где AI перестает быть просто калькулятором слов.

Короче, хватит надеяться, что нейронка сама догадается, что у тебя в голове — она обязательно промахнется. Нужно внедрять двухэтапную проверку, чтобы модель разделяла «кривой промпт» и «сложную задачу». Это спасает от галлюцинаций и цепочки неверных решений, которые в длинных задачах копятся как снежный ком. Либо модель уточняет детали, либо она просто тратит твои токены и время на бесполезный мусор.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с