直接精排所有候选，为何不可行？

这道题其实问的是，在推荐或搜索系统里，为什么不能一步到位用精排模型把所有候选都打一遍分。说白了，这不是精排模型不够准，而是全量精排的成本高到业务根本扛不住。

先说计算效率。精排模型一般深度交叉特征很多，一次推理就要几十毫秒，而候选池通常是百万甚至千万级。如果全量打分，单次请求耗时就是小时级，用户早跑了。而且算力成本也受不了，GPU 跑一次精排的消耗跟候选数成正比，业务很难承受。作为对比，召回阶段用哈希查找或者 [[ANN]] 检索，一次查询毫秒级就能从百万候选里捞出几百个；粗排阶段用轻量 [[双塔]]模型 或者简单特征，再过滤掉大部分，最后精排只处理几十个候选。这样整个链路才跑得动。

再说系统架构。这里有个漏斗效应，每个阶段过滤掉90%的候选，精排只处理可能优质的那一小撮。这样设计的好处是，各阶段可以独立迭代、独立做 A/B 测试，甚至降级熔断。比如召回挂了，系统还能走缓存或者兜底策略；精排模型升级，不影响召回和粗排。但这里有个坑：漏斗的前提是各阶段的打分一致性。如果召回和粗排的排序跟精排冲突太大，比如召回把精排喜欢的候选全丢掉了，那精排再好也没用。常见失败场景就是召回只看热门，忽略了用户长尾兴趣，导致精排可选范围太窄。

举个例子，电商大促时，用户搜'手机'，候选池里可能有几十万款。召回阶段先根据用户历史点击和搜索词，用向量检索加关键词匹配，捞出一千款；粗排再用价格、销量、店铺评分等轻量特征，砍到一百款；精排才上深度交叉模型，考虑用户实时行为、商品属性、上下文等，最终输出十个结果。如果跳过召回和粗排，精排直接面对几十万候选，延迟和算力都爆了。

所以我的理解是，召回、粗排、精排各有适用场景。召回负责海量候选的快速筛选，粗排做中等粒度的过滤，精排做精准排序。真正落地时，这三者必须级联配合，而且每一层都要为下一层留余地。比如召回不能只取最高分的几百个，最好多捞一点，给粗排和精排留足选择空间。

不过分层架构也有代价，级联误差会累积，比如召回漏掉好候选，精排永远看不到。所以现在有些系统开始尝试端到端的联合优化，或者用 [[知识蒸馏]] 把精排知识教给粗排。但我觉得，在延迟和算力瓶颈没突破之前，级联架构还是最务实的方案。

总之，我更倾向把分层架构看成工程约束下的最优妥协，而不是算法能力的缺陷。上线时我会特别关注各阶段的召回率和排序一致性，做好监控和降级策略。