企业 RAG 治理：检索管道背后的组织架构

40% 到 60% 的企业 RAG 部署无法进入生产环境。罪魁祸首几乎从来不是检索算法——HNSW 索引运行正常，嵌入质量也不错，向量相似度搜索已是成熟技术。问题发生在上下游：没有文档所有权、查询时未执行访问控制、PII 裸露在向量索引中，以及检索语料库在上线数周内就与现实脱节。这些都是治理失败，而大多数工程团队将其视为别人的问题，直到合规团队、安全审计，或某个收到了其他租户数据的用户把这变成自己的问题为止。

本文是受控 RAG 知识库的组织与技术解剖——写给拥有管道的工程师，而不是批准预算的高管。

文档所有权的真空

任何企业 RAG 系统需要回答的第一个问题看似简单：这份文档归谁所有？

在实践中，同一份文档通常以三到五个版本分散在 SharePoint、邮件归档、本地磁盘和 Wiki 中。当 RAG 系统在未建立所有权的情况下批量摄取这些版本时，检索就变得不确定——不是基于时效性或权威性，而是取决于哪个版本在嵌入空间中碰巧得分最高。2022 年的安全手册和 2025 年的安全手册会以相近的置信分数同时被检索出来，而模型无法区分二者。

解决方案是一份每份被摄取的文档在进入索引前都必须满足的元数据契约：

• owner：负责内容准确性的具名个人或团队
• source_system：权威来源（例如 Confluence 页面 ID，而非副本）
• last_validated_date：最后一次由人工确认内容有效的时间
• sensitivity_label：公开 / 内部 / 机密 / 受限
• version：明确版本号，能够取代先前版本

这些元数据必须在摄取时附加，而不是事后补填。不支持结构化元数据字段的向量数据库会让事后治理几乎无法实现——你无法过滤无法查询的字段。

所有权不是部署时的一次性任务，而是需要明确的交接流程：当员工离职或团队重组时，其名下的文档必须在下次新鲜度审计前完成重新分配或标记复查。未被治理的文档应自动从活跃检索索引中降级，而不是悄悄留着任其腐化。

访问控制必须在检索之前执行，而非之后

RAG 安全中最危险的误解是：访问控制属于 LLM 输出层——在将结果展示给用户之前过滤响应。这是本末倒置的，并且会产生一类看起来像模型质量问题、实则是安全边界被突破的故障。

如果某份文档在源系统中对某个用户不可见，那么该文档就不应进入检索步骤。不只是不展示在输出中——而是根本不被检索。无权访问 HR 薪酬数据的用户，不应产生会落在薪酬文档附近的嵌入。在 LLM 输出之后才从结果中删除是不够的；检索本身就是暴露。

有两种实用的强制执行模式：

按租户隔离存储：为每个租户（或组织单元）提供独立的向量索引，查询在 API 层被路由到对应的索引，交叉污染在结构上不可能发生。代价是运维开销：你要管理 N 个索引而非一个，任何 schema 变更或索引重建都会乘以 N 倍。适用于租户边界清晰且租户数量有限的 B2B SaaS 场景。

多租户存储加安全修剪：所有内容共存，但每次查询都强制执行过滤。每个检索请求携带用户身份和授权上下文，在向量搜索执行之前转换为元数据过滤器。PostgreSQL + pgvector + 行级安全，或 Pinecone、Milvus 带命名空间范围的元数据过滤器，均原生支持这一模式。关键约束：过滤器必须在服务端根据身份声明构建，绝不能来自客户端提供的参数。允许客户端传入 ?access_level=restricted 来绕过安全修剪的系统根本没有安全可言。

编排器与向量存储之间的 API 层是这一逻辑的落脚点：接收用户身份、将其转换为授权谓词、执行范围内的检索、记录每次访问。没有捷径：在构建授权层之前就搭建检索函数，最终会得到一个不经全面重构就无法合规的系统。

向量索引中的 PII 是一个不同性质的问题

传统数据治理将 PII 视为带有可识别字段的记录：数据库中包含姓名和出生日期的一行数据。向量数据库存储的是嵌入——文本的稠密数值表示。PII 问题在这里有两个不同之处。

其一，嵌入保留了原始文本的语义内容，这意味着即使原始文档已设置访问控制，敏感信息也可能传播到检索层。一张包含客户病情信息的支持工单被索引进共享语料库后，在处理涉及相似语义领域的无关查询时也可能被检索出来。

其二，典型的企业语料库并非专门构建的——它是从为人类读者写就的文档中批量摄取的。人事档案、会议记录、法律往来函件、客户通信，都是候选来源。从未应该被检索的 PII 就这样进入了嵌入空间。

分层防御措施如下：

1. 摄取前扫描：在文档进入管道前运行 PII 检测（Presidio、Amazon Macie，或本地部署的 LLM 以避免向外部 API 发送数据）。对超过 PII 密度阈值的文档进行标记或拒绝。

2. 结构化内容的字段级脱敏：对于已知结构的文档（财务报告、HR 文件），在嵌入之前进行实体替换——用 [PERSON] 替换姓名，用 [ACCOUNT_ID] 替换账号。语义内容得以保留，识别性内容则不保留。

3. 后检索、前 LLM 净化：在将检索到的数据块插入 LLM 上下文前，应用基于 NER 的后处理器。这是最后一道防线，而非主要控制手段——用于捕获摄取前扫描遗漏的内容。

加载中…