向量数据库选型与索引运维

• 四类向量库的定位差异（专用 vs 嵌入式 vs 搜索扩展）
• 三维度对比：数据规模、标量过滤、运维成本
• 不应引入专用向量库的信号判断

四类方案的定位：Milvus 是专用向量库（大规模、分布式、HNSW/IVF 等索引丰富、支持标量过滤与动态 Schema），适合亿级向量、高并发、需向量与标量联合过滤的独立场景；Qdrant 也是专用库（Rust 实现、性能好、payload 过滤强、部署轻），适合中等规模到大规模、对过滤与吞吐要求高的场景；pgvector 是 PostgreSQL 扩展（嵌入现有数据库、事务与 SQL 一体、支持 HNSW/IVF），适合百万级向量、与业务数据强关联、希望"一个数据库搞定"的场景；Elasticsearch/OpenSearch 是全文搜索扩展（kNN 检索 + BM25 混合天然优势），适合"全文检索为主 + 向量为辅"或已重度使用 ES 的场景。三维度选型：数据规模——百万级以下 pgvector 或 Qdrant 足够，亿级选 Milvus/Qdrant 分布式；标量过滤能力——权限/时间/租户过滤占比高时优先过滤能力强（Qdrant payload 索引、Milvus 标量索引、ES 原生过滤）；运维成本——pgvector 零新组件（复用 PG 运维）成本最低，专用库增加集群、备份、监控等运维面。不应引入专用向量库的信号：向量规模小（<50 万）且增长慢；标量过滤与事务需求强（业务数据都在关系库）；团队无专职运维（专用库的集群运维成本无法承担）；全文检索占比更高（ES 更合适）；以及"仅需原型验证"阶段——先用 pgvector 或内存方案验证检索效果，再决定是否引入专用库。选型结论要"数据驱动"：用自有数据压测（规模、QPS、过滤组合、延迟）对比，而非看官网指标。

向量库选型是"规模 × 过滤 × 运维"三维权衡：不存在通吃方案，pgvector 的零运维与 Milvus 的大规模各取一端。答题按四方案定位、三维对比、反信号（小规模/强事务/无运维）与压测验证展开。

• 三个参数的机制与影响（图连接度、构建搜索宽度、查询搜索宽度）
• 参数与召回率、延迟、内存的权衡关系
• 用自有查询集调优的流程

HNSW 三个核心参数：M（每个节点的最大连接数）——决定图的稠密度：M 越大图越稠、路径越短、召回率越高，但内存占用与构建时间上升（每条边要存指针与距离）；efConstruction（构建时的动态列表大小）——决定构建质量：越大图构建越接近"理想近邻图"，召回率上限越高，构建时间与内存上升，但对查询延迟无直接影响；efSearch（查询时的动态列表大小）——决定查询精度：越大搜索越广、召回率越高，查询延迟线性上升。三者关系：召回率主要由 M 与 efSearch 决定（构建质量通过 efConstruction 影响上限），延迟由 efSearch 主导，内存由 M 主导（与向量维度、数据量共同决定）。调优流程（不照搬默认 M=16/efC=200/efS=64）：第一步用自有查询集（带标注）建索引；第二步固定 M 与 efConstruction（如 M=16、efC=200），扫描 efSearch（16→32→64→128→256）画"召回率-延迟"曲线，找"边际收益变缓"点（如 64 到 128 召回率提升 <0.5% 时取 64）；第三步固定 efSearch，扫描 M（8→16→32→48）观察召回率与内存（M 翻倍内存约增 20-40%），在"召回增量 vs 内存增量"平衡点取值；第四步验证 efConstruction（构建时间可接受前提下取较大值提升召回上限）；第五步在目标负载（QPS、并发）下验证 P95 延迟，结合"延迟预算"定最终参数。监控线上召回率（采样评估）确保参数在真实分布上有效，随数据量增长定期复调。

HNSW 调参的本质是"用评估曲线替代默认值"：efSearch 管查询精度、M 管图密度与内存、efC 管构建质量。答题按"三参数机制→调优流程（固定两参扫一参、画收益曲线）→负载验证与定期复调"展开，突出"自有数据 + 收益曲线"方法论。

• pre-filter 与 post-filter 的执行语义与实现差异
• 对权限正确性的影响（过滤后置的泄漏窗口）
• 验证"被过滤文档绝不召回"的方法

