Привет! Мы разработчики Умного поиска Advanced RAG Дима и Семён. Работаем в команде платформы AlfaGen — внутренней GenAI‑инфраструктуры банка и продуктов на её базе.
Авторы статьи:
Дмитрий Аникеенко
Ведущий разработчик, заметил раннюю седину при запуске RAG
Семён Семейкин
Ведущий разработчик, ловил камни от волны заказчиков
В статье расскажем, как мы сделали Advanced RAG, чем он отличается от обычного Умного поиска — RAG. А ещё зачем вообще компаниям и пользователям такие продукты, и как вы можете сделать такой проект с меньшим числом седых волос.
Для начала определимся с терминами, чтобы точно понимать, где просто чат с ИИ, а где уже RAG и тем более ARAG. Если вы гуру нейронок, можете пропустить этот раздел и перейти к «мясу» в хардовой части.
Когда поиск с нейросетями становится умным, а когда — продвинутым
В последнее время чат с нейросетью всё чаще заменяет поисковую строку браузера.
Теперь вы спрашиваете не у Яндекса и Safari, а у вашей любимой языковой модели, что приготовить на ужин и сколько подходов сделать в зале.
Чтобы диалог с нейронкой мог помочь не только с вообще всеми вопросами, но и реально разгружал сотрудника на работе в банке, мы делаем Умный поиск. Мы добавили к чату с нейросетью дополнительный источник, по которому можно искать информацию, и получили Умный поиск по технологии RAG. Мы скармливаем большой языковой модели — LLM, дополнительные локальные знания. Например, Базу знаний о продуктах банка.
Раньше оператор контакт‑центра искал ответ напрямую в базе знаний, переписывал текст о кредите под запрос клиента, проверял свой текст — это, условно, занимало минуту. Умный поиск не просто найдёт все страницы о кредитах в базе знаний. Он учтёт контекст вопроса, изучит разные страницы о кредитах и на их основе выдаст готовый ответ без грамматических ошибок.
На запрос в чат с Умным поиском, ожидание ответа и копирование готового текста уйдёт секунд 15. Вырастет скорость и точность ответов, появится автоматизация.
Если включить Умный поиск, языковая модель обратится к конкретной базе страниц в Confluence или к доскам задач в Jira. Так вы получаете не абстрактный ответ про вообще все проекты, про которые знает интернет, а про конкретные проекты продуктовых команд Альфа‑Банка.
При этом модель понимает, что вы не просто ищете дословное совпадение, а отвечает на ваш вопрос, например, «Что такое AlfaGen».
На первый взгляд, всё логично и понятно. Загрузил базу данных, прикрутил простую фронт‑часть. И вот, менеджер открыл приложение спросить у RAG про открытие кредита.
Ожидание: нейросеть нашла ответ в базе за 3 секунды и составила ответ — бери и отправляй клиенту. Даже корпоративные правила учла и поставила политкорректный эмоджи!
Реальность: модель не поняла контекст и ответила про счёт для бизнеса вместо счёта физлица. Менеджеру пришлось терять время на уточняющий вопрос про физиков. И даже тут ответ не тот, ведь неделю назад правила работы со счетами переписали, а поиск идёт ещё по старой базе. Потом RAG выплюнул ошибку, потому что мы не наладили работу с LLM‑моделями. Идут минуты, очередь клиентов копится, премия утекает сквозь пальцы вместе с лояльностью...
Дальше заглянем под капот и узнаем, насколько глубока кроличья нора, что делать, чтобы ваш RAG работал как в варианте «Ожидание».
Архитектура ARAG
Сейчас в архитектуре ARAG у нас порядка 20 микросервисов. Логика разделена по поиску и загрузке данных. RAG‑ом никого не удивишь, но у нас он немного «не такой» благодаря базе данных Qdrant. К тому же, база шардирована: разные области знаний (домены Confluence) располагаются на разных шардах, что и позволило ускорить поиск.
Ещё из нестандартного к поиску мы прикрутили генерацию синтетических чанков на дополнительной LLM. В момент загрузки данных в базу языковая модель генерирует дополнительные предположения к исходным данным. Таким образом мы пытаемся предугадать, что может спросить пользователь о нашем кусочке текста. Эти вопросы мы сохраняем рядом с исходным текстом, и называем их дочерние чанки («дочки»).
Если пользователь придет и задаст вопрос, который у нас уже есть — мы найдём именно эту «дочку», по ней сможем отыскать исходный кусочек информации и вернуть его пользователю.
На другой стороне RAG'a — в процессе retriever, у нас есть механизм HyDe (Hypothetical Document Expansion), который генерирует дополнительные вопросы, но уже не к исходным данным, а к пользовательскому вопросу.
Получается, пользователь приходит к нам сразу с несколькими вопросами — своим и догенерированным LLM. Так мы расширяем область поиска и с большей вероятностью находим нужный кусочек информации.
Что можно заложить в ARAG «на вырост»
Первый и самый очевидный совет — шардировать и кластеризовать Qdrant для больших проектов. Эта база крута тем, что позволяет хранить дополнительные данные и накладывать фильтры, что делает поиск гибким и точным.
Если у вас всего пара тысяч чанков, хватит чего‑то проще, например, Chroma или PostgreSQL с VectorPG — отличная реляционная база, но там вы сможете хранить разве что сказку про Колобка.
Важно помнить: просто развернуть Qdrant и ждать результатов не получится. Для эффективного поиска нужно понимать работу языковых моделей и уметь грамотно интегрировать RAG‑систему с потоками данных и обработкой запросов. Без этого точность будет далека от ожидаемой.
Не забывайте про фронт‑часть — пользовательский интерфейс для RAG. У нас это Web UI (наша LLM‑платформа с «чатиком») и AI Flow.
И, конечно, нужна идея: что будет искать ваш пользователь и как облегчить ему жизнь. Если идея хорошая, продукт «заживёт» и станет востребованным, а не уляжется в стол после пары демо.
Дальше мы разберём, как из этих четырёх слагаемых собрать продвинутый поиск, который реально работает.
Как подключать базы данных к RAG и не обжечься
Мы подключали к нашему ARAG специфичные источники, например, Базу знаний по продуктам банка. В неё мы обязательно заносим все свежие фичи, описываем их визуал и логику подключения. По базе продакт видит развитие продукта, а оператор контакт‑центра консультирует клиентов.
Подготовить тексты в базе с ИИ
Статьи для баз данных обычно создают продакты или сотрудники поддержки. Про продукты пишут люди с разной подачей, и не все из них копирайтеры. Бывает, что информация размыта и не годится для ответа клиенту.
Что мы делаем: суммаризруем, вытягиваем суть без воды с помощью больших языковых моделей.
Пример реального обращения
Клиент может спросить в чате или на звонке, как закрыть счёт. Оператор отправит этот запрос в RAG. Умный поиск обнаружит, что статьи про закрытие счёта есть в разных разделах базы знаний, потому что непонятно, о каком счёте речь: о корпоративном, бизнес‑счёте для ИП или же клиент хочет просто закрыть карту.
В дело вступает реранжирование. Дополнительный вызов модели позволяет нам изменить оценку чанков, в зависимости от вопроса пользователя. Реранкер — это своего рода «второй взгляд» на результаты поиска. Представьте, что вы ищете информацию в интернете: поисковая система выдаёт список ссылок. Но иногда топ‑результаты не совсем точные или не самые полезные.
Иными словами: поиск выдаёт «черновик» результатов, а реранкер превращает его в «финальный, качественный список».
Что ещё учесть при подключении БД
Ролевая модель: разграничение прав доступа
Наш RAG работает с несколькими ресурсами: Confluence, Jira, База знаний о продуктах банка с разной структурой. Где‑то будут карточки задач, где‑то набор страниц. Часть данных в базах общедоступная, часть закрыта по проектам, часть по статьям. Нужно заложить логику: как искать ответ для юзера с правами суперадмина и для юзера с доступом только к базовым разделам.
Мы собрали на своей стороне отдельный сервис для разграничения прав доступа. Каждый запрос в Умный поиск порождает несколько запросов прав, поэтому такой сервис мы решили взять на себя и обеспечить ему стабильную работу с помощью кеширования и репликации.
Работа с зоопарком баз
Мы делаем внутрибанковский продукт. Наша киллер‑фича — поиск по Confluence. Когда мы запустили ARAG, и люди привыкли им пользоваться, к нам потянулись заказчики из разных команд, которые хотели, чтобы их базу знаний тоже подключили к ARAG.
Они приносили свои базы данных и говорили: «Нам нужна интеграция, чтобы не искать информацию вручную и делать задачи быстрее». При таком формате взаимодействия уходило бы много времени на разработку для каждого заказчика.
Нам очень помог механизм MVP‑прогрузок файлом: заказчик готовил файл определенного формата, мы его загружали в БД, если результаты устраивали обе стороны, мы готовили автоматический загрузчик с возможностью обновлений актуальной информации.
Вам точно стоит заложить такие интеграции и знать ответ, сколько займёт сборка MVP.
Как избежать каши в базе
Когда к RAG начинают подключаться разные команды, быстро возникает проблема: все данные смешиваются в одну большую базу, и поиск начинает работать хуже. Чтобы этого избежать, мы разделяем данные и пользователей на уровне коллекций, доменов и шардов.
Коллекции позволяют логически разделить источники знаний. Например, отдельные коллекции можно создать для:
Confluence,
Jira,
Bitbucket,
продуктовой базы,
индивидуальных баз заказчиков.
Домены помогают объединять данные по смыслу — например, знания про кредиты, карты или внутренние процессы. Это позволяет ограничить поиск только нужной областью знаний.
Шарды используются уже на уровне инфраструктуры. Они распределяют коллекции по разным узлам базы (например, в Qdrant), что ускоряет поиск и снижает нагрузку на систему.
В результате каждый пользователь работает только с теми знаниями, которые ему действительно нужны, а RAG не превращается в огромный и медленный «мешок данных».
Как мы держим RAG актуальным
В начале статьи мы упоминали про переписанные статьи, которые ещё не успели попасть в наш RAG. Это реально боль — когда новые статьи становятся доступны только через неделю, после деплоя. На практике же большинство материалов старше полугода.
Чтобы пользователи получали свежие ответы, нам важно держать статьи актуальными — не старше недели, а лучше — одного дня.
Вот как это работает на примере Confluence:
Получаем диф — узнаём, что изменилось: новые страницы (create), обновлённые (update) или удалённые (delete).
Определяем старые чанки — берём ID тех фрагментов текста, которые придётся удалить после обновления.
Загружаем обновления в Qdrant — всё, что пришло в дифе, добавляется в базу, при этом генерируем синтетический контент для лучшего поиска.
Удаляем устаревшие чанки — старые данные исчезают, остаются только актуальные.
Благодаря такому подходу мы можем постоянно отвечать на вопросы пользователей без перебоев.
Почему обновляемся раз в сутки, а не каждый час? Всё просто: чтобы не нагружать систему избыточными данными. Например если сотрудник написал пару предложений и ушёл за кофе, мы не заберём «часть» его мысли, а дождёмся конца рабочего дня и только после этого добавим информацию в Умный поиск.
Что ещё поделаем в продукте: ближайшие планы, задумки
После раскатки RAG на всех сотрудников банка нам ещё есть что поделать.
Качество и скорость ответов ещё можно улучшить. В идеальной картине скорость ответа на запрос должна составлять от 1 до 3 секунд. На старой архитектуре мы выдавали ответ за 3,5–6 секунд, но и знаний было меньше. Увеличились базы, каждый сервис тянет мощности на себя, а ещё нужно зайти в Confluence и проверить доступы пользователя. С дополнительными настройками Qdrant и некоторой нейромагией мы сможем заехать в 3 секунды.
В это время мы подключаем индивидуальные базы знаний заказчикам — к нам реально выстроилась очередь из проектов.
Параллельно развиваем наш апдейтер, следим, как он автоматом обновляет кусочки данных, которые мы отдаём пользователям.
Где добирать знания по темам: чем пользовались сами, с кем советовались
В минуты отчаяния Когда хотелось погрузиться в тему RAG глубже, мы смотрели вполне стандартные материалы:
Неплохие статьи с Хабра про авточанкование, архитектуру RAG и улучшение точности RAG‑агента.
Можно смотреть видеотуториалы — лучше англоязычные, в русскоязычном сегменте контента по теме мало.
Вместо думскроллинга читаем Телеграм про AI, например, в каналах Big Data AI, Machinelearning, Refat Talks: Tech & AI, AI и грабли бывают любопытные темы.
Помогают новости ресурсов, на которых делаете свой продукт. Мы следим за официальными страницами Qdrant.
В любой удобной вам соцсети и мессенджере читайте, на чём можно запускать LLM и ныряйте в соседние темы.
На этом всё. Задавайте вопросы в комментариях. Ну и пишите, о каких нюансах промышленного RAG мы ещё не упомянули.
