向量库选了 HNSW，在线更新和索引一致性怎么处理？频繁更新的代价是什么？

先这样答

HNSW 是一种多层跳表式图索引，查询从顶层稀疏图逐层下钻到底层稠密图。它的核心优势是高维近邻查询达到毫秒级且召回率高，但图结构特性决定了频繁在线更新代价很大。处理更新与一致性通常依靠架构解耦，而非在原图上高频改写。

频繁更新的代价体现在三方面。一是删除不是真删——直接删点需修复图连接，通常采用墓碑标记延迟清理。频繁删改会让图质量退化，导致召回下降。二是插入会触发邻居重连，写入吞吐远低于查询吞吐，大批量更新通常走后台重建。三是 HNSW 的多层图和全量向量常驻内存，占用大，规模上升后重建窗口变长。

处理一致性有几种方案。首先是版本化索引，新数据写新版本，构建完成后原子切换，查询永远打在完整索引上。其次是增量分区，热数据放支持实时插入的小索引，冷数据放大索引，查询时两路召回合并结果，定期合并到大索引。删除则靠墓碑标记结合查询后过滤，依靠定期 compaction 重建清理。此外，需配合业务缓存失效策略，用文档更新消息驱动索引与缓存清理，通过同一版本号校验保证一致。

总结来说，HNSW 是读多写少场景的最优解。强项是查询，弱项是删改，系统设计的核心思路是用版本切换和冷热分区把在线改图变成离线换图。

面试官会怎么追问

• 「除了 HNSW，你还知道哪些向量索引？它们分别适合什么场景？」 IVF 类属于倒排文件索引，插入便宜，适合写多读少场景，召回率略低。扁平索引采用暴力检索，适合小库精确召回。若对内存敏感，可选 DiskANN 或量化类索引，它们对磁盘友好且省内存。
• 「如果商品知识频繁更新，索引和缓存怎么保持一致？」 采用消息驱动机制。商品文档变更时，发消息同时触发向量索引更新和业务缓存失效。查询时提取版本号进行同一版本号校验，防止查到脏数据。
• 「如果有一批数据需要紧急入库，HNSW 怎么处理最快？」 在当前 HNSW 索引上大批量插入会导致写入阻塞。常规做法是走后台重建，将新数据与存量数据一起构建全新的图索引版本。构建期间线上查询不受影响，完成后原子切换上线新版本。

回答的坑

• 认为 HNSW 支持高效的实时增删改查，忽略了其写入吞吐极低且频繁删除会破坏图质量的事实，遇到频繁更新必须引入冷热分区或版本切换。
• 混淆物理删除与逻辑删除的代价，误以为 HNSW 删数据能立即释放空间，实际只能依赖墓碑标记逻辑隐藏，最终仍需定期重建索引来恢复连通性。