你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计安全的多租户 RAG 推理解决方案
Retrieval-Augmented 生成（RAG）是一种模式，用于构建使用基础模型的应用程序来推理专有信息或其他未在 Internet 上公开提供的数据。 通常，客户端应用程序调用业务流程层，该层从数据存储（例如向量数据库）提取相关信息。 业务流程层将该数据作为上下文的一部分作为基础数据传递到基础模型。
多个客户使用多租户解决方案。 每个客户或租户由来自同一组织、公司或组的多个用户组成。 在多租户方案中，需要确保租户或租户内部的个人只能整合他们有权访问的相关数据。
除了确保用户仅访问他们有权访问的信息之外，还存在多租户问题。 但是，本文重点介绍多租户的这一方面。 本文从单租户 RAG 体系结构的概述开始。 它讨论了在使用 RAG 的多租户中可能会遇到的挑战，以及一些常用方法。 它还概述了多租户的注意事项，并提供了提高安全性的建议。
注意
本文介绍特定于 Azure OpenAI 服务的多项功能，例如 Azure OpenAI On Your Data 功能。 但是，可以将本文中所述的大部分原则应用于任何平台上的基础 AI 模型。
具有编排器的单租户 RAG 体系结构
工作流
在此单租户 RAG 体系结构中，业务流程协调程序从数据存储中提取相关的专有租户数据，并将其作为基础模型的基础数据提供。 以下步骤介绍高级工作流。
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 智能应用程序使用用户的查询和用户授权令牌调用编排器 API。
- 业务流程逻辑从请求中提取用户的查询，并调用相应的数据存储来提取查询的相关地面数据。 下一步，基础数据将添加到发送到基础模型的提示中，就像 Azure OpenAI 中公开的模型一样。
- 编排逻辑连接到基础模型的推理 API，并发送包含检索到的基础数据的提示。 结果将返回到智能应用程序。
有关详细信息，请参阅 设计和开发 RAG 解决方案。
具有直接数据访问的单租户 RAG 体系结构
单租户 RAG 体系结构的此变体使用 Azure OpenAI 的 On Your Data 功能，直接与 Azure AI 搜索等数据存储进行集成。 在此体系结构中，你要么没有自己的业务流程协调程序，要么业务流程协调程序的责任更少。 Azure OpenAI API 调用数据存储以提取地面数据并将该数据传递到语言模型。 此方法使您对要提取的基础数据及其相关性的控制能力减弱。
注意
Azure OpenAI 由Microsoft管理。 它与数据存储集成，但模型本身不与数据存储集成。 模型接收基础数据的方式与协调器提取数据时相同。
工作流
在此 RAG 体系结构中，提供基础模型的服务从数据存储中提取适当的专有租户数据，并将该数据用作基础模型的基础数据。 以下步骤介绍高级工作流。 斜体步骤与前面提到的拥有编排器工作流的单租户 RAG 体系结构相同。
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 智能应用程序使用用户的查询调用 Azure OpenAI。
- Azure OpenAI 连接到支持的数据存储，例如 AI 搜索和 Azure Blob 存储，以提取基础数据。 当 Azure OpenAI 调用 OpenAI 语言模型时，基础数据将用作上下文的一部分。 结果将返回到智能应用程序。
如果要在多租户解决方案中使用此体系结构，则直接访问基础数据（例如 Azure OpenAI）的服务必须支持解决方案所需的多租户逻辑。
RAG 体系结构中的多租户
在多租户解决方案中，租户数据可能存在于特定于租户的存储中，或与其他租户共存于多租户存储中。 数据也可能位于跨租户共享的存储中。 只有用户有权访问的数据才应被用作基础数据。 用户应只查看公用数据、全租户数据或其租户中已筛选的数据，以帮助确保他们仅看到有权访问的数据。
工作流
以下步骤介绍高级工作流。 斜体步骤与具有编排器的单租户 RAG 体系结构工作流相同。
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 智能应用程序使用用户的查询和用户的授权令牌调用业务流程协调程序 API。
- 业务逻辑从请求中提取用户的查询，并调用适当的数据存储，以获取经租户授权的、与查询相关的基础数据。 基础数据会被添加到将在下一步发送到 Azure OpenAI 的提示中。 包括一些或全部以下步骤：
- 业务流程逻辑从合适的租户专用数据存储实例中提取基础数据，并可能应用安全筛选规则以仅返回用户有权访问的数据。
- 业务流程逻辑从多租户数据存储中提取相应的租户地面数据，并可能应用安全筛选规则，以仅返回用户有权访问的数据。
- 编排逻辑从跨租户共享的数据存储中提取数据。
- 编排逻辑连接到基础模型的推理 API，并发送包含检索到的基础数据的提示。 结果将返回到智能应用程序。
RAG 中多租户数据的设计注意事项
在设计您的多租户 RAG 推理解决方案时，请考虑以下选项。
选择存储隔离模型
多租户方案中存储和数据的两种主要架构方法是按租户存储和多租户存储。 这些方法是对包含跨租户共享数据的存储的补充。 多租户解决方案可以使用这些方法的组合。
按租户存储存储
在按租户存储存储中，每个租户都有自己独立的存储。 此方法的优点包括数据和性能隔离。 每个租户的数据都封装在其自己的存储中。 在大多数数据服务中，独立存储不易受到其他租户引起的近邻干扰问题的影响。 此方法还简化了成本分配，因为存储部署的整个成本都可以归咎于单个租户。
这种方法可能会带来挑战，例如增加管理和运营开销以及更高的成本。 如果你有大量小型租户（例如在企业到使用者方案中），则不应使用此方法。 此方法也可能达到或超过 服务限制。
在此 AI 方案的背景下，按租户存储存储意味着，将关联性引入上下文的必要基础数据来自仅包含租户基础数据的现有或新的数据存储。 在此拓扑中，数据库实例是用于区分每个租户的识别器。
多租户商店
在多租户存储系统中，多个租户的数据在同一存储系统中共存。 此方法的优点包括具有成本优化的潜力、能够处理比按租户存储模型更多的租户，以及由于存储实例数较少而降低的管理开销。
使用共享存储的挑战包括需要数据隔离和管理、存在近邻干扰反模式的可能性以及向租户分摊更复杂的成本。 使用此方法时，数据隔离是最重要的问题。 你需要实现安全的方法，以帮助确保租户只能访问其数据。 如果租户具有不同的数据生命周期，这需要根据不同的计划进行操作（例如生成索引），则数据管理也可能很困难。
某些平台具有在共享存储中实现租户数据隔离时可以使用的功能。 例如，Azure Cosmos DB 原生支持数据分区和分片。 通常，使用租户标识符作为分区键来提供租户之间的一些隔离。 Azure SQL 和 Azure Database for PostgreSQL 灵活服务器支持行级别安全性。 但是，这些功能通常不会用于多租户解决方案，因为如果你计划在多租户环境中使用这些功能，则必须围绕这些功能设计解决方案。
在这个 AI 场景中，所有租户的基础数据混合在同一数据存储中。 因此，对该数据存储的查询必须包含租户鉴别器，以帮助确保响应仅限于在租户上下文中仅返回相关数据。
共享商店
多租户解决方案通常跨租户共享数据。 在医疗保健域的示例多租户解决方案中，数据库可能会存储不特定于租户的常规医疗信息或信息。
在此 AI 方案的上下文中，基础数据存储通常可访问，不需要基于特定租户进行筛选，因为数据与系统中所有租户相关且已获得授权。
身份
标识对于多租户解决方案来说很重要，包括多租户 RAG 解决方案。 智能应用程序应与标识提供者集成，以对用户的标识进行身份验证。 多租户 RAG 解决方案需要存储权威标识或对标识的引用的标识目录。 此标识需要流经请求链，并允许下游服务（如业务流程协调程序或数据存储本身）来标识用户。
还需要一种方法来 将用户映射到租户，以便授予对该租户数据的访问权限。
定义租户和授权要求
构建多租户 RAG 解决方案时，必须为解决方案定义什么是租户。 可供选择的两种常见模型是企业到企业模型和企业对消费者模型。 选择的模型有助于确定生成解决方案时应考虑的其他因素。 了解租户数对于选择数据存储模型至关重要。 大量租户可能需要一个模型，这个模型为每个店铺提供多个租户。 租户数量较少可能会允许采用为每个租户配备一个店铺的模型。 每个租户的数据量也很重要。 拥有大量数据的租户可能会由于数据存储的大小限制而阻止您使用多租户存储。
如果打算扩展现有工作负载以支持此 AI 方案，则可能已做出此决定。 一般来说，如果数据存储可以提供足够的相关性并满足任何其他非功能性要求，则可以将现有数据存储拓扑用于地面数据。 但是，如果计划引入新的组件，比如作为专用基础存储的专用矢量搜索存储，那么您仍然需要做出这个决定。 请考虑以下因素：当前的部署标记策略、应用程序控制平面的影响，以及任何每租户数据生命周期的差异，例如绩效付薪体系情况。
在定义解决方案中的租户概念后，您需要定义数据的授权要求。 租户仅能访问其租户的数据，但你的授权要求可能更精细。 例如，在医疗保健解决方案中，你可能有如下规则：
- 患者只能访问自己的患者数据。
- 医疗保健专业人员可以访问其患者的数据。
- 财务用户只能访问与财务相关的数据。
- 临床审核员可以查看所有患者的数据。
- 所有用户都可以在共享数据存储中访问基本医疗知识。
在基于文档的 RAG 应用程序中，你可能希望根据分配给文档的标记方案或敏感度级别限制用户对文档的访问。
定义租户的定义并明确了解授权规则后，将该信息用作数据存储解决方案的要求。
数据筛选
将访问限制仅限于用户有权访问的数据称为筛选或安全修整。 在多租户 RAG 方案中，用户可能会被映射到一个与租户特定的存储。 这并不意味着用户应该能够访问该存储中的所有数据。 定义租户和授权要求 讨论定义数据授权要求的重要性。 应使用这些授权规则作为筛选的基础。
可以使用行级别安全性等数据平台功能来实现筛选。 或者，可能需要自定义逻辑、数据或元数据。 这些平台功能通常不会用于多租户解决方案，因为你需要围绕这些功能设计系统。
封装多租户数据逻辑
我们建议在您使用的存储机制之前设置一个 API 接口。 API 的行为类似于一个守护程序，可帮助确保用户只能访问他们有权访问的信息。
用户可以通过以下方式限制对数据的访问：
- 用户的租户。
- 平台功能。
- 自定义安全筛选或裁剪规则。
API 层应：
- 将查询路由到按租户存储模型中特定于租户的存储区。
- 在多租户存储中，仅选择用户所属租户的数据。
- 使用适当的用户身份来支持平台授权逻辑。
- 执行自定义安全修剪逻辑。
- 存储基础信息访问日志以供审核。
需要访问租户数据的代码不应能够直接查询后端存储。 所有数据请求都应流经 API 层。 此 API 层提供租户数据之上的单一治理或安全性点。 此方法可防止租户和用户数据访问授权逻辑到达应用程序的其他区域。 此逻辑封装在 API 层中。 此封装使解决方案更易于验证和测试。
总结
设计多租户 RAG 推理解决方案时，必须考虑如何为租户构建基础数据解决方案。 了解租户数和存储的每租户数据量。 此信息可帮助你设计数据租赁解决方案。 建议实现封装数据访问逻辑（包括多租户逻辑和筛选逻辑）的 API 层。
贡献者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- 约翰·唐斯 |首席软件工程师
- Daniel Scott-Raynsford | 高级合作伙伴解决方案架构师，数据和 AI
若要查看非公共LinkedIn个人资料，请登录LinkedIn。