Проектирование многопользовательских RAG с помощью Milvus: лучшие практики для масштабируемых корпоративных баз знаний

Введение

За последние несколько лет технология Retrieval-Augmented Generation (RAG) стала надежным решением для крупных организаций, позволяющим усовершенствовать их приложения на базе LLM, особенно те, в которых работают разные пользователи. По мере роста таких приложений внедрение многопользовательской системы становится необходимым. Многопользовательская среда обеспечивает безопасный изолированный доступ к данным для различных групп пользователей, гарантируя доверие пользователей, соответствие нормативным стандартам и повышение эффективности работы.

Milvus - это векторная база данных с открытым исходным кодом, созданная для работы с высокоразмерными векторными данными. Она является незаменимым инфраструктурным компонентом RAG, хранящим и извлекающим контекстную информацию для LLM из внешних источников. Milvus предлагает гибкие стратегии многопользовательского доступа для различных нужд, включая многопользовательский доступ на уровне базы данных, коллекции и раздела.

В этом посте мы расскажем:

• Что такое мультиарендность и почему она важна.

• Стратегии многопользовательской аренды в Milvus

• Пример: Стратегия многопользовательского доступа для корпоративной базы знаний на базе RAG

Что такое мультиарендность и почему она важна

Мультиарендность - это архитектура, в которой несколько клиентов или команд, известных как "арендаторы", совместно используют один экземпляр приложения или системы. Данные и конфигурации каждого арендатора логически изолированы, что обеспечивает конфиденциальность и безопасность, в то время как все арендаторы используют одну и ту же базовую инфраструктуру.

Представьте себе платформу SaaS, которая предоставляет решения на основе знаний нескольким компаниям. Каждая компания является арендатором.

• Арендатор A - это медицинская организация, хранящая часто задаваемые вопросы для пациентов и документы о соответствии нормативным требованиям.

• Арендатор B - технологическая компания, управляющая внутренними рабочими процессами по устранению неполадок в ИТ.

• Арендатор C - компания розничной торговли, в которой хранятся часто задаваемые вопросы по обслуживанию клиентов для возврата товаров.

Каждый арендатор работает в полностью изолированной среде, гарантируя, что данные арендатора A не просочатся в систему арендатора B и наоборот. Кроме того, распределение ресурсов, производительность запросов и решения по масштабированию зависят от конкретного арендатора, что обеспечивает высокую производительность независимо от скачков нагрузки на одного арендатора.

Многопользовательская система также подходит для систем, обслуживающих разные команды в одной организации. Представьте себе крупную компанию, использующую базу знаний на базе RAG для обслуживания своих внутренних отделов, таких как отдел кадров, юридический отдел и отдел маркетинга. В этом случае каждый отдел является арендатором с изолированными данными и ресурсами.

Многопользовательская аренда дает значительные преимущества, включая экономическую эффективность, масштабируемость и надежную защиту данных. Благодаря совместному использованию единой инфраструктуры поставщики услуг могут сократить накладные расходы и обеспечить более эффективное использование ресурсов. Кроме того, этот подход легко масштабируется - для подключения новых арендаторов требуется гораздо меньше ресурсов, чем при создании отдельных экземпляров для каждого из них, как в моделях с одним арендатором. Важно отметить, что многопользовательский подход обеспечивает надежную защиту данных, гарантируя строгую изоляцию данных для каждого арендатора, а также контроль доступа и шифрование, защищающие конфиденциальную информацию от несанкционированного доступа. Кроме того, обновления, исправления и новые функции могут быть развернуты одновременно для всех арендаторов, что упрощает обслуживание системы и снижает нагрузку на администраторов, обеспечивая постоянное соблюдение стандартов безопасности и соответствия.

Стратегии многопользовательской работы в Milvus

Чтобы понять, как Milvus поддерживает многопользовательскую работу, важно сначала рассмотреть, как он организует пользовательские данные.

Как Milvus организует пользовательские данные

Milvus структурирует данные на трех уровнях, двигаясь от широкого к гранулированному: База данных, Коллекция и Раздел/ключ раздела.