执行顺序差异：pre-filter（如 Milvus 的过滤条件、Qdrant 的 payload 过滤在 HNSW 搜索前生效、ES 的 post_filter 语义、pgvector 的 WHERE 先于 ORDER BY）——先按标量条件圈定候选再做向量搜索，过滤严格生效；post-filter——先做向量 top-K 再过滤，被过滤文档"已经进入了候选计算"，且不同实现的行为不同：有的在返回前过滤（结果不含越权文档，但计算浪费）、有的过滤后结果不足 K 条。对权限正确性的影响：权限过滤必须 pre-filter，否则"被过滤文档"可能出现在日志、重排、上下文组装等中间环节（泄漏路径）；更关键的是部分向量库的"近似过滤"实现——如 HNSW 图搜索时对不满足条件的节点"跳过但继续沿边探索"，若实现不当可能返回过滤不完整的结果，或过滤后返回数量不足且不报错（静默丢结果）。验证"绝不召回"的方法：一是构造权限负样本集——为每个角色构造"该角色不应检索到"的文档集合；二是端到端断言——用多组查询（命中负样本的查询）跑检索，断言返回结果中负样本文档 ID 绝不出现（自动化 CI 回归）；三是库级直查验证——直接查询向量库 API（绕过应用层）验证过滤条件生效（防止"应用层过滤了、库内未过滤"）；四是边界场景——过滤条件与 top-K 交互（过滤后候选少于 K 时返回数量与语义）、多条件组合过滤（租户 + 时间 + 权限）、嵌套布尔过滤（OR 组合中的权限分支）；五是审计日志——检索请求记录过滤条件与结果集，抽样人工复核"结果集中的每个文档都满足过滤条件"；六是性能侧验证——pre-filter 与 post-filter 的延迟差异记录，确保权限过滤没有因性能被绕过（有人为性能把权限过滤后置是常见的隐性违规）。

权限正确性验证的核心是"把'绝不召回'变成可断言的契约"：负样本断言 + 库级直查 + 边界场景。答题按"pre/post 语义差异与泄漏风险→负样本集与自动化断言→库级与边界验证→审计复核"展开。

• 无中断升级架构（双写、影子检索、蓝绿）
• 切换与回退条件的设定（指标门槛、窗口、验证）
• 一致性保障（增量追平、双写校验）

无中断升级的架构三件套。双写：升级期间写入路径同时写旧集群与新集群（或旧索引与新索引），保证新环境数据不落后；双写校验——抽样对比两侧写入结果（doc 数、向量指纹），双写失败率监控（新侧写入失败不阻塞主链路，进补偿队列）。影子检索：查询流量复制到新集群（影子模式，结果不返回给用户），对比新旧结果——Recall 差异、Top-K 重合率、分数分布、延迟；影子阶段无用户影响，可充分暴露问题。蓝绿切换：验证通过后把查询流量从蓝（旧）切到绿（新），切换方式——DNS/路由层灰度切换（1%→10%→50%→100% 阶梯），切换期间旧集群保持服务与数据同步（不立即下线）。回退条件设定（事前定义，不是事后拍板）：质量门槛——影子/灰度期"Recall 不低于旧集群 99%、Top-K 重合率不低于阈值、零结果率不上升、错误引用不增加"；性能门槛——P95 延迟增量不超过 X%（如 10%）；数据门槛——新集群 doc 数与墓碑集与旧集群一致（增量追平完成）；任何门槛未达即回退；回退窗口——切换后保留 24-72h 观察期（覆盖完整日周期），观察期内发现问题一键回切；回切动作——路由切回 + 新集群保留（数据继续同步或冻结排查）。一致性细节：切换前"增量追平"（双写期间积压的数据在新集群补齐，用水位对齐）；切换后旧集群继续收双写一段时间（防回切时数据缺失）；版本号入日志（检索日志记录集群版本，支撑回放归因）。

无中断升级的骨架是"双写保数据、影子保验证、蓝绿保切换"，灵魂是"回退条件事前定义"。答题按"三件套机制→回退条件（质量/性能/数据门槛）→灰度阶梯与观察窗口→增量追平与版本日志"展开。

• 扩容手段（分片、副本、资源升配）与适用场景
• 容量规划（规模、增长、内存模型）
• 扩容信号指标（延迟、资源、写入积压）

