В индустрии разработки корпоративных решений всё чаще обсуждают практические примеры внедрения RAG-систем, и один из таких кейсов был недавно представлен автором проекта на GitHub. Разработчик, выступающий под псевдонимом alterfo, описал эволюцию собственной системы, которая начиналась как инструмент для поиска по документации и код-базе, а в итоге превратилась в сложный конвейер с гибридным поиском, графом знаний и механизмом логических рассуждений. Толчком к созданию системы послужила реальная производственная проблема: после переноса проекта в другое облако основная точка входа в мобильном приложении перестала работать, и команда поддержки оказалась перегружена жалобами пользователей. В этих условиях инженеру потребовалось быстро найти способ анализировать огромные объёмы данных — код, задачи, документацию и чаты, чтобы отвечать на критичные запросы и устранять дефекты.

На начальном этапе разработчик написал загрузчики на Python, которые собирали задачи, документацию и сообщения из чатов в markdown-файлы, затем помещал их в единую папку вместе с кодом. Корпоративный AI-провайдер уже предоставил доступ к модели DeepSeek V4 Flash через OpenAI-совместимый API, что позволило в течение часа сформировать анализ девяти критичных дефектов, указав причины и сроки исправления. Этот ранний прототип фактически был простым RAG-конвейером, где векторный поиск по md-файлам дополнялся генерацией ответов на основе найденных фрагментов. Однако вскоре выяснилось, что документация устаревает, а самая актуальная информация сосредоточена в чатах, где сотрудники самоорганизуются для решения текущих задач. Это подтолкнуло автора к переходу на graphRAG — архитектуру, которая строит граф связей между сущностями и документами, что позволяет отвечать на сложные вопросы, требующие многошаговых рассуждений.

Второй этап развития системы был связан с внедрением гибридного поиска, сочетающего BM25 и векторное представление, а также с использованием подхода Graph of Thoughts. Этот метод разбивает исходный вопрос на подвопросы, выполняет серию запросов к базе знаний и затем синтезирует результаты в единый ответ. Инженер также создал дашборд для очистки и актуализации базы знаний, удаляя устаревшие документы и помечая новые источники как приоритетные. За неделю его упомянули в чатах 115 раз, поскольку он успешно находил ответы на актуальные вопросы, опираясь на доступные код, задачи, документы и переписки. Тем не менее, проект столкнулся с организационными трудностями: после сокращения команды и блокировки перевода разработчика систему не удалось развернуть как полноценный сервис, и она осталась в виде набора скриптов и прототипов.

Третий этап начался с решения переписать систему с нуля на Go, поскольку Python, по мнению автора, не подходит для production-решений в силу производительности и типизации. Для инференса использовалась домашняя видеокарта RTX 4090 с 24 ГБ видеопамяти, на которой разместили модели qwen3.8 27b и qwen3-embedder. Помимо graphRAG и гибридного поиска, добавились такие компоненты, как Temporal-awareness (учёт временных связей), logicRAG (логические рассуждения) и серия оптимизаций для работы на ограниченном железе. Этот этап показал, что современные RAG-системы могут выходить за рамки простого поиска и включать элементы семантического анализа, что особенно важно для корпоративных данных, где ответы часто зависят от контекста и времени.

После потери доступа к исходному корпусу данных автор начал искать открытые аналоги для тестирования, но обнаружил, что большинство проектов находятся на ранних стадиях развития или не имеют открытых чатов. В поисках бенчмарков для русскоязычных систем он наткнулся на DRAGON и RUMBA: первый оказался скорее примером создания бенчмарков, чем полноценным тестом, и автор прошёл его с результатом 80,3%, что близко к теоретическому максимуму, поскольку часть вопросов не имеет ответов в новостном корпусе. Второй бенчмарк не подошёл из-за специфики систем. Существующий EnterpriseRAG-Bench с 500 тысячами документов, содержащих чаты, задачи и код, требует около года на локальный прогон, что делает его непригодным для быстрой проверки. Автор также обратился в Альянс ИИ и к разработчикам русскоязычных бенчмарков, но не получил ответа, а в это время Яндекс анонсировал выход Алисы AI для бизнеса, которая решает схожие задачи.

Для российского рынка этот кейс показателен сразу в нескольких аспектах. Во-первых, он демонстрирует, что даже небольшой команде или отдельному разработчику под силу создать функциональную RAG-систему с использованием открытых моделей и локального оборудования, что особенно актуально в условиях ограничений на зарубежные облачные сервисы. Во-вторых, отсутствие качественных русскоязычных бенчмарков для оценки таких систем является серьёзным пробелом, который затрудняет сравнение решений и выбор оптимальной архитектуры. Разработчик приглашает сообщество к участию в создании национальной базы знаний с открытым исходным кодом, что может стать шагом к консолидации усилий в этой области. Однако остаются открытые вопросы: как обеспечить актуальность данных в долгосрочной перспективе, какие методы оценки считать эталонными и как масштабировать подобные решения на более крупные организации.

В настоящее время проект приостановлен из-за нехватки ресурсов на тестирование, но сам код доступен на GitHub, что позволяет другим разработчикам изучать и дорабатывать систему. Эволюция от простого поиска по md-файлам до многослойного пайплайна с графом знаний и логическими рассуждениями иллюстрирует общий тренд в развитии RAG-технологий: переход от статичных индексов к динамическим структурам, способным учитывать временные и логические связи между сущностями. В будущем можно ожидать появления более универсальных бенчмарков и стандартов для оценки таких систем, а также интеграции с корпоративными мессенджерами и платформами совместной работы. Пока же опыт alterfo служит практическим руководством для тех, кто сталкивается с необходимостью быстро организовать доступ к разрозненным данным и превратить их в источник знаний для ИИ-ассистентов.