# CTR预估与推荐系统的目标存在什么gap？
CTR预估起源于计算广告，因为关系到真金白银的定价问题，因此要求预估出来的CTR必须“绝对准确”。这是因为，假如给一个用户准备了A/B/C三个广告，那么无论预测CTR是0.9、0.8、0.6，还是0.5、0.4、0.3都不影响三个广告的展现顺序，但是向客户的收费却有天壤之别。
但是推荐系统只要求“相对准确”。假如ABC换成了三篇文章，只要能够将用户最喜欢的A排在第1位，次喜欢的B排在第2位，无论我们预测的CTR是0.9、0.8、0.6，还是0.5、0.4、0.3，用户都能接受。
看似要求“绝对准确”性，要比“相对准确”，难度更大一些：如果我们能够将用户对每个候选item的CTR都预测准确，那么排序的“相对准确性”自然能够得到保证。但是实际上，“预估CTR”和“排序准确”两个目标存在gap。
这是因为"ctr预估"是pointwise loss，每个样本由<user, item, label(0或1)>组成，loss采用binary cross entropy loss。由于实际系统中，正样本太稀疏，理论上存在这样一种可能性，就是算法将所有<user, item>都预测成0，binary cross entropy loss同样能够最小化，但此时，排序正确性就无从谈起了。所以，现实的CTR算法，往往伴随着在训练时对正样本加权，而在预测时还需要对预估出来的ctr进行校正。
那为什么在推荐系统“精排”阶段，CTR预估算法依然流行？根据我在内容推荐场景下的经验，主要是因为推荐系统中的正负样本比例没有那么悬殊，10%以上的ctr并不罕见，所以即使不对正样本进行加权，也不会出现“所有样本都预测成负类”那种“一边倒”的情况。但是，理论层面上的gap依然存在。
如果要确保排序上的准确性，理论上应该采用Pairwise LearningToRank（LTR），即每个样本由<user, item+, item->三元组组成，预测的目标是<user, item+>的匹配得分要高于<user, item->的匹配得分。为了达成这一目标，可以采用margin-based hinge loss或BPR loss。但是由于"ctr预估"这种ponitwise的算法，在实际排序场景下干得还不错，所以在“精排”阶段使用Pairwise LTR并不是很流行。但是也不是绝对没有，从《Applying Deep Learning To Airbnb Search》和《Improving Deep Learning For Airbnb Search》两篇文章，可以窥探出Airbnb在“排序”阶段，采用双塔模型来实现Pairwise LTR。
https://www.zhihu.com/question/341529083/answer/1616964921
# 现实推荐系统只按"预估CTR"排序吗？
在“排序”阶段，先预估用户对每个候选item的CTR，再按预估ctr对各候选item从大到小排序。这个是最最简单的场景，而现实推荐系统往往是多目标的，并不会只预测ctr并按ctr排序。
- 对于电商推荐，排序不仅要预测用户的点击率，更重要的是预测用户的转化率（CVR）；
- 对于内容推荐，业务关心的除了CTR，还有阅读/观看时长、转发、评论等指标。
因此，实际环境下的推荐排序，往往是一个多目标优化问题，而不是简单预测CTR。关于多目标优化，既有阿里的ESSM这样的hard parameter sharing算法（《Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate》），也有Youtube采用的MMOE这样的soft parameter sharing算法（《Recommending What Video to Watch Next: A Multitask Ranking System》）。
# 为什么CTR预估只适用于具备“真负”样本的场景？
CTR预估本质上就是预测点击与否的二分类算法。
和所有算法一样，CTR预估成功的关键之一就是样本的准确性。对于正样本，一般可发挥的空间不是很大，最多就是卡一个停留时长，将属于“误点击”的正样本剔除。
对于负样本，CTR预估是非常讲究“真实负样本”的，即一定是给用户真实曝光过而被用户忽略的item，才能作为负样本。为此，还有所谓的above-click作法，即只拿用户点击的item的位置以上的未点击item作为负样本。