Knowledge Graph на практике: зачем нужны графы знаний и как их строить для AI-систем

Графы знаний: когда обычные данные начинают думать

Представьте, что ваша база данных внезапно обрела сознание. Не в смысле восстания машин, а в том, что она начала понимать связи между сущностями. Вот что такое граф знаний - это не просто хранилище, это система, которая знает, что Илон Маск основал Tesla, Tesla производит электромобили, электромобили конкурируют с бензиновыми, а бензин добывают в Саудовской Аравии. Все эти связи образуют сеть, где каждый узел что-то значит, а каждое ребро - это утверждение о мире.

Почему RAG без графов знаний - это как поиск в куче мусора

Все сейчас помешались на RAG (Retrieval-Augmented Generation). Берем документы, создаем эмбеддинги, ищем похожие куски текста, кормим LLM. Работает? Да. Эффективно? Нет.

Проблема в том, что RAG ищет по семантической близости, а не по логическим связям. Спросите "какие компании Илона Маска используют аккумуляторы Tesla?", и обычный RAG найдет абзацы про Tesla, абзацы про Илона Маска, может быть что-то про аккумуляторы. Но он не поймет, что SpaceX тоже использует эти аккумуляторы, потому что это не написано явно ни в одном документе. Это знание нужно вывести из фактов: Илон Маск основал SpaceX, SpaceX использует батареи, Tesla производит батареи.

Три уровня сложности графов знаний (выбери свой)

1 Начинаем с онтологии: как не запутаться в собственных определениях

Онтология - это скелет вашего графа знаний. Без нее получится каша, где "клиент" в одном месте означает "юридическое лицо", в другом - "физическое лицо", а в третьем - "тот, кто купил хоть что-то когда-то".

Создавайте онтологию так:

1. Выпишите все сущности (классы). Не больше 20-30 для начала. Клиент, Заказ, Товар, Поставщик.
2. Определите свойства каждого класса. У Клиента есть имя, email, дата регистрации.
3. Опишите отношения. Клиент → создает → Заказ. Заказ → содержит → Товар.
4. Добавьте ограничения. Заказ не может существовать без Клиента. Товар должен иметь цену больше нуля.

@prefix ex:  .
@prefix rdf:  .
@prefix rdfs:  .

ex:Customer rdf:type rdfs:Class ;
    rdfs:label "Customer" ;
    rdfs:comment "A person or organization that purchases products" .

ex:placesOrder rdf:type rdf:Property ;
    rdfs:domain ex:Customer ;
    rdfs:range ex:Order ;
    rdfs:label "places order" .

2 Наполнение графа: откуда брать данные и как их превращать в знания

У вас есть три источника данных:

• Структурированные: базы данных, CSV, API. Легко конвертировать, но часто содержат только явные связи.
• Неструктурированные: документы, письма, чаты. Нужен NLP для извлечения сущностей и отношений.
• Полуструктурированные: JSON, XML, таблицы с нестандартными полями. Самый сложный случай.

Для извлечения знаний из текста используйте комбинацию:

# Пример: извлечение сущностей и отношений с помощью spaCy
import spacy
from spacy.matcher import Matcher

nlp = spacy.load("en_core_web_lg")
text = "Apple Inc. was founded by Steve Jobs in 1976."
doc = nlp(text)

# Извлекаем сущности
entities = [(ent.text, ent.label_) for ent in doc.ents]
# [('Apple Inc.', 'ORG'), ('Steve Jobs', 'PERSON'), ('1976', 'DATE')]

# Паттерн для отношений "основал"
matcher = Matcher(nlp.vocab)
pattern = [{"ENT_TYPE": "PERSON"}, {"LOWER": "founded"}, {"ENT_TYPE": "ORG"}]
matcher.add("FOUNDED", [pattern])
matches = matcher(doc)
# Найдем отношение: Steve Jobs → founded → Apple Inc.

Но готовые модели часто ошибаются в специфичных доменах. Для медицинских текстов или юридических документов придется дообучать или использовать специализированные модели.

3 Хранение и запросы: выбираем движок графовой базы

Neo4j - самый популярный, но не единственный. Выбор зависит от:

• Объема данных: Neo4j тормозит на миллиардах узлов, нужен JanusGraph или Dgraph
• Сложности запросов: нужен ли рекурсивный обход? Поддержка SPARQL?
• Интеграции: облако vs on-premise, поддержка языков программирования

Cypher (язык Neo4j) читается почти как английский:

