Традиционный vs. Графовый RAG: понятное объяснение
Представьте, что у вас есть длинный документ, например, биография человека (X), где каждая глава посвящена одному из его достижений.
Например:
↳ Глава 1: Описывает Достижение-1.
↳ Глава 2: Описывает Достижение-2.
...
↳ Глава 10: Описывает Достижение-10.
Теперь внимательно разберём следующий момент
Допустим, вы создали традиционный RAG (Retrieval-Augmented Generation) на основе этого документа и хотите суммировать все достижения X.
Сделать это с помощью традиционного поиска может быть сложно, так как для полноценного ответа нужен весь контекст...
...но при этом вы, скорее всего, извлекаете только топ-k наиболее релевантных фрагментов из векторной базы данных.
Кроме того, традиционные RAG-системы извлекают каждый фрагмент отдельно, и LLM вынужден самостоятельно восстанавливать связи между этими частями (если они вообще были найдены).
— Графовый RAG решает эту проблему
Основная идея заключается в том, чтобы сначала создать граф (сущности и их связи) из документов, а затем выполнять обход этого графа на этапе извлечения информации.
Как Graph RAG устраняет проблемы традиционного подхода:
1. Генерация графа
🔸 LLM анализирует биографию и строит граф, выявляя сущности и связи между ними.
🔸 В результате получается полноценный граф, а его подграф, связанный с достижениями X, будет выглядеть так:
↳ X → <достиг> → Достижение-1.
↳ X → <достиг> → Достижение-2.
...
↳ X → <достиг> → Достижение-N.
2. Поиск по графу
🔸 На этапе извлечения информации система выполняет обход графа, собирая все релевантные данные о достижениях X.
🔸 Полученный контекст передаётся LLM, что позволяет сформировать логичный, полный и связный ответ, в отличие от традиционного RAG.
— Почему Graph RAG так эффективен?
😫 Структурированные данные — LLM лучше работает с четко организованной информацией.
😫 Более полный контекст — система получает всю нужную информацию, а не только разрозненные куски.
😫 Глубокая связь между сущностями — связи между фактами сохраняются и используются при генерации ответа.
👉 @DataSciencegx
Представьте, что у вас есть длинный документ, например, биография человека (X), где каждая глава посвящена одному из его достижений.
Например:
↳ Глава 1: Описывает Достижение-1.
↳ Глава 2: Описывает Достижение-2.
...
↳ Глава 10: Описывает Достижение-10.
Теперь внимательно разберём следующий момент
Допустим, вы создали традиционный RAG (Retrieval-Augmented Generation) на основе этого документа и хотите суммировать все достижения X.
Сделать это с помощью традиционного поиска может быть сложно, так как для полноценного ответа нужен весь контекст...
...но при этом вы, скорее всего, извлекаете только топ-k наиболее релевантных фрагментов из векторной базы данных.
Кроме того, традиционные RAG-системы извлекают каждый фрагмент отдельно, и LLM вынужден самостоятельно восстанавливать связи между этими частями (если они вообще были найдены).
— Графовый RAG решает эту проблему
Основная идея заключается в том, чтобы сначала создать граф (сущности и их связи) из документов, а затем выполнять обход этого графа на этапе извлечения информации.
Как Graph RAG устраняет проблемы традиционного подхода:
1. Генерация графа
↳ X → <достиг> → Достижение-1.
↳ X → <достиг> → Достижение-2.
...
↳ X → <достиг> → Достижение-N.
2. Поиск по графу
— Почему Graph RAG так эффективен?