扩容手段：副本增加——解决"读瓶颈"（查询 QPS 与读延迟），副本分担查询流量，需考虑一致性开销（写入同步到多副本）与成本（副本数 × 内存）；分片扩展——解决"单分片容量与写入瓶颈"，分片把数据与负载水平拆分，但分片数增加带来跨分片查询与运维复杂度，且多数向量库分片数需在建库时或通过 rebalance 调整（在线加片支持不一，需评估）；资源升配——单节点 CPU/内存升配，最简单但受单机上限约束。容量规划：按"向量规模 = 文档块数 × 维度 × 字节数"估算（float32 每向量 4 字节/维，int8 1 字节/维，PQ 更低）+ HNSW 图结构内存开销（M 参数相关，通常为向量本身的 1.5-3 倍）+ 标量索引与 payload 开销；规划按"当前量 × 增长倍率（如 2-3 年 × 年增长）"预留，并考虑段合并与临时副本的峰值内存。扩容信号指标：读侧——QPS 触顶（延迟随 QPS 快速上升）、P95 延迟持续超标、CPU 长时间高水位；写侧——写入延迟上升、段合并积压（待合并段数增长）、索引构建积压（embedding 队列堆积）；容量侧——内存使用率持续 >70-80%、磁盘增长逼近阈值、分片容量不均（热点分片）；质量侧——召回率漂移（可能因段合并异常或资源争抢）。扩容决策流程：先确认瓶颈类型（读/写/容量），再选手段（读→副本，写/容量→分片），小步扩容 + 压测验证 + 回退预案；扩容前用容量模型预估效果（副本加 1 对 QPS 的理论提升）。

扩容设计的关键是"先分瓶颈类型再选手段"：读瓶颈加副本、写与容量瓶颈加分片。答题按"手段适用场景→容量模型（内存估算公式）→信号指标体系（读/写/容量/质量四类）→决策流程"展开。

• 备份策略设计（全量 + 增量、快照频率、保留周期）
• 备份与变更流程的联动（变更前快照、变更后验证）
• 恢复验证（完整性校验、召回基线对比）

备份策略：全量快照（按日/周）+ 增量备份（按小时/分钟，基于变更日志或 WAL）+ 墓碑/删除事件日志（保证恢复后删除状态也正确）；快照保留周期按"恢复点目标"（RPO：可容忍丢失的数据窗口）与"恢复时间目标"（RTO）设计，如 RPO=15min 需高频增量，RTO=1h 需热备或快速恢复演练。纳入变更流程：任何变更（索引重建、版本升级、参数调整、Schema 变更）前自动触发"变更前快照"；变更执行中记录变更日志（版本号、参数、时间）；变更后按"验证清单"检查（doc 数、采样检索、黄金评估集指标），验证通过才宣告变更成功；变更失败时从变更前快照恢复并回退。恢复验证（恢复 ≠ 成功，必须验证）：一是完整性校验——恢复后 doc 计数与元数据一致、向量维度与索引类型正确、段结构健康（无损坏段）、墓碑集与删除日志对齐（恢复后删除状态正确，防"删了又回来"）；二是召回基线对比——用固定评估集（黄金集）在"恢复后索引"与"恢复前基线"上跑 Recall@K、MRR，差异超阈值（如 Recall 降 >1%）即视为漂移，需重新索引或回退到更早快照；三是数据新鲜度校验——恢复后索引水位与源系统水位对比（增量备份是否追平，丢失窗口内的数据需补回）；四是演练机制——定期（如每季度）做恢复演练（从快照恢复到临时环境，跑完整验证），确保"真到用时能恢复"，并量化 RTO/RPO 达标率。

备份恢复的工程要点是"把备份变成变更流程的一部分，把恢复变成可验证的演练"：快照服务于变更回退，恢复验证服务于"召回基线不漂移"的承诺。答题按"备份策略（快照+增量+删除日志）→变更联动（变更前快照+变更后验证）→恢复验证（完整性+召回基线+水位）→定期演练"展开。

• 三种隔离机制的粒度与实现（collection/partition/namespace）
• 隔离粒度对检索性能与运维复杂度的影响
• 取舍原则与混合方案

