TL;DR
Исследователи из Technical University Munich проверили, как комбинировать три источника для проверки фактов: структурированные базы знаний (типа Википедии, но в виде связей между сущностями), языковую модель для оценки, и веб-поиск как запасной вариант. Система работает в три шага: сначала ищет факты в базе знаний, потом оценивает достаточно ли информации, и только если нет — идёт в интернет.
Главная находка: структурированные источники надёжнее, но покрывают меньше. База знаний даёт высокую точность (94%), но находит ответ только в 73% случаев. Веб-поиск покрывает 91% случаев, но ошибается чаще. Проблема в том, что база знаний — это только то, что уже формализовано и связано, а реальный мир шире. Веб даёт больше, но там шум, противоречия, устаревшие данные.
Решение: fallback стратегия. Сначала проверяем в надёжном источнике (база знаний). Если там нет ответа ("недостаточно информации") — переформулируем вопрос и ищем в интернете. Итоговая точность 93% на бенчмарке FEVER. Система показала, что 70% случаев, помеченных как "недостаточно информации", на самом деле можно проверить — просто нужен второй источник.
Схема метода
ШАГ 1: База знаний (Knowledge Graph)
├─ Находим упоминания сущностей в утверждении
├─ Извлекаем связи типа "Barack_Obama -> birthPlace -> Hawaii"
├─ Ранжируем связи по релевантности
└─ Оцениваем: Подтверждает / Опровергает / Недостаточно информации
ШАГ 2: Классификация
└─ Если получен ответ (Подтверждает/Опровергает) → СТОП
Если "Недостаточно информации" → ШАГ 3
ШАГ 3: Веб-поиск (запасной вариант)
├─ Переформулируем утверждение в 3-5 поисковых запросов
├─ Собираем сниппеты из топ-100 результатов
├─ Ранжируем по релевантности
└─ Финальная оценка: Подтверждает / Опровергает / Недостаточно информации
Важно: Шаги выполняются последовательно. Шаг 3 срабатывает только в ~23% случаев — когда базы знаний недостаточно.
Пример применения
Задача: Проверить заявление из новостей: "Павел Дуров основал Telegram после блокировки ВКонтакте в 2014 году".
Промпт:
Проверь это утверждение в три этапа:
УТВЕРЖДЕНИЕ: "Павел Дуров основал Telegram после блокировки ВКонтакте в 2014 году"
ЭТАП 1 — Проверка по общеизвестным фактам:
Найди ключевые сущности (люди, компании, события, даты).
Для каждой сущности — известные факты и связи.
Оцени: достаточно ли этого для проверки?
Формат ответа:
- Факты: [список]
- Достаточно информации: ДА / НЕТ
- Если ДА — вердикт: ПОДТВЕРЖДЕНО / ОПРОВЕРГНУТО / ЧАСТИЧНО ВЕРНО
ЭТАП 2 — Если информации недостаточно:
Переформулируй утверждение в 3-5 поисковых запросов для максимального охвата.
Покажи запросы.
ЭТАП 3 — Поиск доказательств:
Для каждого запроса: какие источники нужно проверить?
Какие факты подтвердят или опровергнут утверждение?
В конце — финальный вердикт с указанием источников.
Результат:
Модель выполнит три этапа последовательно. Сначала извлечёт факты из своих знаний (Дуров, Telegram, ВКонтакте, 2014). Оценит достаточность — скорее всего скажет "недостаточно" для точной проверки причинно-следственной связи. Сгенерирует поисковые запросы типа "когда основан Telegram", "Дуров покинул ВКонтакте год", "блокировка ВКонтакте 2014". Предложит проверить официальные источники, новости того времени, хронологию событий. Финальный вывод с указанием что верно, что неточно, с ссылками на факты.
Почему это работает
Слабость LLM: Модели путают достоверность источников. Всё, что модель "знает", хранится одинаково — и факт из учебника, и слух из форума, и устаревшая информация. При проверке фактов модель может уверенно выдать неточность, потому что не различает надёжность источника знания.
Сильная сторона LLM: Модели отлично работают с структурой рассуждений и переформулировкой. Если задать последовательность шагов (сначала одно, потом другое) и попросить оценить достаточность информации — модель следует инструкции. Умеет генерировать альтернативные формулировки вопроса для расширения поиска.
Как метод использует это: Разделяет источники по надёжности через последовательность шагов. Сначала — "вспомни базовые факты" (аналог структурированной базы), с оценкой достаточности. Потом — "если мало, переформулируй и ищи шире". Это имитирует работу журналиста: проверил очевидное → если сомнения → копнул глубже. Ключ в том, что модель сама оценивает достаточность на каждом шаге, а не пытается ответить сразу.
Рычаги управления:
- Количество этапов — можно добавить "проверка в специализированных базах" между общими фактами и веб-поиском
- Критерий достаточности — настроить строгость: "высокая уверенность" vs "любые релевантные данные"
- Число поисковых запросов — меньше (1-2) для быстроты, больше (5-7) для полноты охвата
- Источники на этапе 3 — можно задать конкретные: только официальные сайты, только архивы новостей, только научные базы
Шаблон промпта
Проверь утверждение в несколько этапов с переходом к следующему только при необходимости.
УТВЕРЖДЕНИЕ: {утверждение_для_проверки}
ЭТАП 1 — Проверка по базовым знаниям:
1. Извлеки ключевые сущности (люди, места, организации, даты, события)
2. Для каждой сущности — известные факты и связи
3. Оцени релевантность каждого факта утверждению (высокая/средняя/низкая)
4. Вывод: достаточно ли информации для проверки? (ДА/НЕТ)
5. Если ДА — дай вердикт: ПОДТВЕРЖДЕНО / ОПРОВЕРГНУТО / ЧАСТИЧНО ВЕРНО / НЕОДНОЗНАЧНО
Формат ответа этапа 1:
- Сущности: [список]
- Факты: [список с релевантностью]
- Достаточно информации: [ДА/НЕТ]
- Вердикт (если достаточно): [вердикт + краткое обоснование]
ЭТАП 2 — Переформулировка (только если информации недостаточно):
Сгенерируй {число_запросов} поисковых запроса для проверки утверждения:
- Запросы должны покрывать разные аспекты
- Включи синонимы и альтернативные формулировки
- Один запрос на проверку временных рамок (если есть даты)
ЭТАП 3 — План поиска доказательств:
Для каждого запроса из этапа 2:
- Какой тип источника нужен? (новости/официальные документы/экспертные оценки/статистика)
- Какие конкретные факты подтвердят или опровергнут утверждение?
- На что обратить внимание (возможные противоречия, контекст)?
ФИНАЛЬНЫЙ ВЕРДИКТ:
После всех этапов дай окончательную оценку с указанием:
- Вердикт
- Основные доказательства
- Степень уверенности (высокая/средняя/низкая)
- Что осталось неясным (если есть)
Плейсхолдеры:
- {утверждение_для_проверки} — утверждение, которое нужно проверить
- {число_запросов} — количество поисковых запросов (рекомендуется 3-5)
Почему это работает (детали механики)
Исследователи обнаружили противоположные профили ошибок у разных источников:
База знаний (KG-only): Высокая точность (94%), но низкий охват (73%). Когда находит информацию — почти всегда права. Но покрывает только формализованные, общеизвестные связи. Пример: легко проверит "Барак Обама родился на Гавайях" (это в базе), но не найдёт "Дуров покинул ВКонтакте из-за давления ФСБ" (причинно-следственная связь из новостей).
Веб-поиск (Web-only): Балансированная точность (91%) и охват (91%). Находит больше, но и ошибается чаще. Причина: в интернете есть и факты, и мнения, и устаревшая информация, и противоречивые источники.
Комбинация (KG-first + Web fallback): Лучшее из обоих миров — 93% точности. Механика: используем надёжность базы, где она работает, и охват веба, где база молчит.
Дополнительная находка: 70% случаев "недостаточно информации" на самом деле проверяемы — просто нужен второй источник. Это показывает, что оценка достаточности критична: если модель говорит "не знаю" — это не всегда "нельзя проверить", часто это "нужно поискать в другом месте".
Ключевой принцип: Разделение источников по надёжности + явная оценка достаточности на каждом шаге. Это предотвращает "ленивый" ответ модели (галлюцинация вместо признания незнания) и "избыточный" поиск (когда ответ уже ясен).
Ограничения
⚠️ Односложные связи: Метод проверяет прямые факты ("Дуров основал Telegram"), но слаб для цепочек рассуждений ("Если А повлияло на Б, а Б привело к В, то..."). Для проверки сложных причинно-следственных связей потребуется больше шагов.
⚠️ Распространение ошибок: Если на первом шаге модель неправильно извлечёт ключевые сущности (например, перепутает компании с похожими названиями), ошибка перейдёт на следующие этапы. Чем раньше ошибка — тем больше её влияние.
⚠️ Нет явного "нельзя проверить": Если утверждение действительно непроверяемо (субъективное мнение, предсказание будущего, отсутствие любых источников) — система всё равно попытается дать вердикт. Нет механизма остановки с выводом "это невозможно проверить по природе утверждения".
⚠️ Зависимость от промпта: Эффективность сильно зависит от того, насколько чётко заданы критерии достаточности и инструкции для каждого этапа. Размытые формулировки снизят качество оценки.
Как исследовали
Команда из Technical University Munich построила систему из трёх модулей и проверила её на стандартных датасетах для фактчекинга. Идея была простой: а что если использовать сильные стороны каждого источника последовательно, а не смешивать всё сразу?
Взяли 1000 утверждений из датасета FEVER (Fact Extraction and VERification), убрав случаи "недостаточно информации" для чистоты эксперимента. Сравнили три конфигурации: только база знаний, только веб, и гибридная система. Измеряли точность (precision) — как часто система права, когда даёт ответ, и полноту (recall) — как часто система находит ответ, когда он есть.
Результаты показали чёткую закономерность: база знаний — 94% точности, но только 73% полноты. Веб — 91% точности и 91% полноты. Гибрид — 93% точности и 93% полноты. Это подтвердило гипотезу: источники дополняют друг друга, а не конкурируют.
Любопытная деталь: исследователи проверили систему на adversarial версии FEVER (где утверждения специально усложнены) и на другом датасете FactKG — система показала стабильные 77-78% даже без специальной настройки под эти датасеты. Это говорит, что принцип работает широко, не только на тех данных, где его обучали.
Самое интересное: команда взяла 150 случайных утверждений, помеченных как "недостаточно информации", где их система всё равно нашла доказательства. Попросили двух людей и одну LLM оценить: действительно ли найденные доказательства достаточны? В более чем 70% случаев хотя бы один оценщик сказал "да, достаточно". Это говорит о двух вещах: (1) система часто находит валидные доказательства там, где их "не должно быть", и (2) оценка достаточности — субъективна, люди расходятся в мнениях (согласованность между оценщиками была умеренной, Fleiss' κ = 0.385).
Вывод: Последовательная проверка от надёжных к широким источникам работает лучше, чем любой источник по отдельности. Но важно, чтобы модель могла честно сказать "на этом этапе информации нет, иду дальше" — иначе система либо галлюцинирует, либо пропускает проверяемые утверждения.
Ресурсы
Hybrid Fact-Checking that Integrates Knowledge Graphs, Large Language Models, and Search-Based Retrieval Agents Improves Interpretable Claim Verification — исследование о комбинировании структурированных баз знаний, языковых моделей и веб-поиска для проверки фактов.
Код системы доступен на GitHub: github.com/AndriiLata/aiFactCheck
Использованные источники: - DBpedia — структурированная база знаний из Википедии - FEVER (Fact Extraction and VERification) — бенчмарк для проверки фактов - FEVER 2.0 — усложнённая adversarial версия - FactKG — датасет с фокусом на графы знаний
Авторы: Shaghayegh Kolli, Richard Rosenbaum, Timo Cavelius, Lasse Strothe, Andrii Lata, Jana Diesner (Technical University Munich)