企业官网建设流程全解析

上一篇文章里，我们讨论了 RAG 如何支持权限控制。

一个重要结论是：

权限不能只放在页面层，而是必须进入检索链路。

用户没有权限看到的知识，不能进入召回、排序和 Prompt。

但企业 RAG 继续往前走，还会遇到一个更大的问题：

不是一个团队在用知识库，而是多个团队、多个客户、多个项目同时在用。

这时系统面对的就不只是权限问题，而是多租户问题。

比如：

客户 A 和客户 B 都在用同一个知识库系统。 销售团队、研发团队、财务团队共用同一套平台。 Alpha 项目、Beta 项目、Gamma 项目都在持续沉淀资料。

如果多租户设计不合理，知识库很容易混在一起：

客户 A 的资料召回到了客户 B 的内容。 不同项目的答案互相污染。 同一个索引里混入了不该共享的数据。 删除一个租户的数据时，另一个租户的内容也被影响。

这篇文章就讨论一个企业 RAG 非常现实的问题：

RAG 如何做多租户，才能让企业知识库既能共享平台能力，又能保持隔离。

为什么多租户是 RAG 的必答题？

Demo 阶段的 RAG，通常只有一个知识库。

上传文档 ↓ 切分 ↓ Embedding ↓ 检索 ↓ 回答

这个流程简单直接。

但一旦变成企业平台，就会出现多套知识空间。

比如一个 SaaS 知识问答平台，可能同时服务：

多个客户 多个部门 多个事业部 多个子公司 多个项目组

这些知识空间不能相互污染。

多租户问题的本质，不只是“多放几份数据”。

它还涉及：

索引怎么隔离 检索怎么过滤 成本怎么统计 数据怎么删除 配置怎么区分 日志怎么归属

如果这些不做清楚，系统规模一大，就会变得很难维护。

所以多租户不是附加功能。

它是企业级 RAG 平台化的基础能力。

一个常见误区：所有租户共用一套全量索引

很多人最开始会这样设计：

所有文档都写进同一个向量数据库。 检索时只靠 query 去找相关内容。 返回结果后再判断属于哪个租户。

这个方案在小规模时可能还能跑。

但只要租户一多，就会出现几个问题。

第一，召回污染。

不同租户的文档语义可能很接近。

比如“报销流程”“审批规则”“权限申请”在不同租户中都会出现。

如果没有强隔离，检索很容易召回别的租户资料。

第二，性能压力变大。

全量索引越来越大，召回成本和 Rerank 成本都上升。

第三，删除困难。

当某个租户下线，或者某个项目结束时，必须把它的数据彻底清理。

如果所有租户混在一套索引里，删除会很麻烦。

第四，合规风险增加。

客户 A 不应该通过检索看到客户 B 的知识。

这个问题不是“模型自己会不会小心”的问题，而是系统设计问题。

所以多租户不能只靠问答层补救。

它必须从数据和索引层开始隔离。

多租户有哪些隔离方式？

RAG 多租户常见有三种隔离方式。

1. 物理隔离

每个租户一套独立索引、独立存储、独立配置。

比如：

tenant_a_index tenant_b_index tenant_c_index

优点是隔离最强，删除和审计最清楚。

缺点是租户多时运维成本高。

适合：

高敏感场景 大客户场景 合规要求高的场景

2. 逻辑隔离

多个租户共用一套索引，但每条数据都有tenant_id。

检索时通过 metadata filter 过滤。

例如：

{"tenant_id":"tenant_a","doc_id":"doc_001","chunk_id":"chunk_001"}

优点是成本低，扩展快。

缺点是必须保证过滤链路足够严格。

适合：

中小规模 SaaS 平台 租户数量较多 知识隔离要求可通过元数据和权限系统满足

3. 混合隔离

核心客户物理隔离，普通租户逻辑隔离。

这是很多企业平台更现实的做法。

比如：

大客户单独一套索引。 普通客户共用一套多租户索引。

优点是兼顾成本和安全。

缺点是架构更复杂。

如果系统未来要规模化，混合隔离通常更实用。

tenant_id 设计要统一

无论采用哪种隔离方式，tenant_id都是最关键的字段之一。

tenant_id不只是一个字符串。

它应该贯穿整个 RAG 链路：

文档采集 文档解析 Chunk 切分 Embedding 索引写入 检索 Rerank Prompt 日志 审计 删除 导出

比如一个 Chunk 的元数据可以长这样：

{"tenant_id":"tenant_a","space_id":"space_finance","doc_id":"doc_001","chunk_id":"chunk_001","status":"active","version":"2026"}

这里的space_id可以表示租户内部的知识空间。

例如：

tenant_a 下面有 finance、hr、dev 三个空间。

系统检索时，可以先按 tenant 再按 space 过滤。

这样更灵活。

如果tenant_id不统一，后面会非常麻烦。

比如有的地方叫org_id，有的地方叫customer_id，有的地方叫workspace_id。

字段命名不一致，最终很容易导致漏过滤。

所以多租户设计第一件事，就是统一标识体系。

检索阶段必须先过滤租户

多租户最重要的原则之一是：

先限定租户范围，再做语义检索。

一个合理流程是：

