В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.

Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс‑командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.

Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.
Для скорости PoC решили делать локальный деплой.

В этой статье я расскажу, как мы построили локальный RAG‑сервис, оформили его как MCP‑сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.

Общая идея и архитектура

Мы сознательно не пытались сделать «умный поиск по всему сразу». Вместо этого система строится вокруг простого и прозрачного потока данных:

Архитектура состоит из двух основных компонентов — индексатора и RAG‑сервиса (MCP‑слоя), который связывает их с клиентами. Всё развёрнуто на локальном сервере компании и используется как внутренний сервис.

rag-indexer: как мы работаем с источниками знаний

Первый вопрос, который пришлось решить: что именно индексировать и в каком виде.

Мы индексируем три основных типа источников:

• код репозиториев;

• базу знаний и архитектурные описания.

При этом для нас было важно не просто «сложить всё в векторное хранилище», а сохранить контекст. Для каждого документа мы храним метаданные: репозиторий, продукт или подсистему, теги, а также политики доступа. Это позволяет фильтровать и ограничивать поиск ещё до стадии генерации ответа. Использовались в лоб ASTEnhancer и API Confluence для подготовки данных, потом стандартная нарезка на чанки. Для кода CodeSplitter, для статей SentenceSplitter - все из llamaindex. Эмбедер OpenAI text-embedding-3-large.

Обновление индексов происходит несколькими способами. Основной — по триггерам из CI. При изменениях в репозитории код автоматически копируется на локальный сервер и переиндексируется. Для документации используется синхронизация по API, а для крупных изменений предусмотрен ручной запуск.

rag-server: RAG как сервис, а не как скрипт

Второй компонент — rag‑server. Это не просто обёртка над retrieval + generation, а полноценный сервис с собственной логикой обработки запросов. Здесь мы руководствовались принципами разделения ответственности и возможности тестировать каждый элемент по отдельности. Это значит, что отдельно был реализован сервер FastMCP и отдельно, на FastAPI - RAG сервис. Отдельно уточню, что использовалась бд FAISS и llamaindex для работы самого rag. А долполнительные вызовы LLM для расширения запроса пользователя, реранкинга и тд на обычном OpenAI python SDK.

Запрос проходит несколько этапов:

1. принимается от клиента;

2. уточняется и обогащается контекстом;

3. маршрутизируется по продуктам или подсистемам;

4. выполняется поиск по релевантным индексам;

5. результаты ранжируются;

6. формируется ответ с привязкой к источникам.

Ключевая идея здесь — не один глобальный поиск, а управляемый роутинг. Мы сознательно ушли от модели «спроси всё обо всём»: она плохо масштабируется и быстро начинает давать шум.

MCP слой дает стандартизированный протокол для IDE (стэк компании включает C++, C#, Java, Rust, JavaScript, Python). IDE разные, а инструмент один! Это позволяет подключить сервис к нескольким IDE без дублирования бизнес‑логики.

CI/CD и автоматическое обновление

Без автоматического обновления такая система быстро устарела бы, поэтому мы сразу встроили её в существующий CI/CD‑контур.

При пуше в репозиторий GitLab CI:

• код копируется на локальный сервер;

• запускается переиндексация.

Документация обновляется автоматически через API, без ручных действий со стороны разработчиков. Это критично: если ответы начинают отставать от реальности, доверие к системе падает очень быстро.

Эффект и метрики

В продакшене мы получили вполне измеримый эффект:

• время ответа — от 5 до 60 секунд, в зависимости от ширины запроса;

• снижение нагрузки на ключевых экспертов;

• ускорение онбординга новых разработчиков;

• меньше контекстных переключений при работе с кодом.

Это не инструмент «на каждый клик», но в ситуациях, где раньше требовались десятки минут или личные консультации, он окупается очень быстро.

Ограничения

Система далека от идеала, и это важно проговорить честно.

На текущий момент:

• необходимо расширять методы поиска (текущая версия просто по векторам);

• качество ранжирования на сложных запросах требует доработки;

• роутинг по продуктам во многом настраивается вручную.

Вместо заключения

Это не массовый инструмент и не замена поисковику. Разработчику действительно не каждый день нужно искать код из других продуктов.
Но когда такая необходимость возникает, важно получить ответ быстро, из актуальных источников и без риска утечки данных.

Подход с локальным RAG‑сервисом, оформленным как MCP‑сервер, хорошо решает эту задачу и масштабируется под другие внутренние кейсы.