GBDT和FTRL怎么利用点击下单，支付日志建模预测点击率呀？

最近在做推荐系统，大概按照美团的博客来的，但是候选集重排序阶段不知道怎么用GBDT或者FTRL 建模实现重排序？主要以下几个点不清楚？
（1）是把每次产品对用户的一次展示作为一个样本吗比如点击lable=1 下单 label=10 支付label=20 等。这样么次展示是不是要知道一个全局标示，才能知道用户对这次展示是点击了  还是下单支付ne ?
  (2)然后就算有了这个样本那提取 item相关特征比如价格销量  折扣还好说用户特征没有怎么弄比如性别  消费偏好都没有是不是要把用户id作为一个特征呢？否则就没有用户特征呢？相当于把大家当作一个人了？这样应该不对吧？
  我是一个机器学习小白？请大神不吝赐教！！！！感谢

zhihu用户 · 2019-5-18 21:10:54

如果只是打算根据ctr rerank，然后去预估ctr，那一般方案还是比较清晰的。
针对你的问题：
1）先要区分正负样本，预估点击率只需要用到曝光和点击日志即可，这部分一般在hadoop里做离线join，合并到一份日志。如果要做成实时模型，则需要在storm做实时join。全局标示你是指一次请求或查询的request id吧，肯定是需要的，否则无法把几份日志join起来。一般使用的时候还会对负样本做采样，然后在预估的时候再还原。贴一篇屈伟大大几年前pctr的入门文，关于如何join其中几幅图一看就知道了：广告点击率预测 [离线部分] - 推酷
2）特征工程部分是最耗时的，用户特征像你问的年龄性别这些基础属性都是离线计算好的，然后做成服务供预估的时候使用。而实际工程上还会用到实时特征，因为效果更好，这些一般会实现成session server，专门维护实时特征。至于用户id也是非常重要的特征，一般用在lr ftrl这种离散模型里，而不会用在gbdt这类树模型中。不过你提到了按照美团博客来的，应该可以知道他们在推荐上目前主要还是在用树模型，当然你也可以根据自己的应用场景和最终指标多加尝试。

zhihu用户 · 2019-5-18 21:10:55

主要想解决的问题是如何实时地计算用户偏好，从事对离线结果进行重排序，最后把重排序的结果推荐给用户。

我们先来看问题：
用户的离线推荐结果一般更新慢，如果预测错误，重新修正的周期比较久（比如一天），推荐效果不好。

解决方法：
利用用户的实时偏好对离线推荐结果重新排序，使得用户的实时推荐更加准确。

我们先来看如何利用GBDT和FTRL来进行建模：
1. 离线结果如何计算：利用用户的行为（点击，订单，坐标，etc.）计算活动得分（GBDT）。由于计算量大，每天更新。
2. 实时偏好重排序：利用用户的实时行为对离线结果重新排序，利用FTRL。

举个例子：
1. 小A经常去选择一些中餐厅吃饭，离线结果计算出很多的符合条件的中餐厅，但其中也包含一些得分较低的其他餐厅（比如西餐厅）。

2. 小A有在寻找新的餐厅，但是这次他更关注一些西餐厅，但是离线结果不能实时更新，给他推荐的只能是根据其“昨天”的行为推荐出来的大量的中餐厅，与其实时偏好不符合。但是如果加入实时的重排序逻辑，那么小A当前所浏览的西餐厅就会立即对之前的离线结果进行重排序。离线结果中一些得分较低的西餐厅通过实时偏好重排序之后的位置很可能会比较靠前，这样出来的结果更加符合小A当前的想法，推荐更有效果。

GBDT和FTRL怎么利用点击 下单，支付日志 建模 预测点击率呀？

2 个回复

GBDT和FTRL怎么利用点击下单，支付日志建模预测点击率呀？