На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев. С этого года наша команда работает в составе Центра гибридного интеллекта — внутреннего направления, которое отвечает за AI-пилоты, прикладные сценарии и развитие таких решений внутри компании.
В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Для нас это не эксперимент, а один из прикладных продуктов, который мы собираем на собственной инфраструктуре, в том числе с использованием GPU-серверов Рег.облака. Но обо всём по порядку.
Навигация по тексту
Ты открываешь Confluence, ищешь документацию по проекту — и находишь три версии одного и того же документа разных годов. Спрашиваешь коллегу — он в отпуске. Лезешь в GitLab — теряешься в ветках. Через полтора часа появляется примерное представление о том, как работает текущая реализация. Примерное. Так появился проект, про который рассказываем ниже.
Откуда взялась идея
В начале 2025 года команда одновременно вела два крупных проекта: переезд на новый дизайн Руцентра и ребрендинг Рег.ру с новой коммерческой политикой. В обоих случаях нужно было разобраться, как устроен текущий сайт, что оставить, что убрать и что учесть.
Код был старый. JavaScript на устаревших технологиях, один человек, который в этом разбирается, и месяц на закрытие задачи. Нейросети уже тогда помогали — пусть локальные, которые разрешала ИБ, и достаточно слабые. Тем не менее технические задания для верстальщиков мы сгенерировали за пару дней вместо двенадцати месяцев ручной работы.
После этого стало понятно: все это можно автоматизировать, а не собирать по кускам. Дима посмотрел на рынок, увидел платформы, которые агрегируют корпоративные данные и превращают их в продукт, и решил сделать свой вариант. За месяц собрал прототип и получил зеленый свет.
Позже эта работа стала частью более широкого направления: в компании запустили Центр гибридного интеллекта. Его задача — не просто тестировать AI-инструменты ради интереса, а разбирать конкретные сценарии, запускать пилоты, считать результат и оставлять в работе только то, что реально приносит пользу.
Следующие полгода ушли на согласование идеи с отделом ИБ.
Полгода с информационной безопасностью
У ИБ был один ключевой вопрос к любому чат-боту с доступом к корпоративным данным: кто и что может видеть?
Дима заложил механику разграничения доступов в архитектуру еще на этапе прототипа. Решение оказалось простым: бот не хранит права доступа. Он работает с токенами пользователя.
Схема такая. Пользователь один раз заходит в настройки аккаунта и вводит личный токен из Confluence и GitLab. Токены он генерирует сам в интерфейсе сервисов — хелпдеск не нужен, это личные учетные данные.
Когда бот находит документ, он проверяет через API, есть ли у пользователя доступ. Нет — документ пропускается. Решение принимает не модель, а код. В LLM попадает только то, что пользователь и так мог бы увидеть в Confluence или GitLab. Минус у схемы один — скорость. Синхронные проверки работают небыстро. Но задача, которая у человека занимает несколько часов, с ботом решается за пять–семь минут.
После согласования с ИБ добавили логирование, поправили отображение данных — и под Новый год получили разрешение. Сейчас разворачиваем систему во внутреннем контуре.
Как это устроено внутри
Система работает по схеме RAG — Retrieval-Augmented Generation. Модель не дообучаем на корпоративных данных, а подтягиваем релевантные куски текста в момент запроса.
Сначала запрос векторизируется через embedding-модель и уходит в Qdrant — векторную базу данных, где лежат документы из Confluence и код из GitLab. Qdrant возвращает топ-N наиболее близких по смыслу документов — это семантический поиск, не поиск по подстрокам. Дальше система безопасности проверяет доступ к каждому документу. Прошли проверку — отправляем в LLM. Не прошли — отбрасываем.
Модель читает документы, суммирует, делает вывод и возвращает ответ со ссылками на источники. Ссылки ведут на конкретную страницу Confluence или файл в GitLab.
Главная идея — объединить источники. В одном запросе бот находит бизнес-требования из Confluence и текущую реализацию из GitLab. Разработчик видит и что должно быть, и как это реализовано — без переключения между вкладками.
Галлюцинации возможны, если попадаются семантически близкие, но не связанные документы. Поэтому в ответе всегда есть ссылки на источники, чтобы ответ ассистента можно было проверить.
Технический стек
Язык — Python. Оркестратор — Temporal. Если процесс падает на полпути, его можно перезапустить с точки сбоя без потери данных. Самостоятельно реализовать такую логику сложно, поэтому используем готовый инструмент. 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 класса A100 с 24 ГБ видеопамяти. Аренда одной карты — около 40 000 руб./мес. Итого 160 000–200 000 руб./мес. только на вычисления.
Если GPU уже есть — проще. Для небольших команд можно собрать локальный стенд на Mac Studio.Порог входа — от 500 000 руб. Команда — три-четыре человека: бэкенд, фронтенд, ML и дата-инженер. Задачи включают оркестрацию процессов, векторный поиск, агентскую логику, безопасность и обработку данных.
В нашем случае прототип Дима собрал за месяц. Но важно помнить, что у него за плечами — двадцать лет разработки с опытом и во фронтенде, и в бэкенде, и с ML.
Главный вывод
Если процесс можно описать как последовательность действий — его можно автоматизировать. Речь не о том, что ИИ заменит людей. Компании, которые научатся строить собственные решения на открытых технологиях, получат преимущество. Разница между «мы используем ИИ» и «у нас есть рабочий продукт» остается принципиальной.
Если у вас остались вопросы про нашего ассистента или про используемые технологии — напишите в комментариях, будем рады продолжить разговор!
Автор: runity
