2018-04-05如果用户数量和物品数量太大，线下计算无法满足每天全部更新推荐一次推荐。
1. 可以根据用户访问的频率，优先计算访问频率高的用户的线下更新。尽可能满足更新频率略高于用户的历史访问频率(或预测访问频率)。另外新用户和新物品一般第一次更新尽可能及时。
2. 对权重高的物品和用户，对整个系统效果影响较大的物品和用户，尽可能保证他们的更新频率。同时适度保持exploration，多样性，新颖性。
3. 把用户和物品分类，同一类用相同的推荐结果，降低线下计算量。
4. 如第1条回答所述，公司如果有资源上分布式计算，甚至还可以做运维的优化，底层性能的优化，也可以提高公司对于大数据量的计算能力。展开 4
2018-04-09架构是时间，空间，算力等多种东西的折衷，分析问题将可离线计算和必须在线计算的数据拆解，主要还是看每种选择可能性的潜力和提升量。现在往往几十ms的时限下，空间换时间，加cache，分级别离线算好直接取都比较常用 1
2018-10-20@林彦的第3条很喜欢
不是根据每个用户做推荐，而是先将用户做聚类；把(userId、itemId、rank)变成(userGroupId、item、weightdRank)进行训练，得到每个聚群的推荐结果；
cache只需要存储每个聚群的推荐结果、每个用户的聚类映射即可，每次查询，先查询用户的聚类，然后取出聚类的推荐结果返回；
如果这个聚类算法能在线高实时调用，那连新用户冷启动问题都解决了；不过画像数据一般很大，要在几十MS返回画像，同时返回聚类结果，难道有点大；可以借鉴netflix的结构，加入近线层；把用户聚类的计算用streaming(spark streaming/flink/storm)计算，更新到CACHE即可；展开
2018-04-02计算量过大时的解决方法 1采样降低数据量 2 模型几天才更新一次 3如果原来是单机计算 改用分布式