检索扩充生成（RAG）是一种构建应用程序的模式，其中基础模型用于根据专有信息或其他在 Internet 上未公开提供的信息进行推理。 通常，客户端应用程序调用业务流程层，该层从数据存储（例如向量数据库）提取相关信息。 业务流程层将该数据作为上下文的一部分作为基础数据传递到基础模型。
多租户解决方案由多个客户使用，其中每个客户（租户）由来自同一组织、公司或组的多个用户组成。 在多租户方案中，需要确保租户或租户中的个人只能合并他们有权查看的地面数据。
尽管存在多租户问题，但除了确保用户只访问他们应该看到的信息之外，本文重点介绍多租户的这一方面。 本文从单租户 RAG 体系结构的概述开始，讨论有关使用 RAG 的多租户的挑战以及一些常见的方法，并总结了安全的多租户注意事项和建议。
注意
本文讨论一些特定于 Azure OpenAI 的功能，例如 Azure OpenAI On Your Data。 也就是说，本文档中讨论的大部分原则都适用于大多数基础 AI 模型，无论其主机平台如何。
具有业务流程协调程序的单租户 RAG 体系结构
图 1. 单租户 RAG 体系结构
Workflow
在此单租户 RAG 体系结构中，业务流程协调程序负责从数据存储中提取相关的专有租户数据，并将其作为基础模型的基础数据提供。 下面是一个高级工作流：
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 智能应用程序使用用户查询和用户的授权令牌调用业务流程协调程序 API。
- 业务流程逻辑从请求中提取用户的查询，并调用相应的数据存储来提取查询的相关地面数据。 将基础数据添加到发送到基础模型的提示中，例如下一步中在 Azure OpenAI 中公开的模型。
- 业务流程逻辑连接到基础模型的推理 API，并发送包含检索到的地面数据的提示。 结果将返回到智能应用程序。
有关 RAG 的详细信息，请参阅 设计和开发 RAG 解决方案。
具有直接数据访问的单租户 RAG 体系结构
单租户 RAG 体系结构的变体利用 Azure OpenAI 服务直接与 Azure 搜索等数据存储集成的能力。 在此体系结构中，你要么没有自己的业务流程协调程序，要么业务流程协调程序的责任更少。 Azure OpenAI API 负责调用数据存储来提取地面数据并将该数据传递到语言模型。 反过来，你对要提取的地面数据以及该数据相关性的控制更少。
注意
由Microsoft管理的 Azure OpenAI 服务与数据存储集成。 模型本身不与数据存储集成。 如果业务流程协调程序提取数据，则模型以完全相同的方式接收地面数据。
图 2. 具有从 Azure OpenAI 服务进行直接数据访问的单租户 RAG 体系结构
Workflow
在此 RAG 体系结构中，提供基础模型的服务负责从数据存储中提取适当的专有租户数据，并将该数据用作基础模型的基础数据。 下面是一个高级工作流（斜化步骤与业务流程协调程序工作流的单租户 RAG 体系结构相同）：
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 然后，智能应用程序使用用户查询调用 Azure OpenAI 服务。
- Azure OpenAI 服务连接到受支持的数据存储，例如 Azure AI 搜索和 Azure Blob 存储来提取基础数据。 当 Azure OpenAI 服务调用 OpenAI 语言模型时，基础数据将用作上下文的一部分。 结果将返回到智能应用程序。
为了在多租户解决方案中考虑此体系结构，直接访问地面数据的服务（例如 Azure OpenAI）必须支持解决方案所需的多租户逻辑。
RAG 体系结构中的多租户
在多租户解决方案中，租户数据可能存在于特定于租户的存储中，或与其他租户共存于多租户存储中。 可能还会在跨租户共享的存储区中存在数据。 只有用户有权查看的数据才应用作地面数据。 用户应仅看到其租户中常见的（所有租户）数据或数据，并应用筛选规则以确保他们只看到他们有权查看的数据。
图 3：RAG 体系结构 - 具有多个数据存储租户
Workflow
此工作流与业务流程协调程序（步骤 4 除外）的单租户 RAG 体系结构相同。
- 用户向智能 Web 应用程序发出请求。
- 标识提供者对请求者进行身份验证。
- 智能应用程序使用用户查询和用户的授权令牌调用业务流程协调程序 API。
- 业务流程逻辑从请求中提取用户的查询，并调用相应的数据存储来提取租户授权的、相关的查询地面数据。 基础数据会被添加到将在下一步发送到 Azure OpenAI 的提示中。 涉及部分或全部以下步骤：
- 业务流程逻辑从适当的特定于租户的数据存储实例中提取地面数据，可能应用安全筛选规则以仅返回用户有权访问的数据。
- 业务流程逻辑从多租户数据存储中提取相应的租户地面数据，可能应用安全筛选规则以仅返回用户有权访问的数据。
- 业务流程逻辑从跨租户共享的数据存储中提取数据。
- 业务流程逻辑连接到基础模型的推理 API，并发送包含检索到的地面数据的提示。 结果将返回到智能应用程序。
RAG 中多租户数据的设计注意事项
选择存储隔离模型
在多租户方案中，存储和数据有两种主要体系结构方法：每个租户的存储存储和多租户存储。 这些方法除了包含跨租户共享的数据的存储之外。 本部分介绍每个方法。 应注意的是，多租户解决方案可以使用这些方法的组合。
每个租户的应用商店
顾名思义，在每租户的应用商店中，每个租户都有自己的存储区。 此方法的优点包括数据和性能隔离。 每个租户的数据都封装在其自己的存储中。 在大多数数据服务中，独立存储不会受到其他租户的干扰邻居问题的影响。 此方法还简化了成本分配，因为存储部署的整个成本可以归咎于单个租户。
此方法的挑战可能包括更高的管理和操作开销以及更高的成本。 当存在大量小租户（例如企业到消费者方案）时，不应考虑此方法。 此方法还可以针对 服务限制运行。
在此 AI 方案的上下文中，每个租户的存储区意味着将相关性引入上下文所需的基础数据来自仅包含租户的地面数据的现有或新数据存储。 在此拓扑中，数据库实例是每个租户使用的鉴别器。
多租户存储
在多租户存储中，多个租户数据在同一存储中共存。 此方法的优点包括成本优化的可能性、处理租户数比每租户存储模型更高的租户的能力，以及由于存储实例数较少而降低管理开销。
使用共享存储的挑战包括需要确保数据隔离、数据管理、干扰邻居反模式的可能性，以及难以向租户分配成本。 确保数据隔离是此方法最重要的问题。 你有责任实施安全方法，以确保租户只能访问其数据。 如果租户具有不同的数据生命周期，则数据管理也可能是一个挑战，这些生命周期可能需要不同的操作，例如按不同的计划生成索引。
某些平台具有在共享存储中实现租户数据隔离时可以利用的功能。 例如，Azure Cosmos DB 对分区和分片提供本机支持，通常使用租户标识符作为分区键来提供租户之间的某种级别的隔离。 Azure SQL 和 Postgres Flex 支持行级别安全性，尽管此功能在多租户解决方案中并不常见，但如果你计划在多租户存储中使用这些功能，则必须围绕这些功能设计解决方案。
在此 AI 方案的上下文中，这意味着所有租户的地面数据都位于同一数据存储中，这样一来，对该数据存储的查询必须包含租户歧视性，以确保响应仅限于在租户上下文中返回相关数据。
共享存储
多租户解决方案通常具有跨租户共享的数据。 在医疗保健域的示例多租户解决方案中，可能有一个数据库存储非租户特定的常规医疗信息或信息。
在此 AI 方案的上下文中，这是一个通常可访问的地面数据存储，该数据存储不需要根据任何租户进行筛选，因为数据是相关的，并且已授权系统中的所有租户。
标识
标识是多租户解决方案 的关键方面，包括安全的多租户 RAG。 智能应用程序应与标识提供者（IdP）集成，以对用户的标识进行身份验证。 多租户 RAG 解决方案需要一个 标识目录 ，其中存储了权威标识或对标识的引用。 此标识需要流经请求链，允许下游服务（例如业务流程协调程序，甚至数据存储本身）来标识用户。
还需要将用户映射到租户的方法，以便你可以授予对该租户数据的访问权限。
定义租户和授权要求
生成多租户 RAG 解决方案时，必须 定义解决方案的租户。 可供选择的两种常见模式是企业到企业（B2B）和企业对消费者（B2C）。 此决定有助于告知你在构建解决方案时应考虑的领域。 了解租户数对于决定数据存储模型至关重要。 大量租户可能需要每个存储具有多个租户的模型，而较小的租户数可能会允许每个租户模型的存储。 每个租户的数据量也很重要。 如果租户具有大量数据，可能会阻止你使用多租户存储，因为数据存储的大小限制。
在正在扩展以支持此 AI 方案的现有工作负载中，你可能已做出此选择。 一般来说，如果数据存储可以提供足够的相关性并满足任何其他非功能性要求，则可以将现有数据存储拓扑用于地面数据。 但是，如果要将新的组件（如专用矢量搜索存储）作为专用地面存储引入，则需要做出此决定，考虑当前部署印花策略、应用程序控制平面影响以及任何每租户数据生命周期差异（如性能付费情况）。
定义解决方案的租户后，必须定义数据的授权要求。 虽然租户只能从其租户访问数据，但授权要求可能更精细。 例如，在医疗保健解决方案中，可能有如下规则：
- 患者只能访问自己的患者数据
- 医疗保健专业人员可以访问其患者数据
- 财务用户只能访问与财务相关的数据
- 临床审核员可以查看所有患者的数据
- 所有用户都可以在共享数据存储中访问基本医疗知识
在基于文档的 RAG 应用程序中，你可能希望根据文档上设置的标记方案或敏感度级别限制用户对文档的访问。
定义租户的定义并明确了解授权规则后，将该信息用作数据存储解决方案的要求。
筛选
筛选（也称为安全修整）是指仅向有权查看的用户公开数据。 在多租户 RAG 方案中，用户可以映射到特定于租户的存储。 这并不意味着用户应该能够访问该存储中的所有数据。 在 定义租户和授权要求中，我们讨论了定义数据的授权要求的重要性。 这些授权规则应用作筛选的基础。
可以使用数据平台功能（如行级别安全性）来完成筛选，或者可能需要自定义逻辑、数据或元数据。 同样，由于需要围绕这些功能设计系统，这些平台功能在多租户解决方案中并不常用。
封装多租户数据逻辑
建议在所使用的任何存储机制之前使用 API。 API 充当守护者，强制用户仅获取他们应访问的信息。
图 4. 包含封装多租户租户数据访问逻辑的 API 的多租户 RAG 体系结构
如本文前面所述，用户可以限制对数据的访问：
- 用户的租户
- 平台功能
- 自定义安全筛选/修整规则。
此层应具有以下职责：
- 将查询路由到每个租户模型中特定于租户的存储
- 仅从多租户存储中的用户租户中选择数据
- 为用户使用适当的标识来支持启用了平台的授权逻辑
- 强制实施自定义安全修整逻辑
- 存储用于审核目的的地面信息的访问日志
需要访问租户数据的代码不应能够直接查询后端存储。 所有数据请求都应流经此 API 层。 此 API 层在租户数据顶部提供单一治理或安全层。 此方法使租户和用户数据访问授权逻辑从流入应用程序的不同区域。 此逻辑封装在 API 层中。 此封装使解决方案更易于验证和测试。
总结
设计多租户 RAG 推理解决方案时，必须考虑到如何为租户构建基础数据解决方案。 了解租户数和存储的每租户数据量。 此信息可帮助你设计数据租赁解决方案。 建议实现封装数据访问逻辑（包括多租户和筛选逻辑）的 API 层。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
- John Downs | 首席软件工程师
- Daniel Scott-Raynsford | 高级合作伙伴解决方案架构师、数据与 AI