NLP Wanderer

Немного про подходы к RAG: GraphRAG

Одна из самых для меня интересных тем это различные RAG архитектуры и техники. Недавно было создано немалое их количество. На мой взгляд, среди самых значимых:
- Разные способы нарезки чанков (посимвольный, семантический, структурный, ...)
- Извлечение всяческой метадаты из них и автоматический ретривал по ней
- Иерархический автомерджинг чанков
- Умное сжатие найденой информации (контекутальная компрессия)
- Всевозможные способы переписывания запроса (HyDE, Multi-Query, ...)
- Рекурсивный ретривал (с суммаризацией или агентами)
- Гибридные поиски с BM или colbert
- Саморефлексирующиеся системы
- И наконец даже end2end тренировка

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

Сам GraphRAG глобально можно разделить на фазу подготовки данных и на фазу инференса запросов и все это в несколько этапов:

1. Дробим входные документы, разбив текста на чанки по (300-1200 символов)
2. С помошью LLM извлекаем из текстов триплеты (entity, entity, тип relationship), а также "claims" - дополнительные факты из текста (но тут я этот момент опущу)
3. Сохраняем их в графовую базу со всякой сопуствующей метадатой, например Neo4j, получив общий граф знаний всех наших чанков и документов.
4. Выделяем сообщества внутри общего графа, с помошью Hierarchical Leiden Algorithm
5. Для каждого сообщества создаем так называемые Community Reports с помошью той же LLM, а также их суммаризации для упрощения, так же делаются текстовые эмбединги этих суммаризацией
6. Дополнительно для каждого документа текста тоже создается эмбединг путем усреднения текстовых эмбедингов его чанков.

Дальше инференс (он немного отличается для Local и Global поиска, но логика почти одинаковая):
7. Имея запрос, выделяем из него сущности с помощью LLM, находим их в графовой бд и соотвествующие им Community Reports, описание связей и сами текста чанков.
8. Имея всю эту информацию + историю общения, фильтруем все найденое с помошью еще одного LLM запроса на релевантность и только после этого всю сводную информацию отправляем снова в LLM для финального ответа.

Если проанализировать, то основной целью всех этапов было максимизировать этап предобработки документов, используя мощь быстрых LLM, который обычно в RAG представлял из себя только нарезку, чистку и превращение в эмбединги.

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

Теперь моя субъективная оценка: Глобально, мы видим развитие идей суммаризации информации и построение chunk-chunk связей, тогда как обычный RAG работает в основном с query-chunk связями. На мой взгляд, авторы молодцы, но очень сильно перестарались, и получилось крайне много полаганий на работу LLM, она очень часто вызывается даже на этапе инференса, что во многих реальных приложениях просто недопустимо да и конечно будет очень часто подводить. Я же не рекомендую тащить такие штуки в прод, а лишь лучше изучить применение контекстуальной компрессии и извлечения фактов и связей из документов с помошью LLM на этапе предобработки данных и конечно же посмотреть на код, статью и блогпост.

www.group-telegram.com/kr/nlpwanderer.com/54

2.3K viewsedited  Aug 29, 2024 at 06:02

Немного про подходы к RAG: GraphRAG

Одна из самых для меня интересных тем это различные RAG архитектуры и техники. Недавно было создано немалое их количество. На мой взгляд, среди самых значимых:
- Разные способы нарезки чанков (посимвольный, семантический, структурный, ...)
- Извлечение всяческой метадаты из них и автоматический ретривал по ней
- Иерархический автомерджинг чанков
- Умное сжатие найденой информации (контекутальная компрессия)
- Всевозможные способы переписывания запроса (HyDE, Multi-Query, ...)
- Рекурсивный ретривал (с суммаризацией или агентами)
- Гибридные поиски с BM или colbert
- Саморефлексирующиеся системы
- И наконец даже end2end тренировка

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

Сам GraphRAG глобально можно разделить на фазу подготовки данных и на фазу инференса запросов и все это в несколько этапов:

1. Дробим входные документы, разбив текста на чанки по (300-1200 символов)
2. С помошью LLM извлекаем из текстов триплеты (entity, entity, тип relationship), а также "claims" - дополнительные факты из текста (но тут я этот момент опущу)
3. Сохраняем их в графовую базу со всякой сопуствующей метадатой, например Neo4j, получив общий граф знаний всех наших чанков и документов.
4. Выделяем сообщества внутри общего графа, с помошью Hierarchical Leiden Algorithm
5. Для каждого сообщества создаем так называемые Community Reports с помошью той же LLM, а также их суммаризации для упрощения, так же делаются текстовые эмбединги этих суммаризацией
6. Дополнительно для каждого документа текста тоже создается эмбединг путем усреднения текстовых эмбедингов его чанков.

Дальше инференс (он немного отличается для Local и Global поиска, но логика почти одинаковая):
7. Имея запрос, выделяем из него сущности с помощью LLM, находим их в графовой бд и соотвествующие им Community Reports, описание связей и сами текста чанков.
8. Имея всю эту информацию + историю общения, фильтруем все найденое с помошью еще одного LLM запроса на релевантность и только после этого всю сводную информацию отправляем снова в LLM для финального ответа.

Если проанализировать, то основной целью всех этапов было максимизировать этап предобработки документов, используя мощь быстрых LLM, который обычно в RAG представлял из себя только нарезку, чистку и превращение в эмбединги.

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

Теперь моя субъективная оценка: Глобально, мы видим развитие идей суммаризации информации и построение chunk-chunk связей, тогда как обычный RAG работает в основном с query-chunk связями. На мой взгляд, авторы молодцы, но очень сильно перестарались, и получилось крайне много полаганий на работу LLM, она очень часто вызывается даже на этапе инференса, что во многих реальных приложениях просто недопустимо да и конечно будет очень часто подводить. Я же не рекомендую тащить такие штуки в прод, а лишь лучше изучить применение контекстуальной компрессии и извлечения фактов и связей из документов с помошью LLM на этапе предобработки данных и конечно же посмотреть на код, статью и блогпост.

BY NLP Wanderer