// Найти всех клиентов, купивших товар дороже 1000$ в прошлом месяце
MATCH (c:Customer)-[:PLACED]->(o:Order)-[:CONTAINS]->(p:Product)
WHERE o.date >= date('2024-01-01') AND p.price > 1000
RETURN c.name, COUNT(p) as expensive_products
ORDER BY expensive_products DESC

Но Cypher не умеет в логический вывод. Если в онтологии указано, что "VeganPizza является подклассом Pizza", а в данных есть "Margherita является VeganPizza", то запрос "найти все Pizza" не найдет Margherita. Для этого нужны базы с поддержкой RDFS/OWL типа Stardog.

4 Интеграция с AI: делаем граф умным

Вот где начинается магия. Граф знаний + LLM = система, которая не только помнит факты, но и может рассуждать.

Сценарий 1: Улучшенный RAG. Вместо поиска по эмбеддингам всего текста:

1. Пользователь спрашивает: "Какие риски у нашего проекта X?"
2. LLM анализирует вопрос, извлекает ключевые сущности: проект X, риски
3. Ищем в графе: проект X → имеет_задачи → задача Y → имеет_риски → риск Z
4. Находим все риски, связанные с задачами проекта X
5. Для каждого риска достаем из векторной базы соответствующие документы (отчеты, письма)
6. Подаем LLM структурированные данные из графа + контекст из документов

Сценарий 2: AI-агенты с долгосрочной памятью. В статье "Почему ИИ-ассистенты ломаются в бизнес-среде" я писал о проблеме контекста. Граф знаний решает ее:

• Агент общается с клиентом Иваном
• Иван упоминает проблему с доставкой заказа #123
• В граф добавляется: Иван → жалуется_на → доставка → связана_с → заказ #123
• Через месяц Иван спрашивает: "Что там с той проблемой?"
• Агент находит в графе последнюю жалобу Ивана, понимает контекст, проверяет статус заказа #123

# Пример интеграции Neo4j с LangChain
from langchain.graphs import Neo4jGraph
from langchain.chains import GraphCypherQAChain
from langchain.chat_models import ChatOpenAI

graph = Neo4jGraph(
    url="bolt://localhost:7687",
    username="neo4j",
    password="password"
)

chain = GraphCypherQAChain.from_llm(
    llm=ChatOpenAI(temperature=0),
    graph=graph,
    verbose=True
)

# LLM сам генерирует Cypher-запрос на основе вопроса
result = chain.run(
    "Какие продукты чаще всего покупают вместе с iPhone?"
)
# Запрос найдет паттерны в исторических заказах

Типичные ошибки, которые сведут на нет все усилия

Практический кейс: система рекомендаций для e-commerce

Допустим, у вас интернет-магазин электроники. Обычные рекомендации "похожие товары" работают плохо - показывают то же самое, что человек уже смотрел.

С графом знаний:

1. Строим онтологию: Товар, Категория, Бренд, Характеристики, Пользователь, Отзыв
2. Наполняем граф: iPhone 15 → имеет_бренд → Apple → конкурирует_с → Samsung
3. Добавляем поведенческие данные: пользователь123 → купил → iPhone 15 → оставил_отзыв → "отличная камера"
4. Анализируем граф: находим пользователей, похожих на пользователь123 (купили те же товары, оставили похожие отзывы)
5. Смотрим, что эти похожие пользователи купили еще, но пользователь123 - нет
6. Рекомендуем не "похожий на iPhone 15", а "чехол для iPhone 15" (потому что 80% похожих пользователей купили чехол) или "Samsung Galaxy" (потому что 30% перешли с iPhone на Samsung)

Конверсия таких рекомендаций в 2-3 раза выше, потому что они основаны на реальных паттернах поведения, а не на семантической близости описаний товаров.

Что дальше? Графы знаний как основа для AGI

Сейчас все говорят про мультимодальность, но я считаю, что это тупиковый путь. В статье "Мультимодальность - это тупик" я объяснял почему. Добавление зрения и слуха к LLM не создаст разум - нужно добавить способность к логическому выводу и работе с абстрактными понятиями.

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

Через 2-3 года успешные AI-системы будут выглядеть так:

• Ядро - граф знаний с онтологией предметной области
• Множество специализированных LLM для разных задач (анализ текста, генерация кода, планирование)
• Оркестратор, который разбивает сложные задачи на подзадачи, использует граф для хранения промежуточных результатов и проверки согласованности
• Механизм обучения на собственных действиях: каждый успешный результат добавляется в граф как новый факт

Начните с малого. Возьмите одну задачу в вашем проекте, где обычные методы не работают. Постройте простой граф знаний. Увидите разницу сразу - данные начнут "разговаривать", показывать связи, о которых вы не подозревали. А потом уже масштабируйте.