В этой статье — история создания корпоративного RAG-ассистента в компании Рунити. Система ищет информацию одновременно в Confluence и GitLab, учитывает права доступа и не передаёт корпоративные данные наружу. Мы расскажем, как проект начался как личная инициатива, прошёл согласование с информационной безопасностью и стал внутренним продуктом.
Откуда взялась идея
В начале 2025 года команда работала над двумя масштабными проектами: переездом на новый дизайн Руцентра и ребрендингом Рег.ру. Оба требовали глубокого погружения в устаревшую кодовую базу и документацию. Код был написан на устаревших технологиях, а эксперт по нему — всего один человек.
Нейросети уже тогда помогали в работе, хотя использовались локальные, слабые модели, разрешённые ИБ. С их помощью удалось сократить время на подготовку технических заданий с 12 месяцев до нескольких дней.
После этого стало понятно: нужно автоматизировать процесс. Дмитрий Виноградов изучил рынок, увидел появление платформ для агрегации корпоративных данных и решил создать свою. За месяц собрал прототип, показал техническому директору — получил зелёный свет.
Полгода с информационной безопасностью
Главный вопрос ИБ: кто и что может видеть? Решение было заложено в архитектуру с самого начала — бот не хранит права доступа. Он работает с токенами пользователя.
Пользователь вручную вводит свои токены от Confluence и GitLab. При поиске документов система синхронно проверяет через API, есть ли у пользователя доступ к каждому найденному ресурсу. Только прошедшие проверку документы попадают в контекст LLM.
Такой подход исключает утечку данных: модель видит только то, что и так доступно пользователю. Минус — скорость. Проверки замедляют процесс, но вместо нескольких часов ручного поиска задача решается за 5–7 минут.
После согласований, добавления логирования и доработок система получила разрешение к развёртыванию во внутренний контур.
Как это устроено внутри
Система построена по принципу RAG — Retrieval-Augmented Generation. Мы не дообучаем модель, а подтягиваем релевантные данные в момент запроса.
Запрос векторизируется с помощью embedding-модели и отправляется в Qdrant — векторную базу данных, где хранятся документы из Confluence и код из GitLab. Qdrant возвращает топ-N семантически близких документов.
Далее каждый документ проверяется на доступ. Прошедшие — передаются в LLM. Модель анализирует их, делает вывод и возвращает ответ с ссылками на источники.
Ключевое преимущество — совмещение данных. В одном запросе ассистент показывает бизнес-требования из Confluence и текущую реализацию из GitLab. Разработчик видит и «что должно быть», и «как есть».
Галлюцинации возможны, если в базе окажутся семантически близкие, но несвязанные документы. Поэтому в каждом ответе есть ссылки — чтобы можно было проверить источник.
Технический стек
Основной язык — Python. Оркестрация процессов — через Temporal. Это промышленное решение, позволяющее возобновлять упавшие процессы с точки остановки, не теряя данных.
Векторная база — Qdrant. Он поддерживает не только векторы, но и работает как документная БД, что удобно для масштабирования. Остальные данные — в PostgreSQL. Фронтенд — Next.js с Vue. Агентская логика реализована на LangGraph.
Модели — локальные, с фокусом на код. Используем Qwen/Qwen3.5-35B-A3B и аналогичные кодерские модели. Они хорошо понимают языки программирования и работают с кодом как с данными, а также справляются с естественным языком.
Модель читает русский текст из Confluence и английские термины из GitLab как единый контекст — многоязычность решена на уровне модели.
Данные в Qdrant обновляются ночью: весь Confluence стирается и загружается заново. Инкрементальное обновление — в бэклоге.
Четыре агента вместо одного универсального
Мы не стали делать универсального агента. Вместо этого — четыре специализированных:
- Общий чат-бот — отвечает на произвольные вопросы, опираясь на внутренние документы. Подходит для первичного погружения.
- Агент для сбора техрадара — сканирует репозитории, определяет используемые языки и библиотеки, строит актуальный отчёт.
- Агент для архитектурного планирования — помогает разобраться в текущем состоянии перед запуском нового проекта.
- Напарник по программированию — аналог coding assistant, но с доступом к внутренним знаниям компании. В отличие от Copilot, он знает ваш код и требования.
Направления появились после опроса команд: технический директор запросил техрадар, архитектор — документацию, разработчики — помощника по коду.
RAG или файн-тюнинг — и почему выбор очевиден
Файн-тюнинг звучит привлекательно: модель будет знать про продукты компании и писать в нужном стиле. Но на практике это редко работает.
Для качественного дообучения нужно сотни тысяч размеченных примеров — у большинства компаний их нет. Процесс дорогой, требует глубокой ML-экспертизы и может привести к деградации модели.
RAG решает другую задачу: модель не учится, а получает контекст в момент запроса. Это именно то, что нужно — актуальные корпоративные данные под рукой.
Файн-тюнинг оправдан только в узких случаях: например, когда критично, чтобы документация генерировалась в стиле конкретного эксперта. Для поиска по базе знаний это избыточно.
Сколько стоит и кто это строит
Система требует серьёзных ресурсов. Для корпоративного развёртывания с поддержкой нескольких пользователей нужно около четырёх GPU класса A100 с 24 ГБ видеопамяти.
Аренда одной карты — около 40 000 руб./мес. Итого: 160 000–200 000 руб./мес. только на вычисления. Если GPU уже есть — затраты ниже. Для небольших команд есть альтернатива: Mac Studio (300 000–400 000 руб. за штуку), несколько таких устройств можно объединить в локальный кластер на 20–50 человек.
Порог входа — от 500 000 руб. Ниже этой суммы даже экспериментировать сложно.
Команда: бэкенд- и фронтенд-инженер, ML-инженер, дата-инженер — 3–4 человека. Требуются навыки в оркестрации процессов, векторном поиске, агентской логике, промпт-инжиниринге, безопасности и ETL-задачах.
Прототип был собран за месяц. Но важно учитывать: у Дмитрия за плечами 20 лет опыта в разработке, включая фронтенд, бэкенд и ML.
Главный вывод
Если вы можете описать последовательность действий логически — вы можете это автоматизировать.
Речь не о замене людей. Компании, которые учатся строить собственные продукты на открытых ИИ-технологиях, получают реальное конкурентное преимущество. Разница между «мы используем ИИ» и «мы делаем продукт на ИИ» — как между словами и делом.
Сегодня «на базе ИИ» — не фишка, а базовый минимум.