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

Почему векторный поиск не всегда работает

Векторный поиск превращает текст в вектор — точку в многомерном пространстве. Похожие тексты оказываются рядом, и система находит ближайшие к запросу. Но есть три ключевые проблемы:

• Один вектор — один смысл. Документ сжимается в один вектор, и все его смыслы усредняются. При большом объёме данных (от 500 тыс. документов) векторы «сливаются», теряя нюансы.
• Семантическое сходство ≠ релевантность. Поиск возвращает похожий текст, но не обязательно ответ. Для аналитических запросов (например, «Почему X привело к Y?») это критично.
• Нет памяти о связях. Векторный поиск не видит, что одна и та же сущность упоминается в разных документах. Многошаговые вопросы (например, «Кто руководил компанией, которую приобрела организация, финансирующая X?») он не решает.

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

Первый подход: граф из готового дампа

Мы начали с публичного графа знаний Yago — 120 млн фактов, построенных на основе Wikidata. Выбрали его из-за строгой схемы типов и готовой структуры. Данные загрузили в Apache Jena Fuseki, создали API на Go и подключили ИИ-агента.

Агент работает в пять этапов:

1. Выделение сущностей — LLM извлекает из запроса именованные сущности.
2. API Router — подставляет сущность в SPARQL- или Cypher-шаблон.
3. Выполнение запроса — графовая база возвращает узлы и связи.
4. Ранжирование — результаты сортируются по весу узлов и рёбер.
5. Суммаризация — LLM формирует финальный ответ.

Выбор графовой базы данных

У нас было два сценария:

• RAG — нужна скорость и целостность данных.
• Хранилище — большой объём, масштабируемость.

Для RAG рассмотрели FalkorDB и Memgraph, для хранилища — NebulaGraph и JanusGraph. Но начали с Apache Jena Fuseki — она быстро загрузила дамп Yago, но не справлялась с тяжёлыми аналитическими запросами.

Эксперименты и первые результаты

Мы провели 13 экспериментов и 184 замера на бенчмарке ruSimpleQA (4326 вопросов). Граф подключали как дополнительный источник: его ответы объединялись с векторным поиском и передавались реранкеру.

Пробовали:

• Расширить граф через API IMDB.
• Ранжировать сущности по количеству связей.
• Ограничить количество возвращаемых узлов.
• Поиск на глубину 3 с контролем ветвления.
• Поиск в ширину (1–2 хопа).
• Готовые Cypher-шаблоны.
• Векторный поиск по эмбеддингам узлов.
• Графовые алгоритмы (например, поиск пути между сущностями).

Итоги первого подхода

Прирост составил всего +3 п. п. на изолированном агенте. В связке с векторным поиском улучшения не вышли за пределы статистической погрешности.

Почему не сработало:

• Векторный поиск по графу работал плохо из-за скудных описаний.
• Yago слишком универсален — тематическая специфика теряется.
• Каждый шаг в цепочке агента накапливает ошибки.

исходный запрос → выделение сущности → получение результатов из баз → агрегирование ответов из нескольких источников → суммаризация → ответ → оценка llm-as-a-judge

Второй подход: LightRAG на собственных документах

Мы сменили стратегию: вместо универсального графа построили граф из своих документов. Выбрали LightRAG — легковесный RAG-фреймворк с двухуровневым поиском.

Как работает LightRAG

LightRAG решает три главные проблемы векторного поиска:

• чанки слишком маленькие и теряют контекст;
• чанки разрозненны — из разных документов;
• LLM не всегда связывает куски воедино.

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

Режимы запроса

• Только локальные связи.
• Глобальный обзор по тематическим связям.
• Комбинация local + global (по умолчанию).
• Простой векторный поиск.
• Гибридный + наивный с переранжированием.
• Прямой запрос к LLM без RAG.

Как выполняется запрос (гибридный режим)

