一、引言：为什么多租户 RAG 需要深度安全设计？

随着大模型与检索增强生成（RAG）技术在企业场景中的广泛应用，如何在保障知识服务高效性的同时，满足企业对数据安全、权限控制与合规审计的严苛要求，成为系统架构师必须直面的核心挑战。

尤其在 SaaS 化或集团内部多部门共用一套 RAG 平台的场景下，“数据混用”可能直接导致商业机密泄露、合规风险甚至法律纠纷。因此，构建一个具备强隔离、细粒度权限、敏感内容拦截与完整审计能力的多租户 RAG 架构，已不再是“可选项”，而是“必选项”。

本文将围绕企业级安全合规目标，系统阐述多租户 RAG 架构中的五大关键安全模块，并结合向量数据库（如 Milvus）的标量过滤（Scalar Filtering） 技术，提供可落地的技术方案。

二、多租户隔离：向量库中的 tenant_id 是第一道防线

在 RAG 架构中，知识库通常被向量化后存储于向量数据库（如 Milvus、Weaviate、Pinecone 等）。若多个租户（如不同公司、部门）共享同一套向量库，必须确保租户 A 的查询绝不会命中租户 B 的文档。

最直接且高效的方式是在向量数据中增加 tenant_id 字段，并在检索时通过标量过滤（Scalar Filtering） 进行硬隔离。

以 Milvus 为例，其支持在 search() 或 query() 接口中传入表达式（expr）：

results = collection.search(
    data=query_embedding,
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    limit=5,
    expr="tenant_id == 'company_a'"  # 关键：标量过滤
)

该表达式会在向量相似度计算前，先通过 tenant_id 过滤候选集，从物理层面杜绝跨租户数据泄露。这种方案具有以下优势：

• 性能高效：现代向量数据库对标量字段建立索引（如 Milvus 的 Scalar Index），过滤开销极低；
• 逻辑清晰：与业务租户模型天然对齐；
• 扩展性强：未来可叠加更多过滤条件（如部门、项目组等）。

注意：tenant_id 必须在数据写入阶段就写入，且不可篡改。建议在数据摄入管道（Ingestion Pipeline）中由可信服务自动注入，而非依赖前端传参。

三、RBAC 权限控制：用户只能访问所属部门知识

多租户隔离解决了“租户间”隔离，但企业内部往往还需“部门级”甚至“角色级”访问控制。此时需引入 基于角色的访问控制（RBAC）。

典型场景：销售部员工不应访问 HR 部门的薪酬制度文档。

实现思路如下：

1. 用户身份绑定组织单元：在用户登录后，通过 JWT 或 Session 获取其所属 department_id、role 等属性；
2. 知识文档打标：每篇文档在入库时标记其可见范围（如 visible_to_departments: ["hr", "finance"]）；
3. 检索时动态拼接过滤条件：

# 假设当前用户属于 "sales" 部门
allowed_departments = ["sales"]
dept_filter = " || ".join([f"department == '{d}'" for d in allowed_departments])
expr = f"tenant_id == 'company_a' && ({dept_filter})"

最终表达式可能为：
tenant_id == 'company_a' && (department == 'sales' || department == 'marketing')

关键点：RBAC 过滤逻辑应由后端服务统一处理，前端不可构造 expr 表达式，防止越权攻击。

四、敏感词过滤：双重防线拦截高风险内容

即使数据隔离和权限控制到位，用户提问或模型生成内容仍可能包含敏感信息（如身份证号、竞品名称、内部代号等）。为此，需部署双重过滤机制：

1. 正则规则匹配（前置拦截）

在用户提问进入 RAG 流程前，通过预定义正则规则快速识别高危关键词：

import re
SENSITIVE_PATTERNS = [
    r"\b\d{17}[\dXx]\b",  # 身份证
    r"(?i)secret|confidential|竞品",  # 敏感词
]

def contains_sensitive(text):
    return any(re.search(pat, text) for pat in SENSITIVE_PATTERNS)

一旦命中，直接拒绝请求并记录告警。

2. LLM 自查（后置兜底）

对于复杂语义场景（如“如何绕过XX系统的权限？”），正则难以覆盖。此时可让 LLM 自身判断输入/输出是否合规：

• Prompt 设计：在生成阶段加入安全指令，如“若问题涉及敏感信息，请拒绝回答”；
• 专用审核模型：调用轻量级安全审核模型（如 Llama Guard）对输入/输出进行分类。

建议：正则用于高性能拦截，LLM 用于语义兜底，二者互补。

五、审计日志：谁在何时问了什么？

企业合规（如 GDPR、等保）通常要求完整记录数据访问行为。RAG 系统必须实现全链路审计日志，包括：

• 用户身份（user_id）
• 时间戳（timestamp）
• 原始问题（raw_query）
• 检索到的文档 ID 列表（retrieved_doc_ids）
• 模型最终回答（final_response）
• 租户与部门信息（tenant_id, department）

日志应写入不可篡改的审计存储（如 Kafka + S3 + Athena），并支持按时间、用户、关键词等维度追溯。

最佳实践：日志脱敏处理，避免审计系统本身成为数据泄露点。

六、网络安全：VPC、API Gateway 与 JWT 鉴权

最后，从网络层面加固系统：

• 部署在私有 VPC 内：向量数据库、LLM 服务等核心组件不应暴露公网；
• API Gateway 统一入口：所有请求经网关鉴权、限流、日志采集；
• JWT 鉴权：用户登录后颁发 JWT，网关验证签名并解析 tenant_id、department 等声明（claims），透传给后端服务。

后端服务不再信任任何前端传来的租户信息，只认 JWT 中由认证中心签发的可信声明。

七、整体架构流程图

下图展示了多租户 RAG 系统的安全控制全流程：

该架构确保从网络入口到数据出口，每一步都处于安全控制之下。

八、结语

构建企业级多租户 RAG 系统，安全不是附加功能，而是架构基石。通过“向量库标量过滤 + RBAC 动态权限 + 敏感词双重拦截 + 全链路审计 + 网络纵深防御”的五层防护体系，我们可以在保障用户体验的同时，满足最严苛的企业合规要求。

对于系统架构师而言，关键在于：将安全控制点前移、自动化、不可绕过。唯有如此，RAG 才能真正成为企业可信的知识中枢，而非风险敞口。

技术选型提示：本文以 Milvus 为例，但 Weaviate、Qdrant 等也支持类似标量过滤机制，可根据实际技术栈调整实现细节。