Проектирование безопасного мультитенантного решения для вывода RAG
Retrieval-Augmented поколение (RAG) — это шаблон для создания приложений, использующих фундаментальные модели для анализа конфиденциальной информации или других данных, недоступных в Интернете. Как правило, клиентское приложение вызывает уровень оркестрации, который получает соответствующие сведения из хранилища данных, например векторной базы данных. Уровень оркестрации передает эти данные в рамках контекста в качестве грунтующей информации в базовую модель.
Мультитенантное решение используется несколькими клиентами. Каждый клиент или арендатор состоит из нескольких пользователей из одной организации, компании или группы. В многопользовательских сценариях необходимо убедиться, что арендаторы или отдельные лица в рамках арендаторов могут включать только те данные, к которым у них есть разрешение на доступ.
Существуют проблемы многопользовательских систем, помимо необходимости обеспечить, чтобы пользователи имели доступ только к тем данным, к которым они имеют авторизацию. Однако в этой статье основное внимание уделяется этому аспекту мультитенантности. Эта статья начинается с обзора однопользовательских архитектур RAG. В ней рассматриваются проблемы, которые могут возникнуть в мультитенантном окружении с использованием RAG, и некоторые распространенные подходы для их решения. В нем также описываются рекомендации по мультитенантности и рекомендации по улучшению безопасности.
Заметка
В этой статье описывается несколько функций, относящихся к службе Azure OpenAI, например функции Azure OpenAI On Your Data. Однако большинство принципов, описанных в этой статье, можно применять к базовым моделям ИИ на любой платформе.
Архитектура RAG с одним клиентом с оркестратором
Рабочий процесс
В этой архитектуре RAG с одним арендатором оркестратор извлекает соответствующие данные частного арендатора из хранилищ данных и предоставляет их в качестве опорных данных в базовую модель. В следующих шагах описывается высокоуровневый рабочий процесс.
- Пользователь выдает запрос интеллектуальному веб-приложению.
- Поставщик удостоверений проверяет подлинность запрашивающего.
- Интеллектуальное приложение обращается к API оркестратора с запросом пользователя и токеном авторизации пользователя.
- Логика оркестрации извлекает пользовательский запрос из обращения и обращается к нужному хранилищу данных для получения релевантных данных для запроса. Данные заземления добавляются в запрос, который отправляется в базовую модель, например модель, которая предоставляется в Azure OpenAI, на следующем шаге.
- Логика оркестрации подключается к API вывода базовой модели и отправляет запрос, содержащий извлеченные данные о заземления. Результаты возвращаются интеллектуальному приложению.
Дополнительные сведения см. в статье Проектирование и разработка решения RAG.
Архитектура RAG с одним клиентом с прямым доступом к данным
Этот вариант архитектуры RAG с одним клиентом использует функцию On Your Data Azure OpenAI для интеграции непосредственно с хранилищами данных, такими как поиск ИИ Azure. В этой архитектуре у вас либо нет собственного оркестратора, либо у оркестратора меньше обязанностей. API Azure OpenAI вызывается в хранилище данных для получения данных заземления и передачи данных в языковую модель. Этот метод обеспечивает меньше контроля над тем, какие данные заземления следует получить и релевантность этих данных.
Заметка
Azure OpenAI управляется корпорацией Майкрософт. Она интегрируется с хранилищем данных, но сама модель не интегрируется с хранилищем данных. Модель получает опорные данные точно так же, как и когда эти данные извлекаются оркестратором.
Рабочий процесс
В этой архитектуре RAG служба, предоставляющая базовую модель, извлекает соответствующие данные частного клиента из хранилищ данных и использует эти данные в качестве базирования данных в базовой модели. В следующих шагах описывается высокоуровневый рабочий процесс. Курсивные шаги идентичны предыдущей архитектуре RAG для одного арендатора, которая имеет оркестрацию рабочего процесса.
- Пользователь выдает запрос интеллектуальному веб-приложению.
- Поставщик удостоверений аутентифицирует запрашивающего.
- Интеллектуальное приложение вызывает Azure OpenAI с запросом пользователя.
- Azure OpenAI подключается к поддерживаемым хранилищам данных, таким как ИИ Поиск и Azure Blob Storage, для получения исходных данных. Данные заземления используются в рамках контекста, когда Azure OpenAI вызывает языковую модель OpenAI. Результаты возвращаются интеллектуальному приложению.
Если вы хотите использовать эту архитектуру в мультитенантном решении, служба, которая напрямую обращается к данным заземления, например Azure OpenAI, должна поддерживать мультитенантную логику, которую требует ваше решение.
Многотенантность в архитектуре RAG
В мультитенантных решениях данные клиента могут существовать в хранилище для конкретного клиента или сосуществовать с другими клиентами в мультитенантном хранилище. Данные также могут находиться в совместном хранилище, которое используется арендаторами. Только данные, к которым пользователь имеет разрешение на доступ, должны использоваться в качестве базовых данных. Пользователь должен видеть только общие или все данные клиента или данные из своего клиента, которые фильтруются, чтобы убедиться, что они видят только те данные, к которым они авторизованы для доступа.
Рабочий процесс
В следующих шагах описывается высокоуровневый рабочий процесс. Курсивные шаги идентичны архитектуре однотенантной архитектуры RAG с рабочим процессом оркестратора.
- Пользователь выдает запрос интеллектуальному веб-приложению.
- Поставщик удостоверений аутентифицирует запрашивающего.
- Интеллектуальное приложение вызывает API оркестратора с пользовательским запросом и токеном авторизации для пользователя.
- Логика оркестрации извлекает пользовательский запрос и вызывает соответствующие хранилища данных для получения авторизованных клиентом релевантных данных, необходимых для обработки запроса. Данные заземления добавляются в запрос, который отправляется в Azure OpenAI на следующем шаге. Включены некоторые или все указанные ниже действия.
- Логика оркестрации процессов извлекает исходные данные из соответствующего экземпляра хранилища данных для конкретного клиента и может применить правила фильтрации безопасности, чтобы вернуть только те данные, к которым пользователь имеет разрешение на доступ.
- Логика оркестрации извлекает основные данные соответствующего арендатора из мультитенантного хранилища данных и потенциально применяет правила фильтрации безопасности, чтобы вернуть только те данные, к которым пользователь имеет разрешение на доступ.
- Логика оркестрации извлекает данные из хранилища данных, общего для арендаторов.
- Логика оркестрации подключается к API инференции базовой модели и отправляет запрос, содержащий извлеченные данные оснований. Результаты возвращаются интеллектуальному приложению.
Рекомендации по проектированию мультитенантных данных в RAG
При проектировании мультитенантного решения для вывода данных с использованием RAG следует учитывать следующие аспекты.
Выбор модели изоляции хранилища
Два основных подхода архитектуры для хранения и данных в мультитенантных сценариях являются хранилищами для каждого клиента и мультитенантных хранилищ. Эти подходы дополняют следующие хранилища, которые содержат данные, общие для арендаторов. Мультитенантное решение может использовать сочетание этих подходов.
Магазины для каждого клиента
В хранилищах для каждого клиента каждый клиент имеет собственное хранилище. Преимущества этого подхода включают как данные, так и изоляцию производительности. Данные каждого клиента инкапсулируются в собственном хранилище. В большинстве служб данных изолированные хранилища не подвержены шумной проблеме соседей других клиентов. Этот подход также упрощает выделение затрат, так как все затраты на развертывание хранилища могут быть связаны с одним клиентом.
Такой подход может привести к таким проблемам, как увеличение управления и операционных затрат и более высокие затраты. Этот подход не следует использовать, если у вас большое количество небольших клиентов, например в сценариях "бизнес—потребитель". Этот подход также может достичь или превысить ограничения службы .
В контексте этого сценария ИИ магазин на арендатора означает, что необходимые основные данные для обеспечения релевантности в контексте поступают из существующего или нового хранилища данных, содержащего только основные данные для арендатора. В этой топологии экземпляр базы данных является дискриминатором, который используется для каждого клиента.
Многопользовательские магазины
В мультитенантных хранилищах данные нескольких клиентов сосуществуют в одном хранилище. Преимущества этого подхода включают потенциал для оптимизации затрат, возможность обработки большего числа арендаторов, чем модель 'одно хранилище на арендатора', а также снижение затрат на управление из-за меньшего числа экземпляров хранилища.
Проблемы использования общих хранилищ включают необходимость изоляции и управления данными, потенциал для шумные соседские антипаттернные, а также более сложное распределение затрат для клиентов. Изоляция данных является наиболее важной проблемой при использовании этого подхода. Необходимо реализовать безопасные подходы, чтобы гарантировать, что клиенты могут получать доступ только к своим данным. Управление данными также может быть сложной задачей, если у клиентов есть разные жизненные циклы данных, требующие таких операций, как создание индексов в разных расписаниях.
Некоторые платформы имеют функции, которые можно использовать при реализации изоляции данных клиента в общих хранилищах. Например, Azure Cosmos DB имеет встроенную поддержку секционирования и сегментирования данных. Обычно идентификатор клиента используется в качестве ключа секции для обеспечения некоторой изоляции между клиентами. Azure SQL и База данных Azure для PostgreSQL — гибкий сервер поддерживает безопасность на уровне строк. Однако эти функции обычно не используются в мультитенантных решениях, так как необходимо разработать решение вокруг этих функций, если вы планируете использовать их в мультитенантном хранилище.
В контексте этого сценария ИИ основные данные для всех клиентов хранятся в одном хранилище данных. Таким образом, ваш запрос к этому хранилищу данных должен включать дискриминатор арендатора, чтобы гарантировать, что ответы ограничены и возвращают только релевантные данные в контексте арендатора.
Общие хранилища
Мультитенантные решения часто совместно используют данные между арендаторами. В примере мультитенантного решения для домена здравоохранения база данных может хранить общие медицинские сведения или сведения, которые не относятся к клиенту.
В контексте этого сценария искусственного интеллекта базовое хранилище данных обычно доступно и не требует фильтрации на основе конкретных клиентов, поскольку данные актуальны и разрешены для всех клиентов в системе.
Идентичность
Identity является ключевым аспектом мультитенантных решений, включая мультитенантные решения RAG. Интеллектуальное приложение должно интегрироваться с поставщиком удостоверений для проверки подлинности удостоверения пользователя. Для мультитенантного решения RAG требуется каталог удостоверений , в котором хранятся авторитетные удостоверения или ссылки на удостоверения. Это удостоверение должно проходить через цепочку запросов и давать возможность службам ниже по потоку, таким как оркестратор или само хранилище данных, идентифицировать пользователя.
Вам также нужен способ сопоставить пользователя с клиентом, чтобы предоставить доступ к этим данным клиента.
Определение требований к клиенту и авторизации
При создании мультитенантного решения RAG необходимо определить, что такое арендатор в контексте вашего решения. Две распространенные модели, из которых можно выбрать, — это бизнес для бизнеса и бизнес для потребителя. Выбранная модель помогает определить, какие другие факторы следует учитывать при создании решения. Понимание количества клиентов крайне важно для выбора модели хранилища данных. Для большого количества арендаторов может потребоваться модель с несколькими арендаторами для каждого магазина. Меньшее число арендаторов может позволить модель с одним магазином на арендатора. Объем данных для каждого клиента также важен. Клиенты, имеющие большие объемы данных, могут препятствовать использованию мультитенантных хранилищ из-за ограничений размера хранилища данных.
Если вы планируете расширить существующую рабочую нагрузку для поддержки этого сценария ИИ, возможно, вы уже приняли это решение. Как правило, можно использовать существующую топологию хранилища данных для данных заземления, если это хранилище данных может обеспечить достаточную релевантность и соответствовать любым другим нефункциональным требованиям. Однако если вы планируете внедрить новые компоненты, такие как выделенное хранилище векторного поиска в качестве выделенного хранилища заземления, то вам по-прежнему необходимо принять это решение. Учитывайте такие факторы, как текущая стратегия метки развертывания, влияние плоскости управления приложениями и любые различия жизненного цикла данных клиента, такие как ситуации с оплатой за производительность.
После определения того, какой клиент предназначен для вашего решения, необходимо определить требования к авторизации для данных. Арендаторы получают доступ только к данным из своего тенанта, но ваши требования к авторизации могут быть более детальными. Например, в решении для здравоохранения могут быть такие правила, как:
- Пациент может получить доступ только к собственным данным пациента.
- Медицинский специалист может получить доступ к данным своих пациентов.
- Финансовый пользователь может получить доступ только к данным, связанным с финансами.
- Клинический аудитор может видеть данные всех пациентов.
- Все пользователи могут получить доступ к базовым медицинским знаниям в общем хранилище данных.
В приложении RAG на основе документов может потребоваться ограничить доступ пользователей к документам на основе схемы тегов или уровней конфиденциальности, назначенных документам.
После определения клиента и четкого понимания правил авторизации используйте эти сведения в качестве требований для решения хранилища данных.
Фильтрация данных
Ограничение доступа только к данным, к которым пользователи уполномочены получать доступ, называется фильтрацией или ограничением безопасности. В сценарии RAG с множеством арендаторов пользователь может быть сопоставлен с хранилищем, специфичным для определенного арендатора. Это не означает, что пользователь должен иметь доступ ко всем данным в этом хранилище. Определение требований клиента и авторизации описывает важность определения требований авторизации для данных. Эти правила авторизации следует использовать в качестве основы для фильтрации.
Для реализации фильтрации можно использовать такие возможности платформы данных, как безопасность на уровне строк. Кроме того, может потребоваться пользовательская логика, данные или метаданные. Эти функции платформы обычно не используются в мультитенантных решениях, так как необходимо разработать систему вокруг этих функций.
Инкапсулировать многотенантную логику данных
Рекомендуется использовать API перед используемым механизмом хранения. API действует как контролер, который помогает гарантировать, что пользователи получают доступ только к информации, к которой они имеют право видеть.
Доступ пользователей к данным может быть ограничен следующими способами:
- Арендатор пользователя.
- Функции платформы.
- Пользовательские правила фильтрации или ограничения безопасности.
Уровень API должен:
- Перенаправьте запрос в хранилище, конкретное для клиента, в модели отдельного хранилища для каждого клиента.
- Выберите только данные арендатора пользователя в мультитенантных хранилищах.
- Используйте соответствующее удостоверение для пользователя для поддержки логики авторизации с поддержкой платформы.
- Обеспечение пользовательской логики ограничения безопасности.
- Храните журналы доступа к сведениям заземления для целей аудита.
Код, который должен получить доступ к данным клиента, не должен напрямую запрашивать внутренние хранилища. Все запросы к данным должны передаваться по уровню API. Этот уровень API обеспечивает единую точку управления или безопасности на основе данных клиента. Этот подход предотвращает распространение логики авторизации доступа к данным арендатора и пользователей в другие области приложения. Эта логика инкапсулируется на уровне API. Это инкапсуляция упрощает проверку и тестирование решения.
Сводка
При проектировании мультитенантного решения для инференса RAG необходимо учитывать, как выполнить архитектурное проектирование решения для основы данных для ваших клиентов. Ознакомьтесь с количеством клиентов и объемом данных для каждого клиента, которые вы храните. Эта информация поможет вам разработать решение по аренде данных. Рекомендуется реализовать уровень API, который инкапсулирует логику доступа к данным, включая многотенантную логику и логику фильтрации.
Участники
Корпорация Майкрософт поддерживает эту статью. Следующие участники написали эту статью.
Основные авторы:
- Джон Даунингс | Главный инженер программного обеспечения
- Даниэль Скотт-Рейнсфорд | Старший архитектор партнерских решений, & данные и ИИ
Чтобы просматривать закрытые профили LinkedIn, войдите в LinkedIn.