三种隔离机制粒度递增：collection（独立集合）——每个租户一个集合，隔离最彻底（索引、参数、生命周期独立），检索天然不跨租户，但集合数随租户线性增长，运维（监控、备份、迁移）与资源开销大，适合大租户或强隔离需求（合规）；partition（分区）——共享 collection、按分区键隔离（如 tenant_id 分区），隔离在存储与查询层面生效（查询限定分区），运维面小，但分区数过多时小分区管理开销与查询路由复杂度上升，适合租户数量中等、数据量相当；namespace（命名空间/过滤）——共享索引 + 元数据过滤（tenant_id 条件），最灵活、运维最简单，但依赖过滤的正确性（过滤条件漏配即泄漏）、过滤性能随候选集增大下降、无法物理隔离资源。取舍原则：按"租户规模 × 数据量 × 隔离强度要求"分档——租户少（<10）且数据大：collection 级（各自大集合，性能与隔离都好）；租户多（百级）且数据均匀：partition（按租户分区，兼顾隔离与运维）；租户极多（千级+）且单租户数据小：namespace 过滤（或 partition + 过滤混合），依赖服务层强制注入租户条件；合规强隔离场景（金融、医疗）即便租户多也优先 collection/partition 物理隔离。混合方案常见：大租户单独 collection，长尾租户共享 collection + partition/过滤；跨层双保险——即使有 partition 隔离，检索仍附加 tenant_id 过滤（纵深防御）。性能考量：过滤型隔离的 pre-filter 性能（过滤字段建索引）、分区型隔离的分区内检索性能、collection 型的跨集合聚合成本（需要跨集合查询时）。运维考量：collection 数膨胀导致的备份与迁移成本、partition 数过载导致的小对象开销，都要纳入取舍模型。

隔离粒度是"隔离强度与运维成本"的梯度选择：collection 最隔离最贵、过滤最省最险。答题按"三种机制的隔离强度与代价→按租户规模分档选型→混合方案与纵深防御→性能与运维考量"展开。

• 数据质量类监控（召回漂移、索引新鲜度）
• 写入链路监控（构建积压、段合并）
• 删除与空间监控（墓碑堆积、空间回收）

只监控 QPS 与延迟会漏掉"系统在悄悄变坏"：QPS 正常但检索质量已退化、写入正常但索引在积压、删除正常但墓碑在膨胀。数据质量类：召回漂移——定期用固定评估样本（采样查询集）对线上索引测 Recall@K，与基线对比（趋势监控），漂移超阈值告警（根因可能是索引段问题、Embedding 版本漂移、数据缺失）；索引新鲜度——最新文档写入到可检索的延迟（写读延迟）P95，超 SLA 告警（反映摄取链路健康）；零结果率与低分率也归此类。写入链路：索引构建积压——待构建/待合并队列长度（embedding 生产速度 vs 索引消费速度），积压增长预示写入瓶颈或段合并能力不足；段合并积压——待合并段数、合并耗时，段数过多导致查询扫描开销上升；写入失败率与重试率。删除与空间：墓碑堆积——删除标记数量与总文档数比例（墓碑过多：过滤开销上升、空间未回收、查询变慢）；空间回收状态——已删除但未物理清理的段占比、磁盘使用趋势（只增不减异常）；软删除堆积的识别（删除率高但物理空间未降）。监控设计原则：指标分层（资源层 QPS/延迟 + 数据层 新鲜度/漂移 + 写入层 积压 + 清理层 墓碑）；告警分级（漂移/积压 P1 级，趋势类 P2）；监控与告警联动处置（积压→限流写入/加构建节点；墓碑堆积→触发段合并/清理任务；漂移→触发归因流程）；所有指标按"租户/集合"分层，防止整体正常掩盖局部异常。

向量库监控的进阶是"从性能视图到数据生命周期视图"：召回漂移、构建积压、墓碑堆积分别对应检索质量、写入健康、删除健康。答题按四层指标（资源/数据/写入/清理）与处置联动展开，强调分层防掩盖。

• 向量与标量索引的一致性机制（删除传播、版本覆盖）
• 一致性校验方法（计数、指纹、抽查）
• 删除残留的防护与监控

防止"删了还能搜到"需要机制与校验双管齐下。一致性机制：删除——写入侧对向量索引与标量索引（元数据）同时执行删除（同一事务或事件流），向量库用"墓碑/物理删除"、标量库更新状态；更新——按 doc_id 幂等覆盖（旧向量删除 + 新向量写入 + 标量版本递增），先写标量（新版本生效）再删旧向量（或先删旧向量再写新标量，防止中间态"新旧并存"）——推荐"版本号 + 原子切换"（检索条件带版本过滤，新版本到位才切）。一致性校验方法：一是计数核对——索引 doc 总数与元数据/源系统计数对比（删除后两边都减）；二是删除对账——"已删除 ID 清单"与向量库实际存在 ID 对比（定期全量扫描或按批次核对），发现残留即补删；三是抽查检索——从删除清单抽样构造查询（用删除文档的内容片段作为查询），断言检索结果不含该文档（自动化回归）；四是更新对账——同一 doc_id 的向量版本与标量版本比对，旧版本残留计数。防护与监控：删除残留率指标（应删除但仍在索引中的比例）持续监控；删除传播的端到端延迟（删除事件到检索不可见）SLA 监控（超时即告警——这是"删除窗口"风险）；段合并时物理清理墓碑并复核；对"软删除"策略要明确——墓碑保留期结束后必须物理删除，防止长期软删膨胀；所有删除/更新操作记录审计日志（谁、何时、删了什么、传播状态），支撑合规与对账。

