Как я построил Graph RAG систему с точностью 96.7% за 5 дней: от научных статей до production-ready пайплайна

[ZanZy]

1) не нашёл где сказано насколько велик объём базы знаний. А от этого многое зависит.

2) Вопросах о связях: "Как метод X связан с компонентом Y?" — ответ разбросан по разным чанкам

ну разбросан по разным чанкам, и что? если передать БЯМ все нужные чанки, ей не хватит "ума" с ними построить ответ?

[holodoz]

RRF хорош для combining разных сигналов, но когда оба сигнала — embedding-based, прямое cosine similarity точнее.

Очень интересные details, спасибо за article

[cmyser]

Хотелось бы такое же но чисто полностью веб решение, это возможно ?

[Fardeadok]

Вы тестировали точность на документах из папки data? Это текстовые размеченные файлы размером 20 строк и 50? Это на них точность 96% ?

[iva2000]

Очень интересно, спасибо!

Сколько страниц PDF было в базе? Все хорошие, то есть "рождённые в цифре"?

Сколько миллионов токенов стоила обработка базы? Сколько это получается в деньгах на вашей модели? У вас было 14 итераций, значит вы заплатили x14? Будет ли результат лучше, если за примерно те же деньги использовать GLM-5?

Думали ли вы о визуализации вашей базы? Хотя бы какой-то?

В чем для конечного пользователя отличие вашей системы от notebooklm? Чем notebooklm хуже и в чем лучше?

[aladkoi]

У меня все документы готовил opus 4.6 и по деньгам вышло не сильно много. Он исследовал огромную систему продаж , используя документацию по среде разработке , что по итогу дало 1500 страниц технической документации вместе с отдельными картинками. В самой rag в качестве llm используется gjm5. Для создания эмбидингов и reranker вполне хватило локальных моделей.

[aladkoi]

Я свою rag строил на onyx. Все документы были предварительно очищены от шумов и классифицированы по разным атрибутам и содержимому в них. В rag храниться документация на классы, методы, их исходный код, хранятся все связи между ними, различные описания. Сами документы готовил опус и строил в onyx их полученную архитектуру . Теперь rag без проблем, например, может видеть любые документы и сравнивать их, видит, например, "одинаковые" с виду отчеты, но может по "полкам" разложить из чего они состоят и чем отличаются. Во всем этом самое важное правильно подготовить сами документы перед загрузкой в rag систему и правильно создать в ней связи между ними. Я пробовал делать на neo4j, мне не понравилось. В onyx можно создать много агентов под разные задачи и знания, и распределить доступ по пользователям. В качестве СУБД использую postgresql. Как и в neo4j, у меня используются графы между связанными документами. Время начального поиска информации в такой rag составляет в среднем 2 секунды, больше времени уходит на обработку ее llm для получения "красивой" картинки.