Рисунок - Как Milvus организует пользовательские данные .png

Рисунок: Как Milvus организует пользовательские данные

• База данных: Действует как логический контейнер, подобно базе данных в традиционных реляционных системах.

• Коллекция: Сравнимая с таблицей в базе данных, коллекция организует данные в управляемые группы.

• Раздел/ключ раздела: Внутри коллекции данные могут быть разделены на разделы. С помощью ключа раздела данные с одинаковым ключом группируются вместе. Например, если в качестве ключа раздела используется идентификатор пользователя, все данные для конкретного пользователя будут храниться в одном логическом сегменте. Это упрощает получение данных, связанных с отдельными пользователями.

По мере перехода от базы данных к коллекции и ключу раздела детализация организации данных становится все более тонкой.

Для обеспечения большей безопасности данных и надлежащего контроля доступа Milvus также предоставляет надежный контроль доступа на основе ролей (RBAC), позволяющий администраторам определять конкретные разрешения для каждого пользователя. Только авторизованные пользователи могут получить доступ к определенным данным.

Milvus поддерживает несколько стратегий реализации многопользовательского доступа, обеспечивая гибкость в зависимости от потребностей вашего приложения: многопользовательский доступ на уровне базы данных, на уровне коллекций и на уровне разделов.

Многопользовательская лицензия на уровне базы данных

При многопользовательском подходе на уровне базы данных каждому арендатору назначается своя база данных в рамках одного кластера Milvus. Эта стратегия обеспечивает надежную изоляцию данных и оптимальную производительность поиска. Однако она может привести к неэффективному использованию ресурсов, если некоторые арендаторы остаются неактивными.

Многопользовательская аренда на уровне коллекции

При мультиарендности на уровне коллекций мы можем организовать данные для арендаторов двумя способами.

• Одна коллекция для всех арендаторов: Все арендаторы пользуются одной коллекцией, а для фильтрации используются поля, относящиеся к конкретным арендаторам. Несмотря на простоту реализации, такой подход может столкнуться с узкими местами в производительности при увеличении числа арендаторов.

• Одна коллекция для каждого арендатора: Каждый арендатор может иметь отдельную коллекцию, что улучшает изоляцию и производительность, но требует больше ресурсов. Такая схема может столкнуться с ограничениями масштабируемости, если количество арендаторов превысит возможности коллекции Milvus.

Многопользовательская аренда на уровне разделов

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

• Один раздел на арендатора: Арендаторы совместно используют коллекцию, но их данные хранятся в отдельных разделах. Мы можем изолировать данные, назначив каждому арендатору отдельный раздел, что позволит сбалансировать изоляцию и производительность поиска. Однако этот подход ограничен максимальным лимитом разделов Milvus.

• Мультиарендаторство на основе ключей разделов: Это более масштабируемый вариант, при котором единая коллекция использует ключи разделов для разграничения арендаторов. Этот метод упрощает управление ресурсами и обеспечивает более высокую масштабируемость, но не поддерживает массовую вставку данных.

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

Гранулярность	Уровень базы данных	Уровень коллекции	Уровень ключа раздела
Максимальное количество поддерживаемых арендаторов	~1,000	~10,000	~10,000,000
Гибкость организации данных	Высокая: Пользователи могут определять несколько коллекций с пользовательскими схемами.	Средний: Пользователи ограничены одной коллекцией с пользовательской схемой.	Низкая: все пользователи используют одну коллекцию, что требует согласованной схемы.
Стоимость для одного пользователя	Высокая	Средняя	Низкая
Изоляция физических ресурсов	Да	Да	Нет
RBAC	Да	Да	Нет
Производительность поиска	Сильный	Средняя	Сильный

Пример: Стратегия многопользовательской аренды для корпоративной базы знаний на базе RAG

При разработке стратегии многопользовательской аренды для системы RAG важно согласовать свой подход с конкретными потребностями вашего бизнеса и ваших арендаторов. Milvus предлагает различные стратегии многопользовательской работы, и выбор правильной стратегии зависит от количества арендаторов, их требований и необходимого уровня изоляции данных. Вот практическое руководство по принятию этих решений на примере корпоративной базы знаний на базе RAG.

