Привет! Хочу рассказать про AI‑трек, который проектировала наша команда на UWDC 2026, масштабной конференции разработчиков на Урале.
Меня зовут Катерина Лапаева, я руководитель AI‑агентства GIGASCHOOL.
Для выступления на нашей площадке мы пригласили Николая Прохорова, лида системной аналитики рекомендаций музыкального сервиса Звук. Николай поделился опытом создания ИИ‑ассистента на кодовой базе компании.
Николай Прохоров
лид системной аналитики рекомендаций музыкального сервиса Звук
Собрала для вас всю важную информацию и инструкцию по созданию в этой статье.
Зачем это вообще нужно?
Для начала отметим несколько проблем, с которыми сталкивается бизнес каждый день:
Много вопросов о нюансах работы системы. До 11% рабочего времени инженеры тратят только на поиск контактов и попытки понять контекст перед началом работы над функцией.
Разработчики отвлекаются. А если сотрудника отвлекли, время возвращения в рабочий поток занимает примерно 23–24 минуты.
Неактуальная информация в Confluence. Версия в документации может не совпадать с версией в коде. Документация быстро устаревает. Команды тратят много времени на поиск актуальной информации вместо работы над задачами.
Долгий и дорогой онбординг. Когда новый сотрудник приходит в компанию, ему нужно получить огромное количество знаний от HR, лидов, коллег и документации. Полный выход на продуктивность занимает 6–12 месяцев.
Разрыв продуктивности. Разработчики с AI ускорились на 15–20% (35–40% для простых задач), и около 80% сообщают об улучшении продуктивности. У разработчиков сейчас уже есть немало AI‑инструментов для оптимизации собственного труда и прирост производительности, тогда как аналитики и архитекторы становятся бутылочным горлышком.
Если в какой‑то компании уже используются AI‑инструменты, она может быстрее и дешевле производить свой продукт и, следовательно, давать более конкурентные цены. Конечно же, потребитель выберет производителя с AI.
Соответственно, возникает идея разработать некий механизм, который обладает всеми приватными знаниями организации. Это может быть Confluence, дата хаб, трекер задач и так далее. Но мы будем разбираться именно на примере кода.
Почему именно RAG, а не fine‑tuning?
У RAG‑системы есть альтернатива — fine‑tuning. Но в данном случае мы говорим именно про RAG, потому что регулярный файнтюнинг — это дорого, а такую систему проще и дешевле внедрить, гораздо быстрее отдать сотрудникам и начать оптимизировать своё производство. Не нужно переобучать модель после каждого изменения репозитория и строить сложные процессы обновления знаний.
Поэтому задача звучала следующим образом: разработать некий механизм, который обладает всеми приватными знаниями организации и сможет мгновенно отвечать на вопросы по ним.
Требования к системе
Перед проектированием архитектуры сформулируем требования, потому что без классных требований система не взлетит.
RAG‑система должна потреблять сущности репозиториев и файлов кода, чтобы потом отвечать по ним.
RAG‑система должна понимать файлы кода не просто как код, а с бизнес‑интерпретацией и как человек. Например, не как «алгоритм быстрой сортировки или конфиг», а как «реранкер музыкальных треков». Информация нужно отдавать на человеческом языке и содержать человеческую семантику, потому что LLM — языковая модель и должна связывать смыслы в запросе пользователя и при выборке из RAG‑системы.
Минимальный расход токенов. Многие компании, которые начали внедрять AI, столкнулись с тем, что эффект от оптимизации труда перекрывался расходами на токены.
Работа с большим количеством репозиториев. Если репозиториев мало, вам может быть достаточно IDE, LLM с большим контекстом и MCP‑серверов.Но если вы — большая продуктовая организация и много заказчиков, это вам не подойдёт. Поэтому наша RAG‑система должна работать с 500 репозиториев.
Понимание внутренних терминов компании и извлечение метаданных. У любой организации есть свой птичий язык, свои внутренние термины и внутренний глоссарий, которому моделька должна обучиться.
Система должна уметь отбирать только релеватные документы для ответа. На другом докладе в секции говорили о том, что RAG не работает, потому что может перемешать разные версии файлов. Реранкер решает эту проблему, исходя из метатегов фрагмента.
Архитектура решения
На верхнем уровне архитектура выглядит довольно просто.
Есть Git (командная строка, Git, GitLab и пр.), который поставляет информацию о коде в некий оркестратор (по API или DAG‑ом перекладывает данные). Оркестратор кладёт сущности репозиториев и файлов кодов в реляционную БД, создавая слепок состояния кодовой базы на данный момент. После этого данные отправляются в LLM с просьбой описать, что в них написано. Результат складывается в векторную БД.
Архитектура данных
Для решения используются две БД:
реляционная (подойдёт Postgres, например);
БД для векторной коллекции (команда Звука использовала Qdrant и OpenSearch — он же Elasticsearch).
В реляционной БД хранятся сущности репозиториев и файлов кода.
В векторной базе используются три коллекции:
индексы репозиториев;
извлечённая документация;
описания с кодом.
Многие пытаются положить в векторные базы именно файлы с кодом и жалуются, что поиск не работает. Попробуйте положить не код, а именно описание.
Сущность «Репозитории» (Postgres)
Часть данных мы получаем непосредственно из Git (те, что не помечены курсивом на картинке): идентификатор репозитория, имя, описание, URL.
Остальное (всё, что курсивом на картинке) мы извлекаем при помощи AI.
Особенно полезно извлекать архитектурные компоненты, архитектурные паттерны, клиентов системы, пайплайны. Чем больше такой информации будет извлечено, тем лучше потом работает поиск.
Сущность «Файлы кода»
Из Git получаем: идентификатор файла, идентификатор репозитория, имя файла, путь и содержимое. Всё будет работать быстро, даже если БД в PostgreSQL у вас будет весить гигабайт.
Дальше при помощи модели извлекаем всё, что может быть полезно для поиска (язык программирования или разметки, заголовок, структурные поведенческие характеристики и так далее).
Архитектура данных векторной БД
Что тут интересного?
pageContent — здесь хранится кратенькое описание репозитория, оно будет работать как глоссарий;
metadata.name и metadata.id — по ним вы поймёте, что это за репозиторий и как он называется.
url — гид репозитория.
Да, кстати, тип репозитория очень важен, потому что информация в бэкэнд‑сервисах, во фронтенд‑сервисах, в дата‑пайплайнах и репозиториях с документацией может отличаться. Это полезная вещь.
Коллекция с индексами хранит краткие описания репозиториев.
Коллекция с извлечённой документацией хранит документацию к сервису, извлечённую LLM‑кой.
А коллекция с бизнес‑описаниями файлов кода ровно это и хранит.
И делая запрос в первые две, мы можем определить, какие репозитории отвечают на наш запрос и пойти в третий для получения релевантных файлов.
Инжест данных
Инжест данных у нас разделяется на четыре процесса, каждый запускается по событию. В качестве триггера запуска можно использовать ручной запуск.
Переливка репозиториев: получаем список репозиториев из Git, получаем список репозиториев из Postgres, сравниваем и обновляем только изменившиеся записи.
Переливка файлов: получаем обновленные репозитории, клонируем их в файловую систему, получаем список файлов, сравниваем с Postgres и обновляем только изменения.
AI‑инжест файлов: получаем новые или изменённые файлы, передаём модели информацию об организации, информацию о продукте, информацию о репозитории и содержимое файла, получаем структурированное описание и сохраняем результат.
AI‑инжест репозиториев.
Здесь есть важный момент: нельзя одним алгоритмом извлечь все типы репозиториев, потому что у них разная документация. Разделим их на категории:
backend‑сервисы;
frontend‑приложения;
библиотеки;
скрипты;
пайплайны;
проектная документация;
всё остальное.
Для каждого типа репозитория создаётся пайплайн, который извлечёт нужную документацию из репозитория. Далее этот репозиторий помещается во временную векторную базу, и начинается цикл вопросов. Для backend‑сервисов количество таких запросов может доходить до 50. Результаты сохраняются обратно в Postgres, и их нужно раскидать по коллекциям векторных баз (рекомендуем начинать с Qdrant).
Как работает ассистент?
Сначала система получает историю сообщений и объект диалога, потому что в процессе общения темы могут меняться. Например, если пользователь написал: «Поподробнее», система должна понять, что речь идёт о предыдущем обсуждении. После этого выполняется рефразинг — запрос приводится к явному виду.
Далее происходит поиск релевантных репозиториев, затем поиск релевантных файлов внутри найденных репозиториев. После этого собранный контекст передаётся в модельку для генерации ответа.
Пример
Один из запросов выглядел так: «Выведи логику распознавания треков (а‑ля Shazam)».
Система сначала определила контекст, извлекла ключевые слова, продолжила рассуждение и нашла релевантные репозитории, для каждого объяснила причину выбора.
Только после этого моделька формирует ответ с иллюстрацией.
Стоимость и производительность
Что получаем в итоге? Онбординг сокращается с 3 месяцев до 2 недель, снижаются нагрузки на разработчиков на 70% (меньше созвонов и общения в чатах), окупаемость за 3–6 месяцев.
Как посчитать окупаемость? Можно по ФОТу (фонд оплаты труда).
Расходы на инжест по кейсу сервиса Звук подробно представлены на картинке.
Если вы арендуете сервера за GPU, получается немного дешевле.
Подводим итоги
Когда мы говорим про AI в разработке, чаще всего речь идёт о генерации кода. Но самое интересное далеко не это, а то, что в любой крупной компании уже есть огромный пласт накопленных знаний, до которых бывает сложно добраться. Они разбросаны по разным уголкам: от внутренних сервисов и документации до голов отдельных сотрудников. Если AI и может помочь бизнесу с чем‑то полезным сегодня, то именно с этим — превратить эту базу в источник знаний, которому можно задать любой вопрос и получить ответ на человеческом языке.
Если вы уже строили RAG‑системы поверх кодовой базы в компании, внедряли внутренних AI‑ассистентов, то обязательно поделитесь своими кейсами в комментариях. Будет интересно сравнить подходы, решения и результаты.
Для связи с Николаем: https://t.me/nick_prokhorov