• Из запроса выделяются high-level (широкие темы) и low-level (конкретные сущности) ключевые слова.
• Векторный поиск: high-level ищет по вектору связей, low-level — по вектору узлов + один хоп по связям.
• Извлекаются свойства узлов и связей.
• Сортировка по rank (степень узла) и weight (сила связи).
• Достаются исходные чанки.
• LLM суммаризирует и формирует ответ.

Индексация: как строится граф

1. Извлечение сущностей и связей — LLM выделяет узлы и рёбра.
2. Профилирование — каждая сущность и связь описывается как пара ключ–значение.
3. Векторизация — значения преобразуются в эмбеддинги.
4. Хранение — граф и векторы сохраняются вместе, можно добавлять данные без полной переиндексации.

Описание(description) формируется у каждой сущности и связи с помощью LLM на основе чанков, из которых они были выделены. Главная сложность — качество входных данных: очистка, размер чанка и пересечение. Мусор на входе с высокой вероятностью даст мусор на выходе.

Преимущества перед GraphRAG

LightRAG в 30–40 раз дешевле на этапе индексации при сопоставимом качестве. Вместо обхода всего графа он строит релевантный подграф, что снижает нагрузку.

Результаты

Мы проиндексировали корпус документов, на которые векторный поиск не отвечал, и запустили LightRAG на тестовом стенде. Решение дало верные ответы на 74% таких вопросов, что принесло +12 п. п. к точности на полном бенчмарке.

Инфраструктурный вывод: ApeRAG

Развёртывание LightRAG требовало четырёх подов: графовая база, векторная база, MongoDB, API-сервер. Это неудобно. Мы нашли ApeRAG — DevOps-оптимизированная версия LightRAG, позволяющая использовать уже развёрнутые базы. Это значительно упрощает эксплуатацию.

Следующий шаг

Планируем запустить LightRAG на большем объёме данных и проверить гипотезу на production-трафике. Сейчас главный вызов — ускорение построения графа. На H100 с моделями Qwen3-30B и BAAI/bge-m3 индексация идёт со скоростью до 200 документов в час. Этого недостаточно — оптимизация стала приоритетом.

Три главных урока

1. Консультируйтесь с экспертами. Глубокие знания по графам и GraphRAG сэкономили нам минимум несколько недель.
2. Не гонитесь за красивыми числами. Большой граф впечатляет, но не всегда даёт прирост. Важно использовать реалистичную методику оценки.
3. Качество данных важнее архитектуры. Граф — усилитель. Хорошие данные дают хороший граф, мусор — мусор. Инвестиции в очистку окупаются быстрее, чем эксперименты с архитектурой.

Привет! Меня зовут Александр, я из Сбера. Ниже будет сказ про то, как мы творчески посмотрели на задачу улучшения качества поиска. Если вас не пугают термины вроде эмбеддинги, реранкеры, RAG и GraphRAG, то добро пожаловать под кат.

Зачем мы вообще занялись графами знаний

В основе поиска на некоторых поверхностях экосистемы (например, в ИИ-помощнике ГигаЧат, Сбербанк Онлайн) лежит система, под капотом которой — несколько источников с векторным поиском внутри каждого источника, либо с комбинацией векторного и полнотекстового поиска. Устройство поиска — тема отдельной (и не одной) статьи; в текущей я коснусь только ограничений векторного поиска и того, как может помочь граф.

Идея векторного поиска следующая: исходный текст (например, статья из интернета) превращают в вектор в многомерном пространстве, похожие тексты оказываются «рядом», при запросе находим ближайших соседей в этом же многомерном пространстве — вот и готов контекст для LLM, можно предметно отвечать на запрос пользователя, как это делает ГигаЧат.

Но у векторного поиска есть принципиальные ограничения.

