TL;DR
DBA — метод проверки надёжности ответа LLM без дообучения и внешних источников. Суть: задай один вопрос двумя способами (прямо и через разбивку на шаги), сравни ответы. Если ответы разные — модель не уверена, лучше не доверять. Метод работает в обычном чате, нужно только два запроса вместо одного.
LLM часто уверенно врут, не признавая "не знаю". Попроси модель назвать год IPO российского стартапа — она выдаст конкретную дату, даже если компания вообще не выходила на биржу. Проблема в том, что модель не различает знание от догадки — генерирует правдоподобный текст в обоих случаях. Стандартные методы проверки ("Ты уверен?", инструкция "отвечай 'не знаю' если не уверен") плохо работают — модель либо остаётся самоуверенной, либо начинает отказываться от правильных ответов.
Исследователи нашли: правильные ответы стабильны, галлюцинации — хаотичны. Если модель действительно знает факт, она выдаст одинаковый ответ при прямом вопросе ("Когда Озон вышел на IPO?") и при разбивке на шаги ("Шаг 1: Озон — это какая компания? Шаг 2: Когда эта компания вышла на IPO?"). Если модель не знает — начнёт импровизировать, и импровизации будут разными. Несогласие между режимами промптинга — точный индикатор ошибки. У frontier-моделей правильный ответ появляется при согласии в 50 раз чаще, чем при несогласии.
Схема метода
ШАГ 1: Прямой вопрос → Ответ A
"В каком году Озон провёл IPO?"
ШАГ 2: Тот же вопрос через декомпозицию → Ответ B
"Сначала: что такое Озон?
Затем: когда эта компания вышла на IPO?"
ШАГ 3: Сравнить A и B
Если ответы совпадают → доверяй
Если ответы разные → не доверяй (модель не уверена)
Все три шага — отдельные запросы в чат. Сравнение делаешь сам (или просишь модель сравнить).
Пример применения
Задача: Готовишь питч инвесторам про маркетплейс. Нужно упомянуть когда главный конкурент вышел на биржу — факт должен быть точным, потому что слушатели проверят.
Промпт 1 (прямой):
В каком году компания Ozon провела IPO на американской бирже?
Промпт 2 (декомпозиция):
Ответь пошагово:
1. Ozon — это какая компания? (страна, отрасль)
2. Выходила ли эта компания на IPO?
3. Если да — в каком году и на какой бирже?
Отвечай на каждый шаг отдельно, потом дай финальный ответ.
Результат: Если модель в обоих случаях выдаст "2020, NASDAQ" — факт надёжный, можно использовать. Если в первом промпте скажет "2020", во втором "2019" или добавит неуверенность ("точная дата неизвестна") — не включай в презентацию, проверь через поиск. Несогласие = красный флаг.
Почему это работает
LLM генерирует текст вероятностно, но знание стабильно, галлюцинация — случайна. Если модель действительно запомнила факт из обучающих данных ("Ozon IPO 2020"), она выдаст этот факт при любой формулировке вопроса. Это устойчивое знание — как воспоминание, которое ты расскажешь одинаково независимо от того, как тебя спросят.
Если модель не знает — она начинает строить правдоподобную историю на основе паттернов: "российский маркетплейс → наверное выходил на IPO → наверное в 2020-е → скажу 2020". Это шаткая догадка, и при другой структуре промпта паттерны сработают иначе. Декомпозиция меняет последовательность генерации — если факта нет в памяти, импровизации в двух режимах разойдутся.
Рычаги управления:
- Тип декомпозиции — можно разбить на 2 шага (быстро) или на 5 (надёжнее, но дольше). Чем больше шагов, тем сильнее расходятся галлюцинации.
- Формулировка шагов — можно разбить хронологически ("сначала основание компании, потом IPO") или логически ("сначала бизнес-модель, потом финансы"). Разные разбивки = разные пути рассуждения = сильнее проверка.
- Сравнение ответов — можно сравнивать строго (полное совпадение) или мягко (та же суть, другие слова). Строгое сравнение = больше отказов, но выше точность чистых ответов.
Шаблон промпта
Прямой запрос:
{вопрос}
Декомпозированный запрос:
Ответь на вопрос пошагово:
1. {подвопрос_1}
2. {подвопрос_2}
3. {подвопрос_3}
После ответа на каждый шаг дай финальный ответ на исходный вопрос: {вопрос}
Плейсхолдеры:
- {вопрос} — твой исходный вопрос
- {подвопрос_1, 2, 3...} — разбивка вопроса на этапы (сначала идентификация объекта, потом запрос факта о нём)
Принцип разбивки: Если вопрос про объект + его свойство ("Когда X сделал Y?") — раздели: сначала "что такое X?", потом "что X сделал?", потом "когда это произошло?".
🚀 Быстрый старт — вставь в чат:
У меня вопрос: {твой вопрос}
Помоги разбить его на 3-4 подвопроса для пошаговой проверки.
Цель: если ответ на прямой вопрос и на пошаговый совпадут — факт надёжен.
Модель предложит декомпозицию. Потом запусти оба варианта (прямой + пошаговый) и сравни финальные ответы.
Ограничения
⚠️ Затраты: Нужно минимум 2 запроса вместо одного (удвоение токенов и времени). С декомпозицией на 4-5 шагов может потребоваться 3-4 отдельных запроса.
⚠️ Согласованные ошибки: Если модель не знает факта, но выучила устойчивый стереотип ("все российские компании выходят на Лондонскую биржу"), она выдаст одинаково неправильный ответ в обоих режимах. Метод не поймает такие ошибки.
⚠️ Простые вопросы: Для очевидных фактов ("столица России") оба режима всегда согласны — метод не даёт дополнительной информации. DBA полезен для сложных многоступенчатых вопросов, где модели есть простор для галлюцинаций.
⚠️ Требует декомпозиции: Ты должен уметь разбить вопрос на подвопросы. Для некоторых задач (креатив, мнения) декомпозиция не имеет смысла — метод только для фактических вопросов с проверяемым ответом.
Как исследовали
Команда проверила идею на шести бенчмарках (Bamboogle, MuSiQue, HotpotQA и др.) и девяти моделях от 7B до frontier (GPT-5.1, Gemini-2.5). Для каждого вопроса создали вручную проверенную декомпозицию — золотой стандарт, который гарантирует что прямой и пошаговый варианты семантически идентичны. Это убрало ошибки планирования как фактор — остались только ошибки знания и выполнения.
Сравнивали три режима: Direct (прямой вопрос), Assistive (список всех подвопросов сразу, модель отвечает за один запрос), Incremental (подвопросы задаются по одному, каждый — отдельный запрос). Измеряли точность (совпадение с правильным ответом) и согласованность (совпадение между режимами).
Главная находка: У маленьких моделей (до 70B) декомпозиция сильно улучшает точность — на +20-27% на сложных датасетах. Но у frontier-моделей улучшение исчезает или становится отрицательным (−3% до −8%). При этом корреляция точности и согласованности остаётся высокой (до r=0.98) у всех моделей. Это значит: декомпозиция перестала быть костылём для точности, но стала диагностическим инструментом.
Ввели метрику Reliability Multiplier (RM) — во сколько раз правильный ответ чаще встречается при согласии режимов, чем при несогласии. У маленьких моделей RM = 1-2× (почти случайность), у средних 2-10×, у Gemini Pro на Mintaka = 50× — если режимы согласны, вероятность правильности взлетает в 50 раз. Это огромный сигнал для фильтрации.
Проверили DBA против трёх базовых методов детекции ошибок: AYS ("Ты уверен?"), IC-IDK (инструкция "отвечай 'не знаю'"), Self-consistency (голосование по нескольким ответам с температурой). DBA превзошёл все базовые методы по F1-score в 16 из 18 пар модель-датасет. На Llama-70B и Qwen-8B F1 достигал 0.88-0.94, намного выше чем у AYS (0.51-0.76). AUROC всегда выше 0.5, что доказывает: метод реально различает правильные и неправильные ответы, а не просто чаще отказывается.
Почему DBA выигрывает: Базовые методы страдают от избыточной уверенности — модель галлюцинирует, но на "Ты уверен?" отвечает "Да". DBA не полагается на самооценку модели, а проверяет внутреннюю стабильность через поведенческий эксперимент. Несогласие = модель не может воспроизвести тот же ответ дважды = знания нет.
Адаптации и экстраполяции
🔧 Техника: три режима вместо двух → ещё надёжнее
Исследование сравнивает Direct с одним видом декомпозиции (Assistive или Incremental). Можно комбинировать все три:
1. Прямой вопрос → Ответ A
2. Все подвопросы разом в одном промпте → Ответ B
3. Подвопросы по одному, поэтапно → Ответ C
Если A = B = C → максимальная уверенность
Если хотя бы один отличается → не доверяй
Такой подход даёт двойную проверку: Assistive и Incremental — разные способы декомпозиции, если факт устойчив, все три сойдутся. Если модель импровизирует, хотя бы один из трёх разойдётся. Цена — три запроса вместо двух, но для критически важных фактов это оправдано.
🔧 Техника: замени декомпозицию на переформулировку → быстрее адаптировать
Разбивка на подвопросы требует понимания структуры задачи. Можно использовать принцип DBA с переформулировкой вместо декомпозиции:
Промпт 1: "В каком году Озон вышел на IPO?"
Промпт 2: "Перефразирую: когда компания Ozon Holdings впервые
разместила акции на публичной бирже? Укажи год и название биржи."
Сравни ответы — если разные, факт ненадёжен.
Механика та же: стабильное знание устойчиво к вариациям формулировки, галлюцинация — нет. Переформулировка проще чем декомпозиция, но даёт похожий эффект проверки.
🔧 Техника: используй DBA как pre-check перед RAG → экономь на retrieval
В связке RAG (retrieval-augmented generation) можно сначала проверить нужен ли поиск вообще:
1. Задай вопрос в closed-book режиме двумя способами
2. Если ответы совпадают → модель знает, поиск не нужен
3. Если ответы разные → запусти RAG
Польза: RAG тратит токены и время на retrieval + обработку документов. Если модель уверенно знает ответ (согласие в DBA), зачем искать? Экономия на простых вопросах, точность на сложных.