От простого RAG‑бота к многослойному пайплайну с графом знаний
В статье автор делится реальным опытом построения RAG‑системы: от скрипта‑парсера markdown до гибридного ретрива, графа знаний и адаптивных рассуждений.
В статье «История развития RAG на примере одного проекта» автор рассказывает о том, как в течение полугода трансформировал простую RAG‑систему, изначально представлявшую собой скрипт, который «лазил» по markdown‑файлам, в сложный пайплайн с графом знаний, гибридным ретривом и адаптивной схемой рассуждений.
Этап 1 – прототип на LangChain. Первоначальная версия использовала LangChain для цепочки «чтение‑вектор‑поиск‑генерация». Поиск осуществлялся только по векторным эмбеддингам, а контекст формировался из первых N‑текстовых фрагментов. Система быстро «заполнялась» шумом и теряла релевантность.
Этап 2 – гибридный ретрив. Чтобы улучшить точность, автор внедрил гибридный поиск: сочетание BM25‑поиска по оригинальному тексту и ANN‑поиска по эмбеддингам (FAISS). Это позволило сократить среднюю ошибку ранжирования с 0.68 до 0.42 и увеличить показатель R‑Precision на 15 %.
Этап 3 – граф знаний. Дальнейшее масштабирование потребовало структурировать связи между сущностями. Был построен граф на Neo4j, в который импортировались триплеты (субъект‑отношение‑объект) из всех документов. Граф использовался для «дополнительного контекста» при генерации ответов, что повысило точность фактической информации до 92 % в тестах QA.
Этап 4 – адаптивные рассуждения. На последнем этапе автор добавил модуль «модель‑модератор», который в реальном времени выбирает, какой тип ретрива (векторный, BM25 или граф) использовать в зависимости от типа вопроса. Это привело к снижению среднего времени отклика с 3.2 с до 1.8 с без потери качества.
Почему пришлось писать с нуля? Существующие решения (например, готовые LangChain‑агенты) не позволяли гибко комбинировать несколько ретрив‑стратегий и интегрировать графовые запросы без значительных компромиссов в производительности. Переписывание кода дало полную контроль над архитектурой и позволило оптимизировать каждый слой под конкретные требования проекта.
Статья заканчивается выводами о важности модульности, тестирования на реальных запросах и необходимости мониторинга качества в продакшене.
Для разработчиков RAG‑систем это реальный пример того, как от простого прототипа можно перейти к масштабируемой архитектуре, объединяя векторный и графовый поиск. Главное – не бояться отказываться от «готовых» библиотек, если они ограничивают гибкость, и инвестировать в модульный дизайн, который легко адаптировать под новые типы запросов.
