召回和粗排为什么不能跳过?

这道题其实问的是推荐系统为什么非要用漏斗式架构，而不是一个模型打天下。本质是计算资源、模型复杂度和业务效果三者之间的工程取舍。

先说召回。召回的目标是从百万甚至亿级的物品池里，快速捞出一千个左右候选。它用的模型很轻量，比如[[双塔]]或者向量检索，特征也简单，基本是用户和物品的静态属性或者离线算好的向量。召回不追求准，追求快和全，宁可多捞一些不相关的，也不能漏掉用户可能感兴趣的。

然后粗排。粗排夹在召回和精排之间，是个容易被忽视但很关键的角色。它拿到召回的一千个候选，再用一个稍微复杂一点的模型快速筛到一两百个。粗排的模型可能是个轻量级的深度网络，或者一个简单的GBDT，特征是离线计算加少量在线拼接。它的目标是平衡效率和效果，比召回准，但比精排快得多。

最后精排。精排拿到粗排筛出来的一两百个，用最复杂的模型，比如深度神经网络加各种特征交叉，精细打分，决定最终展示顺序。精排单次推理可能要10到100毫秒，而且依赖大量实时特征，比如用户刚点的商品、页面停留时间。

那为什么不能跳过召回和粗排，直接用精排对全量候选打分？这里有个关键的计算复杂度问题。假设全量候选是一亿，精排单次推理50毫秒，那全量打分需要50亿毫秒，相当于500万秒，也就是将近60天。在线服务要求百毫秒级响应，完全不可行。

再说特征成本。精排依赖实时特征，如果对全量候选都去拼特征，存储和计算开销会爆炸。而召回和粗排可以用离线预计算的特征，比如用户向量、物品向量，在线只做向量检索，成本低很多。

还有一个容易被忽略的点是训练分布。精排模型的训练数据来自曝光样本，也就是经过了召回和粗排筛选之后用户实际看到的那些物品。如果直接拿精排去给全量候选打分，模型的推理分布和训练分布严重错位，模型会学偏，效果反而更差。

举个例子，电商推荐系统里，用户搜索“运动鞋”，召回先通过向量检索从一亿商品里捞出一千双鞋，粗排再用点击率预估模型筛到两百双，最后精排结合用户历史购买、实时行为、商品详情等复杂特征，排好顺序。如果跳过召回和粗排，精排直接对一亿商品打分，不仅计算来不及，而且那些从来没被用户看到过的商品，特征拼不全，模型也没见过，打分根本不准。

不过这里有一个值得深入的点：粗排模型的训练数据其实存在选择性偏差，因为它只能看到召回送过来的候选，而召回可能已经丢掉了一些长尾但用户真正感兴趣的商品。所以实际落地时，我会特别关注召回和粗排的召回率监控，以及做全量回放来评估是否有系统性漏报。

所以说，漏斗设计不是不能跳过，而是不可为。它是在计算资源、模型复杂度、业务效果之间找到的最优工程解。我更倾向于把召回、粗排、精排看作一个整体系统，每一层都有自己的边界和职责，而且层与层之间要留有缓冲和降级策略。比如粗排超时，可以用召回结果直接兜底；精排挂了，可以用粗排的排序临时顶上。这种解耦设计才是工业级系统的关键。