推荐系统中引入向量索引召回时，在线 serving 链路应该如何改造？｜高频面试题解析

60 秒回答模板

我会把向量索引放在推荐链路的召回层，通常作为多路召回中的一路，而不是放在精排之后。在线请求进来后，先经过用户上下文解析和特征读取，实时或准实时生成 query vector，例如用用户近期行为、画像、场景和上下文通过 embedding tower 得到用户兴趣向量；然后召回编排层调用向量索引服务做 ANN 检索，拿到 item id、相似度和索引版本，再和规则召回、热门召回、协同召回等结果合并去重，进入粗排、精排和重排。serving 改造重点包括：新增向量召回模块和 RPC/SDK 调用，统一特征口径和向量版本，设置严格超时、限流、缓存和 fallback，保证索引增量更新或周期构建的可见性，记录 query vector 版本、召回耗时、命中数、相似度分布、index version 和候选去向。上线不能只看 Recall@K，还要 A/B 看 CTR、时长、转化、覆盖率、多样性、延迟和降级率，证明这一路召回既带来增量候选，也没有拖垮在线体验。

考点 召回层接入

难度 真实面经题

回答目标 讲清原理、实现和边界

深入解析

先定模块位置

向量索引召回应放在推荐系统的召回层，通常由召回编排层或多路召回服务管理。它的职责是用用户或请求向量从大规模 item 向量库里取 TopK 候选，再交给粗排和精排。不要把它放到精排之后，因为精排面对的是已经被召回筛过的小集合；也不要让业务入口服务直接散落调用索引服务，否则超时、降级、日志和实验开关会很难统一治理。

改造在线请求路径

典型路径是：请求入口解析用户、场景、设备和上下文；特征服务返回用户长期画像、近期行为和场景特征；向量生成模块产出 query vector；召回编排层并行调用向量召回、热门召回、规则召回、协同召回等多路；召回结果合并、去重、截断后进入粗排；粗排、精排、重排再决定最终展示。面试时要说清向量召回是候选生成的一路，不是替代完整排序链路。

保证 query vector 口径一致

在线 query vector 可以来自用户向量表，也可以实时用用户近期行为和上下文通过模型计算。关键是训练、离线构建和在线 serving 的特征口径要一致，包括 embedding 模型版本、归一化方式、行为窗口、类目过滤、场景特征和缺失值处理。若线上实时算向量，需要控制模型推理耗时；若读取预计算用户向量，需要处理冷启动、过期和场景不匹配。

把 ANN 索引服务化

向量索引最好作为独立检索服务或平台能力，对召回层暴露稳定接口：输入 query vector、TopK、过滤条件、召回场景和实验参数，输出 item id、score、index version、召回通道和必要的 debug 信息。索引服务内部可以使用 HNSW、IVF、PQ 或其他 ANN 方案，但面试重点是服务边界、过滤能力、版本控制、容量和可用性，而不是展开算法细节。

控制延迟、缓存和降级

向量召回必须服从推荐在线链路的总延迟预算。工程上要给向量召回设置单路超时、并行调用、连接池、限流、熔断和批量查询能力；对高频用户、热门场景或稳定 query 可以缓存召回结果；超时或结果异常时降级到热门、规则、协同或上一版缓存候选。降级要可观测，并且不能让空结果直接传到排序层造成页面质量波动。

补齐更新、观测和实验闭环

item 向量和索引要有离线全量构建、增量更新或近实时更新机制，并保证 item 上下架、审核状态和业务过滤及时生效。上线后要记录 query vector 版本、item vector 版本、index version、召回耗时、TopK 命中数、相似度分布、过滤原因、去重后保留数、进入粗排/精排的比例和最终曝光点击。A/B 评估要同时看召回覆盖、增量候选、CTR、转化、时长、多样性、新内容曝光、P99 延迟、超时率和降级率。

易错点

把回答写成 HNSW、IVF、PQ 的算法科普，没有回答 serving 链路如何改造、模块放在哪里。
让入口服务直接调用向量索引，忽略召回编排层的统一超时、降级、合并、去重和实验开关。
只说召回效果提升，不讨论 query vector 版本、索引版本、特征口径一致性和 item 更新可见性。
只看离线 Recall@K，不看线上 P99 延迟、超时率、降级率、候选进入排序后的转化和 A/B 业务指标。

面试官追问

向量召回模块应该放在在线链路的哪个环节？

放在召回层，通常和热门召回、规则召回、协同召回并行。它产出候选集合，后面还要经过粗排、精排和重排。放到精排后没有意义，因为精排阶段候选已经被前面的召回层限制住了。

query vector 是实时算还是离线存？

两种都可以。预计算用户向量延迟低、稳定，但对实时兴趣和场景变化不敏感；在线计算能利用当前上下文和近期行为，但会增加模型推理耗时。常见做法是长期兴趣预计算，短期行为和场景特征在线融合，并用版本号保证口径可追踪。

向量索引超时或返回空结果怎么办？

不能把空候选直接传给后续排序。应该设置短超时和熔断，异常时用热门召回、规则召回、协同召回、缓存候选或上一版索引结果兜底，同时记录降级原因、耗时和影响流量，方便判断是索引服务问题还是 query vector 问题。

如何证明向量索引召回有增量价值？

先离线看 Recall@K、相似度分布、覆盖率和与已有召回通道的重合度，再在线 A/B 看 CTR、转化、时长、留存、新内容曝光、多样性和负反馈。还要看增量候选进入粗排、精排和最终曝光的比例，否则只是召回了很多后面用不上的 item。