Граф знаний (knowledge graph) — это граф сущностей и связей между ними. В формальном стандарте такой граф часто описывают через RDF как набор триплетов «субъект-предикат-объект», а в современных RAG- и агентных системах граф знаний используют, чтобы хранить факты, находить связи и подмешивать их в ответ модели.
Важно не путать термин с конкретным продуктом. По состоянию на 2026-08-18 под «графом знаний» в практике могут иметь в виду и RDF-граф из стандарта W3C, и реализацию на графовой БД, и управляемый облачный сервис для GraphRAG; из-за этого модель данных, язык запросов и ограничения зависят от стека.
Английский термин: knowledge graph. Также встречается: KG, «граф сущностей и связей». Близкие, но не равные термины: graph database, RDF graph, GraphRAG.
Простыми словами
Грубо говоря, граф знаний можно представить как карту фактов. В обычной таблице вы храните строки, в папке с документами — куски текста, а в графе знаний сразу видно, кто связан с кем и как именно.
Например, у вас есть компания, продукт, клиент и договор. Граф знаний позволяет хранить не только сами объекты, но и отношения: «клиент использует продукт», «договор относится к региону», «регион накладывает ограничение». Для LLM это полезно там, где ответ зависит не от одного абзаца, а от цепочки связанных фактов.
Как это работает
Техническая база проста: сначала вы выделяете сущности, затем связываете их отношениями, а потом запрашиваете нужный фрагмент графа. В RDF-терминах минимальная единица — триплет: субъект, предикат, объект.
[Документы, таблицы, API]
|
v
[Выделение сущностей]
клиент, продукт, договор, регион
|
v
[Нормализация / reconciliation]
"ООО Ромашка" = "Romashka LLC"
|
v
[Граф фактов]
(Клиент) -[использует]-> (Продукт)
(Договор) -[подчиняется]-> (Политика)
(Регион) -[ограничивает]-> (Действие)
|
v
[Поиск по соседям графа]
|
+-----+-----+
| |
v v
[Графовый поиск] [Векторный поиск]
/
/
v v
[LLM / агент]
|
v
[Ответ]- Сбор данных. Источником могут быть документы, таблицы, каталоги, справочники или уже существующие базы.
- Выделение сущностей. Система находит объекты: компании, людей, продукты, регионы, документы.
- Связывание и нормализация. Одинаковые сущности склеиваются, а между ними добавляются отношения.
- Построение графа. Факты записываются как ребра между узлами; в стандарте RDF — как триплеты.
- Извлечение контекста. По запросу система не только ищет похожий текст, но и проходит по связям графа.
- Генерация ответа. LLM получает найденные факты и формирует итоговый ответ.
Для GraphRAG это особенно важно. В обзорной работе Graph Retrieval-Augmented Generation: A Survey процесс разложен на три части: Graph-Based Indexing, Graph-Guided Retrieval и Graph-Enhanced Generation. То есть граф может участвовать и на этапе индексации, и на этапе поиска, и на этапе подготовки финального ответа.
Где применяется
- RAG и агентные пайплайны. Здесь граф знаний помогает отвечать на вопросы, где важны связи между объектами, а не просто похожие фрагменты текста. Смежные подходы разобраны в материалах GraphRAG (графовый RAG) и Corrective RAG (CRAG).
- Управляемые облачные графы. AWS документирует Amazon Neptune как fully managed graph database и прямо относит knowledge graphs к ключевым сценариям. Поверх него Amazon Bedrock Knowledge Bases документирует fully managed GraphRAG c Neptune Analytics graphs.
- Сведение сущностей и поиск по корпоративным данным. Google Enterprise Knowledge Graph документирован как отдельный продукт Google Cloud; на дату проверки он помечен как Preview, а Basic edition остаётся доступным, но без новых функций, высокого QPS и дополнительных стандартов security/compliance.
- Легаси-доступ к сущностям Google. Google Knowledge Graph Search API всё ещё задокументирован, но Google прямо указывает, что API только для чтения, не подходит как production-critical dependency и для новых проектов рекомендует миграционный путь в Cloud Enterprise Knowledge Graph.
- Open-source и референсные реализации. Для Neo4j есть официальный first-party пакет Neo4j GraphRAG for Python. У Microsoft есть GraphRAG-репозиторий, но он отмечен как demonstration и не является officially supported offering.
Практический пример
Ниже — упрощённый пример того, как граф знаний помогает ответить на вопрос в корпоративной базе знаний. Формат условный, но опирается на RDF-идею триплетов.
:ClientA :uses :ProPlan .
:ClientA :belongsToRegion :EU .
:ProPlan :includes :PrioritySupport .
:EU :restricts :ExternalStorage .
:Policy42 :appliesTo :EU .Вопрос пользователя: «Можно ли клиенту A хранить данные вне ЕС, если он на тарифе Pro?»
- Система находит узел
:ClientA. - Переходит по связям к
:ProPlanи:EU. - Находит ограничение
:EU :restricts :ExternalStorageи связанную политику:Policy42. - LLM получает не весь корпус документов, а короткую цепочку фактов.
- Ответ становится более проверяемым: можно показать, какие именно связи использовались.
Такой сценарий особенно полезен там, где ответ строится по нескольким переходам. Если у вас задача ближе к поиску похожих фрагментов текста, иногда достаточно семантического поиска без отдельного графа.
Практический вердикт: граф знаний имеет смысл, когда для ответа важны явные сущности, связи и маршрут рассуждения. Если у вас только набор текстовых чанков без устойчивых отношений между объектами, граф может оказаться лишней сложностью.
Чем отличается от похожих терминов
| Термин | Что это | Чем отличается от графа знаний |
|---|---|---|
| Граф знаний | Модель фактов как сущностей и связей | Фокус на структуре знаний и отношениях между объектами |
| Графовая БД | Движок хранения и запросов для графовых данных | Это инфраструктура. Она может хранить граф знаний, но сама по себе не равна ему |
| RDF-граф | Формальная модель W3C как набор триплетов subject-predicate-object | Это стандартное представление графа; термин «граф знаний» шире и вендорно трактуется по-разному |
| GraphRAG | Подход к RAG, где граф используется для индексации, поиска или генерации | GraphRAG — это способ применять граф в LLM-пайплайне, а не синоним самого графа знаний |
| Семантический поиск | Поиск по смысловому сходству, обычно через векторные представления | Он не требует явных ребер между сущностями; на практике может дополнять граф, а не заменять его |
Ограничения и заблуждения
- Заблуждение: «граф знаний = любая графовая БД». Нет. База данных — это способ хранения и запроса, а граф знаний — смысловая модель данных.
- Заблуждение: «граф знаний всегда RDF». RDF — важная формальная база, но в практике встречаются и другие графовые модели; из-за этого у разных стеков различаются семантика и инструменты.
- Проблема извлечения из текста. Microsoft в репозитории GraphRAG отдельно предупреждает, что indexing can be expensive. То есть построение графа из неструктурированного корпуса — это не бесплатная и не мгновенная операция.
- Managed GraphRAG имеет продуктовые рамки. В текущей документации Amazon Bedrock для Neptune Analytics graphs указаны ограничения: поддерживается только источник данных S3, нет custom graph-build options, нет autoscaling для Neptune Analytics graphs, а доступность ограничена регионами Frankfurt, London, Ireland, US West (Oregon), US East (N. Virginia), Tokyo и Singapore.
- Google Enterprise Knowledge Graph пока не выглядит как «поставил и забыл». Документация помечена как Preview. Basic edition остаётся доступным, но без новых features, high QPS и additional security/compliance standards.
- Есть и количественные лимиты. В квотах Enterprise Knowledge Graph на дату проверки указаны 2 concurrent entity-reconciliation jobs, 60 Google Knowledge Graph Search API requests per minute, до 10 source BigQuery tables и до 400M total records to process.
- Легаси API Google не стоит брать как критическую зависимость. Документация Knowledge Graph Search API прямо говорит, что API только для чтения, не подходит как production-critical dependency, а для новых проектов предлагается Cloud Enterprise Knowledge Graph.
Редакционное ограничение: эта статья объясняет термин и текущие подтверждённые варианты применения, но не заменяет проектную проверку живых квот, регионов, релизов и ограничений перед внедрением. В этой теме условия у облачных и open-source стеков меняются быстро.
Связанные термины и инструменты
Если вы строите LLM-систему с явными связями между сущностями, посмотрите также GraphRAG, CRAG и семантический поиск. Для оркестрации многошаговых агентных workflow может быть полезен разбор как перенести workflow из LangChain в LangGraph.
Источники
- RDF 1.2 Concepts and Abstract Data Model
- Getting started with Amazon Neptune
- Build a knowledge base with Amazon Neptune Analytics graphs – Amazon Bedrock
- Enterprise Knowledge Graph documentation | Google Cloud Documentation
- Quotas and limits | Enterprise Knowledge Graph | Google Cloud Documentation
- Google Knowledge Graph Search API | Google for Developers
- GraphRAG for Python — neo4j-graphrag-python documentation
- microsoft/graphrag repository
- Graph Retrieval-Augmented Generation: A Survey
Вопросы и ответы
Граф знаний и GraphRAG — это одно и то же?
Нет. Граф знаний — это сама структура фактов и связей. GraphRAG — это способ использовать граф в пайплайне LLM: на этапе индексации, поиска или генерации ответа.
Обязательно ли строить граф знаний именно в RDF?
Не обязательно. RDF — формальная и важная база из стандарта W3C, но вендорские и прикладные реализации могут использовать и другие графовые модели.
Когда граф знаний полезнее обычного семантического поиска?
Когда ответ зависит от нескольких связанных фактов: например, от маршрута «клиент → договор → регион → ограничение». Если задача сводится к поиску похожих текстовых фрагментов, векторного поиска может быть достаточно.
Можно ли брать Google Knowledge Graph Search API как основную прод-зависимость?
По текущей документации — не стоит. Google описывает его как read-only API, не рекомендует как production-critical dependency и предлагает новым проектам Cloud Enterprise Knowledge Graph.