JSFactCheckBench: оценка LLM-фактчекера зависит от того, что именно ему показали

Это не авторская техника промптинга, а выводы из эксперимента. Ниже схема рабочего процесса, собранная из того, что показала статья. В Шаге 1 модель видит весь ответ, в Шаге 2 — только утверждение.

ШАГ 1 (отдельный запрос): ответ LLM → список атомарных утверждений
        (одно утверждение = один факт; местоимения раскрыты; сохранены даты и условия)
        + метка важности: Main / Sub / Irrelevant (относительно вопроса)

ШАГ 2 (отдельный запрос на каждое утверждение, БЕЗ исходного ответа):
        утверждение + дата актуальности + короткая выдержка из источника
        → Supported / Refuted / NotEnoughInfo

ШАГ 3: смотрим отдельно вердикты по Main и по Sub
        (Main с Refuted или NotEnoughInfo = ответ нельзя использовать)

Задача: Контент-менеджер готовит для vc.ru статью про налоги самозанятых. Нейросеть написала длинный ответ с цифрами и датами. Нужно понять, можно ли ему верить, и первым делом проверить главный тезис.

Промпт (Шаг 2, отдельный запрос на одно утверждение):

Ты проверяешь одно утверждение по источнику. Оценивай ТОЛЬКО само утверждение.

Дата, на которую утверждение должно быть верным: февраль 2026.

Утверждение:
«Самозанятые на НПД не обязаны платить обязательные страховые взносы в ПФР».

Источник (выдержка со страницы nalog.gov.ru):
{вставь 1–3 абзаца с сайта ФНС про НПД}

Метки:
- Supported — источник подтверждает утверждение на указанную дату.
- Refuted — источник противоречит утверждению на указанную дату.
- NotEnoughInfo — источник не подтверждает и не опровергает.

Формат ответа:
1. Метка
2. Цитата из источника, на которой основан вердикт (дословно)
3. Одно предложение: почему именно эта метка
Если источник не по теме, ставь NotEnoughInfo. Не используй знания вне источника.

Результат: Модель вернёт одну метку, дословную цитату из вставленной выдержки и короткое обоснование. Проверка идёт по одному утверждению, без исходного ответа. Повторите это для каждого утверждения. Сначала прогоните тезисы Main, потом Sub. Цитату стоит сверить глазами, потому что без неё метке нельзя доверять.

Слабость. Когда рядом с утверждением лежит весь исходный ответ, модель путает текст-контекст с доказательством. Открытые модели начинают соглашаться: ответ звучит связно, значит, утверждение «верное». Эту ошибку промпт «оценивай только утверждение» не устраняет. Вторая слабость: чем длиннее и «шумнее» материал (целая страница или несколько страниц, из которых надо выбрать нужную), тем хуже модель находит нужный фрагмент и тем сильнее расходятся результаты разных моделей.

Сильная сторона. Модели хорошо читают короткий релевантный фрагмент и сверяют с ним одно утверждение. На короткой выдержке все шесть моделей показывают лучшие результаты в таблице.

Как это использовать. Процесс убирает лишний контекст и сокращает нагрузку на поиск. Утверждение изолировано, выдержка короткая, нужный кусок вы нашли заранее. Модели остаётся только сверка.

Рычаги управления: - Размер выдержки. Хотите надёжнее — режьте источник до абзацев по теме. Лучше короткая цитата, чем вся страница. - Контекст. Выкиньте из запроса вопрос и исходный ответ. Оставьте утверждение, в котором местоимения уже заменены на конкретные имена («он» → «Роспотребнадзор»). - Дата. Для быстро меняющихся тем (ставки, лимиты, правила сервисов) указывайте дату актуальности. Её эффект в таблицах нестабилен: у части моделей оценки меняются, у части нет. Для таких тем это страховка, но не гарантия. - Метка NotEnoughInfo. Оставьте её. Она не даёт модели угадывать, когда в источнике нет ответа. - Важность. Размечайте Main/Sub и читайте вердикты по Main отдельно.

Промпты авторов вынесены в приложения, в доступной части текста их нет. Ниже шаблон, собранный из описанной в статье схемы: декомпозиция по тем же пяти шагам и метки с определениями из статьи.

