阿里推荐大赛:ODPS SQL 构建离线评估

上一篇文章介绍了 ODPS SQL 的大概使用方法,几个 tips,和讲到一半的离线评估。现在上来把上次的坑填完。希望对于还没有开始离线调优的团队有点帮助。

划分训练集、验证集

回顾训练集、验证集的划分。

根据时间,可以将前三月划分为训练集:

create table train_set as
select *
from t_alibaba_bigdata_user_brand_total_1
where visit_datetime <= '07-15';

同理,验证集如下,注意去重:

create table validate_set as
select
user_id,
wm_concat(',',brand_id) as brand
from(
select distinct user_id,brand_id
from t_alibaba_bigdata_user_brand_total_1
where type = '1' and visit_datetime > '07-15'
)a
group by user_id;

这里distinct关键字的作用就是去重,当然也可以用group by实现。两者效果一样,那效率呢?在 MySQL 中(如果没记错的话,天池的底层数据库是基于 MySQL 的),两者的实现原理很相似。区别在于distinct会读取所有的记录,而group by是在分组之后每组只返回一条记录,也就是说后者读取的条数要少很多,效率会更高一些。所以可以用以下代码代替上述的子查询:

select user_id,brand_id
from t_alibaba_bigdata_user_brand_total_1
where type = '1' and visit_datetime > '07-15'
group by user_id,brand_id

扯远了… 回来吧。计算推荐集、验证集条数的方法之前也给出了:

select sum(regexp_count(brand,',')+1) from t_tmall_add_user_brand_predict_dh;

接下来要计算推荐集和验证集之间的重复条数,这里可以用 UDF 方便地实现。

UDF 计算重复条数

在我们 Eclipse 中的 ODPS 项目下新建 UDF。填入 Package 名称为:jark.udf,和 UDF 类名:CountHits,点击确认。插件会自动帮我们生成jark.udf包用于写 UDF 代码,和test.jark.udf包用于本地测试。

编辑CountHits.java文件,注意下文的Long不能替换为long类型,否则在ODPS上运行会报Method Not Found错误。:

public class CountHits extends UDF {
public Long evaluate (String a,String b){
if(a == null || b == null) return 0L; //异常值
Set<String> set1 = new HashSet<String>();
Set<String> set2 = new HashSet<String>();
set1.addAll(Arrays.asList(a.split(",")));
set2.addAll(Arrays.asList(b.split(",")));
Long hits = 0L;
for(String s : set2){
if( set1.contains(s) )
hits++;
}
return hits;
}
}

本段函数的主要工作是在a串和b串去重后,计算它们中重复元素的个数。接下来在本地测试下 UDF 。在test.jark.udf包中有两个文件TestCountHits.javaTestUDFBase.java。由于如果 UDF 的输入参数是多个的话,本地测试默认的分隔符是逗号,与我们brand中的逗号冲突了。所以修改下TestUDFBase.java文件的第15行的分隔符为空格(当然也可以其他符号):

private final static String ODPS_SEPARATOR = " ";

顺便修改第72行,去掉(String),原因是Long型不能强制转换成String

return callMeth.invoke(UDFClass, input_parameter.toArray()) + "\n";

TestCountHits.in文件中输入测试输入:

123456,444,555,666 123456,666,777,888
888,999 111,222
111,111,222,222 111,222,222,333

运行TestCountHits.java后,在TestCountHits.out文件中得到测试结果:

2
0
2

测试输入应更为复杂,以上只是示例。在确认 UDF 没有问题后,准备上传。将Package jark.udf打成 jar 包,命名为jark-udf.jar,置于C:/TOOLS下,执行以下命令:

create resource jar C:/TOOLS/jark-udf.jar
create function count_hits jark.udf.CountHits jark-udf.jar

上述命令作用分别是将用户 jar 包上传到 ODPS 和在 ODPS 上注册函数并命名为count_hits。现在使用ls functions命令应该就能看到我们刚刚注册的函数了。

现在,我们就能像调用一般内建函数一样调用我们自己的count_hits函数了。计算推荐集和验证集中的重复条数,有下面代码:

select sum(count_hits(a.brand,b.brand)) hits from t_tmall_add_user_brand_predict_dh a
join validate_set b on a.user_id = b.user_id;

