索引增量更新与运维
知识库会变：新增走增量写入，删除多数向量库只能软删除、定期重建；文档改版要靠版本字段与 chunk 级 id 保证「检索到了也取得到原文」。索引与源数据的一致性是运维问题，不是算法问题。
也叫：索引运维 · 增量更新 · 软删除 · 索引重建 · 数据一致性
先学向量数据库与选型
几个容易被追问的工程点出自 T2-4
元数据过滤：预过滤 vs 后过滤。 带条件的查询（category = 'X' 且语义相似）有两种执行顺序：先过滤再搜（预过滤）或先搜再过滤（后过滤）。后过滤有个致命问题：Top-100 里可能只有 3 条满足条件，结果不够用。Qdrant、Milvus 默认预过滤；pgvector 要留意查询计划。这题是区分「用过」和「读过」的好探针。
增量更新与删除（对应 Q2-23）：
- 新增：直接 upsert，HNSW 支持增量插入。
- 更新：删旧 + 插新，注意向量和原文要原子性对齐，否则会出现「检索到了但取不到原文」。
- 删除：多数实现是软删除（打标记跳过），空间不会立刻释放；删除比例高了会让图结构劣化、召回下降，需要定期 compact 或重建索引。
- 实用做法：用版本号/时间戳做元数据，检索时过滤旧版本，再异步清理——避免更新期间出现检索空窗。
维度与存储估算：1536 维 float32 单条约 6KB，100 万条约 6GB（还没算图结构开销）。这个粗算能力面试时很好用——顺便可以带出降维（T2-3）和量化两个优化方向。
六个库的甜点区各不重叠；迁移成本没想象中高，但别拖到三百万条才想起来
库选型（截至 2026-08）
| 库 | 甜点区 | 运维负担与备注 |
|---|---|---|
| pgvector | 已有 PostgreSQL、百万级以内 | 极低（装个扩展）。事务一致性好，向量和业务数据同库 JOIN；性能不及专用库。零额外运维，起步默认 |
| Qdrant | 中等规模、性能优先 | 低（单二进制／docker run）。Rust 实现无 GC 停顿，元数据过滤强，单节点 P99 延迟通常最低 |
| Milvus | 亿级、真正的分布式 | 高（依赖 etcd／对象存储／消息队列）。大规模场景验证最充分；2.5+ 内置 BM25 全文检索，一库搞定混合检索 |
| Weaviate | 混合检索、开发体验 | 中。原生 hybrid 查询带 α 参数 |
| Chroma | 原型、快速验证 | 极低（进程内嵌）。不建议上生产：不支持混合检索、扩展性有限 |
| Elasticsearch / OpenSearch | 团队已有 ES 栈 | 中。BM25 底子厚，向量能力后补 |
决策线与容易被追问的点
- 一句话决策
< 100 万且已有 PostgreSQL → pgvector；要低延迟强过滤 → Qdrant；亿级／分布式 → Milvus- 只是原型
- Chroma 可以，但规划好迁移 —— 别在它上面跑到三百万条才想起来
- 迁移没那么贵
- embedding 是确定性的，换库不用重算向量；导出向量和元数据重新写入，百万级通常半小时内搞定
- 预过滤 vs 后过滤
- 后过滤的致命处：Top-100 里可能只有 3 条满足条件。Qdrant、Milvus 默认预过滤，pgvector 要留意查询计划
- 增量更新
- 新增直接 upsert；更新 = 删旧 + 插新，向量和原文要原子对齐，否则「检索到了但取不到原文」
- 存储粗算
- 1536 维 float32 单条约 6KB，100 万条约 6GB —— 还没算图结构开销
更新期间还有个坑叫检索空窗：删旧插新的过程里，那条内容一时查不到。实用做法是拿版本号／时间戳当元数据，检索时过滤旧版本，再异步清理。另外，预过滤 vs 后过滤这题是区分「用过」和「读过」的好探针。
以上节选自T2-4 向量数据库与 HNSW：原理与选型，读全文能看到前后语境。