"删了还能搜到"的根因通常是"向量与标量删除不同步"或"更新中间态残留"：机制上要版本原子切换，校验上要删除对账与残留监控。答题按"一致性机制（事件删除/版本覆盖）→三类校验（计数/对账/抽查检索）→残留监控与审计"展开。

• 量化类型与损失机制（SQ 标量、PQ 乘积、int8）
• 同一评估集的前后对比方法（指标、口径）
• 收益量化与决策（精度-性能权衡）

量化决策必须是"同一评估集上的前后对比"：量化前与量化后的索引用完全相同的查询集、标注与参数（k、过滤、efSearch），唯一变量是量化配置。度量召回损失：对比 Recall@K、MRR、nDCG（固定同一 K 与评估集版本）——损失 = 量化后指标 - 基线指标（如 Recall@10 0.93 → 0.90，损失 3.2%）；注意按查询类型分层报告损失（长尾查询、实体密集查询对量化更敏感——量化压缩的是向量精度，稀疏特征与细节信息先受损），分层能看到"整体损失小但某类查询损失大"；附加质量验证——抽样看答案端到端（召回损失是否传导为答案错误）。度量延迟收益：同负载压测（相同 QPS 与并发）对比 P95 延迟、吞吐（QPS）、内存占用——收益 = 延迟下降比例、QPS 提升倍数、内存下降比例（量化后内存显著下降：int8 减半、PQ 可降 4-8 倍）。决策框架：把"损失-收益"做成权衡表（每档量化配置：损失 X%、收益 Y 倍），按业务红线决策——质量红线（如召回损失 < 2%）内选收益最大的配置；质量不敏感场景（候选量大、有重排兜底）可接受更大损失换性能；混合方案——量化索引 + 全精度兜底（低分/高价值查询走全精度索引或重排阶段用全精度向量精算）。工程注意：量化与重排/粗筛配合（量化用于粗召回、重排用原向量），量化参数（PQ 的 m、nbits）也在评估集上扫描；量化后监控线上召回漂移（长期数据分布变化可能放大量化损失）。

量化的本质是"用可量化的精度损失换性能收益"：没有同一评估集对比，决策就是赌博。答题按"同一口径对比方法→分层损失报告→收益量化（延迟/吞吐/内存）→权衡表决策与混合兜底"展开。

• 三种索引的机制（图搜索、倒排+量化、全扫描）
• 召回与延迟的权衡特征（精确度、构建、内存）
• 选型场景与组合使用

三种索引代表"精度-速度-资源"的三种取舍。HNSW：分层可导航小世界图——查询沿图边探索，召回率最高（接近精确）、延迟低且稳定（图搜索与数据量弱相关，对数级）、支持动态插入（增量友好）；代价是内存占用大（图连接边开销，M 参数决定）与构建时间；适合"召回与延迟要求高、内存预算充足"的主索引。IVF-PQ：倒排索引（聚类分桶）+ 乘积量化——查询只扫描与查询相近的少量桶（nprobe 控制扫描桶数），PQ 把向量压缩存储与计算（距离表预计算）；召回率受 nprobe 与 PQ 量化损失双重影响（nprobe 越大召回越高、延迟越慢），内存占用低（PQ 压缩）、适合超大库的"内存可控"场景；代价是量化损失（细粒度丢失）、建库需聚类训练、动态插入需重训练或增量桶。Scan（暴力全扫描）：对所有向量算距离（或经 SIMD/GPU 加速）——召回率 100%（精确），延迟随数据量线性增长，无构建开销（免索引）或构建极简；适合小库（<10 万）、需要精确结果、或作为"基准"验证其他索引的召回上界。权衡要点：召回率——Scan=100% > HNSW（接近）> IVF-PQ（nprobe/PQ 相关）；延迟——HNSW 稳定低延迟（大数据量优势明显）、IVF-PQ 可控但受 nprobe 影响、Scan 数据量敏感；内存——HNSW 最高、IVF-PQ 最低、Scan 与原始向量相同。组合使用：Scan 做评估基准；IVF-PQ 做海量低内存的粗召回、HNSW 精排（或 HNSW 粗召回 + 全精度向量精算）；生产常见"HNSW 为主索引" + 量化变体（HNSW-PQ）在内存与精度间取中间档。

