Graph RAG и «Гарри Поттер»

На новогодних праздниках у меня появился доступ к внешней H100. Пройти мимо такого подарка я не мог, поэтому взялся экспериментировать


На горизонте маячил проект рага со сложными вопросами и сотнями документов (к слову, решили мы этот кейс без графового рага), поэтому хотелось проверить “продвинутый” подход.


Когда я изучил библиотеку от Microsoft , то понял, что на работе что-то подобное мы уже делали.


Если на пальцах, то идея в следующем:


⚪️ Давайте каждый чанк пропустим через LLM
⚪️ Выделим сущности (а также их описание)
⚪️ Выделим отношения между сущностями (а также проставим силу связи между сущностями, это пусть тоже делает LLM)


Вот и готово! По сути у нас есть узлы, ребра, и даже сила связей. Построим граф, и будем по нему искать контекст.


Я думал, что будет работать из коробки, но не тут то было. 3 дня я потратил, чтобы завести графовый раг на банковском документе, скачанном из интернета. Но возникла другая проблема - я не знал, как оценить работу. Поэтому я выбрал книгу о Гарри Поттере. Пришлось даже отойти от графового рага и сделать temporal rag (проблема была в том, что классический графовый раг не учитывает временную компоненту == развитие сюжета).


В итоге, я тестировал подходы, подавая простые и сложные многокомпонентные вопросы. Например, я просил перечислить всех учителей Хогвартса и их предметы. Или перечислить все испытания, которые проходили ученики на пути к философскому камню.


Какие выводы я сделал:


⚪️ Графовый раг - концепция хорошая. Она позволяет искать контекст по всем документам, выделять только нужные сущности и отношения. Также зачастую не упускает мелкие важные детали.


⚪️ Сам граф очень сложно готовить:


🔴 Первая причина - LLM. Если модель слабая и часто галлюцинирует, то граф конечно же развалится. Например, модель одни и те же сущности называет по-разному (в моем случае qwen 3 30b), что только мешает построить граф.
🔴 Вторая причина - количество запросов к LLM. Представьте, что через LLM нужно пропустить все чанки. Это тысячи запросов к языковой модели. Построение индекса довольно долгое (хоть я и запускал в 8 потоков).
🔴 Третья причина - узлы с огромным количеством связей. Представьте, что весь документ про кредит. В итоговом графе у сущности “кредит” будет очень много связей. Это означает, что граф нужно будет преобразовать, перед тем как в нем искать.


Выбрал бы я такой подход для прода? Если данные изначально более менее структурированные и не представляют из себя подобие графа, то нет. Мои эксперименты показали, что классический раг уже хорошо справляется с задачей. А затраты на подготовку графового подхода просто несоизмеримы по сравнению с классическим рагом.


Я бы выбрал что-то среднее, например agentic rag или self rag.


Красивые слайды и примеры можно посмотреть здесь.