亿级向量的检索系统怎么设计？分片、过滤和多租户怎么做？
面试怎么回答
先估算：5 亿条 1024 维向量原始数据约 2TB，全内存成本太高，所以需要量化或磁盘索引，并分布式分片。分片上大租户独占分区，长尾小租户共享分区按租户字段过滤，避免每次查询访问所有分片。过滤是难点：先过滤后检索在数据多时退化，先检索后过滤在条件严时结果不足，所以用分区隔离最常用的租户维度，选择性极强的过滤单独评估，用真实过滤分布压测。多租户在服务端强制注入租户过滤，按租户限流，租户内再按用户权限组过滤。写入上批量和实时分开，删除标记后后台清理。再加多副本、后台重建切换、分片级监控和召回抽检。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
设计一个支撑全公司知识库的向量检索服务：5 亿条向量、200 个租户（部门或客户）、每个租户只能检索自己的数据，P99 延迟要求 200 毫秒以内。面试官问这题，考的是向量检索在大规模、多租户、带过滤条件下的工程设计。
先估算资源
- 5 亿条 × 1024 维 × 4 字节（float32）≈ 2TB 原始向量，加上 HNSW 图结构的开销，全内存放不下或者成本很高；
- 因此需要：量化压缩、磁盘索引，或者两者结合，并且分布式分片。
分片策略
- 按租户分片：大租户独占分片或集合，小租户共享分片。好处是查询只落在相关分片，隔离性好；问题是租户大小差异大时负载不均；
- 哈希分片：数据均匀分布，但每次查询要访问所有分片再合并结果（scatter-gather），分片越多，尾延迟越难控制；
- 混合：大租户单独分区，长尾小租户放在共享分区里按租户字段过滤。
过滤：最容易出问题的地方
带过滤条件的向量检索有两种基本方式：
- 先过滤后检索：先找出满足条件的数据再做向量检索。过滤后数据很少时准确，数据多时退化成暴力计算；
- 先检索后过滤：先做向量检索再过滤。过滤条件很严时，Top K 里可能大部分被过滤掉，结果不足甚至为空。
现代向量库通常在图遍历过程中结合过滤条件，但过滤比例极端时性能仍然会变差。工程上要：
- 用分区隔离最常用、最严格的过滤维度（比如租户），让大部分查询在分区内完成；
- 对选择性很强的过滤，单独评估，必要时走暴力计算；
- 用真实的过滤分布压测。
多租户隔离
- 数据隔离：租户 ID 作为强制过滤条件，在服务端注入，不能由调用方自由传；
- 资源隔离：大租户的大批量写入或高并发查询不能拖慢其他租户，按租户限流；
- 权限：租户内部还可能有文档级权限，需要再按用户的权限组过滤。
写入和更新
- 批量写入和实时写入分开：批量导入走离线构建，实时更新走增量写入；
- 删除通常是标记删除，后台合并时清理，需要关注删除比例过高带来的性能下降；
- 写入后可见性的延迟要明确告诉业务方。
高可用和运维
- 多副本，查询负载均衡；
- 索引重建在后台进行，构建完成后切换；
- 监控：每个分片的延迟、召回率抽检、内存、写入积压。