1. Один вектор — один смысл.Каждый документ сжимается в единственный вектор фиксированной размерности. Один текст может быть релевантен десяткам разных запросов по разным причинам, но вектор усредняет все смыслы до одной точки пространства. При корпусе от 500 тыс. документов эмбеддинги начинают «сливаться»: размерности не хватает, чтобы различить все нюансы, и поиск начинает ошибаться в граничных случаях.Как помогает граф?Сущности и связи в графе не усредняются: каждый узел хранит точное текстовое описание, а рёбра явно кодируют тип отношения. Вместо «близости в пространстве» граф возвращает структурно точный контекст: не «похожий на запрос документ», а «конкретная сущность и её прямые связи».
2. Семантическое сходство ≠ релевантность.Векторный поиск возвращает то, что похоже по смыслу, а не то, что отвечает на вопрос. Для многошаговых и аналитических запросов («Почему X привело к Y?») наиболее близкий по косинусу чанк может не содержать ответа вовсе. Поиск при этом не сигнализирует о провале — он молча возвращает «лучшее из имеющегося» с высоким скором, даже если ответа в корпусе нет.Как помогает граф?Гибридный режим (вектор + граф) запускает параллельно два поиска. Граф проверяет, существует ли в корпусе структурный путь между сущностями запроса — это работает как фильтр уверенности. Если ни вектор, ни граф не нашли релевантного пути, то система может явно вернуть «не знаю» вместо галлюцинации.
3. Нет памяти о структуре и связях.Векторный поиск работает с независимыми чанками: он не знает, что сущность A в одном документе и сущность A в другом — это одно и то же, и что между ними существует цепочка отношений. Multi-hop вопросы («Кто руководил компанией, которую приобрела организация, финансирующая X?») векторный поиск не решает в принципе: ответ требует последовательного обхода трёх разных документов, а не близости к запросу.Как помогает граф?Он хранит связи между сущностями явно и согласованно. Retrieval-агент проходит по графу, собирая ответ по частям из разных источников. Там, где векторный поиск делает один запрос, графовый поиск может сделать направленный обход — и находит ответ, который в одном документе никогда не существовал.

В нашем распоряжении много данных (про устройство нашего петабайтного хранилища я рассказывал в другой статье) и ресурсов (GPU, платформаcloud.ru). В результате мы, почти как наши предшественники физики-экспериментаторы, выдвинули гипотезу: граф знаний как дополнительный источник контекста может улучшить качество ответов. Осталось дело за малым: построить качественный граф и «прикрутить» к поиску.

Для оценки качества используем подход llm-as-a-judge, при котором одна языковая модель выступает автоматическим оценщиком качества ответов другой модели по заданным критериям (точность, релевантность, полнота), заменяя дорогостоящую ручную разметку. В качестве основного бенчмарка взяли переведённый на русский язык SimpleQA — бенчмарк от OpenAI из 4326 коротких фактологических вопросов с однозначными верифицируемыми ответами.

Первый подход к снаряду: граф из готового дампа

Вдохновившись Google Knowledge Panel (это то, что отображается справа от поиска Google и под капотом которого находится Google Knowledge Graph) и различными докладами BigTech-компаний, в которых строят граф «всея», мы сначала пошли тем же путём: поискали релевантные нашим задачам источники и пришли к выбору проекта Yago в качестве основного графа, а также серии других источников для дополнения.

Yago — это один из крупнейших публичных графов знаний со 120 млн верифицированных фактов, построенный на основе Wikidata с жёсткой логической схемой типовschema.org. Граф покрывает большинство общих знаний о мире: люди, места, организации, события. Мы взяли готовый датасет Yago 4.5, позже научились обновлять данные с помощью кода преобразования Wikidata в Yago, выложенного на GitHub.

Основная причина использования этого графа — в структуре хранения. Структура данных Wikidata — триплеты с квалификаторами, а не факты: при работе агента получается четыре шага логики до извлечения факта (для интереса посмотрите, как устроена модель Statement-Qualifier внутри Wikidata). Для работы ИИ-агентов дополнительный вызов LLM критичен — это задержка и лишние токены.

