Использование графов знаний при разработке RAG-систем

1 Введение

Привет, Habr! На связи Александр Сулейкин, Роман Бабенко и Даниил Бутнев. Подготовили совместную статью по теме использования графов знаний при разработке RAG-систем. В рамках статьи рассказываем про основные проблемы традиционных RAG-систем, даем обзор основных открытых проектов графов знаний GraphRAG, показываем и даем краткое описание архитектуры таких систем, а также рассказываем про практическое использование графов знаний на примере трех областей – медицины, метрологии и стандартизации.

В последние годы Retrieval-Augmented Generation (RAG) стала одним из самых популярных подходов к построению систем, способных отвечать на вопросы на основе больших объемов данных. Однако, стандартные реализации RAG имеют ряд ограничений, особенно когда дело касается сложных, взаимосвязанных данных. В этой статье мы рассмотрим, как графы знаний могут решить эти проблемы и какие инструменты существуют для построения RAG на основе графов знаний. Мы также представим результаты оценки качества ответов RAG-систем на основе созданных графов по юридической, технической и метрологической документации.

2 Описание проблем RAG. Как графы знаний могут их решить.

2.1 Стандартный RAG состоит из трех основных этапов:

• Retrieval (Извлечение): Поиск релевантных фрагментов данных из векторной базы данных на основе семантического сходства между запросом пользователя и фрагментами.

• Augmentation (Дополнение): Объединение извлеченных фрагментов с запросом пользователя для формирования контекста.

• Generation (Генерация): Использование большой языковой модели (LLM) для генерации ответа на основе дополненного контекста.

2.2 Проблемы традиционного RAG-подхода

Несмотря на свою эффективность, стандартный RAG сталкивается с рядом проблем:

• Потеря контекста: При извлечении фрагментов информации может быть потеряна важная взаимосвязь между ними, что приводит к неполным или неточным ответам.

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

• Неэффективность при работе с неструктурированными данными:  Извлечение релевантной информации из неструктурированных данных может быть сложным и неточным.

• Галлюцинации: LLM могут генерировать неверную информацию, особенно если контекст неполный или неточный.

В 2024 году для решения таких проблем Microsoft Research представила GraphRAG, совершенно новый метод, который дополняет извлечение и генерацию RAG с помощью графов знаний.  Вместо хранения данных в виде отдельных фрагментов, графы знаний представляют информацию в виде узлов (сущностей) и ребер (отношений между сущностями).  Это позволяет:

• Сохранять контекст: Отношения между сущностями явно определены, что позволяет LLM понимать взаимосвязи между ними.

• Поддерживать многошаговые вопросы: LLM может “пройтись” по графу, чтобы найти информацию, необходимую для ответа на сложный вопрос.

• Улучшить работу с неструктурированными данными: Графы знаний могут быть построены на основе неструктурированных данных путем извлечения сущностей и отношений с помощью методов обработки естественного языка (NLP).

• Снизить галлюцинации: Явное представление знаний в графе помогает LLM генерировать более точные и достоверные ответы.

3. Открытые проекты для создания RAG-систем на основе графов знаний

Существует множество библиотек (фреймворков), которые используются для создания RAG-систем на основе графов знаний:

• GraphRAG ^[3] (MIT license ^[4]): В июле 2024 года Microsoft Research открыла код проекта GraphRAG и сделала его доступным на GitHub. Процесс GraphRAG включает в себя извлечение графа знаний из необработанного текста, построение иерархии сообществ, генерацию сводок для этих сообществ, а затем использование этих структур при выполнении задач на основе RAG.

• LightRAG ^[5] (MIT license ^[4]): Инновационный подход, основанный на GraphRAG, который сочетает атрибуты графов знаний с системами поиска на основе эмбеддингов, что делает его быстрым и производительным, достигая результатов SOTA (State-of-the-Art).

• fast-graphrag ^[6] (MIT license ^[4]): Оптимизированный и быстрый фреймворк GraphRAG, разработанный для интерпретируемых, высокоточных рабочих процессов поиска, управляемых агентами.

