TL;DR
Contradiction Gate — техника из двух отдельных запросов к одной и той же модели: первый решает задачу, второй проверяет входные данные на противоречия. Если проверка находит конфликт — ответ первого запроса отбрасывается, модель отвечает "не могу посчитать".
Главная находка: LLM отличает "не хватает данных" от "данные противоречат друг другу", и ведёт себя с ними по-разному. Если в условии не хватает факта — модель почти всегда честно отказывается отвечать. Но если в условии два факта противоречат друг другу (например: "супруги подают декларацию совместно" и через предложение — "супруги подают декларацию раздельно"), модель это не замечает. Она хватается за один из фактов и уверенно выдаёт число — в 63-76% случаев тот самый ответ, который получился бы на чистых, непротиворечивых данных. Никакого сигнала, что что-то не так.
Решение неожиданно простое: та же самая модель, если её попросить не решить, а проверить входные данные, находит 75-83% этих же противоречий. Значит, модель умеет их видеть — просто не смотрит на них, когда занята расчётом. Технику собирают в два шага: (1) решить задачу как обычно, (2) отдельным запросом спросить модель "нет ли противоречий во входных фактах", и если она отвечает "да" — заменить ответ первого шага на отказ.
Схема метода
ШАГ 1 (запрос 1): Реши задачу на основе данных → число ИЛИ "не могу ответить"
ШАГ 2 (запрос 2, отдельно, та же модель): Проверь эти же данные на полноту
и внутреннюю согласованность → метка: "всё ок" / "не хватает данных" / "есть противоречие"
ШАГ 3 (логика поверх): Если ШАГ 2 = "есть противоречие" →
заменить ответ ШАГА 1 на отказ, независимо от того, что там было
Шаги 1 и 2 — это два отдельных запроса (в исследовании — два отдельных вызова API с одинаковым контекстом). В обычном чате это два сообщения или два отдельных чата с одинаковыми исходными данными.
Пример применения
Задача: Вы — фрилансер-проектный менеджер. Клиент присылает бриф на разработку сайта. В брифе противоречие: в начале клиент пишет "бюджет 80 000 рублей, простой лендинг на одну страницу", а в конце — "нужны также раздел с каталогом на 200 товаров и личный кабинет". Вы просите ChatGPT посчитать смету, и модель, скорее всего, просто посчитает смету по одной из версий требований, не заметив конфликт.
Промпт (запрос 1 — решение):
Ты — опытный проектный менеджер веб-разработки. Вот бриф от клиента:
«Бюджет 80 000 рублей, нужен простой лендинг на одну страницу.
Также нужны раздел с каталогом на 200 товаров и личный кабинет пользователя.»
Посчитай примерную стоимость и сроки разработки на основе этого брифа.
Если данных недостаточно для расчёта — напиши «не могу рассчитать».
Промпт (запрос 2 — проверка, отдельным сообщением или в новом чате):
Проверь этот бриф от клиента на внутреннюю согласованность:
«Бюджет 80 000 рублей, нужен простой лендинг на одну страницу.
Также нужны раздел с каталогом на 200 товаров и личный кабинет пользователя.»
Есть ли в этом брифе факты, которые противоречат друг другу
(например, разный объём работ, разные бюджеты, разные сроки)?
Ответь одним из трёх вариантов:
1) «всё согласовано»
2) «не хватает данных» — укажи каких
3) «есть противоречие» — назови конкретно, какие два факта конфликтуют
Результат: В первом запросе модель скорее всего молча посчитает смету — например, под "простой лендинг" — и не упомянёт, что каталог на 200 товаров и личный кабинет туда явно не влезают при таком бюджете. Во втором запросе, скорее всего, модель прямо назовёт конфликт: "простой лендинг на одну страницу" не сочетается с "каталог на 200 товаров и личный кабинет" при бюджете 80 000 рублей. Увидев эту метку — вы отбрасываете смету из первого запроса и возвращаетесь к клиенту с уточнением, а не с ложно-уверенной цифрой.
Почему это работает
Когда модель решает задачу, всё её внимание уходит на вычисление: она берёт факты по порядку и считает, не сверяя их друг с другом — это похоже на то, как человек, увлечённый счётом в столбик, не замечает, что в условии задачи два раза указан разный возраст персонажа. Модель просто не тратит "ресурс внимания" на сверку фактов между собой, потому что задача сформулирована как "посчитай", а не "проверь".
Но сильная сторона модели — она отлично умеет находить несоответствия, если её явно попросить сравнить факты друг с другом, а не считать. Формулировка "проверь, нет ли противоречий" — это другая задача с другим фокусом внимания, и в этом режиме модель находит конфликт в 75-83% случаев — почти так же хорошо, независимо от того, насколько сильна модель в математике.
Метод использует эту разницу: вместо того чтобы улучшать сам расчёт, он добавляет второй взгляд на те же данные с другой задачей и использует его как фильтр перед тем, как отдать ответ пользователю.
Рычаги управления:
- Метки проверки (всё ок / не хватает / противоречие) → можно расширить под свою задачу, например добавить неоднозначность формулировки
- Формулировка проверочного вопроса → чем конкретнее (например, "сравни цифры бюджета в разных частях текста"), тем выше шанс поймать конфликт
- Что делать при срабатывании гейта → в исследовании это жёсткий отказ, но можно заменить на "покажи оба варианта расчёта" вместо полного отказа
Шаблон промпта
ЗАПРОС 1 (решение):
Ты — {роль эксперта}. Вот входные данные:
«{данные/бриф/условие задачи}»
{конкретное задание — посчитай/реши/сделай вывод}.
Если данных недостаточно для ответа — напиши «не могу ответить».
---
ЗАПРОС 2 (проверка, отдельным сообщением):
Проверь эти же входные данные на внутреннюю согласованность:
«{те же данные/бриф/условие задачи}»
Есть ли в них факты, которые противоречат друг другу?
Ответь одним из трёх вариантов:
1) «всё согласовано»
2) «не хватает данных» — укажи каких именно
3) «есть противоречие» — назови конкретно, какие два факта конфликтуют
---
Если ответ на ЗАПРОС 2 — «есть противоречие», не используй ответ
из ЗАПРОСА 1. Вместо этого сообщи, что данные противоречивы,
и укажи, что именно нужно уточнить.
Что подставлять: {роль эксперта} — под кого маскируется модель (бухгалтер, юрист, проектный менеджер), {данные/бриф/условие задачи} — исходный текст с фактами, {конкретное задание} — что именно нужно посчитать или решить.
🚀 Быстрый старт — вставь в чат:
Вот шаблон техники "Contradiction Gate" — двух-шаговая проверка данных
на противоречия перед тем, как доверять ответу модели.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие именно данные вы обычно подаёте на вход и какого типа противоречия в них встречаются (числовые, категориальные, временные) — потому что от типа данных зависит, как именно сформулировать проверочный вопрос во втором запросе.
Ограничения
⚠️ Дополнительная стоимость: метод требует второй запрос к модели на каждую задачу — это лишнее время и токены, хоть и небольшие.
⚠️ Ложные срабатывания: проверочный запрос иногда находит "противоречие" там, где его нет, и отбрасывает верный ответ. В исследовании это стоило до 5 процентных пунктов точности на чистых данных.
⚠️ Не для всех типов конфликтов проверено: метод надёжно показал себя на противоречиях в категориальных фактах (статус, категория, да/нет). Для числовых противоречий (два разных значения одной суммы) исследователи отмечают, что такие случаи модель скорее читает как "уточнение" или "обновление", а не как явный конфликт — гейт может здесь работать хуже.
⚠️ Одна и та же модель для решения и проверки: если у модели есть "слепое пятно" — она может не увидеть один и тот же тип ошибки в обоих режимах. Использовать разные модели для решения и проверки не проверялось, но потенциально надёжнее.
Как исследовали
Исследователи взяли 91 налоговый кейс из известного юридического бенчмарка SARA (расчёт налога по реальному кодексу США) и создали два вида "порченых" версий: в одних убрали нужную цифру (например, доход), в других — вставили противоречащее утверждение о категориальном факте (например, "подают совместно" рядом с "подают раздельно"). Проверили шесть свежих моделей — GPT-5 mini, GPT-5.2, Claude Sonnet 4.6, Qwen3.7-Plus, Kimi K2.5, Gemini 2.5 Flash — каждую по три прогона для надёжности.
Каждую модель просили либо решить задачу (число или отказ), либо отдельно — проверить входные данные на противоречия. Оказалось, что при нехватке факта модели почти всегда честно отказываются отвечать. А при противоречии — четыре самые точные модели отказывались в 0-15% случаев и в 63-76% случаев тупо выдавали ответ, как если бы конфликта не было. Но те же модели, спрошенные "проверь данные", находили конфликт в 75-83% случаев.
Любопытная деталь: модели с "цепочкой рассуждений" (то есть те, что "думают" перед ответом) не оказались лучше в поиске противоречий, чем модели без такого режима — значит, дело не в глубине рассуждений, а в том, на что модель направляет внимание при формулировке задачи "посчитай" против "проверь". Из этого и родился Contradiction Gate — простой способ заставить модель посмотреть на данные вторым взглядом, прежде чем доверять первому ответу.
Ресурсы
Solving versus Verifying: Catching Contradictions in Tax Reasoning Systems, Albert Sadowski, Jarosław A. Chudziak, Warsaw University of Technology. Датасет и код: доступны публично на Zenodo (doi.org/10.5281/zenodo.22329077). Использован бенчмарк SARA / LegalBench (Holzenberger et al., 2020; Guha et al., 2023).