多租户 RAG 架构设计：如何彻底杜绝客户数据泄露

作者
  • avatar
    姓名
    Nino
    职业
    Senior Tech Editor

在检索增强生成（RAG）系统的实际应用中，最严重的故障莫过于跨租户的数据泄露。当客户 A 提出问题，却收到了包含客户 B 私有文档内容的回答时，企业 AI 应用的信誉将瞬间崩塌。这种泄露往往不是由于模型本身的幻觉，而是源于检索层的架构缺陷。

在通过 n1n.ai 接入高性能大模型（如 DeepSeek-V3 或 Claude 3.5 Sonnet）构建应用时，开发者往往将精力集中在 Prompt 工程或生成质量上。然而，多租户环境下的数据隔离才是决定系统能否投入生产的关键。很多开发者错误地认为，只要在查询时加一个 tenant_id 的过滤器就足够了，但事实并非如此。

多租户隔离的三种核心模式

根据业务规模、成本预算和安全性需求，通常有三种主要的隔离策略：

  1. 共享索引 + 元数据过滤 (Shared Index + Filter)

    • 机制：所有租户的数据存储在同一个向量索引中，每个数据块（Chunk）都带有一个 tenant_id 标签。每次查询时，强制增加一个过滤条件。
    • 优点：成本最低，运维简单，能够轻松扩展到数百万个小租户。
    • 风险：隔离强度完全取决于代码的严谨性。只要有一个查询路径忘记添加过滤条件，就会导致全量数据泄露。

  2. 命名空间 (Namespaces)

    • 机制：在同一个向量数据库实例中进行逻辑分区（例如 Pinecone 的 namespaces 或 Milvus 的 partitions）。
    • 优点：结构上比过滤更安全。在代码中，租户 ID 变成了寻址的一部分。如果忘记提供命名空间，系统通常会报错，而不是返回错误的数据。
    • 缺点：某些数据库对命名空间数量有限制，且管理大量命名空间会带来额外的运维开销。

  3. 独立索引 (Index per Tenant)

    • 机制：为每个租户创建物理上独立的索引或数据库实例。
    • 优点：安全性最高。即使向量数据库本身出现 Bug，也不会发生跨租户泄露。这是受监管行业（如金融、医疗）的首选。
    • 缺点：成本极高，对于拥有数万个免费用户的 SaaS 应用来说，这在经济上是不可持续的。

为什么“过滤器”往往会失效？

元数据过滤最大的问题在于它的“失败模式”。过滤器是一种可选的缩小范围手段。如果你在调用 n1n.ai 提供的模型进行检索时，忘记了在查询中包含 tenant_id，向量数据库不会报错，它会默认你想要搜索整个数据库。

在复杂的企业级应用中，检索函数可能在几十个地方被调用：前端 API、后台异步任务、数据迁移脚本、管理员工具等。依靠人工代码审查来确保每一个调用都包含了正确的过滤器是不现实的。我们需要的是结构化约束。

最佳实践：类型安全的包装器

你不应该允许应用程序的任何部分直接访问原始的向量数据库客户端。相反，应该将其封装在一个必须在实例化时提供租户上下文的类中。

class TenantIndex:
    """整个代码库中唯一可以执行搜索操作的对象"""

    def __init__(self, store, tenant_id: str):
        if not tenant_id:
            raise ValueError("tenant_id 是必填项")
        self._store = store
        self._tenant = tenant_id

    def search(self, query, k=10, where=None):
        # 我们重新构建过滤字典，确保 tenant_id 始终存在
        # 并且不会被调用者传入的 where 参数覆盖
        scoped = { **(where or {}), "tenant_id": self._tenant }
        return self._store.query(query, k=k, filter=scoped)

关键细节：在构建 scoped 字典时，务必将 "tenant_id": self._tenant 放在最后，或者显式地覆盖传入的参数。这样可以防止调用者通过 where 参数恶意注入一个不同的租户 ID。此外，你应该在 CI 流程中加入检测，确保除了这个包装器模块之外，代码库中没有任何地方导入了原始的向量数据库客户端。

容易被忽视的泄露路径

除了检索查询本身，数据还可能通过以下渠道泄露：

  • 检索缓存：如果你使用查询文本的哈希值作为缓存键（Cache Key），那么两个不同租户询问相同的问题（如“公司的报销政策是什么？”）将会触发相同的缓存。如果缓存中存储了租户 A 的私有答案，租户 B 就会看到它。多租户系统中的每一个缓存键都必须包含租户 ID。
  • 重排序器 (Reranker)：在使用 n1n.ai 接入的高级重排序模型时，如果你为了节省延迟而将多个请求的候选文档合并批处理，不同租户的文档就会进入同一个内存空间。务必确保重排序客户端不会跨请求进行批处理。
  • 调试日志与追踪：像 LangChain 或 LlamaIndex 的追踪日志中通常包含检索到的完整文本。如果这些日志没有按租户权限进行隔离，任何拥有日志访问权限的开发人员都能看到所有客户的私有数据。

处理混合作用域：全局 vs. 私有

大多数真实的 RAG 产品都有三层内容：全局（产品文档）、组织（公司内部文档）和私有（用户个人上传）。简单的相等过滤器无法处理这种逻辑。建议采用 Rank Fusion 方案：分别对每个作用域运行一次搜索，然后使用 RRF（倒数排名融合）合并结果。这样不仅安全，还能确保全局语料库不会淹没用户自己的私有文档。

运维建议：成本与监控

在共享索引模式下，成本分摊（Cost Attribution）是一个大问题。你无法直接知道某个特定客户消耗了多少向量存储资源。从第一天起，就应该在所有的检索和生成调用中，将 tenant_id 作为指标的一个维度进行上报。通过 n1n.ai 的统一接口，你可以更轻松地监控不同模型在不同租户下的使用情况和成本分布。

最后，务必编写一个集成测试：向两个租户注入相似但带有特定标识的数据，模拟租户 A 的身份查询租户 B 的内容，断言返回结果必须为空。这是你系统中价值最高的一行测试代码。

通过 n1n.ai 获取稳定、高速的 LLM API 接口，让你的开发团队能够专注于构建这种坚如磐石的安全架构。

立即在 n1n.ai 获取免费 API 密钥。

参考来源：https://dev.to/multigrid/multi-tenant-rag-without-leaking-between-customers-3mlj