Skip to content

Latest commit

 

History

History
99 lines (53 loc) · 4.25 KB

3.2.8.3.md

File metadata and controls

99 lines (53 loc) · 4.25 KB

Task03问答整理

Task03整体流程(外加录屏整理)

  • 学习2.2.1.5 自动化构建用户及物料画像,学习具体的代码的时候建议先把项目中所有文件中的README.md先看看,了解每个包大概是在干什么,然后再根据教程一点一点去理解流程,建议先梳理代码流程,等到最后自己觉得整个流程自己比较熟悉了,就可以慢慢的去看代码的实现细节。

具体详见https://github.com/datawhalechina/fun-rec/blob/master/docs/第二章 推荐系统实战/2.2新闻推荐系统实战/docs/2.2.1.5 自动化构建用户及物料画像.md

问题解答

  • 问:请问这样处理会不会时间复杂度较大?

    image-20210308142624189

    答:不容易吧,爬取的文章判断重复怎么用id啊?如果式唯一性id必然是跟时间相关的。

    问:有没有一种方式可以直接遍历?

    答:不能全部遍历,这里是为后面准备的,比如后面有召回,排序,最后剩下的那些id才需要添加到redis中。

  • 问:请教下大家,正常这两个col的大小是不是一样的?

    image-20210308142624189

    答:不是一样大,你看一下具体内容就知道了,

    问:前端的阅读数,点赞数、收藏数是来自哪一张表的?好像是mysql里面的,我想一下。

    答:遍历redis的动态画像,把mongodb中对应的动态画像更新mongodb上面的应该大一些。

    问:实时的用户的操作是redis去记录,然后一天结束后,把redis的用户操作推到mongoDBredisprotrail,这样理解对吗?所以redisprotrail是记录n-1天内物料用户行为发生的变化,那是不是要是这个新闻没有被点开的话,这个新闻就不会进入redisprotrail里面呀?

    答:应该不是的,redisprotrail应该是一天的数据,featureprotrail是多天的数据。

    问:redisprotrail是参与图里面的哪一步呢?

    答:这一步

    image-20210308142624189

    问:这一步不是用redis的动态去更新mongofeatureprotrail吗?

    答:你说的是左边那一块

    问:按照3.1的描述,是不是featureprotrailredisprotrail存的新闻条数应该是一样多的。

    答:现在是的,后面如果有召回和排序的话,可能就不是。

    问:update_redis_mongo_protrail_data这个函数是遍历material_collection,也就是mongo_server.get_feature_protrail_collection()也就是featureprotrail应该是和featureprotrail一样多的。

    image-20210308142624189

    答:理解一样多没有问题,后面会修改。

  • 问:用户的喜欢,收藏,点击是直接落到mysql里面吗?

    image-20210308142624189

    答:是的,前端点击阅读、喜欢、收藏会实时更新。

  • 问:这个关键词属于长尾是什么意思?

    image-20210308142624189

    答:个别关键词的类别占了大量数目,以至于前三一直是那几个,长尾现象。

  • 问:请教下大家,这个user_exposure.py是用来建exposure_日期这个表的么

    image-20210308142624189

    答:是的。