Компании со временем накапливают тысячи страниц документации, и найти нужную информацию становится всё сложнее. Обычный поиск перестаёт справляться, сотрудники тратят время на навигацию по Wiki и повторяют одни и те же вопросы коллегам.
Как решили эту проблему: когда большие языковые модели стали рабочим инструментом, мы объединили корпоративные знания с возможностями LLM. Так появился Юджин — AI-ассистент, который понимает смысл запроса, а не просто ищет совпадения по словам.
Меня зовут Илья, я директор департамента разработки ЮMoney. Расскажу, почему отказались от готовых решений и как построили RAG-платформу для корпоративных знаний. Материал будет полезен архитекторам, AI-инженерам и всем, кто внедряет корпоративные LLM-решения.
Почему мы не купили готовое решение
Корпоративных AI-ассистентов на рынке много, но большинство требует ручной загрузки данных. Для небольшой базы знаний это приемлемо, но в компании с постоянно меняющейся документацией такой подход не масштабируется. Критичным ограничением стала и безопасность — мы не можем передавать конфиденциальные данные внешним сервисам.
Поэтому собственная платформа дала полный контроль над источниками, индексацией, выбором моделей и развитием продукта.
Что умеет Юджин сегодня
Юджин — внутренний AI-ассистент компании. Он ищет информацию по корпоративным источникам, работает с документами, помогает с кодом и анализирует прикреплённые файлы. Поисковый индекс охватывает документацию, регламенты, инструкции и описания бизнес-процессов.
В чат можно загрузить документ размером до 5 МБ, чтобы получить краткое содержание, найти нужную информацию или задать вопросы по его содержимому.
Почему это не дообучение модели
Мы используем технологию RAG (Retrieval-Augmented Generation): модель не обучается на корпоративной информации. Вместо этого:
-
документы индексируются и преобразуются в векторные представления;
-
по запросу система находит релевантные фрагменты;
-
найденные данные передаются в контекст модели;
-
модель формирует ответ, опираясь на наполненный контекст.
Такой подход позволяет быстро обновлять базу знаний без переобучения модели, снижает стоимость эксплуатации и даёт больше контроля над актуальностью данных и безопасностью.
Как устроен поиск внутри Юджина
Архитектура Юджина сложнее обычного чат-бота и включает два процесса: формирование базы знаний и поиск по запросу пользователя.
Блок 1. Формирование базы знаний Юджина
Шаг 1. Сбор данных
Система подключается к Wiki, Bitbucket и внутренним документам, автоматически выгружая содержимое для индексации.
Индексация происходит непрерывно, но не после каждого сохранения: при частых правках изменения накапливаются и обрабатываются пакетно через заданные интервалы. Это снижает нагрузку и исключает лишние пересчёты.
Шаг 2. Разбиение на чанки
Документы разбиваются на чанки перед векторизацией и индексацией. Размер чанка напрямую влияет на качество поиска: слишком большие фрагменты увеличивают шум и время обработки, слишком маленькие — теряют контекст.
После серии экспериментов мы остановились на размере около 1024 токенов с перекрытием 200 токенов между соседними чанками. Алгоритм рекурсивно делит документ по разделителям разного уровня и объединяет соседние фрагменты, если их суммарный размер укладывается в лимит. Количество токенов рассчитывается через токенизатор эмбеддинговой модели FRIDA, что даёт более точный результат по сравнению с подсчётом слов.
Мы реализовали специализированный чанкер для разных типов документов:
-
OpenAPI (.yml). Разворачивает ссылки $ref, удаляет секцию components, после чего разбивает документ по эндпоинтам. Каждый path + method становится отдельным чанком с метаданными API, метода, пути и описания.
-
Markdown (.md, .markdown). Строит дерево заголовков и добавляет в каждый чанк цепочку родительских разделов. Благодаря этому фрагмент сохраняет контекст своего положения в документе.
-
AsciiDoc (.adoc, .asciidoc). Работает аналогично Markdown, дополнительно извлекая метаданные документа, например автора или версию, и сохраняя их в каждом чанке.
-
PlantUML (.puml, .plantuml, .uml). Учитывает вложенность блоков по отступам и сохраняет заголовок диаграммы. Это позволяет не разрывать логически связанные элементы UML-схем.
-
HTML (.html). Предварительно конвертируется в Markdown, после чего обрабатывается тем же пайплайном. HTML-страницы становятся читаемыми и структурированными чанками.
Для всего остального — универсальное рекурсивное разбиение по параграфам и предложениям.
Шаг 3. Векторизация и хранение данных
Для повышения качества ответов используется параллельно два поиска: полнотекстовый (реализуется с помощью поискового движка OpenSearch) и векторный поиск.
Во время индексации для каждого чанка строится эмбеддинг — числовое представление текста, по которому затем выполняется семантический поиск. Благодаря этому запросы «Как оформить доступ к тестовому контуру?» и «Кто выдаёт права в тестовую среду?» приводят к одному и тому же документу, даже без совпадения формулировок.
Для построения эмбеддингов используется открытая модель FRIDA, развёрнутая как внутренний сервис. FRIDA (https://huggingface.co/ai-forever/FRIDA) оптимизирована для семантического поиска и построена на базе семейства русскоязычных моделей FRED-T5 (Full-scale Russian Enhanced Denoisers T5).
Эмбеддинги хранятся в Milvus. Для индексации мы используем HNSW (Hierarchical Navigable Small World), который обеспечивает высокую скорость поиска ближайших соседей при сохранении высокой полноты результатов.
Блок 2. Поиск ответа на вопрос
После получения запроса параллельно запускаются полнотекстовый и векторный поиск. Полнотекстовый поиск в OpenSearch использует три стратегии: поиск по словам, с учётом опечаток и по фразам. Их результаты объединяются, взвешиваются и дедуплицируются. Текст обрабатывается русским анализатором со стеммингом, поддержкой синонимов, стоп-слов и разбиением составных слов.
Для каждого корпуса создаются два индекса: с чанками документов и с синтетическими вопросами, сгенерированными LLM. Поиск выполняется по обоим. Если найдено совпадение по синтетическому вопросу, возвращается соответствующий чанк.
Параллельно выполняется векторный поиск в Milvus. Пользовательский запрос преобразуется в эмбеддинг с помощью FRIDA, после чего по косинусной близости ищутся наиболее релевантные чанки и синтетические вопросы. При совпадении по вопросу также возвращается связанный чанк.
Результаты полнотекстового и векторного поиска объединяются и передаются на реранжирование с помощью BGE-M3 (BAAI). Эта модель точнее оценивает релевантность пары «запрос — фрагмент», чем bi-encoder FRIDA, используемый на этапе первичного поиска. После реранжирования в контекст LLM попадают только наиболее релевантные чанки, что повышает качество ответа.
Реранкер развёрнут на Triton Inference Server в формате ONNX с квантизацией Q4. За один запрос он оценивает до 40 пар «запрос — фрагмент» и отбирает наиболее релевантные чанки для передачи в LLM. Среднее время ответа — около одной секунды. Эта информация взята из графиков в графане сервиса.
Какие модели используются
Запросы маршрутизируются в зависимости от сценария. Чувствительные корпоративные данные обрабатываются локальными моделями внутри защищённого контура. Для остальных запросов используется GigaChat.
Что дальше
Сейчас Юджин помогает разработчикам быстрее находить документацию, разбираться в сервисах и их взаимосвязях. Следующий этап — поддержка аналитиков, архитекторов и менеджеров: работа со спецификациями, контекстом решений, задачами и отчётными материалами.
С технической точки зрения Юджин развивается в сторону агентной архитектуры на базе ReAct. Новый функционал оформляется как инструмент, новые действия — как skills, а для отдельных классов задач появляются специализированные субагенты.
Наша цель — единое рабочее пространство, в котором сотруднику не нужно выбирать модель или инструмент. Юджин сам определяет оптимальный сценарий выполнения запроса.
В ближайших планах:
-
интерактивный чат со стримингом ответов;
-
поддержка новых форматов документов и схем;
-
интеграция с внутренними сервисами;
-
единая агентная платформа на базе OpenCode.
Вместо выводов
За последние два года мы увидели множество попыток внедрить LLM в корпоративную среду. Часть проектов так и осталась экспериментами, другие стали рабочими инструментами.
Юджин относится ко второй категории. Он начинался как поиск по внутренней Wiki, а со временем превратился в платформу для работы с корпоративными знаниями. Наш главный вывод прост: ценность корпоративного AI — не в универсальном чат-боте, а в глубокой интеграции с внутренними данными, процессами и инструментами компании.
Если вы уже внедряете корпоративного AI-помощника или только планируете это сделать, расскажите о своём опыте в комментариях. С удовольствием обсудим архитектурные решения, RAG, поиск и всё, что не поместилось в эту статью.
ссылка на оригинал статьи https://habr.com/ru/articles/1054144/