• HiRAG ^[7] (MIT license ^[4]): Новый RAG-подход, который использует иерархические знания для улучшения семантического понимания и возможностей захвата структуры RAG-систем в процессах индексации и поиска.

• nano-graphrag ^[8] (MIT license ^[4]): Этот фреймворк предоставляет более легкий, быстрый и чистый GraphRAG, сохраняя при этом основную функциональность. Проекты, в которых использовался данный фреймворк: LightRAG, fast-graphrag, HiRAG.

Активность проекта на GitHub (количество звезд, форков, коммитом и запросов на слияние) показывает насколько проект развивается и интересен сообществу. В таблице ниже представлены данные по каждой из вышеперечисленных библиотек на дату 05.05.2025:

GraphRAG обладает самым большим количеством звезд, что объясняется статусом первой библиотеки для создания RAG на основе графов знаний.

Однако на текущий момент GraphRAG имеет следующие недостатки по сравнению с LightRAG:

• Низкая активность коммитов (MR);

• Проблемы при создании графов с использованием локальных open-source LLM (разработчики не спешат их исправлять, рекомендуя облачные модели OpenAI);

• Отсутствие пользовательского интерфейса.

Учитывая эти факторы, LightRAG можно выделить как одну из самых активно развивающихся и перспективных библиотек.

4. Обзор архитектуры RAG на основе графа знаний

Про архитектуру GraphRAG ^[3] написана не одна статья на Хабр, достаточно ввести GraphRAG в строке поиска или перейти на страницу официальной документации ^[9]. Не будем плодить сущности и рассмотрим архитектуру второй по популярности на GitHub библиотеки RAG с графами знаний – LightRAG ^[10].

GraphRAG имеет две основные проблемы – медленная обработка запросов и реконструирование всего графа при добавлении новых данных. LightRAG решает данные проблемы:

• Сокращая индексацию и время отклика за счет лучшего подхода, чем обход сообщества.

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

Архитектура решения на основе RAG обычно состоит из двух основных процессов: индексации данных и обработки запросов.

4.1 Индексация данных

Процесс индексации данных в LightRAG состоит из четырех этапов, направленных на создание структурированного представления информации для эффективного поиска и анализа.

1) Разбиение на фрагменты: Исходный текст разделяется на небольшие, логически завершенные части (например, абзацы или предложения). Это позволяет более детально анализировать информацию.

2) Выделение ключевых элементов: Используя возможности больших языковых моделей (LLM), из каждого фрагмента извлекаются важные сущности (люди, места, организации и т.д.), связи между ними и основные утверждения. Эта информация служит основой для создания графа знаний.

3) Создание пар ключ-значение: После извлечения элементов используется LLM  для создания структурированных пар ключ-значение (KV) сущностей и связей. 

Ключ (K) – это слово или короткая фраза, а значение (V) – это абзац, обобщающий соответствующие фрагменты. Обычно сущности имеют свое имя в качестве единственного индекса, тогда как связи могут иметь несколько ключей индекса, чтобы охватывать более широкие темы из связанных сущностей. Используя эти пары KV, строится начальный граф знаний.

LightRAG сочетает в себе индексацию графов и стандартный подход, основанный на эмбеддингах. Если быть точным, значение (V) сущностей и связей в парах ключ-значение после профилирования LLM передаются на промежуточный этап для генерации векторных вложений с использованием модели ембеддингов. Эти структуры данных KV обеспечивают более точный поиск, чем менее точные стандартные методы встраивания RAG или неэффективные методы обхода фрагментов в GraphRAG.

4) Дедупликация для оптимизации работы с графом: Для эффективной обработки данных повторяющиеся сущности и связи объединяются, тем самым уменьшая как накладные расходы, так и общий размер графа.

После дедупликации мы получаем окончательную оптимизированную версию графа знаний (KG).

4.2 Обработка запросов

