Эволюция RAG: от локальных скриптов к графам знаний и бенчмаркам
Разработка систем поиска в текстовых базах знаний (RAG) часто воспринимается как процесс линейного внедрения. Однако реальные кейсы показывают, что путь к производительному решению — это серия адаптаций, начиная от экстренного использования Python для устранения критических дефектов в поддержке и заканчивая попытками создания собственных бенчмарков. История одного проекта на Хабре демонстрирует, как требования бизнеса трансформируют технический стек: от простых загрузчиков Markdown до сложных пайплайнов с графами знаний и гибридным ретривингом, написанных на Go.
# Эволюция RAG: от локальных скриптов к графам знаний и бенчмаркам
История развития систем поиска по текстовым базах знаний (Retrieval-Augmented Generation, или RAG) часто описывается в идеализированном ключе: «подключил модель, настроил векторное хранилище, запустил». Однако на практике создание надежной системы — это результат серии итераций, вынужденных компромиссов и постоянным давлением со стороны реальных бизнес-процессов. Пример одного проекта, описанного сообществом, иллюстрирует, как техническое решение трансформируется от простого инструмента поиска по файлам до многослойной архитектуры с графами знаний.
Экстренная фаза: RAG для решения критических дефектов
Все началось не с стратегического планирования, а с острой необходимости. Проект находился в процессе переезда в новое облачное окружение. Хотя операционная часть была успешно переведена, dev-среда, включая чаты, документацию и код, обновлялась постепенно. Остановка основной точки входа в мобильном приложении привела к тому, что поддержка получила нагрузку в три раза выше обычного и выявила девять критических дефектов.
Новый техлид и руководитель службы поддержки оказались в тупике. Традиционные методы поиска информации в разрозненных источниках (код, задачи, треды чатов, документация) не работали оперативно. Был принят прагматичный решение: написать экстренный инструмент на Python.
В течение часа была развернута система, которая собирала задачи, документацию и историю чатов в формате Markdown, складывая их рядом с исходным кодом. Используя доступный корпоративный AI-поставщик (версия Deepseek V4 Flash через OpenAI API), инженер за час проанализировал базу и выдал конкретные рекомендации по устранению дефектов, включая оценку сроков и список уже исправленных проблем. Это был классический кейс использования RAG «здесь и сейчас», когда цель — не идеальная архитектура, а оперативное решение проблемы бизнеса.
Графы знаний и чистка данных
После стабилизации ситуации фокус сместился на качество информации. Новая команда, новый CTO и процессы, требующие постоянных обновлений, привели к тому, что актуальная информация сосредоточилась в чатах, а формальная документация стала устаревать. Люди самоорганизовывались вокруг мессенджеров, делая их главным источником истины.
Автор проекта выбрал подход graphRAG (RAG на основе графов знаний). Подняв решение на базе LlamaIndex и ChromaDB поверх существующих Markdown-файлов, он столкнулся с проблемой «мусорного ввода»: база знаний засорялась устаревшей информацией («мертвые листья»). Было принято решение объявить чаты и код в продакшене единственным источником истины и запустить цикл их актуализации.
Техническая реализация эволюционировала следующим образом: * Гибридный поиск: На первом этапе использовалась комбинация BM25 (поиск по ключевым словам) и векторного поиска, что позволило точно выдавать нужные куски текста. * Граф рассуждений (Graph of Thoughts): На втором этапе внедрена схема, при которой вопрос декомпозируется на подзапросы. Система делает серию запросов к базе, а затем синтезирует полученные данные в единый ответ.
Этот подход оказался настолько эффективным, что за неделю автор был востребован 115 раз, так как система находила ответы на сложные вопросы по актуальному коду и задачам быстрее человека. К сожалению, дальнейшее развитие проекта прервано организационными факторами: запрос на пересмотр условий труда привел к блокировке перевода, а компания, осуществившая миграцию, не подтвердила ставку, что в итоге вылилось в сокращение сотрудника и отсутствие запуска системы как самостоятельного сервиса.
Открытый исходный код и переход на Go
Осознав, что Python как основной инструмент разработки может быть недостаточно масштабируемым для production-решений, автор принял решение написать систему с нуля на языке Go. Этот этап ознаменовался переходом к более продвинутым принципам архитектуры.
Для инференса (вывода ответов нейросети) был использован домашний кластер с картой NVIDIA RTX 4090 (24 Гб VRAM), где разместились модели Qwen 2.5 (38B, вероятно, имеется в виду опечатка в источнике, обычно 32B или 72B, но в тексте указано 27B/3.8, что соответствует Qwen2.5 32B) и соответствующий эмбердер. Помимо графRAG и гибридного поиска, в систему были интегрированы: * Temporal-awareness: учет временных меток для понимания контекста изменений. * LogicRAG: схемы рассуждений, требующие логической цепочки вывода.
Эта версия системы была оптимизирована для работы на домашнем железе, демонстрируя возможность создания мощных инструментов RAG без использования дорогих облачных сервисов.
Проблемы бенчмаркирования и будущие вызовы
Потеряв прямой доступ к исходному контенту для тестирования, автор начал поиск в экосистеме open-source. Анализ существующих решений выявил ряд проблем: 1. LeonAI: Продукт находится на стадии миграции на агентные системы и не имел должной документации. Проведенный синтетический тест показал низкую текучесть (скорость выдачи ответов) системы. 2. DRAGON: Бенчмарк на новостном корпусе, который не обновляется уже полгода. Прохождение этого теста показало 80.3% точности, но автор считает пример сборника вопросов адекватным только для демонстрации подходов к тестированию, а не для реальных замеров. 3. RUMBA: Система, не подходящая по типологии задач. 4. EnterpriseRAG-Bench: Реалистичный бенчмарк из 500 тысяч документов (чаты, доки, задачи, код). Однако для запуска такого теста на локальном оборудовании потребовался бы год времени.
Автор проекта также обратил внимание на отсутствие общепринятых подходов к тестированию таких систем в русскоязычном сегменте и инициировал диалог в Альянсе ИИ и среди разработчиков бенчмарков, получив лишь молчаливый ответ. В условиях анонса Яндексом решения «Алиса AI для бизнеса» (сентябрь), которое также забирает данные из разнородных систем, автор вынужден приостановить работу над проектом из-за нехватки ресурсов для глубокого тестирования.
Проект остается открытым для сообщества под адресом https://github.com/alterfo/kb, приглашая разработчиков к созданию национальной базы знаний с открытым исходным кодом.
Технические пояснения * GraphRAG: Методика, при которой информация из документов структурируется в виде графа сущностей и связей, а запросы обрабатываются с учетом этих связей, что повышает качество ответов на сложные вопросы. * Hybrid Search (Гибридный поиск): Сочетание двух методов поиска — векторного (по смыслу/эмбердингу) и.keyword-based (по точному совпадению слов, например, BM25), что позволяет находить информацию даже при неидеальном формулировании запроса. * Temporal-awareness: Способность системы учитывать время возникновения событий или изменений в документах, чтобы давать ответы, релевантные текущему моменту или конкретному периоду.
Заключение
История этого проекта показывает, что создание RAG-системы — это не разовая задача, а процесс постоянного балансирования между требованиями бизнеса, доступными ресурсами и качеством данных. От временных скриптов до попыток создания новых стандартов тестирования, разработчики сталкиваются с рядом вызовов, для решения которых пока не существует единых стандартов в индустрии.
Система, реализованная автором на Go, демонстрирует потенциал децентрализованных решений и возможность использования мощных локальных моделей. Однако настоящий прорыв может произойти только при появлении общепринятых бенчмарков и консолидации усилий сообщества по созданию качественных наборов данных для обучения и тестирования.