真实面经题目 · 原创解析
这道题考察对向量数据库核心链路的系统设计能力，而不是背某个产品未公开实现。回答要从写入、向量化、分片、持久化、ANN 索引构建、增量更新、元数据过滤、查询召回、重排和运维指标串起来，说明向量、原始文档、元数据和索引如何保持一致。关键是讲清近似召回与过滤条件的协同：先过滤、后过滤、混合过滤各有什么代价；写入与索引的实时性、删除更新、分布式扩展、一致性和评估指标如何设计。
设计 VikingDB 这类向量数据库，可以把核心链路拆成写入链路和查询链路。写入侧先接收文档或向量，做 schema 校验、主键去重、权限和元数据解析；如果输入是文档，还要切片、embedding、归一化，并把原文、向量、元数据、版本和时间戳一起持久化。随后根据集合的分片策略写入 shard，进入增量段或内存索引，再异步构建 ANN 索引，例如 HNSW、IVF、PQ 或混合结构；同时要支持更新、删除、TTL、compaction 和索引重建，保证向量与元数据一致。查询侧接收 query vector 和过滤条件，先做权限、租户、类型、时间等 metadata filter，再在候选空间里做 ANN topK 召回；过滤可以前置缩小搜索空间，也可以 ANN 后置过滤，或通过 bitmap/倒排与 ANN 协同。之后合并多 shard 结果、按距离或内积分数排序，必要时做标量重排、去重和 Cross-Encoder rerank，返回文档片段和元数据。工程取舍主要在写入实时性、召回率、延迟、成本、过滤选择性和一致性之间平衡。
向量数据库至少要管理 id、vector、payload metadata、原始文本或引用、namespace/collection、版本和状态。向量用于相似检索，metadata 用于过滤、权限、排序和生命周期管理，原文或引用用于返回证据。三者要用同一个主键和版本绑定，否则会出现召回到旧向量但展示新文本的错配。
写入链路先做 schema 校验、维度检查、向量归一化策略、主键幂等、租户权限和元数据类型校验。如果输入是文档，还要在库外或库内完成切片、embedding、语言检测和去重。写入成功不一定代表已经进入最终 ANN 索引，因此需要区分 durable write 和 searchable write。
大规模向量通常按 collection、tenant、hash id 或语义分区做 shard。每个 shard 要持久化向量数据、metadata 列或倒排、删除标记和索引文件。分布式场景还要处理副本、leader/follower、故障恢复和跨 shard topK 合并，避免单个热点集合拖垮整体查询。
ANN 索引用于在高维空间里近似找最近邻，常见思路包括图索引、倒排聚类、压缩量化或组合结构。图索引查询召回高但内存成本大，IVF/PQ 更适合压缩和超大规模但需要训练和调参。索引参数会影响 recall、latency、memory 和 build time，需要按集合规模和业务指标选择。
线上系统不能只离线建索引。新写入可以先进入增量 buffer 或小索引，查询时同时查主索引和增量索引；后台再 merge、compact 或 rebuild。删除和更新通常通过 tombstone、版本号和异步清理实现，查询阶段必须过滤已删除或旧版本结果。
过滤条件可能包括租户、权限、时间、类型、标签、地区、状态和业务字段。高选择性过滤适合先用倒排或 bitmap 缩小候选，再做 ANN；低选择性过滤可 ANN 后过滤；复杂场景需要边搜索边过滤，避免 ANN 返回大量不满足条件的候选导致 topK 不足。
查询时先解析 query vector、metric、topK、filter 和 consistency 要求，再路由到相关 shard。每个 shard 返回局部候选，协调节点做全局 merge、去重和分数归一；如果使用混合检索，还要融合 BM25、规则召回或业务热度分。最终返回的不只是 id，还应包含距离、metadata 和可用于上层 RAG 的片段信息。
ANN 与过滤协同是核心难点。先过滤能降低搜索空间但可能破坏索引结构或增加 bitmap 交集成本；后过滤简单但在过滤很严时会返回不足；混合过滤效果好但实现复杂。设计时要根据过滤选择性、topK、索引类型和延迟预算选择策略，并允许查询级自适应。
关键指标包括 recall@K、P95/P99 延迟、写入到可检索延迟、索引构建时长、内存和磁盘放大、删除可见延迟、过滤命中率、topK 不足率和跨 shard 失败率。运维上还要支持索引版本回滚、灰度重建、备份恢复、冷热分层和容量预估。
ANN 后过滤是先按向量相似度取一批近邻，再筛掉不满足条件的结果。如果过滤条件非常严格，例如只允许某租户、某时间窗口或某状态，近邻中大部分会被丢弃，最终可返回数量不足。解决思路是过滤前置、bitmap 协同搜索、扩大候选池或按过滤选择性自适应策略。
HNSW 通常召回和查询延迟表现好，但图结构内存占用较高，构建也较重；IVF 通过聚类缩小搜索范围，适合大规模但依赖训练和 nprobe 调参；PQ 用压缩降低内存和磁盘成本，但会损失精度。实际系统常组合使用，并按集合规模和成本目标调参。
要用版本号和 tombstone 控制可见性。更新时写入新版本并标记旧版本失效，查询阶段按当前版本和状态过滤；删除时先写删除标记让查询立即不可见，再由后台 compaction 清理索引和存储。对于延迟敏感场景，还需要监控删除传播和索引重建进度。
可以提供不同一致性语义，例如写入持久化即返回、写入进入增量索引后返回、或等待主索引可检索后返回。前者延迟低但短时间内搜不到，后者体验更一致但写入更慢。接口应明确返回状态或可选参数，让业务按实时性和吞吐需求选择。
协调节点会向相关 shard 发起查询，每个 shard 返回局部 topK 和分数，再用统一 metric 做全局排序。若不同 shard 使用不同索引段或融合了标量分，需要做分数归一和去重；还要处理部分 shard 超时、热点分片和副本重试，避免单个分片影响整体可用性。
向量库负责语义召回和元数据过滤，BM25 补足关键词、代码符号和实体精确匹配，Cross-Encoder 对候选进行证据可用性重排。RAG 上下文选择还要考虑去重、多样性、时间、权限和 token 预算。向量库返回的距离分只是一个特征，不能直接等同于最终答案证据。
