В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.
Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс‑командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.
Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.
Для скорости PoC решили делать локальный деплой.
В этой статье я расскажу, как мы построили локальный RAG‑сервис, оформили его как MCP‑сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.
Общая идея и архитектура
Мы сознательно не пытались сделать «умный поиск по всему сразу». Вместо этого система строится вокруг простого и прозрачного потока данных:
Архитектура состоит из двух основных компонентов — индексатора и RAG‑сервиса (MCP‑слоя), который связывает их с клиентами. Всё развёрнуто на локальном сервере компании и используется как внутренний сервис.
rag-indexer: как мы работаем с источниками знаний
Первый вопрос, который пришлось решить: что именно индексировать и в каком виде.
Мы индексируем три основных типа источников:
-
код репозиториев;
-
базу знаний и архитектурные описания.
При этом для нас было важно не просто «сложить всё в векторное хранилище», а сохранить контекст. Для каждого документа мы храним метаданные: репозиторий, продукт или подсистему, теги, а также политики доступа. Это позволяет фильтровать и ограничивать поиск ещё до стадии генерации ответа.
Обновление индексов происходит несколькими способами. Основной — по триггерам из CI. При изменениях в репозитории код автоматически копируется на локальный сервер и переиндексируется. Для документации используется синхронизация по API, а для крупных изменений предусмотрен ручной запуск.
rag-server: RAG как сервис, а не как скрипт
Второй компонент — rag‑server. Это не просто обёртка над retrieval + generation, а полноценный сервис с собственной логикой обработки запросов.
Запрос проходит несколько этапов:
-
принимается от клиента;
-
уточняется и обогащается контекстом;
-
маршрутизируется по продуктам или подсистемам;
-
выполняется поиск по релевантным индексам;
-
результаты ранжируются;
-
формируется ответ с привязкой к источникам.
Ключевая идея здесь — не один глобальный поиск, а управляемый роутинг. Мы сознательно ушли от модели «спроси всё обо всём»: она плохо масштабируется и быстро начинает давать шум.
MCP слой дает стандартизированный протокол для IDE (стэк компании включает C++, C#, Java, Rust, JavaScript, Python). IDE разные, а ин��трумент один! Это позволяет подключить сервис к нескольким IDE без дублирования бизнес‑логики.
CI/CD и автоматическое обновление
Без автоматического обновления такая система быстро устарела бы, поэтому мы сразу встроили её в существующий CI/CD‑контур.
При пуше в репозиторий GitLab CI:
-
код копируется на локальный сервер;
-
запускается переиндексация.
Документация обновляется автоматически через API, без ручных действий со стороны разработчиков. Это критично: если ответы начинают отставать от реальности, доверие к системе падает очень быстро.
Эффект и метрики
В продакшене мы получили вполне измеримый эффект:
-
время ответа — от 5 до 60 секунд, в зависимости от ширины запроса;
-
снижение нагрузки на ключевых экспертов;
-
ускорение онбординга новых разработчиков;
-
меньше контекстных переключений при работе с кодом.
Это не инструмент «на каждый клик», но в ситуациях, где раньше требовались десятки минут или личные консультации, он окупается очень быстро.
Ограничения
Система далека от идеала, и это важно проговорить честно.
На текущий момент:
-
качество ранжирования на сложных запросах требует доработки;
-
роутинг по продуктам во многом настраивается вручную.
Вместо заключения
Это не массовый инструмент и не замена поисковику. Разработчику действительно не каждый день нужно искать код из других продуктов.
Но когда такая необходимость возникает, важно получить ответ быстро, из актуальных источников и без риска утечки данных.
Подход с локальным RAG‑сервисом, оформленным как MCP‑сервер, хорошо решает эту задачу и масштабируется под другие внутренние кейсы.
Автор: Devenir-Glorieux
