Knowledge Graph

knowledge graph — сущности, факты и связи в одной модели

Раздел: Языковые модели
Обновлено: 22.10.26

Граф знаний хранит объекты и связи между ними: кто работает над проектом, какую технологию он использует и откуда взят факт. Разберём, как такие связи помогают искать информацию и готовить ответы AI.

Коротко

Knowledge Graph, или граф знаний, — сеть именованных сущностей и утверждений о том, как они связаны. Узлами могут быть люди, организации, документы, места и понятия. Рёбра описывают отношения: «работает в», «автор», «зависит от», «находится в». У сущностей, связей и самих утверждений могут быть типы, свойства, источники и временные рамки.

Граф удобен, когда вопрос касается не одного документа, а цепочки: кто отвечает за проект, какие системы от него зависят и из какого источника это известно. Он не делает факты истинными автоматически и не заменяет поиск по тексту — он даёт данным явную структуру.

Что хранится в графе знаний

Представим внутренний каталог студии. В нём есть сотрудница Ирина, проект «Архив» и технология распознавания речи. В плоских таблицах эти сведения могут лежать в разных системах. Граф собирает их в связанную картину:

Ирина — РАБОТАЕТ_НАД → Архив
Архив — ИСПОЛЬЗУЕТ → Распознавание речи
Архив — ОПИСАН_В → Техническое задание

Здесь «Ирина», «Архив» и «Распознавание речи» — сущности. Надписи на стрелках — типы отношений. У проекта может быть статус, у связи — дата начала, а у утверждения — ссылка на документ, из которого оно получено.

Термин не имеет одной обязательной реализации. На практике встречаются RDF-графы, графы с метками и свойствами, а также собственные модели. Их объединяет идея: смысл хранится не только в отдельных записях, но и в явно названных связях.

Две распространённые модели

RDF и триплеты

RDF описывает утверждение как тройку субъект — предикат — объект, то есть «о ком говорится — какое отношение — с чем». Набор таких троек образует RDF-граф. Идентификаторы обычно задаются IRI, а значениями могут быть другие ресурсы, строки, числа и даты.

studio:irina  studio:worksOn  studio:archive
studio:archive  studio:uses  studio:speechRecognition

RDF — модель данных W3C, а не конкретная база. Один и тот же граф можно записать в Turtle, JSON-LD и других форматах. Для запросов к RDF-данным используют SPARQL; выражения путей (property paths) описывают последовательности связей.

Labeled property graph

В property graph узлы получают метки и свойства, а отношения — направление, тип и собственные свойства. Такой вид часто встречается в графовых СУБД и в запросах Cypher:

MATCH (person:Person)-[:WORKS_ON]->(project:Project)
      -[:USES]->(technology:Technology)
WHERE person.id = 'person-irina-01'
RETURN project.name, technology.name

В примере предполагается, что такие узлы и связи уже созданы, а у Ирины есть устойчивый идентификатор person-irina-01. Поиск только по имени мог бы вернуть нескольких разных людей.

Cypher, Neo4j и другие продукты не являются синонимами knowledge graph. Cypher — язык запросов к графовым данным, Neo4j — конкретная СУБД, а граф знаний — смысловая модель данных, которую можно хранить разными способами.

Зачем нужны идентификаторы и схема

Главная сложность начинается не со стрелок, а с ответа на вопрос: две записи говорят об одной сущности или о разных?

«ООО Ромашка», «Ромашка» и внутренний код org-184 могут обозначать одну компанию. Процесс сопоставления упоминаний с устойчивой сущностью называют entity linking или resolution. Без него граф быстро обрастает дублями и противоречивыми ветками.

Схема или онтология задаёт допустимые типы и смысл отношений. Например:

Person может WORKS_ON Project;
Project может DEPENDS_ON Service;
связь WORKS_ON имеет даты начала и окончания;
утверждение должно ссылаться на источник.

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

При этом онтология не обязательно проверяет полноту записи как схема формы. Например, правила RDF/OWL и проверка обязательных полей решают разные задачи. Для валидации RDF-графа можно задать ограничения SHACL и отдельно выполнить проверку.

Как граф строится из данных

Источниками бывают таблицы, API, документы, журналы событий и ручная разметка. Типичная обработка включает несколько разных задач.

Выделение кандидатов. Из текста извлекаются сущности, отношения и утверждения; из таблиц берутся поля и внешние ключи.
Нормализация. Имена, даты, единицы и типы приводятся к общей форме.
Entity linking. Упоминания связываются с существующими идентификаторами или создают новые сущности.
Запись происхождения. Сохраняется источник, время извлечения, версия и при необходимости оценка уверенности с описанием того, как она получена.
Проверка. Ограничения схемы, дубликаты и конфликты проходят автоматическую и ручную валидацию.
Обновление. Устаревшие связи закрываются временным интервалом или заменяются новыми утверждениями с сохранением истории.

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

Что даёт запрос по пути

Векторный поиск отвечает на вопрос «какие фрагменты похожи по смыслу». Графовый запрос отвечает на вопрос «какие сущности соединены указанным рисунком отношений».

Например, запрос может найти сервисы, от которых зависит проект Ирины через один или несколько промежуточных компонентов. Результат появляется потому, что эти рёбра уже записаны в графе. Сам обход графа не доказывает причинность и не открывает неизвестный факт: он сопоставляет хранимую структуру с шаблоном запроса.

Цепочки из нескольких связей часто называют multi-hop. Они полезны для каталогов зависимостей, расследования происхождения данных, контроля доступа, рекомендаций и вопросов по связанным сущностям. Однако длинный путь может породить слишком много совпадений, а ошибочное ребро распространяет ошибку на все запросы, которые через него проходят.

