TL;DR
Operadic Consistency (OC) — это приём проверки ответа, который использует фундаментальное свойство логически связных рассуждений: если модель отвечает на сложный вопрос напрямую и она же отвечает пошагово (сначала на подвопросы, потом собирает итог) — ответы должны совпасть. Если они расходятся — прямой ответ скорее всего неверный.
LLM часто уверенно отвечает на сложные многошаговые вопросы — и ошибается. Особая боль: модель при повторном вопросе даёт похожий ответ, поэтому стандартный приём "задай три раза и сравни" (self-consistency) не ловит ошибку. Модель стабильно галлюцинирует. Это как проверять себя, переписывая задачу теми же словами — найдёшь ровно те же ошибки.
OC ловит другое: внутреннее противоречие. Задаёшь вопрос напрямую → получаешь ответ A. Раскладываешь тот же вопрос на шаги → получаешь ответ B. A ≠ B — сигнал тревоги. Пошаговый путь при этом обычно надёжнее прямого.
Схема метода
Все шаги выполняются в одном или двух запросах к модели.
ШАГ 1: Прямой ответ
→ Спроси сложный вопрос напрямую → получи Ответ A
ШАГ 2: Пошаговый ответ
→ Разбей вопрос на под-вопрос Q1 и под-вопрос Q2
→ Спроси Q1 → получи промежуточный ответ a1
→ Подставь a1 в Q2 → спроси Q2 → получи Ответ B
ШАГ 3: Сравнение
→ A = B → доверяй
→ A ≠ B → прямой ответ под подозрением, Ответ B надёжнее
Метод работает в одном промпте: можно попросить модель сделать оба пути сразу и сравнить.
Пример применения
Задача: Ты готовишься к переговорам с инвестором. Хочешь понять: был ли Telegram прибыльным в год, когда набрал 100 миллионов новых пользователей?
Это многошаговый вопрос — сначала нужна дата, потом финансовые данные за тот год. Именно такие вопросы модели часто "склеивают" в один уверенный ответ, который на деле неверен.
Промпт:
Ответь на вопрос двумя способами:
СПОСОБ 1 — прямой ответ:
Был ли Telegram прибыльным в год, когда он набрал 100 миллионов новых пользователей?
СПОСОБ 2 — пошаговый:
Шаг 1: В каком году Telegram набрал 100 миллионов новых пользователей за год?
Шаг 2: Используя ответ из шага 1 — был ли Telegram прибыльным в [тот год]?
В конце сравни два ответа. Если они расходятся — объясни, какому больше доверяешь и почему.
Результат: Модель покажет два пути рассуждений: прямой и декомпозированный. Если ответы совпадут — это хороший знак точности. Если разойдутся — модель сама укажет, где именно возникло противоречие, и пошаговый путь с явным промежуточным фактом будет надёжнее для переговоров.
Почему это работает
LLM не вычисляет — она предсказывает следующий токен. На простой прямой вопрос модель выдаёт ответ, который статистически похож на правильный в её обучающих данных. Это работает быстро, но без явного шага "сначала узнаю факт, потом рассуждаю" — легко смешать факты или выдать уверенную ложь.
Стандартная проверка через повтор ("спроси три раза") ловит случайные ошибки, но не системные. Если модель делает один и тот же ошибочный вывод из одних и тех же данных — при каждом повторе она даёт тот же неверный ответ. Уверенность растёт, а ошибка — тоже.
OC использует другую слабость как инструмент. Когда модель идёт пошагово, она явно фиксирует промежуточный факт — и дальше рассуждает от него. Это другой паттерн генерации, который активирует другие связи. Если прямой путь и пошаговый приходят к одному — вероятность правоты высокая. Если расходятся — прямой путь "перепрыгнул" через рассуждение и что-то потерял.
Рычаги управления: - Сколько шагов — для более сложных вопросов можно сделать 3-4 под-вопроса, не только 2 - Инструкция "объясни расхождение" — добавь в промпт "если ответы разные — объясни почему", чтобы модель сама диагностировала ошибку - Явная формулировка подстановки — пиши в шаге 2 не "используй то что выше", а буквально вставляй ответ из шага 1: это снижает потери при переходе
Шаблон промпта
Ответь на вопрос двумя способами и сравни результаты.
**СПОСОБ 1 — прямой ответ:**
{твой сложный вопрос}
**СПОСОБ 2 — пошаговый:**
Шаг 1: {первый под-вопрос — факт или данные, которые нужны для ответа}
Шаг 2: Используя ответ из шага 1 — {второй под-вопрос, зависящий от первого}
**Сравнение:**
Совпадают ли два ответа? Если нет — какому больше доверяешь и почему?
Что подставлять:
- {твой сложный вопрос} — любой вопрос, который требует нескольких фактов или шагов логики
- {первый под-вопрос} — изолируй один ключевой факт, без которого нельзя ответить на главный вопрос
- {второй под-вопрос} — вопрос, в котором явно используется ответ из первого шага
Как понять, нужна ли декомпозиция: Спроси себя — "чтобы ответить на это, нужно сначала узнать X, а потом уже Y?" Если да — вопрос подходит для OC-проверки.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Operadic Consistency — техники проверки ответов через сравнение прямого
и пошагового пути. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой вопрос нужно проверить и как его разбить на шаги — потому что без чёткой декомпозиции невозможно сравнить два пути рассуждений.
Ограничения
⚠️ Простые вопросы: Метод избыточен для фактов, которые не требуют нескольких шагов — "какая столица Франции", "кто написал Войну и Мир". Декомпозировать нечего, сравнение бессмысленно.
⚠️ Субъективные задачи: Если вопрос не имеет единственного правильного ответа (оценка текста, стиль, творческие решения) — расхождение ответов не означает ошибку. Это просто разные перспективы.
⚠️ Некачественная декомпозиция: Если ты неправильно разбил вопрос на шаги, OC-проверка будет сравнивать несопоставимые вещи. Мусор на входе — мусор на выходе. Самый важный навык здесь — правильно выделить под-вопросы.
⚠️ Три запроса вместо одного: Если контекст ограничен или важна скорость — метод утраивает стоимость запроса. Хотя в одном промпте это решаемо.
Как исследовали
Исследователи взяли 12 моделей разного размера — от маленьких 4B до огромных 671B (DeepSeek, GPT-4o-mini, Gemini 2.5 Flash, Llama и другие) — и проверили одну идею: можно ли предсказать, ошиблась ли модель, просто сравнив её прямой и пошаговый ответ? Для каждого вопроса из четырёх датасетов задавали вопрос напрямую и через декомпозицию, результаты сравнивали. Параллельно считали другие сигналы "неуверенности" модели: классическую self-consistency (задай 10 раз, посмотри насколько ответы похожи) и семантическую энтропию.
Ключевая находка: self-consistency хорошо работала на двух датасетах и падала до нуля на двух других — именно там, где вопросы требуют нескольких приёмов рассуждения. OC при этом держала высокую корреляцию с точностью на всех четырёх датасетах без исключений. Это неожиданно — более простой метод (сравни два пути) оказался надёжнее более навороченного (30 повторных генераций).
Дополнительно проверили на пяти "думающих" моделях (reasoning models вроде o1) — там декомпозицию не задавали вручную, а извлекали прямо из их chain-of-thought. OC работала и там: у моделей, которые в своих рассуждениях явно решали подзадачи, можно поймать несоответствие, не добавляя ни одного слова в промпт.
Адаптации и экстраполяции
🔧 Техника: сделать проверку невидимой → получить чистый ответ + внутреннюю диагностику
Если не хочешь видеть два пути — просто попроси модель проверить себя молча:
Ответь на вопрос: {вопрос}
Перед финальным ответом — внутренне проверь себя: разбей вопрос на шаги,
реши пошагово и убедись что получаешь то же самое.
Если есть расхождение — отметь это в ответе.
🔧 Техника: замена сравнения на шкалу уверенности
Вместо бинарного "совпало/не совпало" — попроси модель дать число:
...В конце укажи: насколько уверен в ответе от 1 до 10,
учитывая совпадение двух путей рассуждений?
🔧 Экстраполяция: OC-проверка цепочки решений
Принцип работает не только для вопросов-фактов, но и для стратегических решений с причинно-следственными цепочками:
Оцени решение двумя способами:
СПОСОБ 1 — прямая оценка:
Стоит ли {имя} переходить из найма в собственный бизнес прямо сейчас?
СПОСОБ 2 — пошаговая оценка:
Шаг 1: Каков текущий финансовый запас прочности (runway) у {имя}?
Шаг 2: Каков риск первого года с учётом этого runway?
Шаг 3: Стоит ли переходить сейчас, учитывая этот уровень риска?
Совпадают ли выводы? Если нет — что изменилось в пошаговом разборе?
Ресурсы
Operadic Consistency: a label-free signal for compositional reasoning failures in LLMs GitHub: github.com/natebottman/operadic-consistency-paper
Авторы: Nathaniel Bottman (Incubilate, Seattle), Yinhong Liu (University of Cambridge), Kyle Richardson (Allen Institute for Artificial Intelligence, Seattle)
Связанные методы из статьи: Self-Consistency (Wang et al., 2023), Semantic Entropy (Kuhn et al., 2023), P(True) (Kadavath et al., 2022), Chain-of-Thought (Wei et al., 2022)