RAG без седых волос (или с?)

Привет! Мы разработчики Умного поиска 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:

1. Получаем диф — узнаём, что изменилось: новые страницы (create), обновлённые (update) или удалённые (delete).

2. Определяем старые чанки — берём ID тех фрагментов текста, которые придётся удалить после обновления.

3. Загружаем обновления в Qdrant — всё, что пришло в дифе, добавляется в базу, при этом генерируем синтетический контент для лучшего поиска.

4. Удаляем устаревшие чанки — старые данные исчезают, остаются только актуальные.

Благодаря такому подходу мы можем постоянно отвечать на вопросы пользователей без перебоев.

Почему обновляемся раз в сутки, а не каждый час? Всё просто: чтобы не нагружать систему избыточными данными. Например если сотрудник написал пару предложений и ушёл за кофе, мы не заберём «часть» его мысли, а дождёмся конца рабочего дня и только после этого добавим информацию в Умный поиск.

Что ещё поделаем в продукте: ближайшие планы, задумки

После раскатки 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 мы ещё не упомянули.