建站工具有哪些,网站建设需要怎么做,凤岗镇做网站,菏泽住房和城乡建设部网站本系列文章介绍
在和社区小伙伴们交流的过程中#xff0c;我们发现大家最关心的问题从来不是某个具体的功能如何使用#xff0c;而是面对一个具体的实战场景时#xff0c;如何选择合适的向量数据库解决方案或最优的功能组合。在 “Milvus 向量数据库进阶” 这个系列文章中我们发现大家最关心的问题从来不是某个具体的功能如何使用而是面对一个具体的实战场景时如何选择合适的向量数据库解决方案或最优的功能组合。在 “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 为例数据组织粒度从大到小一共有三种选择DatabaseCollectionPartition 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 NodeResource GroupDatabase。在 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 的高效并可扩展的数据分析系统。郭人通拥有华中科技大学计算机软件与理论博士学位。