Всё это сложили в Apache Jena Fuseki (графовую RDF-базу), сделали API поверх данных (кстати, с ходу написали на Go, потому что можем!), добавили ИИ-агента и вывели на одну из наших внутренних поверхностей. В результате получился аналог Google Knowledge Panel «на минималках»: можно зайти внутри контура компании, сделать запрос (например, «Кто такой Илон Маск») и получить карточку с фотографией и ключевыми характеристиками.

Как агент получает данные из графа

Работа агента разбита на пять этапов:

1. Выделение сущностей. LLM извлекает из запроса пользователя именованные сущности: людей, организации, топонимы, термины.
2. API Router. Сущность подставляется в заготовленный SPARQL- или Cypher-шаблон в зависимости от целевой базы. Подход защищает от ошибок кодогенерации, но ограничивает заранее прописанными сценариями.
3. Выполнение запроса. Графовая база обходит граф и возвращает релевантные узлы и связи.
4. Ранжирование. Результаты сортируются по рангу узла, весу рёбер и покрытию сущностей из запроса.
5. Суммаризация. LLM формирует финальный ответ на основе ранжированного контекста.

О базе данных

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

• Сценарий 1 — RAG (Retrieval-Augmented Generation):относительно малое время отклика и возможности графового поиска, важна целостность данных.
• Сценарий 2 — хранилище данных:большой объём данных по аналогии с Google Knowledge Graph, например для карточек сущностей (персон, локаций, произведений). Справедливости ради, в большинстве таких случаев графовые возможности не нужны, поэтому, теоретически, графовую базу здесь можно заменить на MongoDB или YT.

Исходя из этих сценариев, сформировался следующий шорт-лист:

Сценарий 1 — RAG:

• FalkorDB— MPP in-memory графовая база, активно развивает поддержку GraphRAG.
• Memgraph— in-memory single-node графовая база, оптимальна для быстрого чтения.

Сценарий 2 — хранилище:

• NebulaGraph— open-source база, применяется в Tencent, поддерживает шардирование и горизонтальное масштабирование.
• JanusGraph— фактически надстройка над Cassandra. Также поддерживает масштабирование.

Вначале взялиApache Jena Fuseki— далеко не самую популярную базу, но для быстрого старта и загрузки RDF-дампа графа Yago подошла идеально. Правда, ограничения её использования проявились практически сразу: когда мы начали собирать аналитику по хранимым данным и для этого кидать запросыcount(*), база уходила на десятки минут простоя.

Тестовый стенд, 13 экспериментов и 184 замера

Как только мы загрузили граф в базу и подключили агент, замерили качество на бенчмарке — сначала чистого графа, затем в связке с поиском, чтобы понять, есть ли прирост.

Методика тестирования, согласованная с командой поиска, выглядела так:

1. Поиск получает ответы от поисковых источников.
2. Мы добавляем к ним ответы от агента графа знаний.
3. Все ответы поступают на реранкер, где каждый источник получает скор релевантности.
4. Ответы ранжируются, собираются в единый список, из которого отбираются топ-5 по наибольшему скору релевантности запросу.
5. Эти пять финальных кандидатов передаются модели как контекст для формирования ответа.

Первичный замер показал: прироста на бенчмарках граф не даёт.Чтобы улучшить качество, мы набросали несколько гипотез, собрали тестовый стенд с быстрым подключением различных бенчмарков и версий агентов, и провели серию экспериментов.

Вот часть реализованных идей:

