Как мы построили корпоративного RAG-ассистента: от личного стартапа до внутреннего продукта

На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев. С этого года наша команда работает в составе Центра гибридного интеллекта ^[1] — внутреннего направления, которое отвечает за AI-пилоты, прикладные сценарии и развитие таких решений внутри компании.

В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Для нас это не эксперимент, а один из прикладных продуктов, который мы собираем на собственной инфраструктуре, в том числе с использованием GPU-серверов Рег.облака ^[2]. Но обо всём по порядку.

Навигация по тексту

• Откуда взялась идея ^[3]

• Полгода с информационной безопасностью ^[4]

• Как это устроено внутри ^[5]

• Технический стек ^[6]

• Четыре агента вместо одного универсального ^[7]

• RAG или файн-тюнинг — и почему выбор очевиден ^[7]

• Сколько стоит и кто это строит ^[8]

• Главный вывод ^[9]

Ты открываешь Confluence, ищешь документацию по проекту — и находишь три версии одного и того же документа разных годов. Спрашиваешь коллегу — он в отпуске. Лезешь в GitLab — теряешься в ветках. Через полтора часа появляется примерное представление о том, как работает текущая реализация. Примерное. Так появился проект, про который рассказываем ниже.

Откуда взялась идея

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

Код был старый. JavaScript на устаревших технологиях, один человек, который в этом разбирается, и месяц на закрытие задачи. Нейросети уже тогда помогали — пусть локальные, которые разрешала ИБ, и достаточно слабые. Тем не менее технические задания для верстальщиков мы сгенерировали за пару дней вместо двенадцати месяцев ручной работы.

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

Позже эта работа стала частью более широкого направления: в компании запустили Центр гибридного интеллекта. Его задача — не просто тестировать AI-инструменты ради интереса ^[10], а разбирать конкретные сценарии, запускать пилоты, считать результат и оставлять в работе только то, что реально приносит пользу.

Следующие полгода ушли на согласование идеи с отделом ИБ.

Полгода с информационной безопасностью

У ИБ был один ключевой вопрос к любому чат-боту с доступом к корпоративным данным: кто и что может видеть?

Дима заложил механику разграничения доступов в архитектуру еще на этапе прототипа. Решение оказалось простым: бот не хранит права доступа. Он работает с токенами пользователя.

Схема такая. Пользователь один раз заходит в настройки аккаунта и вводит личный токен из Confluence и GitLab. Токены он генерирует сам в интерфейсе сервисов — хелпдеск не нужен, это личные учетные данные.

Когда бот находит документ, он проверяет через API, есть ли у пользователя доступ. Нет — документ пропускается. Решение принимает не модель, а код. В LLM попадает только то, что пользователь и так мог бы увидеть в Confluence или GitLab. Минус у схемы один — скорость. Синхронные проверки работают небыстро. Но задача, которая у человека занимает несколько часов, с ботом решается за пять–семь минут.

После согласования с ИБ добавили логирование, поправили отображение данных — и под Новый год получили разрешение. Сейчас разворачиваем систему во внутреннем контуре.

Как это устроено внутри

Система работает по схеме RAG — Retrieval-Augmented Generation. Модель не дообучаем на корпоративных данных, а подтягиваем релевантные куски текста в момент запроса.

Сначала запрос векторизируется через embedding-модель и уходит в Qdrant — векторную базу данных, где лежат документы из Confluence и код из GitLab. Qdrant возвращает топ-N наиболее близких по смыслу документов — это семантический поиск, не поиск по подстрокам. Дальше система безопасности проверяет доступ к каждому документу. Прошли проверку — отправляем в LLM. Не прошли — отбрасываем.

Модель читает документы, суммирует, делает вывод и возвращает ответ со ссылками на источники. Ссылки ведут на конкретную страницу Confluence или файл в GitLab.

Главная идея — объединить источники. В одном запросе бот находит бизнес-требования из Confluence и текущую реализацию из GitLab. Разработчик видит и что должно быть, и как это реализовано — без переключения между вкладками.

Галлюцинации возможны, если попадаются семантически близкие, но не связанные документы. Поэтому в ответе всегда есть ссылки на источники, чтобы ответ ассистента можно было проверить.

