01

60 秒回答模板

我会先把扩展目标拆清楚：数据量变大后，不只是存得下，还要在可接受延迟内保持召回质量，并支持增量写入、权限过滤和成本控制。第一步评估规模，包括向量条数、维度、metadata 大小、更新频率、QPS、topK、过滤条件和召回目标。第二步选择索引，数据量较小时可用精确检索或轻量 HNSW；更大规模时要考虑 IVF、HNSW、PQ/量化、磁盘索引或冷热分层。第三步做分片和分区，按租户、业务域、时间、语言、权限或哈希切分，让查询只打必要分片，避免全库广播。第四步优化召回链路，先 metadata 过滤或路由，再向量召回，再 rerank，并用缓存和批量查询降低延迟。第五步建立评估和运维闭环，看 recall@K、nDCG、P95/P99 延迟、索引构建时间、更新可见延迟、分片倾斜、成本和 badcase。扩展方案的关键不是盲目加机器，而是让数据组织、索引结构和查询路由一起服务召回质量。

考点 规模画像
难度 真实面经题
回答目标 讲清设计、取舍和边界
02

深入解析

01

先量化增长压力

向量库扩展前要知道向量条数、维度、每条 metadata、QPS、topK、过滤条件、写入频率和 SLA。百万、千万、亿级向量的索引结构、内存占用、构建时间和查询策略完全不同，不能只说横向扩容。

02

索引选择影响召回和成本

HNSW 查询快、召回好但内存成本高；IVF 适合更大规模但依赖聚类和 nprobe 调参；PQ 或量化能省内存但可能损失精度；磁盘索引和冷热分层适合低频数据。选择要结合延迟、召回、更新频率和机器成本。

03

分片要减少无效搜索空间

分片可以按租户、知识库、业务域、语言、时间、权限或哈希做。业务分区能提高过滤效率和安全隔离，哈希分片有利于负载均衡。查询路由要尽量只访问相关分片，否则分片越多，聚合成本和尾延迟越高。

04

过滤和召回要协同

AI 应用常常需要权限、时间、类型、来源等 metadata 过滤。如果先全库向量召回再过滤，可能过滤后没有足够候选；如果过滤过窄，又可能漏召回。工程上要结合预过滤、分区路由、候选扩展和 rerank 保证质量。

05

更新链路要可在线运行

数据增长通常伴随频繁新增、删除和重嵌入。系统要支持增量写入、后台构建、影子索引切换、删除 tombstone、版本回滚和重建任务监控。否则索引新鲜度和线上稳定性会成为瓶颈。

06

评估要覆盖质量和运维

扩展后要用标注集和线上日志看 recall@K、precision@K、nDCG、空召回率、P95/P99 延迟、QPS、构建耗时、更新可见延迟、分片倾斜、内存/磁盘成本和失败率。没有评估就很容易为了速度牺牲召回。

03

易错点

  • 只回答扩容机器或换更大的向量数据库，没有拆索引、分片和召回链路。
  • 只看存储容量，不看 QPS、P95/P99 延迟、更新频率和召回目标。
  • 盲目使用某一种索引，不说明 HNSW、IVF、PQ 等取舍。
  • 忽略 metadata 过滤和权限过滤，导致召回结果不够或存在安全风险。
  • 分片后所有查询仍然广播全分片，尾延迟和成本没有真正下降。
  • 没有标注集和线上 badcase，无法判断扩展后召回质量是否变差。
04

面试官追问

向量库数据量变大时，为什么不能只加机器？

只加机器可能增加跨分片广播和结果合并成本。还要调整索引结构、分片策略、查询路由和过滤方式，才能同时保持召回和延迟。

HNSW 和 IVF 扩展时怎么取舍？

HNSW 通常召回和延迟表现好但内存成本较高；IVF 更适合大规模压缩搜索空间，但需要训练聚类和调 nprobe。要用业务标注集比较。

metadata 过滤会如何影响向量召回？

过滤条件如果在召回后才做，候选可能被过滤空；如果过滤前过窄，又可能漏掉相关内容。因此要结合分区、预过滤、候选扩展和 rerank。

如何做向量索引的在线重建？

可以后台构建新版本索引，双写或回放增量，完成后影子验证并切流；保留旧索引回滚，监控构建失败、更新延迟和召回差异。