为什么多租户 RAG 是刚需：SaaS 化的隔离要求
自建 RAG（企业内部知识库）只服务一个组织，没有隔离问题。但当 RAG 变成 SaaS 产品（给多个客户提供知识库问答），隔离就变成生死线：客户 A 的问题绝不能返回客户 B 的文档——这是合同义务与法律要求，不是技术偏好。多租户 RAG 的三大课题：数据隔离（知识库的物理或逻辑分离）、检索路由（请求怎么路由到正确的知识库）、配额与成本（每个租户的用量计量与限额）。
三种隔离策略：物理、逻辑与混合
策略一：物理隔离。每个租户独立的向量库实例（独立的 Qdrant/Milvus 实例或独立 collection）——隔离最彻底（数据物理上不可交叉）。优点：安全等级最高、租户间的性能零干扰、合规审计最简单。缺点：资源成本线性增长（每个租户一个实例的运维与成本）、管理复杂（实例的创建、升级、监控的数量随租户增长）。适用：大客户（付费高、安全要求高、文档量大）或合规敏感行业（医疗、金融）。
策略二：逻辑隔离。共享一个向量库、用租户 ID 做元数据过滤——每个向量附带 tenant_id 元数据，检索时强制过滤 WHERE tenant_id = current_tenant。优点：资源效率最高（一个实例服务所有租户）、运维简单（一个系统管理）。缺点：隔离靠代码保证（过滤逻辑的 bug 就是数据泄漏——一个漏掉 WHERE 条件的查询就是灾难）、性能互扰（一个大租户的查询影响所有租户的延迟）。适用：小租户（付费低、文档量小）、开发与测试环境。
策略三：混合策略。大租户物理隔离 + 小租户逻辑隔离——按租户的规模与 SLA 等级分配——成熟 SaaS 的标准形态（本库多租户推理篇的分层思想）。
隔离的选择决策式：泄漏的代价——泄漏一个租户文档给另一个租户，代价多大？代价不可接受 → 物理隔离；代价可容忍（内部测试）→ 逻辑隔离。以及一个关键点：逻辑隔离的安全性完全取决于实现质量——一行代码的 WHERE 遗漏就是数据泄漏——逻辑隔离需要严格的代码审查与测试覆盖。
租户级路由：从请求到正确知识库的映射
路由的实现位置：网关层（请求解析出租户身份 → 路由到对应的知识库配置）——本库 LiteLLM 篇的虚拟 key 思想在这里的翻版。路由的信息：租户 ID → 知识库配置（向量库地址或 collection 名、嵌入模型、分块策略——每个租户可能有不同的配置）。路由的实现方式。方式一：配置中心——租户配置存数据库或配置文件，网关按租户 ID 查配置后路由。方式二：命名约定——collection 名按租户命名（tenant_{id}_docs），路由逻辑简单但灵活性差。方式三：路由服务——独立的路由服务管理租户与知识库的映射——复杂但灵活。路由的安全要点：租户身份的验证（API key 或 OAuth token 确定租户——不能靠前端传的 tenant_id，要从认证层提取——本库安全篇的认证原则）、路由的原子性（租户 ID 与知识库的绑定不可被篡改）。
配额与成本：多租户的运营工程
配额的维度。存储配额（每租户的文档数与向量数上限）、检索配额（每租户的每日检索次数上限）、生成配额（每租户的 LLM token 上限）——三个维度的组合构成租户的 SLA。配额的执行位置：网关层（请求频率与 token 的限制）、存储层（文档数与向量数的限制）。成本的归因：每个租户的检索成本与生成成本按租户归因（本库 FinOps 篇）——「哪个租户在烧钱」的可见性是定价与资源分配的依据。以及一个安全的收尾：配额限制也是安全措施——一个被攻破的租户不能无限制地消耗系统资源（资源耗尽攻击的防线）。
## 多租户 RAG 的进阶：租户级 Embedding 与模型定制
多租户 RAG（正文隔离）的进阶：租户级的模型定制——每个租户用自己的嵌入模型。场景：大租户要求用自己领域的嵌入模型（法律租户用法律嵌入、医疗租户用医学嵌入——通用嵌入对专业领域的检索质量不足）。实现的方式。方式一：每租户独立嵌入服务——独立的嵌入 API 端点（每租户的嵌入模型独立部署——成本最高但隔离最彻底）。方式二：共享嵌入服务 + 模型路由——嵌入服务根据租户 ID 路由到对应的模型（一个服务多个模型的动态加载——资源效率更高）。租户级嵌入的管理：嵌入模型的版本管理（每租户的模型版本独立——一个租户升级不影响其他租户）、嵌入的一致性（同租户的文档用同一版本模型嵌入——混合版本的嵌入不可比）。多租户嵌入的收束：租户级嵌入是「多租户 RAG 的差异化竞争点」——通用嵌入给小租户、领域嵌入给大租户——嵌入模型的差异化是 RAG SaaS 产品的一个潜在竞争维度。
多租户 RAG 的进阶：租户级查询改写与嵌入适配
多租户 RAG（正文隔离）的进阶：租户级的查询改写与嵌入适配——每个租户的业务术语不同，通用查询改写不够精准。租户级的查询改写：每个租户有自己的业务术语表（「客户」在某租户指企业客户、在另一租户指个人消费者——术语表存入租户的配置）、查询改写时用租户的术语表做同义词扩展。租户级的嵌入适配：大租户可以用领域微调的嵌入模型（本库 Embedding 微调篇——租户专属的嵌入模型）。租户级配置的管理：租户配置（术语表、嵌入模型、分块策略、检索参数）存入租户的配置中心——多租户 RAG 的「配置即服务」——租户不仅有自己的知识库，还有自己的检索配置。多租户 RAG 的进阶收束：多租户不只是「隔离」，是「每租户一个定制的 RAG 实例」——隔离是底线、定制是价值——多租户 RAG 的成熟标志是「每个租户都有适合自己的检索体验」。
多租户 RAG 的实施清单：从设计到上线的检查项
多租户 RAG 的实施清单：隔离策略的确认（物理/逻辑/混合——按租户规模与 SLA 决定）、租户身份的认证（API key 或 OAuth——不能靠前端传的 tenant_id）、检索的租户过滤（每个查询强制 WHERE tenant_id 过滤——一行代码的遗漏就是数据泄漏）、配额的设置（存储/检索/生成的三维配额）、成本的归因（按租户的用量统计）、以及数据删除的流程（租户注销时的知识库清理——本库隐私篇的被遗忘权）。清单的用法：新租户接入前逐项打勾、定期复查隔离的完整性——多租户的实施检查清单是 SaaS 化 RAG 的安全底线。
多租户 RAG 的安全设计：跨租户攻击的防御
多租户 RAG（正文隔离）的安全设计：跨租户攻击的防御——多租户 RAG 的安全架构。跨租户攻击的场景：租户 A 的用户构造一个特殊查询，试图获取租户 B 的文档——攻击的方式包括提示注入（在查询中嵌入「忽略租户过滤」的指令——本库提示注入篇）与元数据篡改（伪造租户 ID 的元数据）。防御的层次：认证层的租户绑定（用户身份与租户 ID 的绑定在认证层完成——不能从前端参数获取租户 ID）、检索层的强制过滤（向量检索的 WHERE 条件强制包含租户过滤——过滤条件的遗漏就是安全漏洞）、输出层的租户检查（返回结果中的文档元数据检查——结果中的文档属于正确的租户吗）。安全的设计原则：租户过滤在每个层面强制执行（不能只在应用层过滤——检索层、存储层都要有租户隔离的保障——纵深防御，本库安全篇的原则）。
多租户 RAG 的进阶：租户级定制与配置即服务
多租户 RAG 的进阶：租户级的查询改写与嵌入适配——每个租户的业务术语不同，通用查询改写不够精准。租户级的查询改写：每个租户有自己的业务术语表（「客户」在某租户指企业客户、在另一租户指个人消费者——术语表存入租户的配置），查询改写时用租户的术语表做同义词扩展。租户级的嵌入适配：大租户可以用领域微调的嵌入模型。租户级配置的管理：租户配置（术语表、分块策略、检索参数）存入租户的配置中心——多租户 RAG 的「配置即服务」——租户不仅有自己的知识库，还有自己的检索配置。多租户的进阶收束：多租户不只是「隔离」，是「每租户一个定制的 RAG 实例」——隔离是底线、定制是价值——多租户 RAG 的成熟标志是「每个租户都有适合自己的检索体验」。
多租户 RAG 的运维清单
多租户 RAG 的运维要点：租户隔离的定期审计（抽样验证跨租户检索不可达——隔离的完整性要周期性验证而非一次性设置）、配额使用率的监控（接近配额的租户提前预警——配额耗尽的服务中断要有预告）、以及租户注销的数据清理流程（知识库删除、向量删除、配置清理的完整闭环——被遗忘权的落地）。运维的自动化：租户开通的自动化（新租户的知识库初始化、索引创建、配额配置的一键完成）、租户健康度的仪表盘（每个租户的检索量、空结果率、延迟的分租户视图）。多租户运维的收束：多租户 RAG 的运维把「一个系统的运维」变成「N 个租户的运维矩阵」——自动化与仪表盘是运维矩阵不失控的前提。
小结
多租户 RAG 的三层架构：数据隔离（物理/逻辑/混合——按租户规模与 SLA 分配）、检索路由（网关层的租户→知识库映射——认证层提取租户身份）、配额与成本（三维配额 + 成本归因——运营与安全的双重闸门）。多租户 RAG 不是「一个 RAG 的功能升级」，是「RAG 从工具变成服务」的架构跨越——隔离、路由、配额三件套齐了，RAG 才能从内部工具进化为 SaaS 产品。
读者留言
COMMENTS 暂无还没有留言，来说第一句？