向量库往往在 Demo 里「随便选一个」，到生产才暴露问题：召回掉了、过滤变慢、重建索引卡死写入。
本文聚焦运维视角，不重复讲 RAG 业务链路（见《从零理解 RAG》）。
你真正在运维的对象
- 集合 / Collection：维度、度量（cosine / L2）、元数据字段
- 索引：HNSW、IVF、DiskANN… 参数决定召回与内存
- 写入路径：实时 upsert vs 批量导入
- 查询路径：topK、filter、rerank 前置/后置
把这四块画成拓扑，出问题才知道该拧哪颗螺丝。
索引参数别拍脑袋
以 HNSW 为例（概念层面）：
M/efConstruction：建库质量与内存efSearch：查询时召回与延迟的旋钮
实践：
- 用固定评测集（问题 + 期望文档 ID）扫
efSearch - 画出 Recall@K vs P95 latency 曲线，选拐点
- 把选定参数写进配置与变更记录，禁止「线上随手改」
元数据过滤的坑
「先向量检索再过滤」和「带 filter 的混合检索」延迟差一个数量级都常见。
建议：
- 高频过滤字段建好索引（租户 ID、文档类型、时间）
- 避免超高基数字符串乱过滤
- 过滤选择性极高时，考虑先按元数据缩小候选再向量搜
容量与重建
容量规划要同时看：
| 维度 | 关注点 |
|---|---|
| 向量数 × 维度 | 内存 / 磁盘上限 |
| QPS | 查询副本数 |
| 写入速率 | 是否需要写缓冲 / 异步索引 |
| 重建窗口 | 全量重建要多久、是否双写 |
常见安全操作：
- 蓝绿索引：新索引建好后切流量，再删旧索引
- 双写窗口：迁移期写入两边，避免丢增量
- 只读切换瞬间：短暂停写或接受短暂延迟
监控与告警
最少要有：
- 查询 P50 / P95、超时率
- 空结果率（突然升高 → embedding 或数据问题）
- 索引大小与内存水位
- 写入失败 / 积压长度
召回变差不一定是模型问题——版本错配（旧 embedding + 新库）是经典事故。
运维清单
- embedding 模型版本与维度写进集合元数据
- 有离线评测集，发版可对比 Recall
- 重建有演练记录（耗时、回滚步骤）
- 租户级配额，防止单租户打爆共享集群
向量库稳了，RAG 才有资格谈「效果迭代」；否则你优化的是噪声。