这道题其实问的是一个很实际的问题:在召回和精排之间,粗排这个漏斗到底有没有帮精排筛到好东西,同时又没拖后腿。说白了,粗排就是个中间层,它要从几百上千的候选中快速挑出几十个喂给精排,所以评估必须同时看两件事:筛选质量够不够好,计算够不够快。
先说指标。质量方面,我最关心的是 TopK命中率,就是粗排给精排的TopK里,有多少最终被精排选中了。这个指标直接反映粗排有没有漏掉好内容。另一个是粗排和精排的一致性,我常用Spearman相关系数,看粗排的排序和精排最终排序是不是大致吻合。如果一致性低,说明粗排可能把好内容排到后面去了,精排就算看到了也来不及挽回。效率方面,P99延迟 是硬约束,粗排必须在几毫秒内完成,不然精排等不起,整个链路就卡住了。
离线评估这块有个大坑,就是很多团队只用粗排自己的loss来看效果,比如CTR预估的AUC,这其实是自欺欺人。因为粗排的样本分布和精排完全不一样,精排看到的都是经过粗排筛选的,有严重的选择偏差。我的做法是 模拟真实漏斗:先把粗排输出的TopK送给精排模型打分,然后用精排的NDCG来评估不同粗排策略。举个例子,在B站视频推荐里,新视频刚上线没有点击数据,粗排如果只依赖CTR预估,很可能把新视频全筛掉了,导致冷启动失败。这时候离线就要专门看新视频的命中率,不能只看整体NDCG。
在线评估更直接。我会做Hold-out实验,小流量对比两个粗排版本,看精排层的输入质量有没有变化,比如精排看到的候选集里,CTR更高的内容占比是不是提升了。端到端指标也要盯,比如最终CTR、人均观看时长,还有多样性,粗排如果太保守,精排的探索空间就被压缩了,用户容易审美疲劳。在B站,我还会关注品类分布熵,确保粗排没有把某个小众但忠诚度高的分区给过滤掉。
落地的时候有几个风险必须注意。一个是 粗排和精排的模型结构差异,如果粗排用[[双塔]]、精排用深度交叉网络,它们的排序一致性可能很差,我见过粗排分数高的内容精排反而给低分,这时候要加[[蒸馏]]或者调整粗排的优化目标。另一个是延迟和质量的 trade-off,你不可能既要粗排算得准又要它快,所以我会根据业务场景做取舍:对主页推荐这种高并发场景,宁愿牺牲一点命中率也要保证延迟在5毫秒以内;对搜索补全这种用户等待时间短的场景,可以稍微放宽到10毫秒。
另外,粗排的评估其实还涉及一个很有意思的问题:粗排应该用点估计还是排序学习?我倾向于用pairwise的排序损失,因为粗排本质是个排序任务,但很多线上系统还是用CTR预估的pointwise loss,这里面有个偏差校正的问题,可以再深入聊。
总的来说,我会把粗排评估看成一套组合拳:离线模拟漏斗防过拟合,线上Hold-out保效果,同时用业务指标兜底。核心就一句话,别让粗排成为整个推荐链路的瓶颈,不管是在质量上还是效率上。