索引选型的本质是"召回-延迟-内存的三角权衡"：HNSW 精度换内存、IVF-PQ 内存换精度、Scan 精确换延迟。答题按"三机制原理→三维对比（召回/延迟/内存）→场景与组合（Scan 做基准、IVF-PQ 粗召回、HNSW 精排）"展开。

• 两种分片方式（业务键分片 vs 哈希分片）的机制
• 对查询延迟、热点与跨分片检索的影响
• 分片键选择的权衡与混合策略

分片键决定"数据如何分布、查询如何路由"。按租户/集合分片（业务键分片）：把同一租户（或集合）的数据放在同一分片——查询若带租户条件，路由只落单分片（延迟低、无跨分片）、租户间物理隔离好、可按租户独立扩缩容；但风险是数据倾斜——大租户单分片数据量大、查询热点集中（大租户的 QPS 与数据都压在单分片，形成热点分片，延迟劣化），租户规模悬殊时倾斜严重；且分片数受租户数约束（租户多则分片多）。哈希分片：按 doc_id/向量哈希均匀打散到分片——数据均匀、无热点（大租户数据也均匀分布）；但查询需要广播到全部分片再聚合（跨分片检索），延迟随分片数上升（收敛阶段开销），租户过滤无法下推（每分片都要过滤）；分片间无法按租户隔离资源。影响对比：查询延迟——业务键分片在"带租户条件"时更优（单分片路由），哈希分片在"全局查询"时更优（无需聚合？不——全局查询哈希也要全分片聚合，只是数据均匀）；热点——业务键分片易热点（大租户），哈希分片天然均匀；跨分片检索——业务键分片"跨租户查询"需多分片聚合（且可能遗漏），哈希分片任何查询都默认跨分片；扩展性——业务键分片可针对热点租户单独拆分（如大租户二次分片），哈希分片扩片需数据重分布。选择建议：以租户隔离与单租户性能优先（且租户数据量相对均匀）→业务键分片；数据量大、查询全局性高、租户规模悬殊→哈希分片 + 检索时租户过滤（过滤下推每分片执行）；混合——大租户单独分片（业务键），长尾租户共享分片组内哈希。监控：分片数据量与 QPS 分布（倾斜系数）、跨分片查询占比与聚合耗时、热点分片延迟，触发倾斜告警后调整分片策略（如热点租户迁移分片）。

分片键的本质是"路由效率与均匀性的取舍"：业务键分片省路由但倾斜，哈希分片均匀但跨分片。答题按"两种机制→三维影响（延迟/热点/跨分片）→混合策略（大租户单独、长尾共享）→倾斜监控"展开。

• 迁移路径设计（数据导出、索引重建、切换）
• 双跑对比的方法（影子流量、指标对比、验收门槛）
• 迁移的增量与回退处理

迁移规划分四阶段。第一阶段评估与基线：用同一评估集分别在两库（pgvector 现状与专用库候选）上跑检索指标（Recall@K、延迟、QPS），建立"现状基线"与"目标候选"差距表——迁移的验收标准就是"差距可接受 + 收益明显"（性能、规模、过滤能力）。第二阶段数据与索引迁移：全量导出（向量 + 标量元数据 + 版本/墓碑信息）→ 目标库重建索引（分块策略与向量不变，保证可比）；迁移工具校验"导出-导入"一致性（doc 数、向量指纹抽样比对）；验证目标库索引参数（HNSW 等按评估集调优，不照搬默认）。第三阶段双跑对比：影子流量——线上查询同时打到两库，对比每查询结果（Top-K 重合率、排序差异、延迟分布）、聚合指标（Recall 采样评估、P95）；双跑期覆盖完整业务周期（工作日/高峰）；差异分析——结果差异大的查询聚类定位（是索引参数、过滤语义还是数据差异），确认差异可解释、可接受；对"权限过滤语义差异"重点验证（两库过滤行为可能不同，用权限负样本集回归）。第四阶段切换与回退：灰度切换（1%→全量，路由层控制）；保留旧库同步一段时间（双写或数据快照）支撑回退；切换后监控召回漂移、零结果率与业务反馈；回退条件事前定义（质量指标劣化超阈值即回切）。注意事项：迁移期间增量数据双写（新旧库同时收增量）；删除/墓碑事件迁移（防止旧库删除状态丢失）；评估集与监控体系在新库落地（迁移后持续用同一套尺子）。

