RAG 与向量库运维

• 检索质量指标定义
• 黄金样本与评估
• 监控与告警

检索质量下降可通过监控指标发现：一是检索评估集（golden set）——预先构造带标准答案的查询集，周期性运行检索，计算召回率（Recall@k）、命中率（Hit Rate）、MRR（平均倒数排名）等，偏离基线即告警；二是线上信号——检索命中后生成的回答质量（用户反馈、采纳率）下滑；三是检索日志分析——无命中率（empty retrieval）上升、检索结果相关性评分下降。将这些指标与上行流（embedding 版本、索引状态、数据更新）关联定位根因。

检索质量是 RAG 的根基，检索差则生成必然差。监控核心是"离线评估集 + 线上代理指标"双轨：评估集量化召回率，线上信号反映真实影响。需把检索质量指标与 embedding 版本、索引构建、数据更新等上游变更关联，才能定位"为什么下降"。

• 检索链路分段
• 索引 vs 算力瓶颈区分
• 定位方法

检索延迟分两段：向量查询（向量库侧）与重排（rerank 模型侧）。定位方法：分段埋点——分别计量向量查询耗时与 rerank 耗时，看哪段超时；看索引侧指标——查询 QPS、索引 segment 数、HNSW 图构建代价、内存/磁盘 IO，若 QPS 高或索引碎片多则偏向索引优化；看算力侧——GPU/CPU 利用率，若 rerank 模型算力打满则有排队，偏向算力扩容。用压测分离：仅向量查询 vs 仅 rerank，确定瓶颈段。

定位的核心是"分段测量"——同一超时请求在各段耗时分别暴露。索引问题（构建、碎片、参数）与算力问题（模型吞吐、排队）处理方式不同：前者调索引参数/重建，后者扩容或缓存。用链路分段 + 指标对照 + 压测分离三层定位。

• trace 分段设计
• 检索命中信息关联
• 分析与排障

全链路 trace 用统一 trace_id 贯穿查询解析、embedding 生成、向量检索、rerank、上下文拼接、LLM 生成各 span。检索命中信息（命中的 chunk、相似度分数、来源文档、命中数）作为 span 属性记录。分析时用 trace 关联：检索命中少则看召回（embedding/索引/分块），命中相关但答案差则看生成（上下文截断/模型）。可构建"检索命中概要"，分离检索质量与生成质量。

RAG 排障的关键是"检索-生成因果链"。trace 把检索命中与生成输出关联起来，才能判断"是检索没召回还是生成没用上"。检索命中信息（chunk、分数、来源）是连接两段的桥梁。运维上据此做检索质量与生成质量的分段归因。

• 增量更新与全量重建
• 双缓冲/灰度切换
• 在线一致性

更新策略：增量更新——新增/修改文档只更新对应索引段，适合高频小量更新；全量重建——定期重建整个索引，保证一致性。不影响在线检索的关键是"双缓冲 + 灰度切换"：先在新索引副本上构建完成，再原子切换（写时复制/别名切换），旧索引继续服务直到新索引就绪。切换前做校验（文档数、抽样命中率），失败则回滚。配合版本化管理索引，支持回退。

更新的核心是"先构建后切换"，避免在线检索读到半成品索引。增量更新保证实时性，全量重建保证一致性，两者结合。用索引别名/版本实现原子切换与快速回滚，是"不影响在线"的关键保障。运维上监控构建任务与切换耗时。

• 备份策略（快照/物理备份）
• 恢复时效（RPO/RTO）
• 增量与流式

亿级向量数据备份需分层：全量备份（定期快照/物理文件拷贝）+ 增量备份（WAL 或段日志）+ 远端复制（跨区域）。恢复时效保障：RPO 通过增量与流式复制降低，RTO 通过预置恢复环境、并行重建索引、就近备份降低。向量库（如 Milvus）支持数据段（segment）级备份与恢复，恢复时优先恢复已 flush 的段，未 flush 的从 WAL 重放。定期演练恢复流程验证时效。

备份恢复的难点在"数据量大 + 索引重建耗时"。保障时效靠"快照+增量+远端复制"组合与"恢复演练"。RPO/RTO 要按业务定义并实测。恢复时索引重建是最大耗时点，可预先生成索引或并行重建。备份与恢复要纳入 SLA 演练。

• 核心监控指标
• 告警阈值
• 资源水位预警

监控指标：查询 QPS 与 P99/P95 延迟（反映检索性能与流量）、索引构建任务状态（构建进度、失败率、耗时）、内存水位（HNSW 图常驻内存）、磁盘水位（段文件与日志）。告警：QPS 超过容量或延迟超阈值（如 P99>100ms）告警；构建任务失败/超时告警；内存/磁盘水位超 80% 警告、90% 告警。结合查询限流与扩容。

向量库监控分"业务性能"（QPS/延迟）与"资源健康"（内存/磁盘/构建）两类。内存水位最关键（HNSW 常驻内存，超限 OOM），磁盘水位影响段合并与写入。告警要分级并联动扩容/清理。构建任务监控确保索引不落后于数据。

