Cover image

淘宝穿衣搭配比赛有感

Oct 26, 2015

历时将近一个月的搭配比赛第一赛季落幕了,而自己也是毫无悬念的被Pass掉了,最优排名72,成绩是2.56%。总结经验,吸收教训。

教训

毕竟是第一次参加天池竞赛,没见过什么世面,当第一天提交数据的时候看到第六名的成绩自己乐的屁颠屁颠的,现在看来,大牛们一般在后期才参赛的, 前期在排行榜上折腾来折腾去也提高不了零点几的小虾米在后期一天被刷下去十几名,看来自己还是Too Yonge Too Simple。 总结下问题应该大致分一下几点:

1.靠人脑来搭配

事实上,从比赛开始一直到结束自己几乎都是靠感觉来进行搭配的,然后简单的通过ShellPython处理下就提交了,这样往往导致

  1. 思路混乱,比如说购买信息session的划分,从一天划分改到三天划分最后改到七天划分,却发现并没什么卵用;
  2. 思路混乱直接导致代码的混乱,看src文件下一大堆各式各样的.sh.py.awk,基本上全是用一次就扔的臭代码
  3. 最终的结果是没有什么技术含量,说白了就是“拼凑”

不过这也看出了自己的不足————对学习方面的东西简直一窍不通。虽然整天听到什么机器学习神经网络深度学习这样的词汇,但真正 想用的时候却发现自己还是没有一点储备量的。毕竟是隔行如隔山,我一个做演化算法的去搞学习,一开始还是有点适应期的。既然发现问题也就得 解决问题,缺什么补什么,看来接下来花时间好好研究下学习相关内容。

2.眼高手低

比赛初期其实就想系统的看看学习方面的相关知识,借由此契机来入门机器学习。但看到一开始简单处理的数据就在前50内基本上就没准备什么后续 处理了,随想在临结束前两天被甩出50,然后一跌千里。只有在最后一天才临时抱佛脚的尝试了用tf-idf以及文本余弦相似度来进行预测,但 却没有时间了。整个赛季连模型都没有建立更别提什么训练了。只能说,自作孽,不可活。程序员毕竟是个实践的职业,不上手只会Go Die

3.数据没有充分利用

比赛总共提供了大致三项的可利用信息,一是用户购买历史信息,二是商品的Title信息,三是商品的图像信息。但自己只是用了用户的购买信息。 将每个用户的购买信息按时间分成不同session,然后直接提取来作为搭配。其实通过处理可以发现,购买的历史信息中只存在大约一半的test 集中的商品,即一半的要预测的商品并没有出现过购买记录。所以自己这种方案天生的弊端就是一半的商品没法进行搭配。而大量的信息隐藏在 termimg里边自己却无法利用。看来短板还是很多的。

4.线下评测系统搭建的较晚

因为天池只提供一天一次的评测数据的机会,整个来讲还是太少了,有人利用小号来进行评价,可是毕竟没有那么多的手机号。所以搭建一个 Off-line的评估系统对整个算法的评测过程来讲还是很重要的。然而自己真正做这个是却是在数据切换之后开始的,也就是说离第一赛季结束 还有没有几天了,时间太晚了。

收获

当然也有些许的收获,毕竟这一遭走下来也并不是纯粹的打酱油下来的。

1.Redis

一开始面对这些数据第一反应是导入到数据库里,首先选择的是MySQL,然而对商品的Term以及标记的搭配MatchSet这种长短不一的数据存储就 犯难了,按照String类型存的话每次使用的话还得进行处理,但按照属性-值存的话长短不一又好处理。于是选择了Redis这个传说中的“数据结构 数据库”,这样的话存取数据方便多了,而且Redis是对内存的操作,速度上也会很有优势。但后来想到,用Python的数据结构不也可以处理么,用的 时候把数据load内存里,不用的时候将数据dump到硬盘上。不知到速度上或其他性能上有没有大的区别。不过,Redis毕竟是作为数据库存在的, 数据库就是一种有条理的对文件的组织形式。

2.线下评测系统

虽然这该线下评测系统写的有点晚,但进行过几次测试与线上测试结果对比发现整个逻辑还是没有问题的,最让自己泪奔的是用titletf-idf 文本余弦相似度预测的结果在线下评测是0.008,本来寄希望自己的评测系统写的不准确,水乡在线上测试也是0.008左右,大差不差,这真不知道 自己到底是该哭还是该笑。唯一的好处是可以自己研究学习的时候来搞着玩了。


26 Oct 2015

Post by: MetaCoder