向量库运维

向量库是 RAG 的「记忆中枢」。它一旦丢数据或变慢，整个问答系统就瘫痪。本章覆盖生产运维的关键动作。

1. 备份与恢复

向量索引可重建，但重建需要重新Embedding（耗时烧钱），所以备份就是省钱：

# Milvus 示例：周期性快照
./milvus backup create --name rag-snapshot-$(date +%F)
# 恢复
./milvus backup restore --name rag-snapshot-2026-07-30

ℹ️备份什么

既要备份向量索引，也要备份「原文 + 元数据」，否则恢复后无法追溯片段来源。元数据（权限标签等）尤其不能丢。

向量库随文档量增长要扩容：

维度	做法
存储扩容	分片（shard）把数据摊到多节点
查询扩容	增加副本（replica）提升并发吞吐
索引切换	HNSW 精度高但占内存；IVF 省内存但需调 nprobe

# 给集合加副本提升读吞吐
./milvus collection replica add --name rag_docs --replica 2

多处写入（增量文档）时，需关注一致性级别：

⚠️增量更新要防脏读

边查边写时，若新文档尚未建完向量就被召回，会返回半截内容。写入完成前用「状态标记」屏蔽未就绪片段。

文档更新后，旧向量需失效。建议带版本号：

store.upsert(vector, doc_id="A", version=2)   # 新版本
store.delete(doc_id="A", version=1)            # 下线旧版，防重复命中

监控: 查询延迟 P99、召回命中率、内存/磁盘占用、索引重建耗时
告警: 延迟突增、磁盘将满、副本掉线

💡先快照再大规模重建索引

调整索引参数（如 HNSW 的 M、efConstruction）会触发全量重建。操作前先打快照，重建后对比第 13 章的 context_relevancy，确认精度未掉再切换流量。

🎯练习

为你的向量库写一条定时快照的 cron，并模拟一次「误删集合」后用快照恢复，验证原文与元数据是否完整。