Как мы построили корпоративного RAG-ассистента: от личного стартапа до внутреннего продукта
Привет, Хабр! На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев.
В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Но обо всём по порядку.
Навигация по тексту
Ты открываешь Confluence, ищешь документацию по проекту — и находишь три версии одного и того же документа разных годов. Спрашиваешь коллегу — он в отпуске. Лезешь в GitLab — теряешься в ветках. Через полтора часа у тебя есть примерное представление о том, как работает текущая реализация. Примерное. Как ответ на эту боль появился проект, про который мы расскажем ниже.
Откуда взялась идея
В начале 2025 года наша команда одновременно тащила два крупных проекта: переезд на новый дизайн Руцентра и ребрендинг Рег.ру с новой коммерческой политикой. Оба требовали одного и того же: разобраться, как устроен текущий сайт, что оставить, что выкинуть, что учесть.
Код был древний. JavaScript на дореволюционных технологиях, один человек, который во всём этом разбирался, и месяц на закрытие задачи. Нейросети уже тогда помогали — пусть и локальные, которые разрешал использовать ИБ, и достаточно слабые. Тем не менее технические задания для верстальщиков мы сгенерировали за пару дней вместо двенадцати месяцев ручной работы.
После этого стало понятно: вот бы всё это автоматизировать нормально, а не по кускам. Дима посмотрел на рынок — увидел, что появляются платформы, которые агрегируют корпоративные данные и оборачивают их в продукт. Решил сделать своё. За месяц собрал прототип, получил зеленый свет.
Следующие полгода ушли на согласование идеи с отделом ИБ.
Полгода с информационной безопасностью
У ИБ был один ключевой вопрос к любому чат-боту с доступом к корпоративным данным: кто что может видеть?
Дима предвидел это с самого начала и заложил механику разграничения доступов в архитектуру еще на этапе прототипа. Решение оказалось элегантно простым: бот не хранит никаких прав сам по себе. Он работает с токенами самого пользователя.
Схема такая. Пользователь один раз заходит в настройки аккаунта и вводит свой личный токен из 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 стоит 300 000–400 000 руб., несколько штук можно объединить в локальный стенд на 20–50 человек.
Порог входа — от 500 000 руб. Ниже этой цифры даже экспериментировать будет сложно.
По команде: чтобы собрать такую систему с нуля, нужны бэкенд-инженер, фронтенд-инженер, ML-инженер и дата-инженер — три-четыре человека. Компетенций здесь много: управление долгоживущими процессами, векторный поиск и его индексация, агентская логика, промпт-инжиниринг, модель безопасности, джобы для обогащения данных. Это всё напоминает задачи из e-commerce, где каталог товаров нужно синхронизировать между базой данных и поисковым движком.
В нашем случае прототип Дима собрал за месяц. Но важно помнить, что у него за плечами — двадцать лет разработки с опытом и во фронтенде, и в бэкенде, и с ML.
Главный вывод
Его можно сформулировать просто: если вы можете описать последовательность действий в виде логики — вы можете это автоматизировать.
Это не про то, что ИИ уволит всех людей. Компании, которые научатся не просто пользоваться ChatGPT, а строить собственные продукты на открытых технологиях, получат реальное конкурентное преимущество. Разница между «мы везде используем ИИ» на сайте и «мы предлагаем клиентам нормальный продукт» примерно такая же, как между словами и делом. Добавлять «на базе ИИ» в описание каждого продукта уже точно не нужно — это уже базовый минимум, а не роскошный максимум.
Если у вас остались вопросы про нашего ассистента или про используемые технологии — напишите в комментариях, будем рады продолжить разговор!
Автор: runity