数据库迁移的风险在"行为差异"而非"数据搬运"：两库的检索语义、过滤行为、延迟特征都不同，必须双跑对比验证。答题按"基线评估→数据迁移校验→影子双跑→灰度切换与回退"四阶段展开，强调删除状态迁移与权限语义验证。

• 向量存储的基本计算（维度 × 数量 × 字节数）
• 索引结构的附加开销（HNSW 边、IVF 列表、段）
• 内存与磁盘的成本模型与预估方法

规模估算公式：原始向量存储 = 向量数量 × 维度 × 每维字节数——float32 每维 4 字节（1536 维即每向量 6KB）、float16/int8 每维 2/1 字节、PQ 量化后每向量几十到几百字节。示例：1000 万向量 × 768 维 × 4B ≈ 30GB 原始数据。索引附加开销：HNSW——图边指针与距离缓存，通常为原始向量数据的 1.5-3 倍内存（M 越大越高）；IVF——聚类中心列表 + 量化码本开销较小，但需保留原始向量（未量化时）与倒排列表结构；段结构——向量库的段（segment）机制有额外元数据与未合并段的重叠存储；标量字段与 payload——过滤字段（租户、时间、标签）的索引（倒排/哈希）占用额外内存；副本——每副本复制全部数据与索引（内存与磁盘按副本数翻倍）。内存 vs 磁盘：热数据（活跃段）常驻内存（查询需要随机访问），冷数据/全量在磁盘；内存估算按"全部数据 + 索引开销 + 段合并峰值（合并时新旧段并存，需 1.5-2 倍缓冲）+ 系统余量（>20%）"；磁盘按"原始数据 + 索引 + 快照/备份（备份在库外但规划时计入）+ 增长预留（按年增长倍率）"。估算实践：先用抽样小数据集实测（同维度、同索引参数）得到"每向量内存/磁盘字节数"的实测系数（比公式更可靠），再按目标规模外推；预留增长（如 2 年 × 1.5 倍/年）；量化选项作为容量杠杆（int8 减半、PQ 数倍压缩）；容量规划结果写入"向量库容量模型"文档，随数据增长定期复核。

规模估算的关键是"原始向量只是起点"：HNSW 边开销、段结构、标量索引、副本与合并峰值才是成本大头。答题按"基本公式→索引与结构附加开销→内存/磁盘双模型与峰值缓冲→实测系数外推法"展开。

• 高可用架构要素（副本、分片、故障域）
• 故障类型与恢复流程（节点故障、数据损坏、脑裂）
• 可用性验证（故障演练、SLA 度量）

高可用设计三要素：副本（Replica）——数据在多个节点冗余，副本数 ≥2 保证单节点故障不丢服务（读流量可切副本，写入需多数派或主从复制，注意副本间一致性模型）；分片（Shard）——数据水平分布，单分片故障只影响该分片数据（配合副本：每分片多副本），缩小故障爆炸半径；故障域分布——副本分布在不同机架/可用区（AZ），防单机房故障整体不可用；跨 AZ 部署时注意复制延迟与网络分区（分区时的可用性/一致性取舍：多数派写入保证一致，但分区时可能拒绝写入）。故障类型与恢复：节点故障——主副本故障自动切换（选新主）或读流量切到健康副本，恢复后数据同步追平；数据损坏——检测（段校验、抽样向量完整性）、从副本或快照重建损坏段；脑裂/网络分区——用仲裁机制（多数派）避免双主，恢复后合并或丢弃滞后副本；索引构建故障——重建任务可重试、构建积压告警。恢复流程要点：故障检测（健康检查、心跳、监控告警）→ 自动切换（角色转移、路由更新）→ 数据修复（追平/重建）→ 验证（恢复后校验 doc 数与召回基线）→ 复盘（根因与改进）；RTO/RPO 指标化（恢复时间目标、可容忍丢失窗口）。可用性验证：定期故障演练（杀掉节点、断网、模拟磁盘满）验证自动恢复与切换时间；混沌测试（随机故障注入）暴露单点；度量"可用性 SLA"（如 99.95%：年停机 <4.4h）并监控"切换次数、切换耗时、恢复后验证通过率"；演练发现的恢复瓶颈（切换慢、数据追平慢）纳入改进。

