- 学习2.2.1.5 自动化构建用户及物料画像,学习具体的代码的时候建议先把项目中所有文件中的README.md先看看,了解每个包大概是在干什么,然后再根据教程一点一点去理解流程,建议先梳理代码流程,等到最后自己觉得整个流程自己比较熟悉了,就可以慢慢的去看代码的实现细节。
具体详见https://github.com/datawhalechina/fun-rec/blob/master/docs/第二章 推荐系统实战/2.2新闻推荐系统实战/docs/2.2.1.5 自动化构建用户及物料画像.md
-
问:请问这样处理会不会时间复杂度较大?
答:不容易吧,爬取的文章判断重复怎么用
id
啊?如果式唯一性id
必然是跟时间相关的。问:有没有一种方式可以直接遍历?
答:不能全部遍历,这里是为后面准备的,比如后面有召回,排序,最后剩下的那些id才需要添加到redis中。
-
问:请教下大家,正常这两个
col
的大小是不是一样的?答:不是一样大,你看一下具体内容就知道了,
问:前端的阅读数,点赞数、收藏数是来自哪一张表的?好像是
mysql
里面的,我想一下。答:遍历
redis
的动态画像,把mongodb
中对应的动态画像更新mongodb
上面的应该大一些。问:实时的用户的操作是
redis
去记录,然后一天结束后,把redis
的用户操作推到mongoDB
的redisprotrail
,这样理解对吗?所以redisprotrail
是记录n-1
天内物料用户行为发生的变化,那是不是要是这个新闻没有被点开的话,这个新闻就不会进入redisprotrail
里面呀?答:应该不是的,
redisprotrail
应该是一天的数据,featureprotrail
是多天的数据。问:
redisprotrail
是参与图里面的哪一步呢?答:这一步
问:这一步不是用
redis
的动态去更新mongo
的featureprotrail
吗?答:你说的是左边那一块
问:按照3.1的描述,是不是
featureprotrail
和redisprotrail
存的新闻条数应该是一样多的。答:现在是的,后面如果有召回和排序的话,可能就不是。
问:
update_redis_mongo_protrail_data
这个函数是遍历material_collection
,也就是mongo_server.get_feature_protrail_collection()
也就是featureprotrail
应该是和featureprotrail
一样多的。答:理解一样多没有问题,后面会修改。
-
问:用户的喜欢,收藏,点击是直接落到
mysql
里面吗?答:是的,前端点击阅读、喜欢、收藏会实时更新。
-
问:这个关键词属于长尾是什么意思?
答:个别关键词的类别占了大量数目,以至于前三一直是那几个,长尾现象。
-
问:请教下大家,这个
user_exposure.py
是用来建exposure_日期
这个表的么答:是的。