TL;DR
Hypothesis-Verification — техника, которая перестраивает логику анализа: вместо "ищи что-нибудь по теме" сначала формулируешь что именно должно быть правдой, чтобы каждый из вариантов ответа оказался верным. Только потом идёшь искать доказательства.
Стандартный подход к анализу "иди по теме и собирай что найдёшь" ломается на сложных задачах: первые найденные факты уводят цепочку рассуждений не туда, и каждый следующий шаг усиливает начальную ошибку. Ещё хуже — модель ищет то, что похоже на ответ, а не то, что реально различает верный и неверный варианты.
Метод решает это через четыре роли в одной задаче: Thinker переформулирует каждый вариант ответа в проверяемую гипотезу, Judge находит минимальную улику — ту единицу доказательства, которая разделяет гипотезы, Verifier проверяет улику по фактическим данным, Answer объединяет всё в финальный вывод с явной цепочкой рассуждений.
Схема метода
(Все четыре шага можно запустить в одном промпте)
ШАГ 1 — Thinker: для каждого варианта ответа формулирует гипотезу
"Что должно быть правдой, чтобы ответ X оказался верным?"
→ список гипотез H1, H2, H3...
ШАГ 2 — Judge: из набора гипотез выводит одну дискриминирующую улику
"Что нужно проверить, чтобы различить гипотезы?"
→ одна конкретная улика κ
ШАГ 3 — Verifier: проверяет улику по доступным данным
→ статус ПОДТВЕРЖДЕНО / ЧАСТИЧНО / НЕ ПОДТВЕРЖДЕНО + обоснование
ШАГ 4 — Answer: интегрирует доказательства и формулирует финальный ответ
→ вывод с явной цепочкой логики
Если статус НЕ ПОДТВЕРЖДЕНО → цикл уточнения: гипотезы конкретизируются
и проверка повторяется (обычно 1-2 раза)
Пример применения
Задача: Павел открыл пельменную на Яндекс.Еде четыре месяца назад. Средний рейтинг 3.8 — плохо. Есть три версии: (A) плохой продукт, (B) долгая доставка, (C) слабое оформление карточки. Нужно понять причину, не гадая.
Промпт:
Сыграй роль аналитика по четырёхагентной схеме Hypothesis-Verification.
Контекст: рейтинг 3.8 на Яндекс.Еде, 40 отзывов за 4 месяца.
Отзывы: [вставь 10-15 отзывов]
Варианты причин: A) плохой вкус продукта, B) долгая доставка, C) слабая
карточка/фото
THINKER — для каждого варианта сформулируй гипотезу:
Что конкретно должно быть правдой в отзывах, если причина — A?
Что должно быть правдой, если причина — B?
Что должно быть правдой, если причина — C?
(ключевые сущности, действия, временные паттерны)
JUDGE — из трёх гипотез выведи одну дискриминирующую улику:
Какое минимальное наблюдение в отзывах разделит эти три гипотезы?
Что нужно найти, чтобы исключить две из трёх?
VERIFIER — проверь улику по отзывам:
Найди прямые свидетельства. Выдай статус:
ПОДТВЕРЖДЕНО / ЧАСТИЧНО / НЕ ПОДТВЕРЖДЕНО + временные метки / фразы
ANSWER — интегрируй доказательства:
Какая версия получила подтверждение?
Что исключено и почему? Рекомендация одним действием.
Результат: Модель сначала покажет три явные гипотезы — не "плохая доставка", а "отзывы упоминают конкретное время ожидания больше X минут и связывают его с негативной оценкой". Потом выведет дискриминирующую улику — одну фразу или паттерн, которая присутствует только если одна из версий верна. Затем поищет улику в отзывах и скажет что нашла. Финальный ответ будет с явной ссылкой на найденные доказательства — не интуиция, а логика.
Почему это работает
Простой запрос типа "почему низкий рейтинг?" провоцирует поиск похожего — и модель находит первые подтверждающие факты, игнорируя факты, которые говорят обратное. Это называют смещением подтверждения — LLM генерирует текст, следуя наиболее вероятному паттерну, и ранние рассуждения утягивают остальные.
У LLM есть другая сильная сторона: она хорошо работает с явно заданными ролями и структурированными условиями. Если спросить не "что правда?" а "что должно быть правдой?", модель переключается с поиска подтверждений на формулировку проверяемых условий.
Метод использует именно это: Thinker заставляет модель explicitно разложить логику каждой версии, Judge находит разделяющую улику — то, что отличает версии, а не то, что им общее. Дальше поиск идёт не широко, а точечно: не "собери всё про доставку", а "найди именно это".
Рычаги управления: - Количество гипотез → больше вариантов ответа = больше гипотез, можно ограничить до 2-3 самых вероятных - Формат улики → попроси Judge указать конкретные слова-маркеры, которые нужно искать в тексте - Статус Verifier → добавь порог: "считай ПОДТВЕРЖДЕНО только если улика встречается в 3+ отзывах" - Цикл уточнения → для простых задач убери его, чтобы сэкономить
Шаблон промпта
Работай по схеме Hypothesis-Verification. Задача: {описание задачи}.
Варианты ответа: {A: ..., B: ..., C: ...}
Данные для анализа: {текст / отзывы / факты}
THINKER:
Для каждого варианта — что должно быть правдой в данных,
если именно он верен? Укажи ключевые сущности, действия,
паттерны. Исключи явно неправдоподобные варианты сразу.
JUDGE:
Из набора гипотез выведи одну дискриминирующую улику κ.
Это минимальное наблюдение, которое отделяет верную гипотезу
от остальных. Что нужно найти — и как это выглядит конкретно?
VERIFIER:
Проверь улику κ по данным. Выдай статус:
ПОДТВЕРЖДЕНО / ЧАСТИЧНО / НЕ ПОДТВЕРЖДЕНО
+ конкретные свидетельства (цитаты, факты, временные метки)
Если ЧАСТИЧНО — уточни что именно подтверждено,
что ещё нужно проверить.
ANSWER:
Интегрируй доказательства. Какой вариант верен и почему?
Что исключено? Финальный вывод: {формат вывода}.
Плейсхолдеры:
- {описание задачи} — что анализируешь и зачем
- {A, B, C} — конкурирующие версии / варианты / гипотезы
- {текст / отзывы / факты} — данные, по которым проверяем
- {формат вывода} — например "одно действие", "рейтинг вариантов", "да/нет с обоснованием"
🚀 Быстрый старт — вставь в чат:
Вот шаблон Hypothesis-Verification. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие конкурирующие версии ты рассматриваешь и какие данные есть для анализа — потому что без этого Thinker не сможет сформулировать различающиеся гипотезы. Она возьмёт четырёхагентную структуру и подстроит роли под твою задачу.
Ограничения
⚠️ Открытые вопросы: Метод заточен под выбор между конкурирующими вариантами. Для открытого вопроса без вариантов ответа — менее эффективен: Judge не может сформулировать дискриминирующую улику, если нечего различать.
⚠️ Качество данных: Если исходные данные скудные или однородные, Verifier не найдёт улику — статус будет ЧАСТИЧНО по кругу. Нужно достаточно фактов для сравнения.
⚠️ Сложность задачи: Для простых вопросов с очевидным ответом — избыточно. Структура окупается на реально конкурирующих гипотезах, где интуиция может ошибиться.
⚠️ Цикл уточнения: Если задача плохо структурирована, цикл самоуточнения может зациклиться — модель будет переформулировать гипотезы без реального прогресса. Ограничи максимум до 2 итераций.
Ресурсы
Название: Think, Then Verify: A Hypothesis-Verification Multi-Agent Framework for Long Video Understanding
Датасеты и бенчмарки: EgoSchema, NextQA, IntentQA, VideoMME-L
Авторы: Zheng Wang, Haoran Chen, Haoxuan Qin, Zhipeng Wei, Tianwen Qian, Cong Bai
Организации: Zhejiang University of Technology (Китай), UC Berkeley (США), East China Normal University (Китай)
Код: https://github.com/Haorane/VideoHV-Agent