上面演示了一般 UDF 的创建使用过程,其他类似的 UDF 都可以参考以上过程构建。UDF 是 SQL 的一大工具 ,很多规则算法都可以用过 UDF 方便地实现。

计算评测值

我们知道准确率的计算公式:$precision = hits / pnums$,为pnums为推荐条数。

召回率的计算公式有:$recall = hits / vnums$,vnums为验证集条数。

而 F1 的计算公式有:

为了计算方便,我们用full outer join连接验证集和推荐集,并将计算出的 hitspnumsvnums 放到临时表里。感谢 @木同学style 的建议。

select sum(count_hits(p.brand,v.brand) hits,
sum(regexp_count(p.brand,',')+1) pnums,
sum(regexp_count(v.brand,',')+1) vnums
from t_tmall_add_user_brand_predict_dh p
full outer join validate_set v on p.user_id = v.user_id

有了这三个值后,就可以用上面的公式轻松计算出评测值了。

select (hits/pnums) precision, (hits/vnums) recall,(2*hits/(pnums+vnums)) F1
from (
select hits , pnums , vnums
from ...
)a;

OK,感觉讲的有点啰嗦了… 整合上面计算评测值的代码后,有如下代码:

create table evaluation as
select (hits/pnums) precision , (hits/vnums) recall , (2*hits/(pnums+vnums)) F1 ,
hits , pnums , vnums , getdate() eval_time
from (
select sum(count_hits(p.brand,v.brand) hits,
sum(regexp_count(p.brand,',')+1) pnums,
sum(regexp_count(v.brand,',')+1) vnums
from t_tmall_add_user_brand_predict_dh p
full outer join validate_set v on p.user_id = v.user_id
)a;

我们将评测值写到了evaluation表中,可供组员查看分析。运行一次上面代码后,若以后再进行评测,可以将第一行改成insert into/overwrite table evaluation后直接运行,个人喜欢用into,这样可以与上次的结果进行比较。

现在已有的模型算法就可以在本地测试调优后,再上传到线上进行评估了。

关于数据集的几点想法

对于离线评估我也并没有深刻的见解,只是想无责任地说点个人的想法,还望大家一起讨论纠正。

  1. 上面的训练集和验证集的划分有一定的局限性。主要是模型可能会高度依赖于训练集和验证集的构成,导致过拟合的问题。要消除这种依赖,可以借鉴自助法,每次训练时从训练集中随机抽取一部分,验证时也随机从验证集中抽取一部分,抽取比例一样,例如抽取63.2%。XLab/XLib 提供了随机采样的接口。

  2. 线上预测我们是用前四个月预测第五个月,时间划分是 4:1 的关系。所以离线划分训练集、验证集时,也按这个比例划分会更合理。即最后24天的数据作为验证集。

  3. 上面的离线评估是用来训练模型用的,当我们后期融合模型时如果继续在训练集上融合,还是会造成过拟合。所以可以在训练集上再拆分成训练集 A 和预测集 B,B 的生成方法和验证集类似,也取最后 1/5。在 A 上训练模型,B 上做出预测,得出融合系数。再在整个训练集上训练模型,在验证集上做出预测。最后将预测结果用得到的融合系数融合,融合结果再在验证集上得到最终预测结果。关于模型融合,是一门高深的学问,希望有经验的大大出来分享一下。

  4. 原始数据集噪声很大,相信很多同学都发现有垃圾用户、刷钻用户的存在。《推荐系统实践》里说「使用正确的用户数据对推荐系统至关重要」。所以,在忙着实现各种模型算法之前不如先做下数据清理。去噪的方法有很多,比如基于规则、基于离群点检测、基于聚类等等。

写在最后

本人小硕一枚,以前没有搞过机器学习,对各种模型也是一知半解。参加这个比赛最主要的目的是为了学习,学习 ODPS 学习模型算法,而不是名次(吐槽下淘汰赛制让我不得不把名次看重了)。所以,我会把平时的学习心得记录下来,最后就算离开了也有值得纪念的东西留下(没了虚拟机,什么都没了啊!!)。我写的这些东西相信很多同学上手都比我快(仰望首页的大神们),希望能有更多的同学出来分享自己的心得,营造更好的学习氛围。实在是有太多的东西值得学习。