作者回复: 非常好
作者回复: 大致流程确实是这样的。但是其实在实际应用中,tf serving的延迟问题会比较严重。我们会想尽一切办法去减少tf serving的负担。所以特征预处理这块会尽量放到推荐服务器内部来做,或者放到离线做好预存到线上存储。 比如id 2 embeding这一步,可以把id和emb的对应关系放到redis里或者其他线上数据库,减轻tf serving的压力和模型体积。
作者回复: 真实的环境下,候选物品库中存放的是物品的一些基本信息,一般不包含embedding。 embedding应该从特征数据库redis中去拿。 我们的课程项目做了一定程度的简化,候选物品库是直接从数据文件中预载入的。
作者回复: 这就是咱们课程的目的,还是多感谢自己的努力,相信能坚持下来的同学一定可以在工作中有所收获,有所提高。
作者回复: pyspark的部分是咱们课程的学员贡献的。 现实工作中建议最好还是用scala来维护,毕竟是spark原生支持的语言,真正的大数据工程师一般会使用scala。但是也不反对python来维护,跟其他python项目在一起维护会方便些。
作者回复: 我看好边缘计算的发展,一直是近两年我看好的方向。至于多大程度解决了特征更新的问题,我觉得他们会一直共存。边缘计算永远也替代不了服务器端的特征更新设施。
作者回复: 是的,最好是可以在推荐服务器内部把特征都准备好,处理好。tf serving只做inference,不承担太多特征预处理压力。
作者回复: 几乎没有,除非你通过某种方式把模型本身进行蒸馏压缩,让模型需要的特征数量减少。
作者回复: 这是一个模型更新的问题,不是选用模型的问题。基本思路是做模型的online learning,和embedding的实时生成。
作者回复: 1.是的,所有线上inference用到的特征都可以放入redis 2.一般二分类问题倾向于用cross entropy loss,当然,不排除可以用其他loss function。