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

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

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

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

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

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

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

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

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

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

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

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

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

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

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