Понимание структуры арендаторов перед выбором стратегии многопользовательской работы

Корпоративная база знаний на базе RAG часто обслуживает небольшое количество арендаторов. Эти арендаторы обычно являются независимыми бизнес-подразделениями, такими как ИТ-отдел, отдел продаж, юридический отдел и отдел маркетинга, каждому из которых требуются отдельные услуги базы знаний. Например, отдел кадров управляет конфиденциальной информацией о сотрудниках, такой как руководства по вступлению в должность и политика льгот, которая должна быть конфиденциальной и доступной только для сотрудников отдела кадров.

В этом случае каждое подразделение должно рассматриваться как отдельный арендатор, и стратегия многопользовательской аренды на уровне баз данных часто является наиболее подходящей. Назначая выделенные базы данных для каждого арендатора, организации могут добиться сильной логической изоляции, упростить управление и повысить безопасность. Такая схема обеспечивает арендаторам значительную гибкость - они могут определять пользовательские модели данных в коллекциях, создавать столько коллекций, сколько необходимо, и самостоятельно управлять контролем доступа к своим коллекциям.

Повышение безопасности с помощью физической изоляции ресурсов

В ситуациях, когда безопасности данных придается большое значение, логической изоляции на уровне базы данных может быть недостаточно. Например, некоторые бизнес-подразделения могут работать с критическими или очень чувствительными данными, требуя более надежных гарантий от вмешательства других арендаторов. В таких случаях мы можем реализовать подход физической изоляции поверх структуры многопользовательской аренды на уровне базы данных.

Milvus позволяет нам сопоставлять логические компоненты, такие как базы данных и коллекции, с физическими ресурсами. Этот метод гарантирует, что деятельность других арендаторов не повлияет на критически важные операции. Давайте рассмотрим, как этот подход работает на практике.

Рисунок - Как Milvus управляет физическими ресурсами.png

Рисунок: Как Milvus управляет физическими ресурсами

Как показано на диаграмме выше, в Milvus существует три уровня управления ресурсами: Узел запросов, Группа ресурсов и База данных.

• Узел запросов: Компонент, обрабатывающий задачи запросов. Он работает на физической машине или в контейнере (например, в капсуле в Kubernetes).

• Группа ресурсов (Resource Group): Набор узлов запросов, который выступает в качестве связующего звена между логическими компонентами (базами данных и коллекциями) и физическими ресурсами. Вы можете назначить одну или несколько баз данных или коллекций одной группе ресурсов.

В примере, показанном на диаграмме выше, есть три логические базы данных: X, Y и Z.

• База данных X: содержит коллекцию A.

• База данных Y: содержит коллекции B и C.

• База данных Z: содержит коллекции D и E.

Допустим, в базе данных X хранится критически важная база знаний, на которую не должна влиять нагрузка из базы данных Y или Z. Чтобы обеспечить изоляцию данных:

• Базе данных X назначается собственная группа ресурсов, чтобы гарантировать, что ее критическая база знаний не будет затронута нагрузкой от других баз данных.

• Коллекция E также выделена в отдельную группу ресурсов в родительской базе данных(Z). Это обеспечивает изоляцию на уровне коллекции для конкретных критических данных в общей базе данных.

Тем временем остальные коллекции в базах данных Y и Z совместно используют физические ресурсы группы ресурсов 2.

Тщательно сопоставляя логические компоненты с физическими ресурсами, организации могут создать гибкую, масштабируемую и безопасную архитектуру многопользовательского доступа, соответствующую их специфическим бизнес-потребностям.

Проектирование доступа на уровне конечного пользователя

Теперь, когда мы ознакомились с лучшими практиками выбора стратегии многопользовательского доступа для корпоративной RAG, давайте рассмотрим, как спроектировать доступ на уровне пользователя в таких системах.

В таких системах конечные пользователи обычно взаимодействуют с базой знаний в режиме "только чтение" через LLM. Однако организациям все равно необходимо отслеживать данные вопросов и ответов, генерируемые пользователями, и связывать их с конкретными пользователями для различных целей, например для повышения точности базы знаний или предоставления персонализированных услуг.

