本系列文章介绍
在和社区小伙伴们交流的过程中，我们发现大家最关心的问题从来不是某个具体的功能如何使用，而是面对一个具体的实战场景时，如何选择合适的向量数据库解决方案或最优的功能组合。在 “Milvus 向量数据库进阶” 这个系列文章中，我们会聚焦回答这一类问题，如 “在 AI 应用开发的不同阶段，向量数据库应该如何选型”，“如何正确的构建 RAG 多租系统” 等。虽然这个系列名为进阶，但内容同时适用于初级和进阶用户。我们希望通过这些内容的介绍，帮助大家在向量数据库应用的过程中少走弯路。
上期回顾
Milvus作为成熟的开源向量数据库，提供了Milvus Lite、Standalone和Distributed三种部署形态，满足从原型构建到大规模生产部署的不同需求。上篇文章中，我们详细讨论了各形态特点、适用场景及如何根据项目阶段和数据规模选择合适的Milvus部署方式，同时对比了其他开源向量数据库如Qdrant、Weaviate和Chroma的特点和适用规模。本文中，我们将结合Milvus，讲一讲如何构建 RAG 多租户/多用户系统。
现在市面上的 RAG 系统不管是 toB 的还是 toC 的，基本都需要考虑多租。这篇文章我们结合 Milvus，讲一讲如何构建 RAG 多租户/多用户系统。我们会涉及的关键主题有：
用户数据组织与权限控制
To B 大型知识库系统的多租户设计
To C RAG 应用的多用户设计
非活跃用户的成本控制
本篇是上篇，主要展开前两个主题。
01.
用户数据组织与权限控制
用户数据组织与权限控制相关度比较高，我们结合一些例子放在一起讲。先来看看在向量数据库中怎么合理的组织用户数据。面向生产的向量数据库系统一般都会提供多层数据组织能力。以 Milvus 为例，数据组织粒度从大到小一共有三种选择：Database，Collection，Partition Key/Partition。
图1. Milvus 的多层数据组织结构
图1. 给出了这种结构的大致示例。这里的 Database 指的是一个逻辑上的数据库，概念上和关系型数据库的 Database 接近。Collection 对应的是 Database 内的表。Partition 是表内的数据逻辑分组，具有相同 Partition Key 的数据会被分为同一组。例如我们指定用户 ID 作为 Partition Key，相同用户的数据就会被分到同一个逻辑分组，以方便后续按用户粒度进行数据查询。在权限控制层面，Milvus 提供了比较完善的 RBAC (Role Based Access Control) 机制，系统管理员可以为每一个用户设置数据访问范围以及权限级别。
注意：Milvus 提供了 Partition 和 Partition Key 两种逻辑分组机制，其概念类似，但使用方式略有差异。咱们文中所涉及的都是 Partition Key 这种方式。
从Database、Collection 到 Partition Key，数据组织粒度由大逐渐变小。如果把用户（或租户）映射到更大的粒度（例如为每个用户分配一个 Database），将为用户提供很高的数据组织灵活性，也能适应更广泛的业务需求，但对应的单用户成本也会比较高，整个系统所能支持的用户数量也较少。相反，如果把用户对应到更低的粒度（例如为每个用户分配一个 Partition Key），那么我们可以支持的用户数量会很高，且单用户成本极低，但这种情况下的数据组织需要非常固定，例如所有用户的数据 schema 都需要保持一致。下表总结了不同粒度的主要差异：
接下来，我们展开聊聊 To B、To C 两种典型 RAG 的多租系统设计。
02.
To B大型知识系统的多租设计
这类场景中，租户数量一般比较少。比如企业内多个独立的业务团队或部门，如果他们都在提供不同的知识库服务，那么对于数据库中台团队，每一个这样的业务团队或部门都是一个租户。
在向量数据库层面，中台团队需要根据业务复杂度为每个租户分配一到多个 Database，业务彼此在 Database 这个粒度进行隔离。这种组织方式几乎把所有的关于 collection 的使用的灵活度都交给了租户：对于 collection 的数据模型、collection 创建数量、不同 collection 上的用户访问权限控制等都不做任何限制。这样的多租设计可以有效支撑不同业务对于向量数据库的差异化使用方式。
图2. 逻辑层到物理层的映射
很多时候，我们需要保障核心业务的服务质量。因此除了 Database 粒度的逻辑隔离，我们还需要关注物理隔离。Milvus 支持逻辑层 Database/Collection 到物理层资源的映射。上图给了一个简单的例子，图中从下到上共出现了三层概念：Query Node，Resource Group，Database。在 Milvus 系统内部，支撑查询任务的组件是 Query Node。每个 Query Node 部署在一个物理节点（如一台物理机或一个Pod）。一到多个 Query Node 可以组成一个 Resource Group，每个 Resource Group 是承载逻辑到物理映射的单元：我们可以将一到多个 Database 或 Collection 映射到一个 Resource Group。
在这个例子中，我们有三个逻辑的 Database，我们假设 Database X 所支撑的知识库很关键，我们不希望 X 受到 Y、Z 的负载干扰。因此我们将 X 单独分配到一个 Resource Group。另外，在图的最右边我们也为 Collection E 单独分配了 Resource Group。注意这里我们讲了两种不同的模式：X 是整个 Database 进行物理隔离，E 是将某个 Database 中的 Collection 单独拿出来进行物理隔离。对于 Database Y、Z 中剩下的所有 Collection，我们让其共享 Resource Group 2 的物理资源。
接下来我们再来看看用户层的设计。通常，企业级知识库的用户都是以只读的方式进行服务访问。很多时候，我们也会关心这些用户产生的问答数据，或希望建立数据与用户的关联。举个例子，考虑一个医院的智能咨询服务台。患者的咨询一般都是一些即时提问，如 "今天专家还有没有临时号"、"采血在几楼" 等。从医院的角度看，希望能够不断的提升问答质量，因此需要对咨询问答对进行记录。注意这些问答对并不会对 RAG 系统的知识库产生直接更新，而是会被写入另外一个专门记录问答的数据库（这里不一定需要向量数据库）。这个库的背后，一般需要一到多名知识库的维护人员，他们通过分析实际的问答数据对知识库做持续迭代。
图3. 企业知识库组成结构
现在，我们把前面讲的所有东西拼成一个整体，其中：
系统管理员负责整个系统的维护，以及系统资源到租户的分配。如分配 Database，确定 Database 到 Resource Group 的映射，Resource Group 的扩容等。
租户（即图中的 Database Owner & Developers）根据业务构建知识库，并根据用户的问答数据持续迭代这个知识库。
用户以只读的方式通过 LLM 间接访问知识库，访问数据持续积累至问答记录库。
在这个例子中，我们的向量数据库系统只针对多租户进行了设计，但并没有针对单个租户的多用户进行设计。即多用户的概念只存在于业务层，向量数据库对此不感知。这里有些同学可能会有疑问：如果我想根据每个用户的历史咨询上下文进行更精准的回答，那不需要在向量数据库中为每个用户维护一个私有的问答上下文吗？这个问题很好，但要看情况。如果是咱们例子中的这类即时咨询，本质是随机性比较高的搜索，影响结果的核心是知识库质量，而非历史上下文。
下期预告
当然，也有不少场景是上下文敏感的。这个时候我们的向量数据库系统就需要感知用户层，并需要为每个用户维护一个上下文记忆。关于这部分多用户的设计，和我们接下来要讲的 To C 场景极为类似，感兴趣的同学可以继续看下篇。
作者介绍
郭人通，Zilliz 合伙人和产品总监，CCF 分布式计算与系统专委会执行委员。专注于开发面向 AI 的高效并可扩展的数据分析系统。郭人通拥有华中科技大学计算机软件与理论博士学位。
推荐阅读
