数据与租户：schema 怎么排、租户怎么隔

2.1RAG 的 schema：把 chunk 落成 entity

一个 chunk 就是 Milvus 里的一行 entity：主键 + 向量 + 一段原文 + 一组用来过滤的标量字段；schema 设计的本质，是预先想清楚"检索时要按什么条件切、答案要回溯到哪份原文"。

一行 entity 的典型字段：pk（主键，自增或外部 ID）、dense（语义向量）、可选的 sparse（稀疏向量，给 BM25/全文检索用，03 章的混合检索靠它）、text（VARCHAR，存 chunk 原文，既喂 LLM 也是 BM25 的分词源）、parent_doc_id（指回整篇文档）、一组过滤用标量（tenant_id / timestamp / source / acl_tags），以及一个 dynamic field（动态字段 $meta，JSON，装那些零散、不稳定的元数据）。

比文档深一层：三个容易被默认值带过去的点。其一，分块发生在 Milvus 之外——切分策略、chunk 大小、重叠都是在 LangChain 或自建管道里决定的，Milvus 只负责存切好的结果，所以"召回质量差"很多时候根因在分块、不在索引。其二，parent_doc_id 不是可有可无的装饰：有了它才能"删整篇文档的所有 chunk"（按 parent_doc_id 批量 delete）和"取相邻块"（small-to-big：命中小 chunk，回查同一 parent 的前后块补上下文）；没存它，删一篇文档就得逐 chunk 找、上下文也拼不回来。其三，过滤字段必须是显式标量字段——同一个值塞进 $meta 这个 JSON 里也能过滤，但 JSON 路径过滤要解析、要走通用扫描，比独立标量列上的索引慢一截；凡是高频 filter 的维度，提成显式列。

与下一节的关系：schema 决定了一行里有哪些字段；其中 tenant_id 这个字段怎么用来切分租户，正是下一节四级隔离要展开的——它既可以只是个普通过滤列，也可以被提升成 partition key。

2.2多租户四级隔离：从物理到逻辑的四档

在一套 Milvus 上隔离多个租户有四档——Database、Collection-per-tenant、Partition-per-tenant、Partition Key（按 tenant_id 分区）；从上到下隔离越来越弱、可扩展性越来越强，选型由租户数量主导。

四档的机制底座是 深潜 01 的数据模型（partition vs shard）。逐档看：

Database——最强的逻辑隔离单元，不同 database 之间近乎物理隔离、RBAC 也能按 database 授权。但每个集群的 database 数量默认上限是 64（maxDatabaseNum）。适合"少数几个彼此完全独立的大业务线/大客户"，撑不了海量租户。

Collection-per-tenant——每个租户一个 collection，隔离强、可独立建索引、可单独 drop。配置项上 collection 数量上限写着 65536，但这是个配置值不是真实墙：官方实测在约 10000 个 collection 量级就开始劣化，建议控制在 5000 以内。更隐蔽的是，有效负载是 collection × shard × partition 一起计入 maxGeneralCapacity 这个总预算——partition 会悄悄吃掉 collection 的额度。适合"数百到数千个、需要强隔离的中大客户"。

Partition-per-tenant——一个 collection，每个租户一个 partition。比 collection 轻，但单个 collection 的 partition 数量硬上限是 1024。适合"上千以内、且能共用同一份 schema 的租户"，超过 1024 就此路不通。

Partition Key——一个 collection，把 tenant_id 声明为 partition key，Milvus 自动按哈希把每个租户的数据分散进 num_partitions 个物理分区（默认 64）。没有硬上限，可达百万级租户。代价是隔离最弱（所有租户物理上同处一个 collection、共享分区），且带一串硬限制（见下文 callout）。这是海量小租户 RAG 的默认选择。

比文档深一层——记住这条主线：四档的可扩展性是 Partition Key > Partition > Collection > Database，而隔离强度正好反过来：Database > Collection > Partition > Partition Key。租户越多、越要往可扩展那头走，单租户能拿到的隔离就越弱——这不是某一档的缺陷，而是这条轴上无法回避的权衡。决策因此几乎只问一个问题：有多少租户、要多强的隔离。

Partition Key 的路由机制：把 tenant_id 设为 partition key 后，Milvus 用它哈希到 num_partitions 个分区。关键约束是——查询必须带 tenant_id == "A" 这样的等值过滤，才会触发分区裁剪（深潜 04 的分区裁剪），只扫该租户落到的那个分区；不带这个 filter，就退化成全 collection 扫描，既慢又跨了租户。2.5.4 起还有个 Partition Key Isolation（partitionkey.isolation=true）：给每个 key 值建独立索引，进一步提升单租户查询效率——但它要求 filter 里正好一个 key 值，一旦写成 tenant_id IN ["A","B"] 或多租户聚合查询，隔离就被破坏、回退普通扫描。

