Графы знаний

Question Answering over KG

Google обрабатывает 8.5 миллиарда запросов в день. Значительная часть из них - фактические вопросы: «Когда родился Эйнштейн?», «Какая столица Австралии?». За быстрыми ответами в информационных блоках стоят системы KGQA, извлекающие ответы из Knowledge Graph за миллисекунды - без поиска по веб-страницам.

**Google Knowledge Graph:** прямые ответы на фактические вопросы в поисковике - KGQA в действии
**Amazon Alexa / Apple Siri:** голосовые ассистенты конвертируют речь в запросы к KG для получения точных фактов
**Медицинские системы:** вопросы о взаимодействии лекарств, симптомах заболеваний через медицинские KG (UMLS, DrugBank)

KGQA: постановка задачи

Пользователь спрашивает: «Кто снял фильм с актёром, который родился в той же стране, что и Нолан?». Граф знаний Wikidata знает ответ - нужно лишь превратить текст в структурированный запрос. Это задача **KGQA** (Knowledge Graph Question Answering): автоматическое получение ответов из графа знаний по вопросам на естественном языке.

KGQA состоит из двух ключевых подзадач: **Entity Linking** (найти в тексте упоминание «Нолан» и связать с wd:Q25191) и **Relation Detection** (понять что «снял» = wdt:P57, «родился» = wdt:P19). Ошибка в любой из них ломает весь ответ.

Benchmark-датасеты для оценки KGQA: **WebQuestions** (6642 вопроса из Google Suggest, ответы из Freebase), **SimpleQuestions** (108K однохоповых вопросов), **WebQuestionsSP** (с аннотированными SPARQL-запросами), **HotpotQA** (multi-hop, требует рассуждений через несколько сущностей).

**Метрика:** основная метрика KGQA - **точность (exact match)**: доля вопросов, на которые получен правильный ответ. Для вопросов с множеством ответов используют F1. State-of-the-art на WebQuestions - около 85% F1 (2024).

Entity Linking в KGQA - это:

Semantic Parsing: генерация SPARQL

**Semantic Parsing** - классический подход к KGQA: превратить вопрос на естественном языке в формальный запрос (SPARQL, логическую формулу или lambda-исчисление). Система обучается отображению: текст → структурированный запрос.

Современные системы используют **BERT/T5** как энкодер вопроса и авторегрессионный декодер для генерации SPARQL токен за токеном. Ключевая проблема - **Entity Linking**: URI сущностей (wd:Q584365) не могут быть напрямую вокабуляром модели. Решение: сначала связать упоминания с URI, потом подставить в шаблон.

**SPARQL Constraint Decoding:** чтобы гарантировать синтаксически корректный SPARQL, используют constrained beam search - маска допустимых токенов на каждом шаге декодирования. Иначе модель может сгенерировать невалидный запрос.

Почему URI сущностей (wd:Q583...) нельзя напрямую включить в вокабуляр seq2seq-модели для SPARQL-генерации?

Embedding-based QA

Альтернатива semantic parsing - не генерировать запрос, а работать в пространстве эмбеддингов. Вопрос и возможные ответы проецируются в одно векторное пространство, правильный ответ - тот, чей вектор ближе всего к вектору вопроса.

Ключевой вопрос: как получить эмбеддинги ответов? Используют **KG эмбеддинги** (TransE, RotatE, ComplEx) - каждая сущность KG уже имеет вектор. Вектор ответа строится как комбинация: `entity_embed(Толстой) + relation_embed(P19)` должен указывать на «место рождения Толстого».

**Преимущество Embedding QA:** работает даже с неполным графом - эмбеддинги обобщают структуру и могут отвечать на вопросы о неявных фактах. **Недостаток:** сложнее объяснить, почему выдан конкретный ответ.

В TransE-based QA вектор ответа вычисляется как topic_entity + relation. Что это означает геометрически?

Multi-hop reasoning

«Кто президент страны, в которой родился автор Преступления и наказания?» - здесь нужно два шага: найти автора книги (Достоевский), затем найти страну рождения (Россия), затем найти президента. Это **multi-hop reasoning** - ответ требует цепочки рассуждений через несколько сущностей.

**GraftNet** строит подграф вокруг топик-сущностей из вопроса (до K хопов), затем запускает GNN для агрегации информации и классифицирует каждый узел как «ответ / не ответ». Это позволяет рассуждать по структуре графа без явной генерации SPARQL.

**LLM + KG гибриды** (2023-2024): большие языковые модели умеют рассуждать, но галлюцинируют факты. Граф знаний точен, но не умеет рассуждать в тексте. Гибриды используют LLM для декомпозиции вопроса и планирования шагов, а KG - как источник верифицированных фактов на каждом шаге.

**HotpotQA** - benchmark для multi-hop, требует объяснения цепочки рассуждений (supporting facts). SOTA в 2024 - около 75% F1, человек набирает ~91%. Разрыв объясняется сложными вопросами, требующими здравого смысла.

Почему одношаговые embedding QA-системы не справляются с multi-hop вопросами?