用户问题 ↓ 识别当前 tenant_id ↓ 构造 tenant filter ↓ 在当前租户范围内做召回 ↓ Rerank ↓ 生成答案

比如：

tenant_id = tenant_a status = active space_id in ["finance", "shared"]

如果先全库召回，再事后过滤，就有两个风险。

第一，越权或串租户内容已经进入候选。

第二，过滤后结果可能不够。

所以最稳的方式是把租户过滤前置。

这和权限控制的原则一样：

不要先看见，再判断能不能看。

而是先限制可见范围，再去检索。

多租户和权限控制有什么区别？

多租户和权限控制经常被放在一起讨论，但它们不是同一件事。

可以这样理解：

多租户解决“属于谁”的问题。 权限控制解决“谁能看”的问题。

例如：

tenant_a 里有 finance、hr、dev 三个空间。 finance 空间里只有财务角色能看某些文档。

这里有两层边界：

第一层是租户边界。

第二层是租户内权限边界。

所以企业 RAG 往往需要双层过滤：

tenant filter + permission filter

比如：

tenant_id = tenant_a AND department = finance AND status = active AND allowed_roles intersects current_user.roles

如果只做租户过滤，不做权限过滤，内部仍然可能越权。

如果只做权限过滤，不做租户隔离，又容易串租户。

所以这两个能力要一起设计。

成本怎么统计？

多租户平台上线后，成本归属很重要。

因为不同租户会消耗不同数量的：

Embedding 检索 Rerank 模型调用 存储 带宽 日志

如果没有成本统计，就很难回答：

哪个租户最耗资源？ 哪个空间查询最多？ 哪个项目文档更新最频繁？ 哪个租户需要单独扩容？

所以每一次请求最好都带上租户维度的指标。

比如：

tenant_id space_id query_tokens retrieval_count rerank_count generation_tokens latency error_count

这样你才能做费用分析和性能分析。

多租户不是只管隔离，还要管计量。

数据删除和迁移要可控

多租户系统里，删除和迁移是常见需求。

比如：

某个客户退订了。 某个项目结束了。 某个部门改组了。 某套知识空间需要迁移到另一个租户。

这时系统必须能准确删除或迁移对应的数据。

如果 tenant_id 不清楚，或者 Chunk 和原文档之间没有映射关系，删除就会出问题。

一个完整的删除流程应该包括：

标记 tenant 关闭 ↓ 停止新文档入库 ↓ 从检索范围中排除 ↓ 清理向量索引 ↓ 清理原始文件 ↓ 清理缓存和日志中可删除部分

迁移也类似。

如果一个租户需要改名、换空间或调整组织结构，系统应该能根据元数据重建索引。

所以建议保留：

doc_id -> chunk_id -> vector_id

这种可追溯映射关系。

多租户平台的配置也要隔离

多租户不只是数据隔离。

配置也要隔离。

比如：

不同租户使用不同检索策略 不同空间使用不同 chunk 参数 不同客户使用不同模型 不同部门使用不同摘要模板 不同租户有不同限流和配额

这意味着系统不能把所有配置写死在全局。

更好的做法是：

tenant_config space_config retrieval_policy prompt_policy quota_policy

这样不同租户可以有自己的策略。

比如：

tenant_a：更重视权限和日志 tenant_b：更重视成本 tenant_c：更重视多轮问答质量

多租户平台的价值之一，就是策略可配置。

一个可落地的多租户架构

一个比较稳妥的多租户 RAG 架构，大致可以这样设计：

用户请求 ↓ 身份认证 ↓ tenant_id 识别 ↓ 权限上下文加载 ↓ 构造租户过滤器 ↓ 候选检索 ↓ Rerank ↓ Prompt 生成 ↓ 日志和成本记录

其中有几个关键点。

第一，tenant_id 要从认证系统或网关中拿，不能随便信前端传参。

第二，租户过滤器要进入检索层，不要放到最后。

第三，检索结果、Rerank 候选和最终引用都要可追溯到 tenant。

第四，删除、迁移和下线流程必须同步更新索引。

第五，租户级日志和配额要单独统计。

做到这些，企业 RAG 才能从单体知识库变成真正的平台化系统。

落地建议

第一，小规模可以逻辑隔离，大客户优先物理隔离。

第二，统一tenant_id和space_id的命名，别在不同模块里各写各的。

第三，检索前先过滤租户，再做召回和 Rerank。

第四，租户和权限要双层控制，不能只做一层。

第五，文档删除、租户下线和空间迁移要有完整流程。

第六，成本统计要按租户做，方便收费和扩容。

第七，配置要可分租户管理，不要全局写死。

第八，多租户上线前一定要做串租户测试。

总结

RAG 做多租户，核心不是把知识库分成几份这么简单。

它要解决的是隔离、检索、权限、成本、配置和删除整条链路的问题。

最重要的原则是：

先识别租户，再做检索；先限定范围，再让模型回答。

如果租户边界不清楚，知识库就会互相污染，答案也会失去可信度。

企业级 RAG 想要长期运行，多租户是绕不过去的一步。

下一篇文章，可以继续讨论 RAG 如何处理 PDF、Word、Excel 和网页。

因为真实知识库不只是纯文本，文档解析质量会直接影响后续所有环节。