共计 981 个字符，预计需要花费 3 分钟才能阅读完成。
为什么突然会聊到这个话题呢，最近负责的这个项目有这个环节，也是有机会去学习这块的知识，顺便在实际的项目中实践一下。
为什么要粗排？
最主要的原因还是性能问题。在实际的业务项目中，可以分发的内容动辄上百万甚至更多，为了尽可能的抓住用户的兴趣，你可能加了很多路的召回，比如长期画像、短期画像、实时cf等等，诸如u2i 、i2i等等，反正你一搜召回就会出现很多很多的召回方法。那么这么多的召回方法，每一个都可以返回成百上千的数据，具体的数量都是可以人工配置，但是不管怎么样，数量多起来，自然而然多路召回汇总数据也会很多。也许你会说各个召回之间的有很多数据的交集，的确你只要监控召回返回结果就会发现很多相同的内容被不同的召回方法召回回来，但是还是会有不一样的，所以你的召回结果还是很多。到此你召回了大几千甚至上万的内容，如果你要直接喂给精排模型，精排模型肯定炸锅了，分分钟超时，这对于精排模型来说压力太大了。自此粗排就横空出世了，既然精排的胃口没那么大，那么我就来帮帮你。
粗排是什么样子？
在上一段就聊到了，粗排要帮精排的忙，所以粗排要具备以下特性
- 模型简单
- 速度快
- 跟精排目标一致
现在就来聊聊这些特性
模型简单
做深度模型要体现模型的简单，那么就不要加过多的复杂计算逻辑，比如attention、transformer等计算复杂度较高的计算逻辑。还有就是使用的特征也没那么多，都是精排模型的子集。其实说到这就又想到一点，准确率和效率的权衡。你看粗排模型简单，处理大量的输入内容速度又很快，但是你也不能预估的不准，不然精排也无能为力，你都把用户喜欢的过滤了，精排还推荐个锤子。
速度快
一般生产环境都是有rt限制的，所以速度快就是要求耗时要短，召回回来上万的内容你要在很短的时间内，几十毫秒或者上百毫秒就要处理出结果出来，然后再将结果传递给精排模型，所以这块对工程的实现也是有一定的要求的。当然这块是有一些优化方案的。
目标一致性
既然粗排是给精排排忧解难，那么他们两个的目标肯定是要一致的，举个例子粗排优化点击率，精排优化时长，那么可能就会出现你意想不到的问题，比如点击率高的可能是吸引眼球的低质的内容，达不到时长优化的目的。
总结
1、粗排的诞生是为了缓解精排的输入内容过多的压力，准确率和效率的权衡
2、粗排的特性介绍
下一篇就会讲粗排模型的数据样本生成，这里面会介绍一些经典的方法和工业界的方法。
