RAG 检索怎样用元数据过滤租户内容

我在把 RAG 接到多租户知识库时，最先遇到的不是向量模型效果，而是“相似”的结果可能来自错误租户。可靠的做法只有一个核心：把 tenant_id 作为服务端生成的硬过滤条件，放进向量检索请求；不要先召回一大批结果，再在应用层删除跨租户内容。

先把租户边界写进每个向量片段

一份文档通常会被切成多个 chunk。如果只在原始文档表上记录租户，向量库里的片段就缺少独立的授权边界，后续很容易出现“文档归属正确、片段过滤失效”。入库时建议把下面几类字段作为最小元数据合同：

字段类型也要固定。例如 tenant_id 是精确匹配的关键词，不要把它当全文字段分词；时间、状态和数值范围则分别使用向量库支持的对应类型。这样既能减少误匹配，也便于索引优化。

把过滤器放进向量检索请求

检索接口可以按下面的适配层组织。这里不绑定某一家向量数据库，vector_store.search 代表你对实际 SDK 的封装；不同产品可能把参数叫 filter、where 或 query_filter，但安全责任不变。

from dataclasses import dataclass

@dataclass(frozen=True)
class AuthContext:
    tenant_id: str
    allowed_scopes: tuple[str, ...]

def retrieve_for_tenant(vector_store, encoder, auth: AuthContext, question: str):
    # 租户身份来自已验证的会话，不从 question 或模型输出中解析
    if not auth.tenant_id:
        raise PermissionError("缺少租户身份")

    # 过滤条件由服务端固定，调用方只能提供业务范围而不能替换 tenant_id
    metadata_filter = {
        "and": [
            {"field": "tenant_id", "eq": auth.tenant_id},
            {"field": "document_status", "eq": "published"},
            {"field": "access_scope", "in": list(auth.allowed_scopes)},
        ]
    }

    # 先构造过滤器，再执行向量查询；不要先取全库结果再删除
    query_vector = encoder.embed(question)
    hits = vector_store.search(
        vector=query_vector,
        filter=metadata_filter,
        limit=8,
        include_metadata=True,
    )

    # 结果复核是第二道防线，不是替代检索过滤
    safe_hits = [item for item in hits if item.metadata.get("tenant_id") == auth.tenant_id]
    if not safe_hits:
        return {"answer": "当前租户没有可访问的相关内容", "sources": []}
    return {"answer_context": safe_hits, "sources": [item.metadata["source_id"] for item in safe_hits]}

代码里最重要的不是字典长什么样，而是数据流向：tenant_id 从认证上下文进入过滤器，问题文本只负责生成向量。若把过滤器交给大模型，让模型自行决定“查哪个租户”，那就把访问控制变成了提示词约束，不能接受。

性能和空结果要分开处理

元数据过滤不是只为安全服务，也会改变检索性能。对经常参与条件判断的字段建立匹配类型正确的索引；字段已经入库后再补索引，通常还要观察构建期间的查询负载。过滤很严时，limit=8 不一定能拿到 8 条结果，应用层不要用“取消过滤再补满”来掩盖数据问题。

我更愿意把空结果分成三类记录：租户确实没有资料、资料存在但状态不可见、过滤字段缺失或类型错误。前两类可以给用户明确的无结果提示，第三类应进入数据修复队列，并在检索层拒绝不完整片段。

上线前检查这四个隔离边界

• 身份边界：反向代理、应用会话和检索服务对 tenant_id 的来源是否一致？
• 写入边界：批量导入、重切片和补偿任务是否都会写入相同的租户字段？
• 查询边界：所有检索入口，包括问答、引用补全和后台搜索，是否复用同一个过滤适配层？
• 输出边界：生成提示词、引用列表和缓存键是否可能泄露别的租户内容？

如果业务需要跨租户管理员检索，应单独设计受控的审计角色和范围列表，不要给普通检索接口增加一个“跳过过滤”的布尔参数。这个开关一旦进入通用链路，后续很难证明每个调用者都使用正确。

相关问题

只在召回后过滤，为什么不够安全？

向量库已经把跨租户片段返回给应用，日志、缓存、重排和提示词组装都可能先接触到它们。后过滤只能减少最终展示，不能撤回已经发生的数据暴露。

租户 ID 应该放在向量文本里吗？

不建议把它当普通正文拼进 embedding 文本。租户身份是精确授权条件，应放在可过滤元数据中；否则语义相似度会把权限字段当成语言内容。

过滤后没有结果，能否自动放宽条件？

可以放宽非安全条件，例如时间范围或可选标签，但 tenant_id 和授权范围不能放宽。任何降级都必须保留硬租户过滤，并留下可审计的原因。