在我们的业务场景中，优化指标是总的商机数（联系经纪人算是商机），通过对业务指标进行拆解，将目标拆分成：
- 提升用户搜索次数
- 提升搜索pctr（pctr表示点击次数/请求数）
- 提升搜索pcvr（pcvr表示）
本篇文章主要介绍做房源ctr时的一些工作：
- 采样
- 特征
- 模型
- 评价指标
- 踩过的坑：线上线下效果不一致
- position bias
- EE问题
1. 采样
通常搜索推荐的样本来自于用户行为，但是由于埋点数据的准确性、还有用户误点击等原因，可能导致我们无法准确地获取正负样本。正样本比较简单，曝光且点击的为正样本；但是对于负样本，有点困难，我们尝试了几种不同的方式：
- 最后一次点击位之前的曝光未点击数据
- 日志中所有曝光但未点击的数据
- 日志中所有曝光但未点击的数据 + 随机采样未曝光的数据
在我们的场景中，最后借鉴了美团的采样方式，这种方式在我们的任务上表现最佳。
2.特征
特征纬度：
- 房源特征，连续型特征如点击率、房价、面积、居室、单价、单价排名等；类别特征，房源ID、房价或面积分桶
- 用户特征，连续型特征，如活跃天数、点击率、是否产生商机等；类别特征，如历史点击的房源列表、产生商机的房源列表
- 搜索词特征，解析搜索词后的槽位信息，如小区、商圈、居室、房价、面积等
- 交叉特征，主要是用户画像与房源特征的交叉，以及用户历史点击/商机与房源的交叉。说明一下，用户画像是用户在房价、面积、居室、小区、商圈等纬度上的统计值，表示出用户在各维度不同区间的倾向度，交叉后用倾向度作为交叉特征的值。
对模型效果提升比较大的是，交叉特征以及房源点击率、房价、面积、居室、单价、单价排名等。
思考房源排序与其他场景的不同：
- 相比其他场景，买房的需求可能会更聚焦一些。比如用户的条件是300万以下的房子，又或者想要3居的房子。因为这些需求对用户来说是刚需，是必须满足的条件。所以交叉特征表现很好。
- 房价、面积、居室等是刚需，如果满足不了就是不行，因此这些特征的重要程度很高。（对于树模型而言，因为做这个项目的大部分时间还是在树模型阶段）
- 页面可展示的维度重要度更高，对模型影响更大，比如房价、面积、居室、单价等。其实这些也是用户刚需，越被用户关心的维度，越会展示出来。
3. 模型
模型迭代与一般做推荐比较类似，从LR、xgboost/lightgbm、wide&deep、deepFM。
这里想重点说一下第一次上模型的坎坷。刚进入搜索项目组房源排序还没有模型，第一次尝试模型，组长说直接把所有的特征都扔进去，他说的所有特征包括第2部分说到的特征，他建议的方式是将数值特征离散化后one-hot，类别特征（用户点击房源）直接one-hot；反正最后特征维度比较大，最开始用的是LR模型，然而模型基本学不出什么东西。后面组长还让我们分析样本，为什么模型学不出东西；但说实话，那么多维特征，一个个分析为什么不对，这个太难了。
最后，我直接忽视组长说的特征处理方式，简单地用了十几维特征（主要是想验证下自己的想法），包括：房源点击率（这个已经被验证比较好用）、页面展示的维度（房价、面积、居室等）、用户画像与房源维度的交叉特征（房价、面积、居室、行政区、商圈、小区等）。模型效果出来了（忘了具体是多少，但模型收敛了，auc也上升了）。后面基于这个版本上做了一些其他特征以及特征处理的尝试，然后上线。上线后，ctr也得到了比较大的涨幅。
思考
为什么堆特征没有效果？
在我的文章wide&deep VS deepFM中有对wide部分的特征进行分析，说wide部分的特征是“直接的”、“暴力的”、“显然的”关联规则。然而，当仅仅把房源one-hot作为特征是没有这种关联规则的。另外，由于买房是长周期事件，用户在点击房源上可能有一定的发散性，所以这导致最开始的尝试失败。为什么有些统计类特征在房源排序上比较重要？
仅是个人想法。买房是一件长周期但用户需求收敛的过程，最终用户行为会越来越聚焦，因此有些统计特征能反应出用户的某些聚焦行为。另外，虽然用户买房会有个人倾向，但其实买房也很看中性价比，只要刚性需求能够满足，如果房子性价比更高用户也是会考虑的。在房源搜索中模型效果有限
多次迭代优化，模型效果最明显的是在无搜索词的情况。简单点说，用户搜索条件越宽泛，模型能带来的提升越明显。这可能也与指标有一定的关系，因为我们优化的是搜索的点击率，即ctr=点击总次数/搜索总次数，不关心点击的位置，只关心点击次数。但是用户搜索条件越明确，满足条件的房源越少，我们做过统计，60%-70%的搜索返回的房源量不超过120套房源。而且，相比其他场景，用户对于买房会比较有耐心，看返回房源的情况。这也是为什么我们更关心点击次数，不太关心点击位置的原因。
4.评价指标
最开始我们关注的是auc，也会看下logloss（只是为了看下分布）。后面踩过一些坑后，线下模型训练除了看auc，还会看gauc（每次搜索的auc）、top recall、topn ctr、diff率、MAP、NDCG等，其中MAP、NDCG仅用来参考。简单点说，无法只用一个指标作为标准，需要多指标综合考虑。
5. 踩过的坑: 线上线下效果不一致
遇到的问题和知乎的回答一模一样，在你做推荐系统的过程中都遇到过什么坑？ - 辛俊波的回答 - 知乎
5.1 线上线下特征不一致
- 处理代码不是同一套代码或者模块
最开始线下的特征处理是我们做算法的自己处理，但是在线上特征处理是工程同学，因此会出现线上线下不一致的情况。后面为了解决这个问题，联合工程同作做了一套特征处理的平台，线上线下都在平台上处理来保证特征逻辑一致性。 - 数据穿越
不小心用了T时刻的特征训练了T时刻的数据，线下表现特别好，上线后没效果甚至下降。这个只能在写代码处理的时候多校验了。
5.2 数据分布的不一致
数据的“冰山效应”----离线训练用的是有偏的冰山上的数据，而在线上预估的时候，需要预测的是整个冰山的数据，包括大量冰面以下的数据！
下图中左边是我们的Baseline，绿色的表示正样本，红色表示负样本，灰色部分表示线上由于推荐系统的“偏见”（预估分数较低），导致根本没有展现过的数据。
原因是模型学到了不同的东西，但是不能很好的拟合线上的情况。
对于这种情况，最根本的手段就是解决数据的有偏问题。尤其是新模型，一开始相当于都是在拟合老模型产生的样本，刚上线效果如果比较差，经过一段时间迭代，影响的样本分布慢慢趋近于新模型，也能收敛，但效率较低。
作者还给出两个在他们场景中有效的经验：
- 对无偏数据进行上采样
这里的无偏是相对的，可以是随机/探索流量产生的样本，也可以是新模型产生的样本。大概意思，就是尽可能利用这些对新模型有利的样本。 - 线上线下模型融合
比较trick的方法，没有太多方法论，但是确实能work。
新模型预估分数和老模型预估分数
直接在线上做线性融合，刚上线的时候a选取比较小，随着慢慢迭代，a慢慢放大。
我们有尝试过对随机/探索流量产生的样本进行采样加到负样本中，也就是方法一【对无偏数据进行上采样】，效果有所提升，但仍然线上pctr相比baseline下降。可能是因为采样还不够对新模型有利？但我有个问题，如果是对新模型有利，那线下效果不是提升更多吗？难道不是线上线下不一致更严重？
5.3 指标
详细的指标说明可见另一篇文章搜索排序指标。
最开始我们只用了全局auc作为指标，但是可能出现整体正样本的位置靠前了，但是对query维度而言，位置没什么变化，甚至有些正样本靠后了，所以后面增加了query维度的auc，类似于阿里提出的gauc。除了gauc，还增加了topn的ctr、topn的recall、diff率等指标，综合衡量线下模型的效果。
其他参考资料具体可见：
6. position bias
广告和推荐消除position bias - xiaobao的文章 - 知乎
7. EE问题
EE问题一般出现在推荐中，但是由于我们是房源搜索，也需要EE，某种程度上需要让用户看到不同的房源。详细介绍后续再补充。
