TL;DR
Justified QA — техника промптинга, которая заставляет LLM для каждого ответа-кандидата выводить доказательства "за", доказательства "против", рассуждение и финальный вердикт в JSON-структуре. Вместо одного ответа модель генерирует список кандидатов с обоснованием каждого.
Главная находка: LLM при работе с большим объёмом информации (документы, контекст) теряют как полноту (пропускают правильные ответы), так и точность (включают неверные). Причина — модель "решает в голове" без явной проверки каждого кандидата. Когда информация размазана по многим источникам или нужна сложная логика, модель спотыкается: то забывает проверить очевидное, то принимает косвенное упоминание за доказательство.
Метод решает проблему принудительной декомпозицией: модель сначала собирает ВСЕ возможные кандидаты (приоритет на полноту), затем для каждого явно выписывает цитаты "за" и "против", рассуждает вслух и выносит вердикт. Эта структура +0.14 F1 на RAG-задачах по сравнению с обычным промптом.
Схема метода
ШАГ 1: Сбор кандидатов → список ВСЕХ возможных ответов (приоритет на полноту)
ШАГ 2: Для каждого кандидата:
→ evidence_for: цитаты-доказательства "за"
→ evidence_against: цитаты "против"
→ reasoning: рассуждение по критериям
→ final_judgment: TRUE/FALSE
ШАГ 3: Финальный ответ → только TRUE-кандидаты
[Всё в одном промпте, одним запросом]Пример применения
Задача: Ты готовишь обзор российских IT-компаний для инвестора. Нужно понять, какие из упомянутых в статьях компании реально подходят под критерии: выручка >1 млрд рублей, работают с госзаказами, имеют продукт в сфере ИИ.
Промпт:
Твоя задача — ответить на вопрос на основе предоставленных документов.
Выведи ответ в формате JSON по схеме:
{
"question": "Какие компании подходят под ВСЕ критерии: выручка >1 млрд ₽, госзаказы, продукт в ИИ?",
"candidate_answers": [
{
"candidate_answer": "Название компании",
"evidence_for": [{"doc_id": "ID документа", "text": "Цитата-доказательство..."}],
"evidence_against": [{"doc_id": "ID документа", "text": "Цитата-опровержение..."}],
"reasoning": "Подробное рассуждение по каждому критерию: выручка — да/нет потому что..., госзаказы — да/нет потому что..., ИИ-продукт — да/нет потому что...",
"final_judgment": "TRUE/FALSE"
}
],
"answer": ["Список компаний только с TRUE вердиктом"]
}
Инструкции:
* Сначала собери ВСЕХ возможных кандидатов — приоритет на полноту. Потом фильтруй через reasoning и final_judgment.
* Каждая компания — отдельный candidate_answer.
* В evidence включай ВСЕ релевантные предложения из документа, пропуская нерелевантные (ставь "..." вместо них).
===== Документы =====
[здесь тексты статей]
===== Вопрос =====
Какие компании подходят под ВСЕ критерии: выручка >1 млрд ₽, работают с госзаказами, имеют продукт в сфере ИИ?Результат: Модель выдаст JSON с 5-10 кандидатами. Для каждой компании — конкретные цитаты из документов с указанием источника. В reasoning будет явная проверка каждого критерия. В финале — отфильтрованный список только подтверждённых кандидатов. Ты видишь ВСЮ логику принятия решений — можно проверить любой вердикт.
Почему это работает
Слабость LLM: Модели отвечают "потоком сознания" — генерируют ответ без явной проверки каждого факта. При сложных вопросах (несколько критериев, много источников) это ведёт к пропускам и ошибкам. Модель не "видит" свои рассуждения — они остаются неявными.
Сильная сторона LLM: Модели отлично работают с структурой. Если задать шаблон "для каждого X сделай Y" — они следуют ему. JSON-схема создаёт принудительную декомпозицию: модель не может перейти к final_judgment, пока не заполнит evidence_for/against и reasoning.
Как метод использует силу против слабости: Структура промпта экстернализует рассуждения — выносит их из "головы" модели в текст. Это работает как Chain-of-Thought, но с жёстким форматом. Исследователи обнаружили: для мощных моделей (Gemini Pro) JSON-структуры достаточно, для слабых (Flash) нужен дополнительный этап "подумай своими словами" перед JSON (+0.07 F1).
Рычаги управления:
- Количество кандидатов: "собери минимум 10 кандидатов" → больше полноты, длиннее вывод
- Детализация evidence: "включай ВСЕ релевантные предложения" vs "только ключевую цитату"
- Chain-of-thought: добавь "сначала подумай своими словами, потом JSON" для сложных задач
- Критерии в reasoning: явно перечисли что проверять → модель проверит каждый пункт
Шаблон промпта
Твоя задача — ответить на вопрос на основе предоставленных документов/информации.
Выведи ответ в формате JSON:
{
"question": "{вопрос}",
"candidate_answers": [
{
"candidate_answer": "{кандидат}",
"evidence_for": [{"source": "{источник}", "text": "{цитата-доказательство}"}],
"evidence_against": [{"source": "{источник}", "text": "{цитата-опровержение}"}],
"reasoning": "{рассуждение по каждому критерию}",
"final_judgment": "TRUE/FALSE"
}
],
"answer": ["{только TRUE-кандидаты}"]
}
Инструкции:
* Приоритет на ПОЛНОТУ при сборе кандидатов. Фильтруй через reasoning и final_judgment.
* Каждый отдельный ответ — отдельный candidate_answer.
* В evidence включай все релевантные фрагменты, пропуская нерелевантные ("...").
===== Контекст =====
{документы или информация для анализа}
===== Вопрос =====
{твой вопрос}Плейсхолдеры:
{вопрос}— что ищешь/проверяешь{документы или информация}— тексты для анализа{критерии}— можно добавить в инструкции явный список критериев для reasoning
🚀 Быстрый старт — вставь в чат:
Вот шаблон Justified QA для анализа информации. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]LLM спросит: какой вопрос анализируем? какие критерии проверяем? какие документы/источники? — потому что эти параметры определяют структуру reasoning и что искать в evidence.
Ограничения
⚠️ Длина вывода: Для каждого кандидата модель генерирует evidence + reasoning. При 20+ кандидатах вывод становится очень длинным — следи за лимитами токенов.
⚠️ Качество источников: Метод работает когда есть документы/контекст для анализа. Без источников evidence_for/against будет пустым — модель вернётся к "галлюцинациям".
⚠️ Субъективные критерии: Исследователи тестировали на фактических вопросах (есть/нет в документе). Для субъективных оценок ("качественный продукт?") evidence менее надёжен.
⚠️ Дополнительная верификация даёт мало: Отдельный этап проверки каждого ответа улучшил результат всего на +0.02 F1. Основная ценность — в самом Justified QA промпте, не в дополнительных шагах.
Как исследовали
Команда Google DeepMind взялась за QUEST-LOFT — бенчмарк где LLM должна найти ответы в корпусе из 328 документов (Wikipedia-статьи). Вопросы требуют сложной логики: "найди X И Y" или "X ИЛИ Z", где ответ — список из 5-15 сущностей. Это не "столица Франции", а "какие швейцарские фильмы про сталкинг" с ответом из нескольких пунктов.
Первый сюрприз: исследователи провели ручную проверку golden answers и обнаружили, что треть "ошибок" модели — на самом деле ошибки в эталоне. Модель отвечала правильно, но её ответ не совпадал с неполным golden set. Это важный урок: бенчмарки врут чаще, чем кажется.
После ревизии тестировали комбинации: RAG vs длинный контекст × базовый промпт vs Justified QA × с верификацией vs без. Результат: RAG + Justified QA = 0.83 F1 против 0.67 F1 у базового RAG (почти +25% относительного улучшения). Длинный контекст (весь корпус в промпте) дал только 0.77 F1 даже с оптимизациями.
Второй сюрприз: Chain-of-thought перед JSON помогает только слабым моделям. Gemini 1.5 Pro справлялся с JSON-структурой напрямую, а вот Flash без "подумай сначала" терял ~0.05 F1. Вывод: чем мощнее модель, тем меньше нужны костыли.
Практический инсайт: Самый большой буст дала не верификация (+0.02), а сам Justified QA промпт (+0.14). Структура с evidence и reasoning — это главное, остальное — тюнинг на краях.
Оригинал из исследования
Контекст: Ниже — полный промпт Justified QA, который дал лучшие результаты на QUEST-LOFT.
Your task is to answer a given question based on the provided documents.
Please do so by outputting a response in the form of a JSON object
conforming to the following schema:
```json
{
"question": "",
"candidate_answers": [
{
"candidate_answer": "",
"evidence_for": [{"doc_id": "", "text": ""}],
"evidence_against": [{"doc_id": "", "text": ""}],
"reasoning": "",
"final_judgment": ""
}
],
"answer": [""],
"answer_doc_ids": ["
Адаптации и экстраполяции
💡 Адаптация для проверки резюме кандидатов:
{
"question": "Подходит ли кандидат под требования: 3+ года Python, опыт ML, английский B2+?",
"candidate_answers": [
{
"candidate_answer": "Иван Петров",
"evidence_for": [{"source": "резюме", "text": "5 лет разработки на Python... участвовал в ML-проектах..."}],
"evidence_against": [{"source": "резюме", "text": "Английский не указан..."}],
"reasoning": "Python 5 лет — ОК. ML — есть упоминание проектов. Английский — НЕТ данных в резюме, нужно уточнить.",
"final_judgment": "MAYBE — уточнить английский"
}
]
}🔧 Техника: добавить "MAYBE" вердикт → для неопределённых случаев
Оригинал использует только TRUE/FALSE. Для реальных задач часто нужен третий вариант — "недостаточно данных". Добавь в инструкции: final_judgment: "TRUE/FALSE/MAYBE — укажи что уточнить".
🔧 Техника: упростить для быстрых проверок
Полный JSON избыточен для простых вопросов. Минимальная версия:
Для каждого варианта ответа:
1. Кандидат: [название]
2. ЗА: [цитата-доказательство]
3. ПРОТИВ: [цитата-опровержение]
4. Вердикт: ДА/НЕТ + почему
Финал: [только ДА-кандидаты]Та же логика, меньше формализма — для чатов без анализа документов.
Ресурсы
Evaluation of retrieval-based QA on QUEST-LOFT (2025)
Nathan Scales, Nathanael Schärli, Olivier Bousquet — Google DeepMind
Связанные работы:
- LOFT benchmark: Lee et al., 2024 — оригинальный бенчмарк длинного контекста
- Chain-of-Verification (CoVe): Dhuliawala et al., 2023 — верификация через дополнительные вопросы
- QUEST dataset: Malaviya et al., 2023 — датасет сложных вопросов с множественными ответами
Библиотека: OneTwo — фреймворк для работы с LLM от DeepMind