召回-ALS（Alternating least Squares）-交替最小二乘

项目背景：使用星球联盟的每日必做

#准备数据

分类情况：

情况	标签
仅曝光 未点击 未完成	0
仅一次点击 未完成	1
仅多次点击 未完成	2
仅一次完成	3
多次完成	4

 

1.数据来源：

表mlg.xqlm_app_child_task，任务曝光数据

表mlg.xqlm_app_taskfinish_details 任务完成情况数据

2.sql语句，得到曝光表，点击表，完成表：

# SQL语句
# select passid as uid,dailytaskid  from mlg.xqlm_app_child_task where dt='2020-03-18' and pagetype='sy_2' and eventtype='1' and dailytaskid is not null
# select passid as uid,dailytaskid  from mlg.xqlm_app_child_task where dt='2020-03-18' and pagetype='sy_2' and eventtype='2' and dailytaskid is not null
# select uid,dailyid as dailytaskid  from mlg.xqlm_app_taskfinish_details where dt='2020-03-18' and dailyid is not null

3.数据预处理

data_0:仅曝光表count=1 且 点击表、完成表count为0

data_1：仅点击表count=1 且完成表count为0

data_2：仅点击表count>1 且完成表count为0

data_3：完成表count=1

data_4：完成表count>1

样本数量：

label 0|5589175|

label 2| 215338|

label 1| 423625| 

label 3|1646449| 

label 4|6606331| 

 

 

 

#模型训练

ALS.train(ratings, 20, 10, 0.01)

参数：

rank:20

inter:10

lambda:0.01

1) ratings : 评分矩阵对应的RDD。需要我们输入。如果是隐式反馈，则是评分矩阵对应的隐式反馈矩阵。

2) rank : 矩阵分解时对应的低维的维数。即PTm×kQk×n中的维度k。这个值会影响矩阵分解的性能，越大则算法运行的时间和占用的内存可能会越多。通常需要进行调参，一般可以取10-200之间的数。

3) iterations :在矩阵分解用交替最小二乘法求解时，进行迭代的最大次数。这个值取决于评分矩阵的维度，以及评分矩阵的系数程度。一般来说，不需要太大，比如5-20次即可。默认值是5。

4) lambda: 在 python接口中使用的是lambda_,原因是lambda是Python的保留字。这个值即为FunkSVD分解时对应的正则化系数。主要用于控制模型的拟合程度，增强模型泛化能力。取值越大，则正则化惩罚越强。大型推荐系统一般需要调参得到合适的值。

5) alpha : 这个参数仅仅在使用隐式反馈trainImplicit时有用。指定了隐式反馈信心阈值，这个值越大则越认为用户和他没有评分的物品之间没有关联。一般需要调参得到合适值。

从上面的描述可以看出，使用ALS算法还是蛮简单的，需要注意调参的参数主要的是矩阵分解的维数rank, 正则化超参数lambda。如果是隐式反馈，还需要调参隐式反馈信心阈值alpha 。

#实验结果

均方误差 = 0.015047

均方根误差 = 0.122666

##上线测试结果

 

优化改进：

测试结果显示，完成率和有曝光记录的人均完成任务数较小。这表明，很多用户对于曝光的任务一个也不感兴趣，一个也没完成。

原来的推荐思路是根据点击和完成情况进行数据的rating分类，经过ALS模型训练，根据预测的rating值排序，对用户进行推荐。

情况	rating
仅曝光 未点击 未完成	0
仅一次点击 未完成	1
仅多次点击 未完成	2
仅一次完成记录	3
多次完成记录	4

 

考虑了两点：

1.在用户历史行为中，有的用户从来就没有完成任务或者只是点击却并未完成。这样模型的预测结果 max(rating)<3 ,这样排序出来的列表，用户仍然是不感兴趣，并且不会做的。可以适当添加一些别的他没有见过的任务去探索一下他的兴趣点。

2.每日必做的模式是只有完成前3个任务，才会更新后面的任务，而且从有完成记录用户的人均任务完成数来看，平均每个用户的完成数是1到2个，所以应该思考如何提高前三个任务的完成率。

优化想法：

1.对于预测max(rating)<3的用户，不再根据任务的rating排序进行推荐。推荐列表的第3，6，9个位置设置为该用户从未被曝光过的任务，其余位置设置为训练数据中，完成率为topk的任务。

2.对于预测3<【(rating>3).count()】<9的用户，剩余位置用完成率topk的任务补充。

3.对于预测【(rating>3).count()】>=9的用户,仍然按照rating的排序来推荐。

 

 

 

 

#用户冷启动

根据完成情况统计，将完成率为topK的items推荐给新用户