向量库高可用的核心是"副本保冗余、分片控爆炸半径、故障域防共因"，恢复能力要演练验证。答题按"三要素（副本/分片/故障域）→故障类型与恢复流程→RTO/RPO 与演练验证"展开。

• 混合检索的架构（双路召回、融合、过滤时机）
• RRF 融合的实现细节（k 值、排名来源、去重）
• 过滤与融合的交互（过滤前置、融合后过滤）

混合检索架构分三段：双路召回——向量路（稠密检索）与全文路（BM25/稀疏检索）并行执行，各自返回 top-N 候选（每路 N 按融合预算定，如各 50）；融合——RRF（Reciprocal Rank Fusion）对两路排名合并：每条文档得分 = Σ 1/(k + rank_i)（k 通常 30-100，越小对前排权重越大），按融合分排序取最终 top-K；过滤——时机选择：权限等安全过滤必须在两路召回前（pre-filter，两路都带过滤条件执行），防止越权候选进入融合；非安全过滤（样式、类型）可融合后做；融合后再过滤会减少最终结果数，需在召回阶段预留余量（两路各多召回一些）。实现细节：排名来源一致性——两路必须对同一候选空间打分（同一文档 ID 体系，向量路与全文路的结果按 doc_id 对齐合并，同一 doc_id 出现两路则分数累加）；去重——同 doc_id 只保留一次（两路都命中时 RRF 分数自然叠加，但展示去重）；分数归一化——RRF 不需要分数归一化（只依赖排名），这是它优于线性加权的原因；过滤条件传递——两路检索都携带相同过滤（租户、时间、权限），保证过滤语义一致（否则"全文路过滤了、向量路没过滤"导致泄漏或结果不一致）；低分处理——融合后分数低于阈值的候选丢弃（阈值按分布设定），保证"没有证据就拒答"的链路成立。工程落地：双路召回并行（延迟取两路最大值而非和）；每路失败降级（向量库故障时全文路兜底，反之亦然）；融合结果日志（记录两路排名与融合分，支撑调试与调参——k 值与每路召回量在评估集上调优）；混合检索的评估（Recall@K 与单路对比，验证融合增益）。

混合检索落地的三个关键：双路并行与 ID 对齐、RRF 融合细节（k 值、去重）、过滤时机（安全过滤前置到两路）。答题按"架构三段→RRF 实现细节→过滤与融合交互→降级与调参"展开。

• 超时与并发控制（超时预算、限流、熔断）
• fallback 路径设计（全文检索、缓存、降级答案）
• 降级后的用户体验与恢复机制

可用性兜底的核心是"让检索失败不拖垮整个 RAG 链路"。超时控制：为向量检索设置超时预算（如 300ms，占端到端预算的一部分），超时即中断（放弃该路或走 fallback）；超时预算分层（向量库调用、重排、生成各自预算），防止单环节拖死全链路；用"快速失败"策略（明确超时阈值而非无限等待）。并发限制：向量库侧连接池与并发上限（防查询洪峰打垮实例），应用侧限流（按租户/查询类型配额），超限请求排队或直接降级；熔断——连续失败/超时比例超过阈值（如 30%）即熔断向量路，直接走 fallback，熔断后周期性探测恢复（半开状态）。fallback 设计：主路径向量检索失败时按级降级——第一级：全文检索（BM25/倒排）替代（语义能力下降但仍有结果，需在提示中标注"基于关键词检索"）；第二级：缓存结果（相同/相似查询的最近成功结果）；第三级：无检索兜底——直接拒答或通用模型回答（标注"未检索到资料"）；fallback 链路的优先级与切换条件明确（超时/熔断/空结果分别走哪级）。降级后的体验：答案标注降级状态（"检索服务异常，结果基于关键词匹配"），降低用户对答案的预期；关键查询（高价值/合规）在降级时转人工或拒答。恢复机制：熔断探测恢复后自动切回主路径；降级期间记录降级率指标（降级查询占比），恢复后监控主路径健康（延迟、错误率）确认回归；降级演练——定期注入故障验证 fallback 链路有效（否则 fallback 可能"从未被测试过"而在真故障时也坏）。整体设计目标："主路径可用性 99.9%、降级路径可用性 99%"——让故障时"变差但不宕机"。

检索降级设计的本质是"给故障设计逃生通道"：超时预算、并发限流、熔断与 fallback 四级防护保证主路径故障时链路仍有输出。答题按"超时与并发→熔断→fallback 分级（全文/缓存/拒答）→体验标注与恢复演练"展开。