Шаг 1: разбор ответа на утверждения (отдельный запрос):

Вопрос пользователя: {вопрос}

Ответ, который нужно разобрать:
{ответ_модели}

Разбей ответ на атомарные утверждения. Для каждого:
1. Одно утверждение = один факт, который можно проверить отдельно.
2. Замени местоимения и неполные названия на конкретные («он» → «Банк России»).
3. Верни пропущенные время, причину, сравнение.
4. Добавь предпосылки, без которых утверждение непонятно.
5. Оставь только то, что можно проверить объективно. Мнения и оценки пометь как Unevaluable.

Для каждого утверждения поставь метку важности относительно вопроса:
- Main — прямо отвечает на вопрос или содержит ядро/часть ответа.
- Sub — даёт связанную информацию, но не отвечает на вопрос.
- Irrelevant — не связано с вопросом и ответом.

Формат: нумерованный список «[Метка] утверждение».

Шаг 2: проверка (отдельный запрос на каждое утверждение, без вопроса и исходного ответа):

Оценивай ТОЛЬКО это утверждение.
Дата, на которую оно должно быть верным: {дата}.

Утверждение: {утверждение}

Источник (короткая выдержка): {выдержка}

- Supported — источник подтверждает утверждение на указанную дату.
- Refuted — источник противоречит утверждению на указанную дату.
- NotEnoughInfo — источник не подтверждает и не опровергает.

Ответ:
1. Метка
2. Дословная цитата из источника
3. Одно предложение с обоснованием
Не используй знания вне источника.

Что подставлять: {вопрос} и {ответ_модели} — оригинал разговора. {утверждение} — одна строка из списка Шага 1. {дата} — когда факт должен быть верным. {выдержка} — 1–3 абзаца с официального сайта, взятые вами вручную или найденные поиском.

🚀 Быстрый старт — вставь в чат:

Вот шаблон двухэтапной проверки ответа LLM. Адаптируй под мою задачу: [твоя задача, например «проверить статью про налоги»].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, какой вопрос задавали модели, на какую дату проверять и откуда брать источники. Эти данные нужны, чтобы корректно отделить главные утверждения от второстепенных и привязать проверку к дате. Она возьмёт структуру из шаблона и подстроит метки и формат под твою тему.

⚠️ Без источника проверка слабая: если не дать модели выдержку и просить судить «по памяти», результат лишь заметно лучше случайного угадывания, даже у лучших коммерческих моделей. Фактчекинг без источника не заменяет проверку человеком.

⚠️ Эффект «соглашательства» показан на открытых моделях: падение при добавлении контекста — у четырёх открытых моделей среднего размера. У GPT-5.1 и Sonnet оно слабое. Если вы работаете с топовыми коммерческими моделями, выигрыш от изоляции утверждения будет скромнее.

⚠️ Дата не панацея: указание даты по-разному влияет на разные модели. Надёжного правила «всегда указывай» в статье нет.

⚠️ Один язык и небольшая выборка вопросов: японский язык, 85 вопросов, темы из японских соцсетей (медицина, ядерная энергетика, экономика). Для русских тем закономерности вероятны, но не проверены.

⚠️ Это бенчмарк, не проверенная техника промптинга: предложенный выше процесс собран из выводов статьи. Сами авторы такой двухэтапный процесс как готовый метод не тестировали. Кроме того, в доступной части текста нет разбора, как именно ведут себя модели на Main и Sub и как работает выбор источника при нескольких страницах: об этом известны только общие выводы из аннотации и цифры из таблиц.

⚠️ Строить бенчмарк вам не нужно: главная ценность статьи для практика — принципы проверки, а не датасет и список доверенных доменов.

• Rethinking the Evaluation of LLM Fact-Checkers — Ayana Niwa, Masahiro Kaneko (MBZUAI), Miyu Yamada (Science Tokyo), Hisami Suzuki, Kouta Nakayama, Satoshi Sekine (NII-LLMC)
• Датасет: https://huggingface.co/datasets/llm-jp/JSFactCheckBench
• Основа вопросов: JSocialFact (Nakazato et al., 2024)
• Метод декомпозиции на атомарные утверждения: Liu et al. (2025)