Технический стек

Язык — Python. Оркестратор — Temporal ^[11]. Если процесс падает на полпути, его можно перезапустить с точки сбоя без потери данных. Самостоятельно реализовать такую логику ^[12] сложно, поэтому используем готовый инструмент. Temporal активно применяют в AI-продуктах как оркестрирующий слой.

Векторная база — Qdrant. Он умеет хранить не только векторы, но и документы, как MongoDB. Это упрощает развитие системы. PostgreSQL — для остальных данных. Фронтенд — Next.js (Vue). За агентскую логику отвечает LangGraph.

Модели развернуты локально, с фокусом на работу с кодом. Используем Qwen/Qwen3.5-35B-A3B и аналогичные модели. Они хорошо работают с языками программирования и справляются с естественным языком. Русский текст из Confluence и английские термины из GitLab модель воспринимает как единый контекст.

Данные в Qdrant обновляются ночью: раздел Confluence полностью пересобирается. Это медленно и дорого. Инкрементальное обновление пока в бэклоге.

Четыре агента вместо одного универсального

Мы не стали делать одного универсального агента. Сделали четыре — под разные задачи.

Общий чат-бот. Задаешь произвольный вопрос, получаешь ответ с опорой на внутренние документы. Хорошо работает для первичного погружения в проект или поиска чего-то, про что не знаешь, где искать.

Агент для сбора техрадара. Проходит по репозиториям, собирает, какие языки программирования и библиотеки используются, строит отчет. На руках — актуальная картина технологического ландшафта, а не то, что кто-то вручную внес в Confluence год назад.

Агент для архитектурного планирования. Помогает разобраться в текущем ландшафте перед тем, как начинать новый проект. Берешь задачу, смотришь, что уже есть в кодовой базе и в документации, получаешь опорные точки для проектирования.

Напарник по программированию. Ближе всего к классическому coding assistant, но с доступом к внутренним знаниям компании. В отличие от Copilot, он знает вашу кодовую базу и ваши требования, а не просто генерирует по паттернам из интернета.

Четыре направления появились не из воздуха: мы просто спросили у команды, что нужно. Технический директор сказал про техрадар, руководитель архитектуры — про архитектурную документацию, разработчики — про ассистента для кодинга.

RAG или файн-тюнинг — и почему выбор очевиден

Этот вопрос возникает у всех, кто внедряет LLM внутри компании.

Файн-тюнинг звучит привлекательно: модель знает ваши продукты и пишет в нужном стиле. На практике это редко работает. Нужны сотни тысяч размеченных примеров, высокая стоимость и ML-экспертиза. После дообучения модель часто хуже справляется с базовыми задачами. RAG решает другую задачу: модель получает актуальный контекст в момент ответа. Нам важно именно это — не стиль, а доступ к актуальной информации.

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

Сколько стоит и кто это строит

Если коротко: дорого и сложно.

Самый ощутимый барьер — инфраструктура. Чтобы система работала в корпоративном режиме с одновременным доступом нескольких пользователей, нам потребовалось примерно четыре GPU класса ^[2]A100 с 24 ГБ видеопамяти. Аренда одной карты — около 40 000 руб./мес. Итого 160 000–200 000 руб./мес. только на вычисления.

Если GPU уже есть — проще. Для небольших команд можно собрать локальный стенд на Mac Studio.Порог входа — от 500 000 руб. Команда — три-четыре человека: бэкенд, фронтенд, ML и дата-инженер. Задачи включают оркестрацию процессов, векторный поиск, агентскую логику, безопасность и обработку данных.

В нашем случае прототип Дима собрал за месяц. Но важно помнить, что у него за плечами — двадцать лет разработки с опытом ^[13] и во фронтенде, и в бэкенде, и с ML. 

Главный вывод

Если процесс можно описать как последовательность действий — его можно автоматизировать. Речь не о том, что ИИ заменит людей. Компании, которые научатся строить собственные решения на открытых технологиях, получат преимущество. Разница между «мы используем ИИ» и «у нас есть рабочий продукт» остается принципиальной.

Если у вас остались вопросы про нашего ассистента или про используемые технологии — напишите в комментариях, будем рады продолжить разговор!