Knowledge Graph и RAG

Граф и векторный индекс решают разные задачи поиска. Их место в общей системе объясняет разбор RAG и AI-поиска.

Векторный поиск хорошо подбирает нестрого сформулированные и тематически близкие фрагменты.
Граф хорошо фильтрует по типам, проходит по явным отношениям и показывает путь к результату.
Текстовый источник хранит детали и формулировки, которые не вошли в структуру графа.

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

GraphRAG — общее название для RAG-подходов, использующих графовую структуру. Это не один стандартный алгоритм. Например, исследовательский проект Microsoft GraphRAG извлекает сущности, отношения и дополнительные утверждения, строит сообщества и отчёты по ним, а затем предлагает несколько режимов поиска. Такой индекс может быть полезен для вопросов о структуре всего корпуса, но его построение требует дополнительных моделей, времени и проверки качества.

Источник факта важнее красивого ребра

Связь Компания — ВЛАДЕЕТ → Сервис без контекста может быть неполной. Владение меняется со временем, относится к определённой юрисдикции и подтверждается конкретным документом. Для такой связи полезно хранить контекст:

откуда взято утверждение;
когда оно было актуально;
кто добавил утверждение или какая программа его извлекла;
какой уровень доверия присвоен;
есть ли конкурирующее утверждение.

В RDF происхождение можно группировать по именованным графам или моделировать отдельными утверждениями. В property graph метаданные часто помещают в свойства отношения либо выносят факт в самостоятельный узел. Универсального способа нет: структура выбирается под запросы и правила предметной области.

С чем часто путают

Граф знаний и графовая база. База даёт хранение и запросы; граф знаний добавляет предметный смысл, идентичность сущностей и правила интерпретации.
Граф знаний и онтология. Онтология описывает понятия и ограничения, граф — конкретные факты и сущности.
Граф знаний и семантический поиск. Граф сопоставляет явные связи, семантический поиск — близость представлений текста или других объектов.
RDF и файл. RDF — абстрактная модель данных; Turtle и JSON-LD — способы её записать.
SPARQL и Cypher. Оба запрашивают графы, но относятся к разным моделям и экосистемам.
GraphRAG и любой KG. Граф может существовать без LLM и RAG; GraphRAG использует граф для подготовки контекста генерации.

Частые заблуждения

«Граф сам делает логические выводы»

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

«Для multi-hop граф всегда лучше vector RAG»

Преимущество зависит от вопроса, полноты графа и качества entity linking. Если нужного ребра нет или схема не отражает отношение, обход не найдёт нужный путь. В документе при этом может быть прямой и легко извлекаемый ответ.

«LLM быстро построит готовый KG из папки документов»

Извлечение создаёт черновые сущности и связи. Дубли, местоимения, отрицания, временные оговорки и конфликтующие источники требуют отдельной обработки. Чем важнее решения на основе графа, тем заметнее цена валидации.

«Любая сеть узлов является графом знаний»

Технический граф может описывать клики или соединения без предметной семантики. Knowledge graph обычно связывает сущности и утверждения так, чтобы их смысл был доступен людям и программам.

Например, граф ComfyUI хранит порядок обработки, а не утверждения о мире. С этим другим видом графа знакомит раздел ComfyUI на TimeSaver VFX: провод между нодами передаёт данные, но не означает отношение «автор» или «зависит от» из графа знаний.

Частые вопросы

Какой формат выбрать: RDF или property graph?

RDF удобен для совместимости, глобальных идентификаторов, публикации связанных данных и инструментов W3C. Property graph часто проще для прикладной разработки, свойств на отношениях и поиска по образцу связей. Выбор определяется обменом данными, запросами, правилами и доступными инструментами.

Граф знаний обязан храниться в графовой базе?

Нет. Небольшой граф может жить в файлах, реляционных таблицах или объектном хранилище. Специализированная СУБД становится полезнее, когда нужны частые запросы по путям, индексы, конкурентные обновления и управление большим набором связей.

Как измеряют качество KG?

Отдельно проверяют точность и полноту сущностей, сопоставление упоминаний, отношения, источники, временные границы и ответы на контрольные запросы. Одна общая «точность графа» скрывает, где именно возникает ошибка.

Можно ли объединить несколько графов?

Можно, если согласованы идентификаторы, типы и правила доверия к источникам. Простое слияние файлов часто создаёт дубли и конфликтующие утверждения. RDF облегчает объединение за счёт глобальных IRI, но не решает автоматически вопрос идентичности.

Чем Wikidata сложнее набора триплетов?

Утверждения Wikidata могут иметь уточнения, ссылки на источники и ранг. Это позволяет указать период действия, источник и предпочтительность значения. Такой контекст показывает, почему реальный граф знаний богаче схемы «два узла и стрелка».

Главное

Knowledge Graph хранит сущности как связанную систему утверждений. Его сила не в картинке из кружков, а в устойчивых идентификаторах, типизированных отношениях, путях запроса и происхождении фактов.

RDF со SPARQL и графы свойств с Cypher предлагают разные способы выразить эту идею. Графовая СУБД отвечает за исполнение, онтология — за смысл и ограничения, а сам граф — за конкретные данные. В RAG он особенно полезен рядом с текстом и векторным поиском: структура находит явные связи, документы дают подробности, а модель формирует ответ из переданного контекста.

Источники

Что дальше:

Сначала основа Начать с основ: что такое AI → Полезно, если нынешнее определение пока опирается на незнакомые понятия. Следующее понятие Semantic Search → Прямая смысловая связь с темой этой статьи. Вся область Языковые модели → Посмотреть соседние понятия внутри одной темы.