• Расширение покрытия графа дополнительными источниками.Добавили IMDB — постарались сделать максимально просто, через интеграцию на уровне API, а не базы данных: другими словами, мы параллельно отправляем запрос в разные базы. Агрегировать источники на уровне данных намеренно не стали, чтобы не решать задачу сопоставления сущностей из разных источников.
• Ранжирование извлечённых сущностей по релевантности. Простейший способ: по количеству связей у узла. Столкнулись с интересным случаем: на запрос, который содержал слово «Москва», база первой находила не город, а гостиницу «Москва» в Баку.
• Различные лимиты после ранжирования(сколько отсекаем после запроса в базу). Про поиск баланса между полнотой данных и размером контекста.
• Умный поиск на глубину 3. Обход графа на каждом уровне с контролем ветвления (берём не всех соседей, а только релевантных запросу). Кстати, это дало самый сильный прирост качества.
• Поиск в ширину на один или два уровня. Возврат найденного узла вместе с ближайшими соседями на один и два хопа.
• Использование подготовленных Cypher-шаблонов. Предзаданные паттерны запросов для типовых сценариев.
• Векторный поискпо эмбеддингам узлов и свойств графа (напомню, что начали мы с полнотекстового поиска).
• Встроенные графовые алгоритмы. Использование нативных графовых функций Memgraph. Например, если в запросе есть две сущности, то возвращаем маршрут между ними.

Итоги первого подхода

Прирост качества на ruSimpleQA составил+3 п. п.на агенте в изоляции — для нас это оказалось неожиданно мало. Рост совместного качества графа и поиска не вышел за пределы статистической погрешности. Предварительный вывод: граф на основе Yago не дал статистически значимого улучшения по сравнению с текущим векторным поиском.

Почему не сработало: наши гипотезы

Анализируя ошибки, мы пришли к нескольким выводам.

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

Готовый граф ≠ ваш тематика.Yago универсален, но «размыт»: тематическая специфика теряется в океане общих знаний. По большому счёту, нас, возможно, выручила бы интеграция данных на уровне графа, чтобы в нём было больше связей, причём из разных источников.

Агент накапливает ошибки.Каждый шаг трансформации в цепочке накапливает погрешность:

исходный запрос → выделение сущности → получение результатов из баз → агрегирование ответов из нескольких источников → суммаризация → ответ → оценка llm-as-a-judge

Второй подход к снаряду: LightRAG на собственных документах

Во втором подходе мы решили сменить парадигму. Во-первых, вместо построения универсального графа знаний попробовать построить граф прямо из наших документов (напомню, что рядом с нами — огромное хранилище с большим количеством данных). Во-вторых, найти «коробочное» решение с гибридным поиском и возможностью построения графа из текста. К слову, после отработки узкоспециализированного решения мы планируем собрать единое решение на основе первого и второго подходов, чтобы выжать максимум пользы из наших трудов.

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

Как работает LightRAG

LightRAG — это RAG-фреймворк на основе графов знаний, ключевым принципом которого являетсядвухуровневая система поиска (dual-level retrieval), объединяющая детальный локальный и широкий глобальный поиск.

Killer feature: чем LightRAG принципиально отличается от векторного поиска

В сравнении с графовым поиском у векторного поиска есть три системные проблемы:

• чанки слишком маленькие и теряют контекст;
• чанки разрозненны — достаются из совершенно разных документов;
• LLM пытается связать разрозненные куски, но не всегда справляется.

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

Режимы запроса

Только локальные связи и детали графа

Глобальный обзор через широкие тематические связи

Комбинация local + global (рекомендуется по умолчанию)

Простой векторный поиск без графа

Гибридный + наивный с переранжированием

Прямой запрос к LLM без RAG

Как выполняется запрос (на примере гибридного режима)

• Из запроса выделяются ключевые слова двух уровней:high-level— широкие концепции или темы;low-level— конкретные сущности или термины.
• Выполняется векторный поиск по обоим уровням:high-levelищет по вектору связей;low-levelищет по вектору нод, затем делает один хоп по ближайшим связям.
• Извлекаются свойства (properties) найденных нод и связей.
• Выполняется сортировка поrank(сумма степеней нод) иweight(сила связи, определяется LLM на этапе построения графа).
• Достаются чанки, из которых были выделены найденные ноды и связи.
• LLM суммаризирует чанки и формирует ответ.

Индексация: граф знаний + векторы

Перед поиском LightRAG за четыре этапа строит граф знаний из документов:

