Проектирование многопользовательской RAG с Milvus: лучшие практики для масштабируемых корпоративных баз знаний
Введение
За последние пару лет Retrieval-Augmented Generation (RAG) стала надежным решением для крупных организаций, позволяющим улучшать их приложения на базе LLM, особенно приложения с разнообразными пользователями. По мере роста таких приложений внедрение мультитенантной архитектуры становится необходимым. Мультитенантность обеспечивает безопасный, изолированный доступ к данным для разных групп пользователей, укрепляя доверие пользователей, помогая соответствовать нормативным требованиям и повышая операционную эффективность.
Milvus — это open-source векторная база данных, созданная для работы с высокоразмерными векторными данными. Она является незаменимым инфраструктурным компонентом RAG, храня и извлекая контекстную информацию для LLM из внешних источников. Milvus предлагает гибкие стратегии мультитенантности для различных потребностей, включая мультитенантность на уровне базы данных, коллекции и раздела.
В этой статье мы рассмотрим:
Что такое мультитенантность и почему она важна
Стратегии мультитенантности в Milvus
Пример: стратегия мультитенантности для корпоративной базы знаний на базе RAG
Что такое мультитенантность и почему она важна
Мультитенантность — это архитектура, в которой несколько клиентов или команд, известных как "тенанты," совместно используют один экземпляр приложения или системы. Данные и конфигурации каждого тенанта логически изолированы, что обеспечивает конфиденциальность и безопасность, при этом все тенанты используют одну и ту же базовую инфраструктуру.
Представьте SaaS-платформу, которая предоставляет решения на основе знаний нескольким компаниям. Каждая компания является тенантом.
Тенант A — медицинская организация, хранящая FAQ для пациентов и документы по соблюдению нормативных требований.
Тенант B — технологическая компания, управляющая внутренними рабочими процессами устранения неполадок в IT.
Тенант C — розничный бизнес с FAQ службы поддержки клиентов по возврату товаров.
Каждый тенант работает в полностью изолированной среде, что гарантирует, что данные Тенанта A не попадут в систему Тенанта B и наоборот. Кроме того, распределение ресурсов, производительность запросов и решения по масштабированию определяются для каждого тенанта отдельно, обеспечивая высокую производительность независимо от всплесков нагрузки у одного из тенантов.
Мультитенантность также подходит для систем, обслуживающих разные команды внутри одной организации. Представьте крупную компанию, использующую базу знаний на базе RAG для внутренних отделов, таких как HR, юридический отдел и маркетинг. В такой конфигурации каждый отдел является тенантом с изолированными данными и ресурсами.
Мультитенантность дает значительные преимущества, включая экономическую эффективность, масштабируемость и надежную безопасность данных. Совместно используя единую инфраструктуру, поставщики услуг могут снизить накладные расходы и обеспечить более эффективное потребление ресурсов. Такой подход также легко масштабируется — подключение новых тенантов требует значительно меньше ресурсов, чем создание отдельных экземпляров для каждого, как в моделях с одним тенантом. Важно, что мультитенантность поддерживает надежную безопасность данных, обеспечивая строгую изоляцию данных для каждого тенанта, а средства контроля доступа и шифрование защищают конфиденциальную информацию от несанкционированного доступа. Кроме того, обновления, исправления и новые функции можно развертывать для всех тенантов одновременно, упрощая обслуживание системы и снижая нагрузку на администраторов, при этом обеспечивая постоянное соблюдение стандартов безопасности и соответствия требованиям.
Стратегии мультитенантности в Milvus
Чтобы понять, как Milvus поддерживает мультитенантность, важно сначала рассмотреть, как он организует пользовательские данные.
Как Milvus организует пользовательские данные
Milvus структурирует данные по трем уровням, от общего к более детальному: Database, Collection и Partition/Partition Key.
Figure- How Milvus organizes user data .png
Рисунок: как Milvus организует пользовательские данные
Database: Выступает в роли логического контейнера, аналогичного базе данных в традиционных реляционных системах.
Collection: Сопоставима с таблицей в базе данных; коллекция организует данные в управляемые группы.
Partition/Partition Key: Внутри коллекции данные могут быть дополнительно сегментированы с помощью Partitions. Используя Partition Key, данные с одинаковым ключом группируются вместе. Например, если использовать user ID в качестве Partition Key, все данные конкретного пользователя будут храниться в одном и том же логическом сегменте. Это упрощает извлечение данных, связанных с отдельными пользователями.
По мере перехода от Database к Collection и далее к Partition Key детализация организации данных становится все более тонкой.
Для обеспечения более надежной безопасности данных и надлежащего контроля доступа Milvus также предоставляет мощный Role-Based Access Control (RBAC), позволяющий администраторам задавать конкретные разрешения для каждого пользователя. Доступ к определенным данным могут получать только авторизованные пользователи.
Milvus поддерживает несколько стратегий реализации мультитенантности, обеспечивая гибкость в зависимости от потребностей вашего приложения: мультитенантность на уровне базы данных, на уровне коллекции и на уровне разделов.
Мультитенантность на уровне базы данных
При подходе мультитенантности на уровне базы данных каждому тенанту назначается собственная база данных в рамках одного и того же кластера Milvus. Эта стратегия обеспечивает надежную изоляцию данных и оптимальную производительность поиска. Однако она может приводить к неэффективному использованию ресурсов, если некоторые тенанты остаются неактивными.
Мультитенантность на уровне коллекции
Здесь, при мультитенантности на уровне коллекции, мы можем организовывать данные тенантов двумя способами.
Одна коллекция для всех тенантов: Все тенанты совместно используют одну коллекцию, а для фильтрации применяются поля, специфичные для тенанта. Хотя этот подход прост в реализации, по мере увеличения числа тенантов он может сталкиваться с узкими местами в производительности.
Одна коллекция на тенанта: У каждого тенанта может быть выделенная коллекция, что улучшает изоляцию и производительность, но требует больше ресурсов. Такая схема может столкнуться с ограничениями масштабируемости, если число тенантов превысит емкость Milvus по количеству коллекций.
Мультитенантность на уровне разделов
Мультитенантность на уровне разделов сосредоточена на организации тенантов в рамках одной коллекции. Здесь у нас также есть два способа организовать данные тенантов.
Один раздел на тенанта: Тенанты совместно используют коллекцию, но их данные хранятся в отдельных разделах. Мы можем изолировать данные, назначив каждому тенанту выделенный раздел, сбалансировав изоляцию и производительность поиска. Однако этот подход ограничен максимальным лимитом разделов в Milvus.
Мультитенантность на основе Partition Key: Это более масштабируемый вариант, при котором одна коллекция использует ключи разделов для различения тенантов. Этот метод упрощает управление ресурсами и поддерживает более высокую масштабируемость, но не поддерживает массовые вставки данных.
В таблице ниже приведены основные различия между ключевыми подходами к мультитенантности.
| Гранулярность | На уровне базы данных | На уровне коллекции | На уровне ключа партиционирования |
|---|---|---|---|
| Макс. поддерживаемое число арендаторов | ~1,000 | ~10,000 | ~10,000,000 |
| Гибкость организации данных | Высокая: пользователи могут определять несколько коллекций с пользовательскими схемами. | Средняя: пользователи ограничены одной коллекцией с пользовательской схемой. | Низкая: все пользователи совместно используют одну коллекцию, что требует единой схемы. |
| Стоимость на пользователя | Высокая | Средняя | Низкая |
| Изоляция физических ресурсов | Да | Да | Нет |
| RBAC | Да | Да | Нет |
| Производительность поиска | Высокая | Средняя | Высокая |
Пример: стратегия мультитенантности для корпоративной базы знаний на базе RAG
При проектировании стратегии мультитенантности для системы RAG важно согласовать подход с конкретными потребностями вашего бизнеса и ваших арендаторов. Milvus предлагает различные стратегии мультитенантности, и выбор правильной зависит от количества арендаторов, их требований и необходимого уровня изоляции данных. Ниже приведено практическое руководство по принятию таких решений на примере корпоративной базы знаний на базе RAG.
Понимание структуры арендаторов перед выбором стратегии мультитенантности
Корпоративная база знаний на базе RAG часто обслуживает небольшое число арендаторов. Эти арендаторы обычно являются независимыми бизнес-подразделениями, такими как IT, Sales, Legal и Marketing, каждому из которых требуются отдельные сервисы базы знаний. Например, отдел HR управляет конфиденциальной информацией о сотрудниках, такой как руководства по адаптации и политики льгот, которая должна быть конфиденциальной и доступной только сотрудникам HR.
В этом случае каждое бизнес-подразделение следует рассматривать как отдельного арендатора, и стратегия мультитенантности на уровне базы данных часто является наиболее подходящей. Назначая каждому арендатору выделенные базы данных, организации могут обеспечить строгую логическую изоляцию, упростить управление и повысить безопасность. Такая конфигурация предоставляет арендаторам значительную гибкость — они могут определять пользовательские модели данных внутри коллекций, создавать столько коллекций, сколько необходимо, и независимо управлять контролем доступа к своим коллекциям.
Повышение безопасности с помощью изоляции физических ресурсов
В ситуациях, когда безопасность данных является высоким приоритетом, логической изоляции на уровне базы данных может быть недостаточно. Например, некоторые бизнес-подразделения могут обрабатывать критически важные или особо конфиденциальные данные, что требует более строгих гарантий защиты от вмешательства со стороны других арендаторов. В таких случаях мы можем реализовать подход физической изоляции поверх структуры мультитенантности на уровне базы данных.
Milvus позволяет нам сопоставлять логические компоненты, такие как базы данных и коллекции, с физическими ресурсами. Этот метод гарантирует, что активность других арендаторов не влияет на критически важные операции. Давайте рассмотрим, как этот подход работает на практике.
Figure- How Milvus manages physical resources.png
Рисунок: Как Milvus управляет физическими ресурсами
Как показано на диаграмме выше, в Milvus есть три уровня управления ресурсами: Query Node, Resource Group и Database.
Query Node: Компонент, который обрабатывает задачи запросов. Он работает на физической машине или в контейнере (например, в pod в Kubernetes).
Resource Group: Набор Query Nodes, который действует как мост между логическими компонентами (базами данных и коллекциями) и физическими ресурсами. Вы можете выделить одну или несколько баз данных или коллекций одному Resource Group.
В примере, показанном на диаграмме выше, есть три логические Databases: X, Y и Z.
Database X: Содержит Collection A.
Database Y: Содержит Collections B и C.
Database Z: Содержит Collections D и E.
Допустим, Database X содержит критически важную базу знаний, на которую мы не хотим, чтобы влияла нагрузка от Database Y или Database Z. Чтобы обеспечить изоляцию данных:
Database X назначена собственная Resource Group, чтобы гарантировать, что ее критически важная база знаний не будет затронута рабочими нагрузками из других баз данных.
Collection E также выделена отдельной Resource Group внутри своей родительской базы данных (Z). Это обеспечивает изоляцию на уровне коллекции для конкретных критически важных данных внутри общей базы данных.
Тем временем остальные коллекции в Databases Y и Z совместно используют физические ресурсы Resource Group 2.
Тщательно сопоставляя логические компоненты с физическими ресурсами, организации могут создать гибкую, масштабируемую и безопасную архитектуру мультиарендности, адаптированную к их конкретным бизнес-потребностям.
Проектирование доступа на уровне конечного пользователя
Теперь, когда мы изучили лучшие практики выбора стратегии мультиарендности для корпоративной RAG, давайте рассмотрим, как проектировать доступ на уровне пользователя в таких системах.
В этих системах конечные пользователи обычно взаимодействуют с базой знаний в режиме только для чтения через LLMs. Однако организациям по-прежнему необходимо отслеживать такие данные вопросов и ответов, генерируемые пользователями, и связывать их с конкретными пользователями для различных целей, например для повышения точности базы знаний или предоставления персонализированных сервисов.
Возьмем в качестве примера интеллектуальную консультационную стойку обслуживания в больнице. Пациенты могут задавать вопросы вроде: «Есть ли сегодня свободные записи к специалисту?» или "Нужна ли какая-либо специальная подготовка к моей предстоящей операции?" Хотя эти вопросы не влияют напрямую на базу знаний, для больницы важно отслеживать такие взаимодействия, чтобы улучшать услуги. Эти пары вопросов и ответов обычно хранятся в отдельной базе данных (это не обязательно должна быть векторная база данных), предназначенной для журналирования взаимодействий.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
Рисунок: Архитектура мультиарендности для корпоративной базы знаний RAG
Диаграмма выше показывает архитектуру мультиарендности корпоративной системы RAG.
System Administrators контролируют систему RAG, управляют распределением ресурсов, назначают базы данных, сопоставляют их с ресурсными группами и обеспечивают масштабируемость. Они обслуживают физическую инфраструктуру, как показано на диаграмме, где каждая ресурсная группа (например, Resource Group 1, 2 и 3) сопоставлена с физическими серверами (query nodes).
Арендаторы (владельцы баз данных и разработчики) управляют базой знаний, итеративно улучшая её на основе данных Q&A, созданных пользователями, как показано на диаграмме. Разные базы данных (Database X, Y, Z) содержат коллекции с различным содержимым базы знаний (Collection A, B и т. д.).
Конечные пользователи взаимодействуют с системой в режиме только чтения через LLM. Когда они отправляют запросы в систему, их вопросы записываются в отдельную таблицу записей Q&A (отдельную базу данных), постоянно возвращая в систему ценные данные.
Такой дизайн гарантирует, что каждый уровень процесса — от взаимодействия с пользователем до администрирования системы — работает слаженно, помогая организации создавать надёжную и постоянно совершенствующуюся базу знаний.
Резюме
В этом блоге мы рассмотрели, как фреймворки мультитенантности играют критически важную роль в масштабируемости, безопасности и производительности баз знаний на базе RAG. Изолируя данные и ресурсы для разных арендаторов, компании могут обеспечивать конфиденциальность, соответствие нормативным требованиям и оптимизированное распределение ресурсов в общей инфраструктуре. Milvus, благодаря своим гибким стратегиям мультитенантности, позволяет компаниям выбирать нужный уровень изоляции данных — от уровня базы данных до уровня раздела — в зависимости от их конкретных потребностей. Выбор правильного подхода к мультитенантности гарантирует, что компании смогут предоставлять арендаторам индивидуализированные услуги, даже при работе с разнообразными данными и рабочими нагрузками.
Следуя изложенным здесь лучшим практикам, организации могут эффективно проектировать и управлять мультитенантными RAG-системами, которые не только обеспечивают превосходный пользовательский опыт, но и легко масштабируются по мере роста бизнес-потребностей. Архитектура Milvus гарантирует, что предприятия смогут поддерживать высокие уровни изоляции, безопасности и производительности, что делает её важнейшим компонентом при создании корпоративных баз знаний на базе RAG.
Следите за новыми материалами о мультитенантном RAG
В этом блоге мы обсудили, как стратегии мультитенантности Milvus предназначены для управления арендаторами, но не конечными пользователями внутри этих арендаторов. Взаимодействия конечных пользователей обычно происходят на уровне приложения, тогда как сама векторная база данных ничего не знает об этих пользователях.
Возможно, вы задаётесь вопросом: Если я хочу предоставлять более точные ответы на основе истории запросов каждого конечного пользователя, разве Milvus не нужно поддерживать персонализированный контекст Q&A для каждого пользователя?
Это отличный вопрос, и ответ действительно зависит от конкретного сценария использования. Например, в консультационном сервисе по запросу запросы случайны, и основной акцент делается на качестве базы знаний, а не на отслеживании исторического контекста пользователя.
Однако в других случаях RAG-системы должны учитывать контекст. Когда это требуется, Milvus необходимо взаимодействовать с уровнем приложения, чтобы поддерживать персонализированную память о контексте каждого пользователя. Такой дизайн особенно важен для приложений с огромным числом конечных пользователей, что мы более подробно рассмотрим в моей следующей публикации. Следите за новыми материалами!
Читать далее
VDBBench Adds Cost-Aware Benchmarking for Vector Databases
Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.