作者回复: 非常非常好的问题。细心的话可以发现transitionMatrixAndItemDis这个矩阵完全是在driver端。 难点在于如何分布式地处理转移概率矩阵,解决方案确实是业界的难点。另外在随机游走的时候因为肯定要访问全部的转移矩阵,所以理论上来讲需要把这个矩阵broadcast到所有节点,这又是一个容易oom的问题。 有好的思路可以欢迎分享!但不是一个短时间能够解决的业界难题。
作者回复: 非常好的观察,推荐所有的同学都能好好观察数据并得出这样有用的结论。 确实是这样,由于一些长尾,冷门电影的存在(毕竟热门电影还是极少数的),导致概率转移矩阵中游走到冷门电影的概率其实非常小,所以在游走次数比较小的时候,很容易覆盖不到。 因为课程的示例程序采用了比较小的采样次数和游走长度,所以这个问题比较严重,工作中肯定要在算力允许的前提下,尽量增加采样次数,适当增加游走长度,来保证生成结果的稳定性和覆盖率。
作者回复: 在项目中用最简单的average pooling的方法生成了user embedding。也就是把用户评价过的高分高分电影的embedding进行平均。 user embedding的其他生成方式也很多,像你说的,也可以根据历史行为构建用户-物品的关系图,然后直接在其上进行随机游走,直接一同生成user 和item emb。 或者采用其他双塔结构的模型生成item和user emb等等。
作者回复: 300000的物品规模单机环境肯定比较吃力了,代码中的实现也是单机下的随机游走,不管再如何优化都比较困难。 生产环境请关注spark的图计算api graphX https://spark.apache.org/graphx/ 我认为比较好的教程 https://endymecy.gitbooks.io/spark-graphx-source-analysis/content/ 其实期待更多的同学能参与到项目的维护中来,我们不仅是一个课程,更是一个业界交流的平台,期待能看到新的进展。
作者回复: 理解非常正确。 而且针对graph embedding方法,不要认为所有的图数据都是由序列数据生成的,有一些天然的图数据,比如知识图谱,是只能使用graph embedidng方法,不能使用item2vec的。所以graph embedding应用范围更广,保存的信息也更多。
作者回复: EGES是希望融合更多side information,只用id信息并不是它的意义所在。而且除了这些原理上的分析外,我不主张给任何人模型效果好坏的建议,决定的因素太多了。 但总的来说,如果你只有id类的历史行为信息,使用EGES的意义不大。
作者回复: 这是个简单的脑筋急转弯问题吧。电影的3.5是平均分,你再想想。
作者回复: 是这样,内存问题是工程实现中最大的限制。我没有深入研究过spark的graphX,以及一些图计算的分布式引擎。如果有经验的同学可以谈谈如何进行分布式的转移矩阵处理。
作者回复: 不可以。Embedding冷启动的问题大家问的比较多,我找时间统一回复一下。 简单来说生成环境下对于冷启动物品需要指定一个默认embedding,或者基于一些其他的相似条件取相似embedding的平均。
作者回复: 会的,但通常我们也希望更多的去推荐爆款商品,这还是跟你自己的观察和决定相关