Благодаря индексации текста на основе графов, LightRAG использует стратегию двухуровневого поиска. Этот подход идентифицирует низкоуровневые и высокоуровневые ключи из подграфов с несколькими переходами в KG для ответа на разнообразный набор запросов.

Низкоуровневый поиск:  Предназначается для получения конкретной детализированной информации из отдельных узлов и ребер для обработки локальных запросов. На этом уровне он предоставляет подробную информацию на уровне узла.

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

5. Практическое использование графа знаний в RAG

В процессе разработки нескольких пилотных проектов на основе RAG мы протестировали использование графов знаний и сделали оценку качества такого подхода. Результат представлен в конце раздела.

Стандартный пайплайн создания и оценки качества ответов RAG состоит из следующих шагов:

• Подготовка датасета (вопрос – ответ) для оценки качества ответов RAG-системы. Если заказчик не готов предоставить такие вопросы и эталонные ответы, то создаем их с помощью библиотеки giskard ^[11] и валидируем;

• Непосредственно разработка RAG-системы, загрузка и индексация необходимых источников данных. В зависимости от задачи применяем различные инструменты для разработки – собственный продукт SmartSearch ^[12], low-code нодовые редакторы (статья про них на Хабр ^[13]), библиотеки langchain ^[14]/ langgraph ^[15]/ llama_index ^[16];

• Оценка разработанной RAG-системы на основе тестового датасета. Для проведения автоматической оценки применяем библиотеку langfuse ^[17] и метод оценки LLM в качестве судьи (LLM-as-a-judge). Суть метода заключается в оценке правильности ответа разрабатываемой RAG-системы относительно эталонного ответа. На данном шаге важно, чтобы модели LLM, используемые в RAG-системе, и для оценки были разные.

В качестве инструментов для создания RAG на основе графов знаний были выбраны:

– сервер LightRAG;

– локальный провайдер ollama с моделями LLM gemma3:27b и эмбеддингов bge-m3;

– облачный API DeepSeek с моделью для оценки DeepSeek V3;

– БД Neo4j для работы с графами;

– БД Milvus для работы с векторами;

– БД Redis для работы со структурами данных типа «ключ — значение».

Сервер LightRAG разработан для обеспечения веб-интерфейса и поддержки API. Веб-интерфейс позволяет загружать и индексировать документы (Рисунок 5), анализировать графы знаний (Рисунок 6) и выполнять RAG-запросы (Рисунок 7).

Для составления таблицы оценки наивного RAG и на основе графа знаний были подготовлены документы, вопросы и эталонные ответы из трех доменных областей:

1) Метрология – Руководство пользователя Цифровой метрологической лаборатории;

2) Стандартизация – Единый отраслевой стандарт закупок (ЕОСЗ);

3) Медицина – Клинические рекомендации. Острые респираторные вирусные инфекции (ОРВИ) у взрослых.

Полученные результаты оценки правильности ответов с использованием LightRAG превосходят оценки наивного RAG в среднем на 10 – 15 % в зависимости от типа документации. При этом среднее время получения ответа по графу знаний в 3 раза больше, чем при наивном RAG (75 с против 25 с).

Уменьшение времени ответа таких систем – задача на будущее. В будущих статьях постараемся осветить эту проблему более детально и описать возможные методы ее решения, подходы и конкретные проекты/ библиотеки.

6. Выводы

Использование графов знаний является перспективным подходом к построению RAG-систем, способных отвечать на вопросы на основе больших объемов данных. Использование графов знаний позволяет решить ряд проблем, присущих стандартному RAG, и улучшить качество ответов. Данный подход рекомендуется применять наряду с другими методами улучшения качества – очистка данных от шума, продвинутый (семантический) чанкинг, гибридный поиск, двухэтапный поиск с применением переранжирования и пр.

Опрос: Применяли ли вы графы знаний в своих проектах? Если да, то какие библиотеки использовали и было ли улучшение точности ответов?

Наш ТГ-канал: t.me/dataundercontrol ^[18]