Обычный RAG хорошо решает поиск близких фрагментов текста, но плохо держит связи между сущностями, документами и шагами рассуждения. Поэтому в инженерной практике все чаще строят не только векторный индекс, но и структурированный слой знаний: граф сущностей, граф чанков, онтологию домена или гибрид этих представлений. Этот сдвиг не отменяет классический RAG [Lew20]. Он добавляет к нему явную память о связях, типах и путях, что особенно важно для многошаговых запросов, обзорных вопросов по корпусу и доменных систем, где важны точность и трассируемость [Edg24, Gut24, Zhu25, Wu25].
Литература показывает, что GraphRAG не является одной техникой. Это семейство систем с разными инженерными целями. Одни строят граф поверх самих документов и чанков, чтобы улучшить навигацию по корпусу [Edg24, Guo24, Zhu25, Xia24]. Другие подключают внешний граф знаний или доменную онтологию, чтобы опереться на уже нормализованные сущности и отношения [Wu25, Men24]. Третьи делают гибридный слой, где граф используется не вместо векторного поиска, а вместе с ним [Sar24, Lee24, Min25].
- Граф дает наибольшую пользу там, где запрос требует пройти по нескольким связям, собрать ответ из нескольких документов или удержать структуру предметной области [Sun18, Sun19, Gut24, Xia25].
- Для простых factoid запросов и коротких локальных ответов чистый векторный RAG часто дешевле и не хуже по качеству. Графовый слой оправдан не всегда [Xia25, Han25].
- На практике лучше всего работают гибридные схемы. Сначала семантический поиск находит стартовые узлы или чанки, затем граф расширяет и упорядочивает контекст [Zhu25, Sar24, Lee24, Wu25].
- Самое слабое место GraphRAG не retrieval, а construction. Если сущности плохо склеены, отношения шумные, а схема расплывчата, то граф лишь формализует ошибки [Sa16, Don14, Ao21, Mih23].
- Онтология особенно полезна в узких доменах. Она задает типы сущностей, допустимые отношения и ограничения, тем самым снижая шум и галлюцинации при построении графа [Wim10, Ana13, Men24, Mih23].
- Главный инженерный trade off состоит не между графом и векторами, а между качеством структуры и стоимостью ее поддержки. Последние работы показывают, что умеренно сложные графы и классические NLP методы нередко дают почти ту же пользу, что и дорогая LLM экстракция [Guo24, Min25].
| Класс подхода | Как устроен | Сильные стороны | Слабые стороны |
|---|---|---|---|
| Граф по корпусу и чанкам | Из документов извлекаются сущности, связи, иерархия и соседство чанков. Поиск идет по локальным и глобальным структурам [Edg24, Guo24, Xia24] | Хорошо собирает разрозненный контекст. Удобен для обзорных и многошаговых запросов | Качество сильно зависит от chunking и entity linking. Индекс быстро усложняется |
| KG-guided retrieval | Векторный поиск дает seed chunks, затем граф расширяет и упорядочивает контекст [Zhu25, Che24b] | Хороший баланс между recall и связностью ответа. Легко встроить в существующий RAG | Нужна аккуратная настройка расширения, иначе растет шум и токены |
| Внешний граф знаний как второй источник | Система использует готовый KG вместе с текстовым корпусом [Wu25, Xu22, Sun18] | Нормализованные сущности, явные отношения, интерпретируемость | Внешний KG может быть неполным, устаревшим или плохо состыкованным с корпусом |
| Гибридный Graph плюс Vector RAG | Отдельные каналы поиска по тексту и по графу объединяются на этапе rerank или fusion [Sar24, Lee24, Min25] | Лучшее практическое соотношение пользы и риска. Устойчив к неполноте любого одного источника | Больше компонентов, сложнее отладка, труднее понять вклад каждого слоя |
| Онтологически управляемое построение KG | Онтология задает типы, отношения и ограничения для извлечения знаний [Men24, Wim10, Mih23] | Высокая точность в домене. Лучше контроль качества и согласованность | Дорого проектировать и поддерживать. Сложно масштабировать на открытый домен |
| Query layer через графовые запросы | Вопрос переводится в подграф, SPARQL или иной структурный запрос, затем ответ дополняется генерацией [Yih15, Ban23] | Максимальная точность при хорошо заданной схеме. Сильная трассируемость | Хрупкость к формулировкам пользователя. Высокая цена подготовки схемы и линковки |
До LLM эпохи основная задача была такой: как совместить неполный knowledge base и неструктурированный текст для QA. Классические работы показали, что лучший ответ часто требует обоих источников сразу, а retrieval должен строить question-specific subgraph, а не просто список документов [Sun18, Sun19]. В параллель развивались системы knowledge base construction, где ключевыми были probabilistic fusion, извлечение из шума и контроль качества [Don14, Sa16].
Современный GraphRAG унаследовал оба направления. От QA над графами он взял идею многошагового поиска по структуре. От knowledge base construction он взял проблему качества фактов и canonicalization. Новое в LLM эпохе состоит в том, что граф теперь нужен не только для точного ответа, но и для сборки хорошего контекста для генератора [Edg24, Gut24, Zhu25].
Самый устойчивый паттерн в работах таков: семантический retriever быстро находит кандидатов, после чего графовый слой расширяет контекст по связям, ранжирует пути и убирает фрагментацию знаний [Zhu25, Sar24, Lee24]. Это лучше, чем пытаться заменить dense retrieval чистым обходом графа. Граф полезен как структурный корректор, а не как единственный источник релевантности.
Хорошие системы индексируют не один объект, а несколько уровней сразу: сущности, отношения, chunks, документы, сообщества сущностей. KG-Retriever строит иерархический индекс графа и документов [Che24b]. GraphRAG и LightRAG используют не только локальные связи, но и более крупные единицы вроде community summaries или dual-level retrieval [Edg24, Guo24]. Это снижает разрыв между локальным фактом и глобальной темой.
В сильных работах граф используется не только для отбора, но и для сборки итогового контекста. KG$^2$RAG показывает, что важен не просто retrieval соседних узлов, но и организация чанков в связный порядок [Zhu25]. TKG-RAG делает то же на уровне chunk graph и за счет этого снижает шум и число токенов [Xia24].
Практический барьер GraphRAG состоит в цене построения и обновления графа. Поэтому особенно важны работы, где показывается, что dependency parsing, rules и простая fusion логика могут приблизиться к дорогой LLM экстракции [Min25]. Это важный сигнал для продакшна: полный LLM-first pipeline не всегда нужен.
Если система работает в финансах, медицине, промышленности или enterprise knowledge base, выигрыш дает не самый большой граф, а самый дисциплинированный. Онтология задает разрешенные типы и отношения, а значит уменьшает ложные ребра и делает retrieval более управляемым [Wim10, Men24]. Text2KGBench особенно ценен тем, что оценивает не только полноту извлечения, но и соответствие онтологии и уровень галлюцинаций [Mih23].
| Тип системы | Где сильна | Где слаба |
|---|---|---|
| Chunk graph и document graph | Корпусные QA, обзорные вопросы, поиск по связанным документам [Edg24, Guo24] | Сложно поддерживать чистую сущностную нормализацию |
| External KG plus text | Доменные ассистенты, где есть готовый справочник сущностей [Wu25, Sun18] | Интеграция с текстом и покрытие внешнего KG часто ограничены |
| Ontology-first KG | Регулируемые и узкие домены, где важны типы и ограничения [Men24, Mih23] | Высокий входной порог и медленное расширение схемы |
| Graph-only retrieval | Многошаговая логика и path reasoning [Gut24, Li24] | Хуже стартует, если вопрос выражен не через сущности, а через свободный текст |
| Hybrid Graph plus Vector | Наиболее универсальный продакшн выбор [Sar24, Lee24, Min25] | Архитектурно сложнее, требуется tuning fusion и observability |
- Ошибки entity linking и deduplication. Если одна сущность распадается на несколько узлов, граф теряет смысл.
- Ложные отношения, извлеченные из слабого prompt или шумного OpenIE, быстро портят traversal и reranking [Mar18, Jar23].
- Слишком агрессивное graph expansion увеличивает токены и снижает точность.
- Слишком жесткая онтология тормозит ingestion новых типов данных.
- Отсутствие оценки по слоям скрывает проблему. Нужно измерять отдельно качество extraction, linking, retrieval и final answer [Mih23, Xia25].
Для инженерного проектирования область удобно свести к трем сценариям.
- Если корпус в основном текстовый, а вопросы локальные, достаточно обычного RAG с хорошим rerank.
- Если важны междокументные связи, обзорные ответы и multi hop reasoning, нужен graph over chunks or entities [Edg24, Gut24, Zhu25].
- Если домен узкий, цена ошибки высока и есть стабильная терминология, стоит строить ontology-guided KG и затем добавлять гибридный retrieval [Men24, Sar24, Wu25].
На сегодня наиболее зрелый вывод литературы прост: не стоит противопоставлять GraphRAG и RAG. Графовый слой приносит пользу не сам по себе, а когда он компенсирует конкретую слабость текстового retrieval: разрыв связей между фактами, потерю глобальной структуры или потребность в типизированном доменном знании [Xia25, Han25]. Поэтому лучший практический дизайн обычно не graph-only, а hybrid-by-default.
GraphRAG и KG-RAG следует понимать как инженерный способ добавить в RAG явную структуру памяти. Самые сильные результаты дают системы, которые строят умеренно качественный граф, соединяют его с векторным поиском и используют структуру для расширения, сжатия и упорядочивания контекста [Zhu25, Sar24, Lee24, Min25]. Самые слабые результаты возникают там, где граф строится ради самого графа, без контроля качества сущностей, схемы и стоимости обновления [Sa16, Don14, Xia25].
Для практики это означает следующее. Граф знаний и онтология оправданы не как модный индекс, а как средство сделать retrieval более связным, объяснимым и доменно дисциплинированным. Если задача требует именно этого, структурно-семантический RAG дает заметный выигрыш. Если нет, то простой RAG остается более дешевым и часто достаточным решением [Lew20, Xia25].