Графы знаний
KG + LLM: RAG и Grounding
В 2023 году юрист в США подал в суд документы с 6 выдуманными прецедентами - их написал ChatGPT. Штраф 5000 долларов. Если бы у LLM был доступ к legal knowledge graph, каждая ссылка на дело верифицировалась бы до отправки документа.
- **Медицинские AI-ассистенты:** grounding к MeSH/SNOMED knowledge graph снижает частоту галлюцинаций о лекарственных взаимодействиях с 18% до 3% по данным исследований 2024 года
- **Корпоративные чат-боты:** Microsoft Copilot использует Microsoft Graph (граф сотрудников, документов, встреч) для grounding ответов о внутренних данных компании
- **Научные поисковики:** Semantic Scholar и OpenAlex строят KG статей и цитирований - LLM получает верифицированные метаданные, а не галлюцинирует авторов и годы публикации
GraphRAG: граф как источник контекста
Стандартный RAG берёт top-k чанков из векторного поиска. Проблема: чанки изолированы, связи между сущностями теряются. GraphRAG (Microsoft, 2024) строит knowledge graph из документов и использует его при retrieval: запрос расширяется через связи в графе. Вопрос 'Кто работал с Тьюрингом в Блетчли-парк?' находит не только статью о Тьюринге, но и всех связанных через hasColleague/workedAt.
Два режима GraphRAG: (1) Local search - обход графа от найденных сущностей (глубина 1-3), подходит для специфических фактов; (2) Global search - резюме на уровне кластеров графа, подходит для аналитических вопросов 'о чём этот корпус'. Стоимость global search на больших графах высока - нужна иерархическая суммаризация.
Чем GraphRAG принципиально отличается от стандартного RAG с векторным поиском?
Entity Grounding: привязка к реальным сущностям
LLM генерирует 'Apple CEO Tim Cook' - но какой Apple? Apple Inc., Apple Records, Apple Bank? Entity grounding (entity linking) связывает упоминания в тексте с конкретными узлами в knowledge base. Wikidata, Freebase, DBpedia - базы для grounding. Для домена: корпоративный KG с продуктами, сотрудниками, контрактами. Grounded LLM ответ содержит URI сущности, а не только текст.
Entity Linking pipeline: (1) Named Entity Recognition (NER) - найти упоминания; (2) Candidate Generation - найти кандидатов в KG по строковому совпадению; (3) Entity Disambiguation - выбрать правильный кандидат по контексту. spaCy + nel (Neural Entity Linking) или GENRE (Autoregressive Entity Retrieval) - state-of-the-art.
Зачем LLM-системе нужен entity grounding - разве LLM не 'знает' что такое Apple?
Верификация фактов через KG
LLM утверждает: 'Илон Маск является CEO Tesla с 2008 года'. Это проверяемый факт: в Wikidata есть (Elon Musk, position held, CEO of Tesla, start time: 2008). Fact verification pipeline: (1) extraction - извлечь claim из текста LLM; (2) decomposition - разбить на атомарные факты; (3) KG lookup - проверить каждый факт в графе; (4) verdict - SUPPORTED / REFUTED / NOT ENOUGH INFO.
FEVEROUS, FEVER - benchmark datasets для fact verification. FactKG - датасет, специфичный для проверки по knowledge graph. Автоматическая верификация: precision ~85% на простых фактах, падает до 60% для составных утверждений с отрицанием или временными ограничениями.
Почему автоматическая верификация фактов через KG менее точна для составных утверждений с отрицанием?
Снижение галлюцинаций через KG
Knowledge graph снижает галлюцинации LLM через три механизма: (1) KG-Retrieval Augmentation - подача верифицированных фактов в контекст до генерации; (2) Post-hoc Verification - проверка сгенерированного текста через fact verification pipeline; (3) Constrained Generation - ограничение пространства генерации шаблонами, построенными по KG (SPARQL -> шаблон ответа). Комбинация всех трёх даёт лучший результат.
KGLLM (Knowledge Graph augmented LLM): retrieval из KG через SPARQL → структурированный контекст → LLM генерация с явными цитатами источников. Метрики: FactScore (процент фактических утверждений с поддержкой в источнике), SAFE (Search-Augmented Factuality Evaluator). Лучшие модели достигают 90%+ FactScore при KG-grounding.
Knowledge graph полностью устраняет галлюцинации LLM
KG снижает галлюцинации для фактов, которые есть в графе, но не устраняет галлюцинации полностью - граф неполон, а LLM может галлюцинировать и при наличии контекста
Три оставшихся источника галлюцинаций при KG-grounding: (1) граф содержит устаревшие данные, (2) LLM неправильно интерпретирует структурированный контекст, (3) вопрос требует рассуждений поверх фактов, а не просто их поиска. Fact verification pipeline снижает, но не ликвидирует проблему
Что такое Closed World Assumption и как она влияет на верификацию фактов через KG?
Ключевые идеи
- **GraphRAG:** обход связей графа при retrieval сохраняет структурные отношения между сущностями - стандартный RAG их теряет при разбивке на чанки
- **Entity grounding:** привязка упоминаний к URI в KG открывает доступ к актуальным структурированным данным вне параметров LLM
- **Fact verification:** atomic decomposition -> SPARQL lookup -> verdict; Closed World Assumption требует 'NOT ENOUGH INFO' при отсутствии данных, а не автоматического 'REFUTED'
Связанные темы
KG + LLM интеграция применяет все предыдущие концепции knowledge graphs:
- Enterprise Knowledge Graphs — Корпоративный KG из предыдущего урока становится источником grounding для enterprise LLM-ассистентов
- SPARQL и онтологии — Fact verification pipeline генерирует SPARQL запросы для проверки каждого атомарного утверждения
Вопросы для размышления
- GraphRAG строит граф из документов через NLP extraction. Какие ошибки extraction наиболее критичны для качества downstream ответов - и как бы минимизировали их влияние?
- Fact verification через автоматический SPARQL достигает 85% precision. Для каких применений этого достаточно, а для каких нет? Что делать с оставшимися 15% ошибок?
- Closed World vs Open World Assumption: Wikidata использует Open World. Как это влияет на дизайн fact verification системы - и какие типы запросов принципиально не решаемы через KG lookup?