面试题 · 检索
搜索「A/B测试」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在推荐或搜索系统中，为什么不能跳过召回和粗排阶段而直接使用精排模型对所有候选进行打分？请从计算效率和系统架构角度分析。
复杂度鸿沟
算力成本
延迟与吞吐的权衡
| 阶段 | 延迟要求 | 候选规模 |
|---|
按学习路线查看教程、项目和面试题。
| 模型复杂度 |
|---|
| 召回 | <10ms | 百万→千 | 极简 |
| 粗排 | <20ms | 千→百 | 轻量 |
| 精排 | <50ms | 百→十 | 重度 |
漏斗效应的价值
不是"精排不够准"，而是"全量精排太贵"。分层架构是工程约束下的最优解，而非算法能力的妥协。
建议系统学习该知识点
场景切入
假设你现在做一个电商搜索，用户搜“手机”，候选池里有1000万商品。如果不用召回和粗排，直接让精排模型给每个商品打分，你觉得系统能扛得住吗？
层层追问
搜索系统的流程你熟悉吧？从候选池到最终展示，中间会经过哪些阶段？……那为什么不直接让精排模型对所有候选打分？……如果候选池有1000万，精排一次推理50ms，算算总耗时？
直球架构
从计算效率和系统架构角度，解释为什么搜索推荐系统必须用召回-粗排-精排级联架构，而不能跳过前两级直接全量精排打分。
这道题其实问的是，在推荐或搜索系统里，为什么不能一步到位用精排模型把所有候选都打一遍分。说白了，这不是精排模型不够准，而是全量精排的成本高到业务根本扛不住。
先说计算效率。精排模型一般深度交叉特征很多，一次推理就要几十毫秒，而候选池通常是百万甚至千万级。如果全量打分，单次请求耗时就是小时级，用户早跑了。而且算力成本也受不了，GPU 跑一次精排的消耗跟候选数成正比，业务很难承受。作为对比，召回阶段用哈希查找或者 [[ANN]] 检索，一次查询毫秒级就能从百万候选里捞出几百个；粗排阶段用轻量 [[双塔]]模型 或者简单特征，再过滤掉大部分，最后精排只处理几十个候选。这样整个链路才跑得动。
再说系统架构。这里有个漏斗效应，每个阶段过滤掉90%的候选，精排只处理可能优质的那一小撮。这样设计的好处是，各阶段可以独立迭代、独立做 A/B 测试，甚至降级熔断。比如召回挂了，系统还能走缓存或者兜底策略；精排模型升级，不影响召回和粗排。但这里有个坑：漏斗的前提是各阶段的打分一致性。如果召回和粗排的排序跟精排冲突太大，比如召回把精排喜欢的候选全丢掉了，那精排再好也没用。常见失败场景就是召回只看热门，忽略了用户长尾兴趣，导致精排可选范围太窄。
举个例子，电商大促时，用户搜'手机'，候选池里可能有几十万款。召回阶段先根据用户历史点击和搜索词，用向量检索加关键词匹配，捞出一千款；粗排再用价格、销量、店铺评分等轻量特征，砍到一百款；精排才上深度交叉模型，考虑用户实时行为、商品属性、上下文等，最终输出十个结果。如果跳过召回和粗排，精排直接面对几十万候选，延迟和算力都爆了。
所以我的理解是，召回、粗排、精排各有适用场景。召回负责海量候选的快速筛选，粗排做中等粒度的过滤，精排做精准排序。真正落地时，这三者必须级联配合，而且每一层都要为下一层留余地。比如召回不能只取最高分的几百个，最好多捞一点，给粗排和精排留足选择空间。
不过分层架构也有代价，级联误差会累积，比如召回漏掉好候选，精排永远看不到。所以现在有些系统开始尝试端到端的联合优化，或者用 [[知识蒸馏]] 把精排知识教给粗排。但我觉得，在延迟和算力瓶颈没突破之前，级联架构还是最务实的方案。
总之，我更倾向把分层架构看成工程约束下的最优妥协，而不是算法能力的缺陷。上线时我会特别关注各阶段的召回率和排序一致性，做好监控和降级策略。