TL;DR
Это протокол опровержения. Модель строит таблицу: по строкам версии (кандидаты), по столбцам улики. В каждой клетке она пишет «подтверждает», «противоречит» или «не относится» и называет улику. Версия, у которой противоречий больше, чем подтверждений, отбрасывается. Вывод разрешён, только когда отброшено не меньше половины версий. Ответ выдаётся одной строкой в фиксированном формате.
Главная находка: в задачах «выбери одну из перечислимых версий» потолок задаёт сила модели, а пол задаёт дисциплина вывода. За два года смена поколений моделей почти не подвинула результат (от −0,03 до +0,08 по шкале 0–1). А ошибки «дисциплины» остаются даже у топовых моделей: рассуждение не заканчивается, формат ответа нарушен, между запусками на одном вопросе результат скачет. У одной модели разброс доходил до 0,39 от всей шкалы, то есть то почти ноль, то почти максимум. Причина в том, что модель по привычке прыгает к ответу по похожести и не проверяет версии по одной.
Протокол ставит модель в рамки: версии перечислены, каждая проверена, ответ в одной строке. Он спасает «недисциплинированные» модели: у DeepSeek-V4-Flash прирост +0,27, и целиком за счёт того, что рассуждение наконец заканчивается. У Kimi K3 разброс упал с 0,218 до 0,007. Но дисциплинированным моделям протокол вредит: у Qwen3 падение на 0,09–0,12. Поэтому его нужно включать избирательно.
Схема метода
ШАГ 1: Версии (кандидаты) → закрытый список, выход за него запрещён
ШАГ 2: Матрица «кандидат × улика» → в каждой клетке: поддерживает / противоречит / не относится
+ при «противоречит» обязательно указать улику («противоречит E3»)
ШАГ 3: Итог по строке → версия совместима, если подтверждений больше, чем противоречий,
и ключевая улика подтверждена; иначе несовместима
ШАГ 4: Проверка достаточности → отброшено ≥ ½ версий? Нет → пересмотреть улики
ШАГ 5: Выбор → совместимая версия с наибольшим числом подтверждений
→ одна строка: [Итог]: X
ЗАПРЕТЫ: выбирать по порядку в списке; копировать готовый ответ из примера
Всё это можно сделать в одном промпте, одним проходом.
В полной версии статьи вокруг протокола пять этапов: гипотезы → проверка → причинная цепочка → действие → обратная проверка. Тот же шаблон ниже покрывает все пять.
Пример применения
Задача: Селлер на Wildberries увидел, что заказы по карточке «Худи оверсайз» упали на 35% за неделю. Он хочет не гадать, а получить проверяемый разбор причин, который можно показать партнёру.
Промпт:
Ты аналитик маркетплейса. Ты не гадаешь, а проверяешь версии по уликам.
Заказы по карточке «Худи оверсайз» (WB) упали на 35% за 7 дней. Найди причину.
H1: Конкурент снизил цену
H2: Карточка просела в выдаче из-за падения рейтинга
H3: Закончились ключевые размеры (M, L)
H4: Выросла комиссия или логистика, и мы подняли цену
H5: Сезонный спад спроса
Других версий не добавлять.
E1: Рейтинг карточки 4,8 → 4,7 за неделю
E2: Остатки: M — 0, L — 0, S и XL — по 40 шт.
E3: Наша цена выросла с 2 490 до 2 790 ₽ (4 дня назад)
E4: Топ-3 конкурентов: цены не менялись
E5: Поисковые запросы по «худи оверсайз» в категории: −5% к прошлой неделе
E6: Позиция по главному запросу: 12 → 31
KEY: E2
1. Построй матрицу: строки H1–H5, столбцы E1–E6. В каждой клетке одно из: support / oppose / irrelevant.
2. Для каждого oppose обязательно укажи улику: «oppose — противоречит E4».
3. Версия совместима, если support больше, чем oppose, и ключевая улика не противоречит версии.
4. Если несовместимы меньше половины версий, напиши «Недостаточно: пересмотри улики» и перепроверь самые спорные клетки.
5. Выбери совместимую версию с наибольшим числом support. Порядок в списке и примеры не учитывай.
Сначала матрица, потом итог по строкам, потом одна строка:
[Главная причина]: Hx
Результат: Модель выдаст таблицу 5×6 с пометками в клетках и ссылками на улики при каждом «противоречит». Дальше будет итог по каждой версии (совместима или нет), проверка «отброшено не меньше половины» и финальная строка в заданном формате. Каждый вывод можно проверить глазами по клеткам.
Почему это работает
Слабость. Модель склонна отвечать по ассоциации: увидела «упали заказы», сразу сказала «конкуренты». Версии не перебираются, ответ нельзя проверить. Просить её «покритиковать себя» без внешней структуры почти не помогает: самопроверка без опоры не улучшает рассуждение, а иногда ухудшает. Даже явная инструкция «исправь ошибку» срабатывает меньше чем в половине случаев.
Сильная сторона. Модель хорошо заполняет клетки по маленьким локальным вопросам: «улика E3 поддерживает версию H1 или противоречит ей?» С такой мелкой задачей она справляется надёжнее, чем с «найди причину».
Как протокол их связывает. Он разбивает большую задачу на клетки, требует называть противоречащую улику («противоречит E3») и не пускает к выводу, пока не отброшена половина версий. Формат одной строкой делает ответ проверяемым. В статье показано, что эффект даёт структура, а не знания: когда из протокола убрали все вставленные доменные знания, результат не изменился.
Рычаги управления: - Порог «не меньше половины» → ужесточи (две трети) для рискованных решений, ослабь для быстрых. - Ключевая улика (KEY) → задай свою. Это «без этого версия не живёт». - Закрытый список версий → дай модели право добавить одну версию, если нужен более широкий поиск. Это ослабляет протокол. - Формат одной строки → по абляциям именно этот слой «стоит дороже всего» на сильных моделях. Убери его, если читаешь ответ глазами и машинная проверка не нужна. - Запреты («не выбирай по порядку», «не копируй пример») → оставь всегда, они защищают от лени.
Шаблон промпта
Ты аналитик. Ты не гадаешь, а проверяешь версии по уликам.
{задача: что нужно определить или выбрать}
{H1: версия}
{H2: версия}
{H3: версия}
Других версий не добавлять.
{E1: улика}
{E2: улика}
{E3: улика}
KEY: {номер ключевой улики}
1. Построй матрицу: строки — версии, столбцы — улики. В каждой клетке одно из: support / oppose / irrelevant.
2. Каждый oppose обоснуй ссылкой на конкретную улику: «oppose — противоречит E_».
3. Версия совместима, если support больше, чем oppose, и ключевая улика её не опровергает. Иначе несовместима.
4. Проверка достаточности: несовместимых версий должно быть не меньше половины. Если меньше, напиши «Недостаточно» и перепроверь спорные клетки.
5. Выбери совместимую версию с наибольшим числом support. Порядок в списке и примеры не влияют на выбор.
6. Если нужна рекомендация, выведи действие, которое прямо следует из выбранной версии. Затем проверь его на запреты и риски: {ограничения}.
Матрица → итог по строкам → проверка достаточности → одна строка:
[{название итога}]: {версия}
Что подставлять:
- {задача}: один вопрос (диагностика, выбор причины, выбор варианта).
- Версии: 3–7 штук; если не знаешь, попроси модель сначала сгенерировать список и согласуй его.
- Улики: факты, цифры, наблюдения, лучше пронумерованные.
- {ограничения}: что нельзя рекомендовать (бюджет, закон, риски).
🚀 Быстрый старт — вставь в чат:
Вот шаблон протокола опровержения «кандидаты × улики». Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие версии рассматриваем, какие есть факты и какая улика ключевая. Без закрытого списка версий и пронумерованных улик матрицу не построить, а на ней и держится метод. Модель возьмёт паттерн из шаблона и соберёт готовый промпт под твою задачу.
Ограничения
⚠️ Дисциплинированным моделям протокол вредит: на моделях, которые и так рассуждают аккуратно и завершают ответ, качество в среднем падает (порядка 0,09–0,12 по шкале 0–1). Сначала проверь свою модель без протокола. Включай его, если ответы то обрываются, то нарушают формат, то скачут между запусками.
⚠️ Только задачи с перечислимыми версиями: метод требует закрытого списка кандидатов и набора улик. Для открытых, творческих задач и задач «придумай» он не подходит.
⚠️ Протокол не поднимает потолок: он убирает сбои дисциплины. Если модель не знает предметной области или ошибается в клетках, матрица зафиксирует ошибку аккуратно, но не исправит её.
⚠️ Клетки судит та же модель: ошибки в отдельных клетках возможны. Протокол делает их видимыми, но не убирает. В статье формат проверяется кодом, в чате ты проверяешь клетки глазами.
⚠️ Один домен: основной тест был на диагностике в традиционной китайской медицине, плюс отдельная проверка на математике. Перенос на бизнес-задачи логичен, но в статье напрямую не измерялся.
⚠️ Больше токенов и длиннее ответ: матрица занимает место, на простых вопросах это лишнее.
Как исследовали
Исследователи взяли публичный бенчмарк TCMEval-SDT: 200 клинических случаев, где нужно определить синдром по набору признаков. Каждую из пяти базовых моделей прогоняли с протоколом и без него, до трёх повторов, с парными статистическими тестами. Сначала показали, что два года прогресса моделей почти ничего не дали в «голом» режиме. Зато проявились сбои дисциплины: незаканчивающиеся рассуждения, нарушенный формат, огромный разброс между повторами.
Затем проверили гипотезу «протокол помогает там, где дисциплины нет, и мешает там, где она есть». Она подтвердилась. У DeepSeek-V4-Flash прирост +0,27, и разбор показал, что он целиком от спасения незавершённых рассуждений. У Kimi K3 разброс упал с 0,218 до 0,007. У Qwen3-4B и Qwen3-32B (с одинаковым бюджетом токенов и контролем температуры) протокол стоил 0,09–0,12.
Абляции (по очереди убирали части протокола) показали два интересных результата. Во-первых, основную цену на сильных моделях платит слой жёсткого формата, а связка причинной цепочки и формата работает в разные стороны в разных условиях. Во-вторых, удаление всех вставленных знаний не изменило оценку: эффект несёт структура, а не знания. Наконец, протокол переделали под математику с подброшенными ложными предпосылками. Он нашёл их в 89,8% случаев при 6,8% ложных тревог и вернул точность к уровню без дезинформации. Правда, на одной модели с небольшим запасом для улучшения.
Вывод для практики: не накручивай структуру на всё подряд. Сначала посмотри, где у твоей модели ломается дисциплина, и вводи рамки именно туда.
Адаптации и экстраполяции
🔧 Техника: перенос на проверку предпосылок → защита от ложных вводных
В статье показан двухэтапный вариант протокола для задач с подброшенной ложной информацией: «кандидаты» это предпосылки задачи, «улики» это проверки (числа, связи, внутренняя согласованность). Ложные предпосылки переписываются в виде напоминания, и только потом идёт решение.
Перед решением задачи:
1. Выпиши все предпосылки из условия (P1, P2, ...).
2. Проверь каждую по трём пунктам: числа верны? связи верны? не противоречит ли другим предпосылкам? Клетки: ok / fail / n/a, при fail укажи, что не сходится.
3. Каждую предпосылку с fail перепиши в виде напоминания: «Напоминание: на самом деле ...».
4. Реши задачу, опираясь только на проверенные и исправленные предпосылки.
🔧 Техника: добавить блок «ключевая улика» → быстрее отсев
Если в
задатьKEY: E_, версии, которым ключевая улика противоречит, автоматически несовместимы. Полезно, когда есть факт «без него версия невозможна» (например, нулевые остатки на складе для версии «спрос упал»).
Это мои адаптации, их в статье нет в таком виде. Первая основана на описанной в статье двухэтапной схеме, вторая на правиле «ключевой улики».
Ресурсы
- Статья: Output Discipline Sets the Floor: A Falsification-Guided, Model-Agnostic Agent Protocol for Auditable Hypothesis-Driven Decision Making
- Авторы: Jing Liu, Yongxing Qi, Ping Yao, Ting Wu (Hangzhou Innovation Institute, Beihang University; 32007 Unit, Beijing)
- Бенчмарк: TCMEval-SDT (определение синдромов в традиционной китайской медицине, 200 случаев)
- Связанные работы: исследование распространения ложных предпосылок по цепочке рассуждений (10–72% потерь точности); самокоррекция без внешней обратной связи; MedAgents, MDAgents (многоагентные подходы для сравнения)
- Разбор опирается на доступную часть статьи (аннотация, введение, описание фреймворка и протокола); подробные таблицы результатов и приложения в материале отсутствовали.