Возьмем для примера интеллектуальную консультационную службу больницы. Пациенты могут задавать такие вопросы, как "Есть ли сегодня свободные встречи со специалистом?" или "Нужна ли какая-то особая подготовка к предстоящей операции?". Хотя эти вопросы не оказывают прямого влияния на базу знаний, больнице важно отслеживать такие взаимодействия для улучшения качества обслуживания. Эти пары вопросов и ответов обычно хранятся в отдельной базе данных (не обязательно векторной), предназначенной для регистрации взаимодействий.

Рисунок - Архитектура многопользовательского доступа для корпоративной базы знаний RAG .png

Рисунок: Многопользовательская архитектура для корпоративной базы знаний RAG

На диаграмме выше показана многопользовательская архитектура корпоративной системы RAG.

• Системные администраторы следят за работой системы RAG, управляют распределением ресурсов, назначают базы данных, сопоставляют их с группами ресурсов и обеспечивают масштабируемость. Они управляют физической инфраструктурой, как показано на диаграмме, где каждая группа ресурсов (например, группа ресурсов 1, 2 и 3) сопоставлена с физическими серверами (узлами запросов).

• Арендаторы (владельцы и разработчики баз данных) управляют базой знаний, итерируя ее на основе данных вопросов и ответов, генерируемых пользователями, как показано на диаграмме. Различные базы данных (Database X, Y, Z) содержат коллекции с различным содержанием базы знаний (Collection A, B и т. д.).

• Конечные пользователи взаимодействуют с системой только в режиме чтения через LLM. По мере того как они запрашивают систему, их вопросы регистрируются в отдельной таблице записей вопросов и ответов (отдельная база данных), непрерывно передавая ценные данные обратно в систему.

Такая конструкция обеспечивает бесперебойную работу каждого уровня процесса - от взаимодействия с пользователями до администрирования системы, - помогая организации создать надежную и постоянно совершенствующуюся базу знаний.

Резюме

В этом блоге мы рассмотрели, как фреймворки с множественными правами аренды играют важную роль в масштабируемости, безопасности и производительности баз знаний на основе RAG. Изолируя данные и ресурсы для разных арендаторов, компании могут обеспечить конфиденциальность, соответствие нормативным требованиям и оптимизировать распределение ресурсов в общей инфраструктуре. Milvus с его гибкими стратегиями многопользовательской аренды позволяет предприятиям выбирать нужный уровень изоляции данных - от уровня базы данных до уровня раздела - в зависимости от их конкретных потребностей. Правильный выбор многопользовательского подхода позволяет компаниям предоставлять арендаторам индивидуальные услуги даже при работе с различными данными и рабочими нагрузками.

Следуя приведенным здесь рекомендациям, организации могут эффективно проектировать и управлять системами RAG с несколькими арендаторами, которые не только обеспечивают превосходный пользовательский опыт, но и легко масштабируются по мере роста потребностей бизнеса. Архитектура Milvus позволяет предприятиям поддерживать высокий уровень изоляции, безопасности и производительности, что делает ее важнейшим компонентом для создания баз знаний RAG корпоративного уровня.

Оставайтесь с нами, чтобы узнать больше о многопользовательской системе RAG

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

Вы можете задаться вопросом: Если я хочу предоставлять более точные ответы на основе истории запросов каждого конечного пользователя, разве Milvus не должен поддерживать персонализированный контекст вопросов и ответов для каждого пользователя?

Это отличный вопрос, и ответ на него зависит от конкретного случая использования. Например, в службе консультаций по требованию запросы носят случайный характер, и основное внимание уделяется качеству базы знаний, а не отслеживанию исторического контекста пользователя.

Однако в других случаях системы RAG должны учитывать контекст. Когда это требуется, Milvus должен сотрудничать с прикладным уровнем, чтобы поддерживать персонализированную память о контексте каждого пользователя. Такая конструкция особенно важна для приложений с большим количеством конечных пользователей, о чем мы подробнее расскажем в моем следующем посте. Оставайтесь с нами, чтобы узнать больше!