2.3元数据与标量索引：要 filter 的字段就要建索引

显式标量字段装高频过滤维度、dynamic field 装零散元数据；铁律是——任何你要 filter 的字段都得建标量索引，否则 filter 退化成全表扫描，把向量索引的加速整个抵消掉。

显式标量字段 vs dynamic field：判据是"过滤频率 + 维度是否稳定"。tenant_id、timestamp、source、acl_tags 这类几乎每条查询都用、形态固定的，做成显式标量列并建索引；那些稀疏出现、形态多变、低频过滤的元数据（某些来源独有的标签、调试信息），塞进 dynamic field（$meta JSON）即可。提成显式列的代价是 schema 要预先定义、改动要重灌；换来的是过滤走专用索引而非 JSON 路径解析。

比文档深一层——按基数选索引类型：标量索引不是只有一种，选错类型同样拖慢过滤。基数（cardinality，不同取值的个数）是主判据：

与下一节的关系：标量索引让 filter 本身快起来；但即使 filter 飞快，它和向量检索叠加时还有一层更深的反直觉——过滤掉的行越多，向量索引（尤其图索引）反而越容易召不回来。这就是下一节要收口的 01 面④。

2.4过滤比↔索引：极严的 filter 会饿死图遍历

过滤比越高（通过的行越少），越伤 HNSW 的图遍历——图在被过滤掉的点之间走不动、凑不齐连通候选，召回反而塌；这是 01 面④反直觉点的机制收口，也直接影响索引选型。

比文档深一层——为什么是图索引塌：机制底座是 深潜 03 的过滤比→索引。HNSW 是靠"在邻居图上贪心游走"找近邻的：从入口点出发，每步跳到离 query 更近的邻居。当 filter 极严，图上绝大多数点都被判出局，游走时从一个通过的点跳不到下一个通过的点——邻居全被过滤掉了，搜索要么提前困死、要么扫遍全图也凑不齐 top-k，召回因此塌。IVF 类（先聚类分桶、桶内暴力扫）受影响小得多：它本来就是在选中的桶里线性扫，过滤掉一部分行只是少扫几个，不破坏可达性。

Milvus 2.x 用 iterative filtering（可迭代过滤） 和 概率（alpha）策略缓解这个问题——大致是动态判断 filter 的选择性，过滤太狠时改变遍历/补采样策略，避免空手而归。但缓解不等于消除，选型规则不变：

2.5综合：给一个多租户 SaaS 客服 RAG 排 schema

把 2.1–2.4 叠到一个具体场景——数千租户、每租户文档带来源和日期、查询按"租户 + 最近 90 天"过滤——一次决定隔离级别、标量字段、各字段索引，以及那个叠加 filter 的选择性如何反推向量索引。

场景：SaaS 客服知识库，数千个租户，每个租户有自己的文档，文档带 source（来源系统）和发布日期；典型查询是"在本租户、最近 90 天的文档里，找和问题相关的内容"。逐面落地：

① 隔离级别——数千租户、无强物理隔离/合规要求、共用一份 schema。Database（≤64）和 Partition（≤1024）都装不下数千，Collection-per-tenant 数千个已逼近建议上限且运维重。落到 Partition Key（图 2.2 的默认终点）：把 tenant_id 设为 partition key。代价照单接收——初始灌库不能用 bulk import、load 整个 collection、RBAC 管不到内部，租户隔离靠应用层强制 tenant_id == 当前租户。

② schema 放哪些标量字段——除向量和 text 外，显式标量列至少要有：tenant_id（partition key，也是隔离边界）、timestamp（文档日期，给"最近 90 天"）、source（来源过滤/统计）、parent_doc_id（删整篇、取邻块）。零散的额外元数据进 $meta。

③ 各建什么标量索引——按 2.3 的基数判据：timestamp 用 STL_SORT/range（"最近 90 天"是范围查询）；source 基数低（就那么几个来源系统）用 BITMAP；tenant_id 作为 partition key 由分区机制承载路由，若还要在过滤里直接命中，按其高基数用 INVERTED。

④ 叠加 filter 的选择性 → 向量索引——查询里 tenant_id == X 先触发分区裁剪，把范围缩到该租户那个分区；再叠 timestamp >= now-90d。在单个租户的数据量内，"最近 90 天"未必很严（90 天往往是大多数文档），所以叠加后的过滤比对该租户通常是中等而非极端——HNSW 一般扛得住。但对那些只有几篇文档、且 90 天内更少的小租户，叠加后往往只剩个位数行通过：这正是 2.4 的高过滤比陷阱，对这类租户的查询要么靠 iterative filtering 兜底、要么对极小集合直接暴力扫。关键不是全局选一种索引，而是认识到同一套 filter 在大租户和小租户上的选择性天差地别，召回风险集中在尾部小租户。