1. Извлечение сущностей и связей. LLM выделяет из текста узлы (люди, организации, концепции) и рёбра (связи между ними) с описаниями.
2. Профилирование (KV-структуры). Каждая сущность и связь описывается как пара ключ–значение с деталями.
3. Векторизация. Значения (V) из KV-пар преобразуются в эмбеддинги, обеспечивая более точный поиск, чем стандартный chunk-based RAG.
4. Хранение. Граф и векторы сохраняются совместно, что позволяет инкрементально добавлять новые данные без переиндексации всей базы.

Описание(description) формируется у каждой сущности и связи с помощью LLM на основе чанков, из которых они были выделены. Главная сложность заключается в качестве входных данных: очистке, размере чанка и величине пересечения между ними. Мусор на входе с высокой вероятностью даст мусор на выходе.

Преимущества над GraphRAG

Главное отличие от Microsoft GraphRAG — экономичность и скорость: LightRAG примерно в30–40 раз дешевлена этапе индексации данных при сопоставимом качестве ответов. Вместо сложного обхода всего графа LightRAG редуцирует граф до нужного минимума (релевантного подграфа), что снижает нагрузку.

Что получилось в результате

Мы взяли корпус документов (предварительно проанализировали, на какие именно вопросы продовый поиск не отвечает, и подобрали релевантные документы), проиндексировали их через LightRAG, подключили агент к LightRAG и прогнали на тестовом стенде на бенчмарках.

Результат:решение на LightRAG дало верные ответы на 74% вопросов из тех нескольких сотен вопросов, на которые не ответил поиск — и это дало +12 п. п. к точности ответов на полном бенчмарке из 4326 вопросов.

Кроме этого нам визуально понравилось то, что строит LightRAG (отдельно построили ещё несколько узкоспециализированных графов в качестве демонстрации).

Вывод про инфраструктуру: ApeRAG

После работы с несколькими экземплярами LightRAG мы прочувствовали, насколько это неудобно —четыре пода на каждый экземпляр: графовая база, векторная база, опционально MongoDB для хранения метаданных документов по обработке, сервер REST API сервер c пользовательским интерфейсом. Начали оборачивать всё в Helm-чарт — и нашли интересный проектApeRAG: по сути, LightRAG на DevOps-стероидах, с возможностью использовать уже развёрнутые базы. Ну блеск!

Следующий шаг

Планируем запустить LightRAG на большем количестве документов нашего хранилища и проверить гипотезу улучшения качества поиска уже на production-трафике. Если результаты подтвердятся, то расскажем в следующей статье.

Здесь перед командой во весь рост встаёт крайне интересный инженерный и продуктовый вызов:ускорение построения графа. На текущем сетапе с H100 используем следующие модели:

LLM (построение графа)

Qwen/Qwen3-30B-A3B-Instruct-2507-FP8

BAAI/bge-m3

BAAI/bge-reranker-v2-m3

Скорость индексации составиладо 200 документов в час(в зависимости от размера документа) — нас это не устраивает, и оптимизация стала следующим приоритетом.

Три главных урока

1. Консультируйтесь с экспертами в индустрии — не оставайтесь с проблемой один на один.Для решения задачи мы собрали сильную инженерную команду, но сразу ощутили нехватку глубоких знаний по графам и GraphRAG. В результате нашли эксперта, который помог двигаться быстрее. Этот урок стоил бы нам минимум несколько лишних недель, реши мы разбираться в одиночку.
2. Не гонитесь за красивыми числами на дашбордах.Большой готовый граф сразу показывает впечатляющие метрики, но это не всегда конвертируется в прирост на реальных бенчмарках. Важно с самого начала договориться об оценочной методике, максимально приближенной к промышленному сценарию использования.
3. Качество данных важнее архитектуры.Граф — это усилитель: хорошие данные на входе дают хорошие связи на выходе, мусорные — дают мусорный граф. Инвестиции в очистку и подготовку корпуса окупаются значительно быстрее, чем эксперименты с архитектурой поверх грязных нерелевантных данных.