一句话定义
向量库的生产排错 = 五类症状（延迟/召回/写入/资源/一致性）× 三步定位（现象→根因→动作）的标准清单，加上一套向量库特有的监控项（金标准集定期复测召回、段状态、副本滞后）与变更纪律。
为什么重要
向量库的故障形态与传统 DB 不同：它有"静默劣化"这种独有物种——召回率慢慢下滑、p99 慢慢变差，没有报错、没有告警，直到业务方"感觉搜索变笨了"。本篇把 kp-008/009/017/022 的机制知识压缩成值班时能直接翻的清单，并补上"怎么在用户感知之前发现劣化"的监控设计。
前置知识
kp-008/009（HNSW 机制与参数——延迟/召回类故障的根因库）、kp-022（写删语义——一致性类故障的根因库）、kp-024（指标测量）。
核心概念
- 金标准集（golden set）：几百条带 GT 的固定查询，每次发布/变更后自动复测 recall——唯一能发现"静默劣化"的探针。
- 段状态监控：growing/sealed 段数量、墓碑比例、合并积压——写入健康的直接体检表。
- 副本滞后：主副本日志位点差——决定故障切换时会丢多少秒数据。
- 变更灰度：参数/索引/版本变更先旁路对比（影子查询）再切流。
原理与机制
排错总清单（现象 → 定位 → 动作）：
| 类 | 症状 | 定位 | 动作 |
|---|---|---|---|
| 延迟 | p99 毛刺、尖刺与合并窗口同步 | 合并任务时间表 vs 尖刺时刻 | 错峰合并、限流合并 IO |
| 延迟 | 带过滤比无过滤慢一个量级 | 查选择率分桶 p99（kp-017） | 切过滤执行策略/预过滤/分片路由 |
| 延迟 | 上线初期快、运行数月变慢 | 段数量、墓碑比例、图插入量 | 触发合并；评估周期性重建索引 |
| 召回 | 金标准集 recall 逐步下滑 | 数据分布漂移？增删改统计？未合并墓碑？ | 分段复测定位；重建索引/重训分区 |
| 召回 | 仅过滤查询召回差 | 过滤执行策略与选择率（kp-017） | 换策略；检查过滤字段索引 |
| 召回 | 量化后掉点 | 量化前后对比评测 | rescoring / 提 efSearch / 升精度（kp-009） |
| 写入 | 写入积压、导入奇慢 | WAL/队列积压、索引构建互锁 | 批量化；导入期关索引（kp-022） |
| 资源 | OOM | 按 kp-026 账本核对峰值 | 量化/降 M/错峰构建/加内存 |
| 资源 | 磁盘 IO 打满 | DiskANN 场景 IO 等待、合并重写 | 换高 IOPS 盘、限合并并发 |
| 一致性 | 刚写入查不到 | 一致性级别、可见性延迟（kp-022） | 升一致性档或接受有界滞后 |
| 一致性 | 删了还在/改了回旧值 | 墓碑跨副本传播、查询打旧副本 | 查副本滞后；验证读路由 |
监控项基线（向量库特有 + 通用）：
- 业务面：金标准 recall@k（每小时）、按选择率分桶的 p99、空结果率；
- 引擎面：QPS/p99、growing 段数与最老 growing 段年龄、墓碑比例、合并队列长度、副本滞后、内存/磁盘水位；
- 变更面：每次索引/参数/版本变更的记录与前后评测快照。
变更纪律：任何变更（ef/M/量化/版本升级）走"影子对比 → 灰度副本 → 全量"三段；每段都以金标准集与 p99 通过为准。
公式或模型
本节不适用：清单篇，涉及的计算均见被引 kp。
图示
排错决策流:
业务报告"搜索变笨" ─► 金标准集复测
├─ recall 跌 ─► 分布漂移? 墓碑堆积? 量化? ─► 重建/精排/升精度
└─ recall 正常 ─► 查 p99 与段状态
├─ p99 跌坏 ─► 合并窗口? growing 暴力扫? 过滤策略? ─► 错峰/flush/换策略
└─ 全正常 ─► 查询侧问题(embedding/切块/融合) ─► 转应用层排查实例或案例
值班复盘三连：①周一召回投诉——金标准集从 0.96 掉到 0.88，定位为竞对数据注入使分布漂移，旧索引分区失配，重训质心后恢复；②周三 p99 翻倍——监控显示每天 02:00 合并任务与批处理争 IO，错峰后恢复；③周五"删掉的文档还能搜到"——该查询走只读副本且副本滞后 90 秒，属于有界滞后的预期行为，业务改为删除后强制读主副本。三类故障对应三类根因库：分布（kp-007/009）、资源调度（kp-026）、一致性（kp-022）——这正是清单按类组织的理由。
直观类比
排错清单像急诊分诊手册：发热（召回跌）先量体温（金标准复测）再查感染源（漂移/墓碑/量化）；胸痛（p99 飙）先做心电图（段状态与合并队列）——症状对应检查、检查对应处置，值班时不需要重新发明诊断学。
常见误区（运维视角的元误区）
- "有报错才需要值班响应"——向量库最大风险是无报错的静默劣化；没有金标准集的监控体系等于没有召回监控。
- "参数变更不用走发布流程"——ef/M/量化档位都是生产变更，必须灰度+评测快照；"随手 SET 大点 ef"可在高峰期引发雪崩。
- "只监控引擎不监控数据"——分布漂移、墓碑堆积、租户倾斜都是数据侧病灶，引擎指标看起来一切正常；分桶统计与段健康度必须进大盘。
- "恢复即结案"——每次故障要更新排错清单条目（症状→根因→动作），清单是活文档；不复盘的清单半年就过时。
自测题
- 为什么金标准集必须"固定且带 GT"？
- p99 尖刺与合并窗口同步，怎么确认与缓解？
- 召回逐步下滑的三步定位法？
答：只有固定查询集 + 事先算好的 GT，才能把每次复测的 recall 差异归因于系统变化而非测量变化——它是"静默劣化"的唯一灵敏探针。
答：对齐时间戳确认相关；缓解为合并限速/错峰、拆小合并批次、高峰降合并并发——治本是写入节奏与合并策略的容量规划（kp-022/026）。
答：先金标准集分桶复测确认"真跌且在哪类查询跌"；再查数据侧（分布漂移/墓碑比例/增删改统计）；最后查索引侧（是否长期未重建/量化档位/分区失配），按确认的根因选重建、精排或重训。
与其他知识点的关系
本篇是 kp-008/009/017/022/024/026 全部机制知识的运维出口；kp-025 的评测协议为金标准集提供 GT；kp-027 处方中的"再评估触发条件"由本篇的监控指标触发。
延伸阅读
本节不适用：本篇为生产实践汇编，条目源自常见故障模式；机制依据见各被引 kp 的延伸阅读。