• 上下文超限处理
• 截断与优先级策略
• 质量影响

上下文超限时需截断：按相关性优先级拼接——先保留系统提示与用户问题，再按检索相似度从高到低填充检索片段，超出窗口的部分丢弃。可用 Token 预算分配：系统提示+问题占固定预算，检索片段按分数和预算依次加入，必要时压缩（提炼）或分批。截断后需监控"被截断片段的占比"与质量影响，避免因截断丢失关键信息。

截断的核心是"保留最相关信息"。按相似度排序 + 预算分配是常用策略；也可用"压缩重写"（LLM 压缩检索片段）替代简单截断。运维上要监控截断率与由此引发的质量下降，并反馈调整检索 top-k 或分块大小。

• embedding 升级的兼容问题
• 双写与重建
• 迁移与回滚

embedding 模型升级使新向量与旧向量空间不兼容（余弦相似度不可比），直接混合会导致检索错乱。迁移方案：双写——升级期间新旧 embedding 并行生成，新文档写入新向量、旧文档按需重建；全量重建——择机用新 embedding 重建全部索引，切换前用采样集对比新旧模型的检索质量（Hit Rate/MRR）。迁移需灰度：先小范围验证新 embedding 检索质量，再全量重建，并保留旧索引可回滚。

embedding 升级的核心风险是"空间不兼容"。迁移要"先验证、后重建、可回滚"。对比新旧 embedding 在评估集上的检索质量决定是否值得迁移。重建期间在线服务用旧索引，新索引就绪后切换。双写/重建是保证在线不受影响的常态手段。

• 反馈收集机制
• 根因分析
• 改进闭环

收集"答非所问"反馈：用户显式反馈（点赞/踩/纠错）、隐式信号（采纳率、重问率、删除重问）、抽样人工标注。改进闭环：将负面样本归因——是检索没召回相关（召回问题）、检索到但排序错（rerank）、上下文截断（拼接）还是模型生成（生成）？根据归因改进检索参数、分块策略、rerank 或 prompt。负面样本回流到评估集持续验证改进效果。

反馈闭环的核心是"收集→归因→改进→再验证"。答非所问通常是检索与生成链路的某个环节出问题，需分类归因而非一刀切。负面样本回流到评测集形成闭环，确保持续改进且不回归。运维上把反馈数据与检索/生成 trace 关联。

• HNSW 与 IVF 特性对比
• 选型依据
• 性能运维

HNSW 基于图结构，检索延迟低、召回率高，适合高并发低延迟场景，但内存占用大、构建慢；IVF 基于聚类（倒排），内存占用小、构建快，适合数据量大、可接受略高延迟的场景，需权衡 nprobe 与召回。选型依据：数据量、QPS、延迟要求、内存预算、召回目标。性能运维：监控 QPS/延迟/内存，调 HNSW 的 efSearch、IVF 的 nprobe，维护段合并与索引重建。

索引选型是"召回率×延迟×内存"的权衡。HNSW 高召回、低延迟但资源贵，IVF 省内存但延迟/召回略差。运维要针对指标调参数（efSearch/nprobe 越大召回越高但越慢），并随数据量增长评估是否重建或换索引。Milvus 适合大规模、PGVector 适合与 PG 集成的中小规模。

• 构建参数调优
• 增量与全量重建窗口
• 构建对在线的影响

构建参数：HNSW 的 M（每节点连接数）、efConstruction（构建质量）影响召回与内存，IVF 的 nlist（聚类数）影响检索速度。增量更新通过段合并（segment merge）实现，后台执行；全量重建需规划窗口（低峰期），因为重建消耗 CPU/内存并可能影响在线查询。运维上用"后台构建 + 双份索引 + 切换"降低影响，监控构建耗时与资源占用，控制并发构建数。

构建运维的关键是"平衡构建代价与在线性能"。参数过大则构建慢内存高，过小则召回低。增量更新保证实时性，全量重建在窗口内完成一致性。用资源隔离与限速避免构建拖垮在线。运维要监控构建进度、段合并状态与资源占用。

• 延迟预算管理
• 批处理优化
• 失败降级

rerank 是重排模型推理，延迟预算要控制（如 P99 < 50ms），否则拖累整体检索链路。批处理——把多个查询的候选文档合并批量推理，提升 GPU 利用率与吞吐；但批处理会引入等待，需平衡 batch 大小与延迟。失败降级——rerank 服务故障或超时时，降级为"按向量相似度直接排序"（跳过 rerank），保证可用性。用缓存（相同查询的 rerank 结果）减少重复计算。

rerank 是延迟与质量的关键权衡点：rerank 提升质量但增加延迟。运维重点在"延迟预算 + 批处理 + 降级"：控制预算不拖垮链路，批处理提吞吐，故障降级保可用。监控 rerank 延迟、吞吐、降级次数与质量影响。

• 召回差的分段定位
• 响应慢的分段定位
• 排障方法论

