向量数据库写入放大：只看查询延迟是不完整的

向量数据库评测常常只看查询延迟和召回率，但生产系统还有写入。Embedding 不断更新、文档删除、权限变化、索引重建、分片迁移，都会带来写入放大。只看查询快不快，会低估维护成本。

向量索引不是静态展品，它在真实业务里会持续变化。写入路径不稳，查询再快也很难长期运行。

一、写入路径要拆开看

flowchart TD
  A[Document Change] --> B[Chunking]
  B --> C[Embedding]
  C --> D[Index Insert]
  D --> E[Compaction Or Merge]
  E --> F[Searchable]

用户看到的是“文档更新”，系统做的是切片、向量化、索引写入、后台合并和可见性切换。每一步都有延迟和失败可能。

二、写入放大来自后台维护

HNSW、IVF、LSM 类存储路径都会有不同维护成本。删除也不一定是真删除，可能先打 tombstone，再异步清理。

write_amplification_sources:
  - vector insert
  - metadata update
  - tombstone record
  - segment merge
  - index rebuild
  - replica sync

如果业务频繁更新文档，必须评估后台 merge 对查询延迟的影响。

三、评测要包含混合负载

只用静态数据集压测查询不够。应该构造读写混合 workload。

workload:
  query_qps: 500
  insert_qps: 50
  delete_qps: 10
  update_qps: 20
  vector_dim: 1536
  top_k: 20
metrics:
  - query_p95
  - query_p99
  - write_latency_p95
  - index_freshness_lag

index_freshness_lag 很关键：文档更新后多久能被检索到。很多业务不能接受分钟级不可见。

四、删除和权限更新更麻烦

RAG 场景中，文档权限变化后，无权限用户必须立刻不能检索到相关切片。如果向量索引删除滞后，就可能泄漏。

SELECT chunk_id, active, permission_version
FROM vector_chunk_registry
WHERE doc_id = 'doc_123';

建议维护 registry，把索引状态、权限版本和文档版本分开记录。查询时至少要做 metadata 过滤兜底。

写入压测还要观察后台任务。很多系统在短时间压测里看起来很稳，跑几个小时后 merge backlog 才开始堆积。评测报告应记录后台队列长度、段数量、删除标记比例和 compaction 耗时。

background_metrics:
  segment_count
  merge_queue_depth
  tombstone_ratio
  compaction_cpu
  freshness_lag_p95

如果查询 p99 在后台合并期间明显抖动，就要重新评估写入节奏和资源隔离。

五、总结

向量数据库评测不能只看查询延迟和召回率。写入放大、删除滞后、索引合并、权限更新和 freshness lag 都要进入测试。

查询快只是半张成绩单。写入路径稳定，向量检索系统才算真的能上生产。

向量数据库越接近业务主链路，越要把更新、删除和权限变更当成一等场景，而不是查询 benchmark 的附录。