这是一场完完全全的实战，承接上期阙文晖老师的“推荐系统架构从0到1”，针对搭建推荐系统时面临的挑战，从数据视角、以多案例的形式在线给出有效可行的解决方案。
这次实战由90后清华学霸、微信AI算法专家钱桥开讲！
推荐系统搭建过程中，最难的三个挑战
当你面对不同任务，搭建一套推荐系统所面临的挑战也不尽相同，开场我们先重点介绍推荐系统的三个挑战。
算法效果和计算复杂性的挑战。在推荐池中候选物品的数量庞大，典型的应用场景是商品推荐，可以达到亿级甚至更高时，如何保证长尾商品的推荐精度，以及如何优化推荐系统的工程效率（不与物品数量呈线性增长）。
推荐要有明确的个性化需求，即每个人看到的推荐结果完全不同，但推荐的内容都是符合用户自身喜好。比如我们做的音乐推荐。
推荐池中的物品拥有一定的实时性，或是潮流性，典型的应用场景包括新闻推荐，这将对系统的反应速度提出巨大的挑战。
实战案例看透推荐系统数据工程
以短视频音乐推荐为例，它是给特定用户、特定上传的视频，推荐合适的配乐，目标是让用户选用系统推荐的歌曲。
第一，仅针对用户的个性化喜好进行推荐，不考虑歌曲与视频的搭配。第二，仅通过用户的行为数据，忽略用户的画像数据，即以前曾给这个用户推荐过哪些歌曲，他选用了哪些进行推荐。当然，这将导致没有历史行为的冷启用户推荐效果变差。
模型方面，我们以非常经典的Youtube个性化召回模型为例。
模型需要训练的参数有三：一是Embedding，海量的音乐Item都将通过一个向量表示，类似于NLP任务中的词表；二是中间的三层前向网络；第三部分是最后的“分类层”。不难看出，第一部分和第三部分的参数规模与推荐池中音乐的数量呈线性关系。
我们认为，用户选用过的或是长时间收听的音乐是他喜欢的。所以，我们将这些音乐的Id作为序列输入模型，随后经过Embedding层、三层前向网络和“分类层”，得到系统对每个音乐的推荐概率。
线上推荐的4个步骤及各自的计算复杂性
步骤一：通过用户ID，拉取该用户最近选用/收听的行为，即音乐ID列表，实现“行为索引”的数据结构需要支持按Key的高效读&写操作，在微信的技术框架下通常选用String-KV来实现，也可以选用开源的Key-Value数据库。
步骤二：通过上一步中得到的音乐ID，拉取其向量表示，实现这个“向量索引”的数据结构仍然需要支持按Key的高效读、写操作。
步骤三：将拉取到的向量列表，作为输入进行三层网络的前向推导，得到最终的向量表示。这部分的计算复杂度并不高，并且工业界也有很好用的例子，例如TensorFlowServing等。
步骤四：将推导的向量输入进全连接层，再通过softmax计算概率分布，排序得出Top-K的推荐结果。倘若我们把全链接层d*N的矩阵，看作N个列向量，其中N是推荐池大小。我们不难通过数学推导得出，这里的任务实际上是查询给定向量的K近邻。在这里，我们选用微信技术环境中的SimSvr实现这个操作，当然类似功能的开源工具有faiss等。
线上推荐模块如何更新、实时性如何
“行为索引”的更新是完全实时的，因为它与模型部分无关。当用户在客户端进行了首听/选用行为后，这条行为数据会通过上报接口实时写入String-KV，从而对该用户的下次推荐产生影响。
其余几部分是通过存储数据，并通过训练新模型进行更新的。
进一步剖析，“行为索引”是通过用户A的行为影响用户A的推荐结果，很容易做到实时。而其余几个模块，是通过其他人的行为，影响用户A的推荐结果，这部分想做实时性是较难的，但正是这部分的实时性，影响了推荐系统是否有能力推荐实时的物品。
这里我们有Plan-A和Plan-B。Plan-A相对保守，使用历史一段时间的数据训练模型，收敛后更新至线上，实现成本较低，但会带来两个问题。（1）模型实时性差，延迟正比于训练时间。（2）受存储和训练时长的影响，训练数据存在上限。
Plan-B相对激进，是我们线上实际使用的方法，可以做到准实时。我们将客户端上报的数据，即用户生产的数据送入消费队列中。另一端，训练脚本从队列中消费mini-batch级的数据包，进行训练。训练部分可以进一步拆解，主要包括计算梯度、参数更新、模型同步至线上三部分，以及一些容灾、补录功能。
我们的需求是每5分钟进行一次训练模块到线上服务的同步，其中“三层网络”由于参数规模小，直接替换即可没有难点。而“向量索引”和“SimSvr”由于参数规模巨大，需要做增量更新。“向量索引”部分只需要按Key进行写替换即可，而“SimSvr”需要支持在线的KNN查询，增量更新后需要重新建立索引，复杂度相对较高。
直播最后，钱桥老师提出了两个很深入的问题，并给出重磅福利：回答出色的同学将免去简历筛选环节，直接获得腾讯微信实习生的面试机会。
