TL;DR
Когда языковая модель отвечает на сложный вопрос быстро и уверенно — это чаще признак ошибки, а не правоты. Исследователи измерили внутреннюю "уверенность" модели (насколько сильно она сосредоточена на одном варианте токена вместо нескольких) на каждом шаге рассуждения и заметили закономерность: правильные ответы на трудные задачи начинаются с низкой уверенности (модель прощупывает разные подходы) и заканчиваются высокой (сходится к выводу). А неправильные ответы часто уверены с первого токена — модель хватается за первую попавшуюся идею и не сомневается в ней до конца.
Это ломает привычный подход "выбери самый уверенный из нескольких ответов модели" — он отлично работает на лёгких задачах, но на сложных начинает систематически выбирать уверенно неправильные ответы. Причина простая: модель, которая сразу закрыла для себя все альтернативы, просто не увидела, что задача сложная.
Метод Consilience решает это, оценивая не среднюю уверенность ответа, а траекторию: он специально штрафует высокую уверенность в начале рассуждения и требует высокую уверенность в конце. Из нескольких сгенерированных вариантов ответа выбирается тот, у которого разница "уверенность в конце минус уверенность в начале" максимальна.
Схема метода (оригинал, техническая часть)
ШАГ 1: Сгенерировать n вариантов ответа на один и тот же промпт (параллельно) → n текстов
ШАГ 2: В каждом варианте отделить фазу рассуждения от фазы финального ответа
(по маркеру типа ) → две части текста
ШАГ 3: Посчитать среднюю "уверенность" (на основе log-вероятностей токенов)
первых W токенов рассуждения → C_initial
ШАГ 4: Посчитать среднюю уверенность последних W токенов рассуждения → C_final
ШАГ 5: Вычислить итоговый счёт: S = C_final − α × C_initial
ШАГ 6: Выбрать вариант с максимальным S как финальный ответ
⚠️ Все шаги требуют доступа к логитам/log-вероятностям токенов — это API-функция, а не то, что видно в обычном чате ChatGPT или Claude. Посчитать это руками в диалоге нельзя.
Что из этого реально применимо в чате
Прямой метод (с формулой и log-вероятностями) требует программирования и API с доступом к логитам — недоступно обычному пользователю чата.
Но из находки можно вытащить рабочий принцип промптинга: если задача сложная, не позволяй модели скатиться в мгновенную уверенность. Заставь её сначала явно "расщепить" пространство решений — рассмотреть несколько разных подходов — и только потом сходиться к одному ответу. Это имитирует ту самую "правильную" траекторию (низкая уверенность → высокая), но делается текстовой инструкцией, а не измерением вероятностей.
Задача: Вы просите Claude или ChatGPT решить нетривиальную бизнес-задачу — например, придумать стратегию выхода на рынок доставки в Казахстане для российского фудтех-стартапа, где очевидного решения нет.
Промпт:
Реши задачу: {опиши сложную задачу}.
Не давай сразу один ответ. Сначала предложи 3 РАЗНЫХ подхода к решению,
принципиально отличающихся друг от друга (не вариации одного и того же).
Для каждого подхода честно укажи, в чём он слабый и где может провалиться.
Только после этого — сравни все три и выбери один, объяснив,
почему именно он выдерживает критику лучше остальных.
Финальный ответ дай отдельным блоком с чёткой уверенностью в решении.
Результат: Модель выдаст три содержательно разных варианта решения с их слабыми местами, затем — сравнение и один финальный выбор с аргументацией. Это структурно похоже на паттерн "разведка → сходимость", который в исследовании коррелирует с правильными ответами.
Почему это работает
Модель генерирует текст токен за токеном, и её "уверенность" на каждом шаге — это просто степень того, насколько предыдущий текст сузил выбор следующего слова. Это не индикатор истинности, а индикатор того, насколько сильно модель уже закрыла альтернативы.
На простых задачах закрыть альтернативы сразу — это нормально: там правильный путь один и очевиден. На сложных задачах мгновенное закрытие альтернатив означает, что модель не заметила сложность и выбрала первую попавшуюся линию рассуждения, даже если она ошибочна.
Явная инструкция "сначала предложи разные подходы, потом выбери" заставляет модель текстуально проиграть тот же процесс, который в исследовании измеряли через вероятности: сначала расширение пространства решений, потом сужение. Рычаг управления здесь — число подходов (3 в примере) и требование, чтобы они были содержательно разными, а не вариациями одной идеи — без этого условия модель может сгенерировать три похожих ответа и не получить эффекта разведки.
Ограничения
⚠️ Оригинальный метод недоступен в чате: формула Consilience считается по log-вероятностям токенов через API — это требует кода и доступа к внутренним данным модели, не доступным в обычном интерфейсе ChatGPT/Claude.
⚠️ На лёгких задачах метод не нужен: если модель и так уверенно и правильно отвечает с первой попытки, требование "разведки" — лишняя трата токенов и времени.
⚠️ Текстовая имитация — не то же самое, что измерение: просьба "предложи 3 разных подхода" заставляет модель писать текст в нужной структуре, но не гарантирует, что внутренняя уверенность модели действительно распределилась — это косвенная аналогия, не строгое воспроизведение метода.
Как исследовали
Команда из AWS AI Labs проверяла гипотезу на моделях GPT-OSS-120B/20B, DeepSeek-R1-Distill и Qwen3 — на задачах по математике (HMMT), знаниям уровня аспирантуры (GPQA), генерации кода (LiveCodeBench) и агентных правках кода (SWE-bench). Для каждого запроса генерировали пул из 256 ответов и выбирали лучший разными методами — сравнивали с простым выбором "самого уверенного ответа" целиком.
Ключевое наблюдение: на всём датасете уверенность неплохо предсказывает правильность, но если отфильтровать только трудные задачи (где модель угадывает правильно меньше 20% раз), картина разворачивается — неправильные ответы становятся более уверенными, чем правильные, и распределения перестают разделяться. Это и натолкнуло на идею смотреть не на уровень уверенности, а на её изменение во времени.
Результаты подтвердили гипотезу: на генерации кода метод поднял точность модели GPT-OSS-120B с 65.7% до 69.7% (там, где голосование большинством вообще неприменимо, так как ответы — это код, а не варианты из списка). На SWE-bench (реальные правки кода агентом) метод дал прирост в решённых задачах на несколько процентных пунктов.