召回差分段定位：先看命中率/召回率指标，再逐段排查——embedding（向量质量差/版本过旧）、分块（chunk 过大/过小导致语义割裂）、索引（构建不全/参数不当/数据未更新）。响应慢分段定位：先看整体延迟，再分解——检索（向量查询慢/rerank 慢）、生成（模型推理慢/上下文过长）。用 trace 分段测量每段耗时与命中情况，对照指标定位瓶颈段。

排障的核心是"分段测量 + 指标对照"。召回问题归因于 embedding/分块/索引三源头，响应问题归因于检索/生成两段。用 trace 与指标把"症状"归因到"根因"，避免在错误环节调优。运维上建立"RAG 排障 Playbook"。

• 分段指标定义
• 采集埋点
• 监控与告警

分段指标：检索段（召回率/命中率、向量查询耗时、无命中率）、rerank 段（rerank 耗时、批处理吞吐）、生成段（生成延迟、TTFT/TPOT、输出长度）。采集：在管道各阶段埋点，输出分段耗时与命中统计，写入时序库；检索命中信息（chunk/分数）入日志供分析。监控：分段延迟 P99、各段耗时占比、召回率趋势，异常即告警。分段指标用于定位瓶颈在检索还是生成。

分段采集的价值是"让 RAG 管道延迟可归因"。响应慢时通过分段耗时占比定位是检索还是生成。召回率与命中率反映检索质量。运维上把分段指标与 trace、日志三信号联动，形成完整可观测性。

• 批处理与吞吐
• 缓存命中率
• 版本升级兼容

embedding 服务运维：批处理——把多个文本合并为 batch 推理，提升 GPU 吞吐，需控制 batch 大小与延迟；缓存——对相同/相似文本的 embedding 结果做缓存，提高命中率可显著降低重复计算与延迟；版本升级兼容——升级 embedding 模型后新向量与旧向量空间不兼容，需双写/重建并对比检索质量，避免索引混用。监控 QPS、缓存命中率、embedding 延迟与版本。

embedding 是高频调用，批处理与缓存是成本/延迟关键。缓存命中率直接决定重复计算量。版本升级是最大风险点（空间不兼容），需受控迁移。运维上把三者的指标统一监控，并做好版本治理。

• 容量计算模型
• 索引类型对容量的影响
• 内存/磁盘估算

容量估算：原始数据 = 向量维度 × 向量数 × 精度（如 float32 4 字节）。索引放大系数：HNSW 内存约为原始数据的 1.5-3 倍（图结构+邻居表），IVF 内存约为原始数据 1.1-1.5 倍（聚类+倒排）。磁盘还需加上段文件、日志与备份。估算公式：内存 ≈ 向量数 × 维度 × 4B × 索引系数；磁盘 = 原始数据 + 日志 + 备份。据此确定实例规格与分片。

容量估算的核心是"原始向量 + 索引放大系数 + 副本/备份"。索引类型决定内存放大，副本决定总量。估算不足会导致 OOM，估算过度则浪费成本。运维上用公式做预算，并预留增长空间与分片扩展能力。

• 分片与副本布局
• 故障切换
• 重建耗时保障

高可用设计：分片（shard）按数据量水平扩展，副本（replica）跨节点/可用区冗余保证读可用。故障切换——主副本故障时自动切换到从副本，配合健康检查与选举。重建耗时——副本故障后需重建，耗时取决于数据量与索引构建速度，通过就近副本、预置索引、并行重建降低 RTO。设计上要避免同分片副本放同一物理机（反亲和），并定期演练切换。

向量库高可用与数据库类似：分片扩容量、副本保可用、故障切换保连续性。重建耗时是 RTO 关键，需预置索引与并行能力。反亲和布局避免单点故障。运维上演练切换流程，监控副本落后与重建状态。

• 向量隔离方式
• 配额与限流
• 租户级监控

多租户 RAG 隔离：数据隔离——按租户分区（partition/collection）存储向量，检索时限定租户范围，避免跨租户数据泄露；配额——按租户限制向量存储量、检索 QPS、embedding 调用量，超限限流或拒绝；监控——按租户统计 QPS、延迟、存储占用与成本，支撑租户级治理与计费。隔离可用租户 ID 过滤 + 分区索引实现。

多租户的核心是"数据隔离 + 资源配额 + 成本归因"。数据隔离保证安全（不见他人数据），配额保证公平（坏邻居不拖垮他人），成本归因支撑计费。运维上强制租户 ID 贯穿检索，按租户监控与限流。

• 墓碑机制
• 段合并
• 空间回收

向量库删除采用墓碑（tombstone）机制：删除标记记录删除的 ID，检索时过滤，而非立即物理删除（因为不可变段）。更新 = 删除 + 新增。段合并（segment merge）——定期把小段合并成大段，合并时顺带落实删除（真正物理删除已标记数据），回收索引空间。运维需监控墓碑比例、段数量与合并任务，控制段个数避免检索性能下降。

不可变段结构决定了删除用墓碑+合并落地。墓碑保证检索正确，段合并既提升性能（减少段数）又回收空间。运维要监控墓碑增长（若长期不合并，删除数据仍占空间）与段数，规划合并窗口。