Sber: grafo de conhecimento Yago quase não ajudou a busca, enquanto LightRAG agregou 12 p.p. de precisão

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

Почему граф не взлетел В основе поиска на части сервисов

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

Для проверки взяли переведённый на русский SimpleQA от OpenAI на 4326 фактологических вопросах и использовали схему llm-as-a-judge для автоматической оценки. Первый прототип строили на Yago 4.5, одном из крупнейших открытых графов знаний, который загрузили в Apache Jena Fuseki, а поверх данных подняли API и агента.

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

13 экспериментов подряд

После первых замеров команда собрала отдельный тестовый стенд и прогнала 13 экспериментов с 184 измерениями. Сначала проверяли чистый граф, затем связку графа с обычным поиском через реранкер, который собирал единый топ кандидатов для ответа. Базовый вывод оказался неприятным: на ruSimpleQA граф в изоляции дал только +3 п.п., а вместе с действующим поиском результат не вышел за пределы статистической погрешности.

• Подключили дополнительные источники, включая IMDB, но без сложной агрегации данных на уровне базы Пробовали ранжировать сущности по релевантности, например по числу связей у узла Меняли лимиты после ранжирования, чтобы балансировать полноту контекста и его размер Тестировали умный обход графа на глубину до трёх уровней и поиск в ширину на один-два хопа Добавляли векторный поиск по эмбеддингам узлов и графовые алгоритмы вроде поиска маршрута между сущностями Проблемы были не только в инфраструктуре, но и в природе самого графа. Для эмбеддингов приходилось использовать короткие и бедные описания сущностей, из-за чего векторный поиск по графу сам работал нестабильно. Yago оказался слишком универсальным: он хорошо покрывает мир в целом, но плохо отражает конкретную тематику и связи, важные для реальных пользовательских запросов. Плюс каждый шаг агентной цепочки добавлял новую погрешность — от извлечения сущности до финальной суммаризации.

Поворот к

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

«Мусор на входе с высокой вероятностью даст мусор на выходе.»

Сбер проиндексировал через LightRAG корпус документов, подобранный под те вопросы, на которые продовый поиск не отвечал, и снова прогнал бенчмарки. Здесь эффект оказался уже заметным: LightRAG дал верные ответы на 74% из нескольких сотен ранее непокрытых вопросов и прибавил 12 п.п. к точности на полном наборе из 4326 запросов. Отдельный плюс — экономичность: в статье говорится, что LightRAG примерно в 30–40 раз дешевле Microsoft GraphRAG на этапе индексации при сопоставимом качестве. Следующий шаг — проверка на production-трафике и ускорение индексации, которая пока упирается примерно в 200 документов в час даже на H100.

Что это значит

История Сбера показывает простую вещь: сам по себе большой граф знаний ещё не делает поиск умнее. Гораздо важнее, насколько граф привязан к твоему домену, как он связан с векторным поиском и на каких реальных провалах ты его измеряешь. Для команд, которые строят RAG-поиск, это хороший сигнал не гнаться за красивой демкой с публичным графом, а вкладываться в качественный корпус, гибридный retrieval и честную оценку на живых сценариях.