先来谈谈我自己在DW范式上的实践。在我之前的《先入为主：将先验知识注入推荐模型》一文中就提到过“重要特征当裁判”。强bias特征作为SENet或LHUC（Learn

Prediction》。这篇文章研究的是，如何训练并部署一个模型，就能胜任“首页推荐”、“猜你喜欢”等多个领域。前两个改进也很“直觉”（嘿嘿，知道我模仿的是谁吗？）每个域学习各自的batch

前言记得我入算法这一行的第一份工作面试的时候，最终的boss面的面试官是前微软工程院的副院长。面试进行得很顺利，不免向前院长卖弄一番，谈了谈我对算法的理解。我说算法工程师就好比厨师，模型是灶上功夫，而数据预处理+特征工程就好比刀工。再好的食材，不切不洗，一古脑地扔下锅，熟不熟都会成问题，更甭提味道了。好的刀工能够将食材加工成合适的形状，无需烈火烹油，也能做出好味道。同理，特征工程做得好，简单模型也能做出不错的效果，当然有了nb的模型，“或许”能够锦上添花。（这个故事的后半段是，前副院长听了我的比喻，问了我一个问题：有没有比刀工更重要的呢？我不记得当时是怎么回答的了，应该是答得不好。副院长说，好的厨师要擅于挑选食材，所以好的算法工程师要会挑选数据。嗯，这个道理等到我写《负样本为王》的时候，理解得就更通透了。负样本挑错了，再好的特征工程也无法挽救你的召回模型。）讲这个故事是为了引出今天的主题，即推荐系统中的特征工程。这个话题比较大，是单单一篇文章无法涵盖的，所以也要先做一下限定。首先，本文不介绍特征工程的基础套路。所谓基础套路，就是大家耳熟能详的那些常规原始特征。用户侧无非就是人口属性（性别、年龄、职业、位置等）、用户安装的app列表、用户的各种观看+互动历史那一堆；物料侧无非就是基本属性（作者、长度、语言），还有基于内容理解（thanks

看到知乎上的一个问题“如何向深度学习模型中加入先验知识？”，觉得这是一个很好的问题，恰好自己在这方面有一些心得，今天拿出来和大家聊一聊。说这个问题有趣，是因为提问者一定是对DNN的“智能”程度不满意了：DNN不是号称自己“万能函数模拟器”吗？这么明显不过的pattern,

(CFM)提升了变体的质量，Google的这篇论文还提出如下观点，值得我们注意并加以实践Google原文还是拿CL当辅助任务与主任务（双塔召回）共同训练，。但是作者也指出，在未来会尝试“先用CL

回归前言大约半年前，换了新工作，从此开始了为了丰富海外人民的业余文化生活，而殚精竭虑、绞尽脑汁的日子，也就没时间、没心情打理我的知乎和微信公众号了，两个地方都荒得长草了。那今天怎么又回来了？原因有三：的确是舍不得我这辛辛苦苦攒下的粉。每个关注我的朋友，都是靠我爆肝码字、做视频换来的，是对我过去辛苦创作的一种肯定，实在舍不得半途而废。何况还有同学私信我追更，使我深受感动。知乎最近应该搞了一个“返航计划”，以唤醒流失作者，算是给我的回归增加了一个契机。促使我下定决心回归的最后一根稻草是，唉，最近比较烦、比较烦、比较烦。人家梁朝伟心烦的时候，能去伦敦喂鸽子，而我只能写篇文章，娱众并自娱，在虚拟世界中慰藉心灵。书归正传，今天咱们说说双塔模型。可能是因为我的网名有一个“塔”字，换到新东家后，就让我负责双塔召回+粗排上的工作，从此开始了一段与“双塔”爱恨交加、一言难尽的日子。有感而发，有了下面的文章。正文开始之前，先声明两点：双塔是“召回”+“粗排”的绝对主力模型。但是要让双塔在召回、粗排中发挥作用，带来收益，只改进双塔结构是远远不够的。如何采样以减少“样本选择偏差”、如何保证上下游目标一致性、如何在双塔中实现多任务间的信息转移...，都是非常重要的课题。但是受篇幅限制，本文只聚集于双塔模型结构上的改进。市面上关于双塔改进的文章有很多，本文不会一一罗列这些改进的细节。遵循本人文章的一贯风格，本文将为读者梳理这些改进背后的发展脉络，了解这些改进“为什么这样做”，希望能够激发读者在“改进双塔”上新的灵感。至于“怎么做”，请感兴趣的读者稳步原文。双塔分离：成也萧何，败也萧何双塔的模型结构很简单，训练的时候将用户侧的信息喂入一个DNN（aka,

前言常读我的文章的同学会注意到，我一直强调、推崇，不要孤立地学习算法，而是要梳理算法的脉络+框架，唯有如此，才能真正融会贯通，变纸面上的算法为你的算法，而不是狗熊掰棒子，被层出不穷的新文章、新算法搞得疲于奔命。之前，我在《推荐算法的"五环之歌"》梳理了主流排序算法常见套路：特征都ID化。类别特征天然是ID型，而实数特征需要经过分桶转化。每个ID特征经过Embedding变成一个向量，以扩展其内涵。属于一个Field的各Feature

前言自从我上次在知乎回答了问题《机器学习中较为简单的算法有哪些？》，很多同学私信我询问我FM算法在推荐系统中的应用细节，索性今天就专门写一篇文章，仔细聊一聊FM这把“推荐算法中的瑞士军刀”。正文开始之前，我说几句题外话。第一，谈谈本文的标题。机器学习算法中的瑞士军刀，可不是随便起的。以前Xgboost因为方便易用、功能广泛、性能优异，被誉为Kaggle比赛中的瑞士军刀。因为同样的优点，我将FM称作“推荐算法中的瑞士军刀”，其中有两个含意：如果你身处大厂，周围训练、上线的资源都很充裕，需要在已经很优秀的业务指标上锦上添花，那么你肯定看不上FM这样的老古董，而是追求DNN、GNN这样的大杀器，而且将Attetion、Transformer之类的花哨结构，能加的都给它加上。但是，既然是瑞士军刀，那么拿它与屠龙刀比威力，就不太公平了。有一日，你脱离了大平台，单独出来行走江湖。这个时候，你才发现，即便屠龙宝刀白送给你，你自己一个人也很难扛起来。适合于业务草创阶段的算法兵器，应该具备：（1）快速训练+上线；（2）尽量白盒，以便定位问题；（3）一专多能，减少开发、维护成本；（4）性能上也不算差。此时，你会发现，FM几乎是你唯一的选择。第二，本文主要介绍FM应用于推荐系统中的一些实战经验，需要读者对FM有一定的基础。对FM还不太了解的同学，我推荐以下参考资料：掌握FM原理，推荐读美团的博客《深入FFM原理与实践》。FFM的部分可以忽略，在我看来，FFM损失了FM的很多优点（比如，通过公式简化，将时间复杂度由减少为），更像是为了Kaggle专门训练的比赛型选手。这就好比，奥运会上的射击冠军，未必能够胜任当狙击手一样。FM用于召回，推荐读张老师的《推荐系统召回四模型之：全能的FM模型》。但是，需要注意的是，FM虽然是能够覆盖召回+排序的全能选手，但是对于不同业务，FM在样本选择、模型设计、上线部署的细节上，都有较大差异。这一点，张的文章没有涉及，而本文将为读者梳理之。如果想亲手实践，可以尝试alphaFM。该项目只不过是作者八小时之外的课外作品，却被很多公司拿来投入线上实际生产环境，足见该项目性能之优异和作者功力之深厚，令人佩服。强烈建议不满足只当“调参侠”的同学，通读一遍alphaFM的源代码，一定收获满满。接下来的文字中，我首先梳理一下FM的特点，再按照精排、召回、解释模型的顺序，介绍FM在各个业务中的技术细节，比如：如何无偏地收集样本、如何设计模型、如何部署上线。细心的读者可能注意到，这里面没有“粗排”的内容。我们尝试过粗排模型（并非FM，而是双塔+蒸馏），线上收益并不明显，所以在就里就不详细叙述了，感兴趣的同学可以参考阿里的论文《Privileged

layer声称的“任意阶交叉”完全没有实现的必要。而且浅层模型必须简单，好起到了类似“正则”的作用，防止DNN过分扩展。因此在我看来，浅层模型实现超过3层的交叉，完全是不务正业。第5环：Field

前言前段时间面试了许多应界生同学，惊讶地发现很多同学只做深度学习，对于LR/GBDT这样的传统机器学习算法，既不掌握理论，也从未实践过。于是就想写一篇文章，梳理一下推荐算法由传统机器学习，发展到深度学习，再到未来的强化学习、图神经网络的技术发展脉络，因为「只有了解过去，才能更好地把握当下与未来」。无奈这个题目太大，再加上近来分身乏术，实在无暇宏篇大论。于是今日小撰一文，聚焦于深度学习的核心思想Embedding（「Embedding

关注本人的同学可能发现，我最近点评的文章都是关于"GNN在推荐系统应用"方向的。这当然与现如今这个方向非常火有关，但是作为一个合格的炼丹师+调参侠，总要搞清楚一门技术为什么火？这么火的技术对于自己是否有用？根据我的理解，由“传统机器学习→深度学习→图计算或知识图谱”这一路下来的发展脉络如下：一切技术的目标都是为了更好地“伺候”好“推荐系统的一等公民

group一周观看超过3次。因为user-tag行为稀疏，因此图中没有user-tag的边video-tag：video和其携带的tagvideo-media：video和其来源tag-tag：两个

之间没有边但是训练时提供的原图，q与i之间是实实在在存在边的，q与i节点上的信息沿着边相互传统，q与i之间的点积自然很大。这样的信息泄漏使模型根本学不到有用的信息。为此，在为每个

有人的地方就会有江湖，就会有鄙视链存在，推荐系统中也不例外。排序、召回，尽管只是革命分工不同，但是我感觉待遇还是相差蛮大的排序排序，特别是精排，处于整个链条的最后一环，方便直接对业务指标发力。比如优化时长，只要排序模型里，样本加个权就可以了。排序由于候选集较小，所以有时间使用复杂模型，各种NN，各种Attention，能加的，都给它加上，逼格顿时高大上了许多。用于排序的基础设施更加完善，特征抽取、指标监控、线上服务都相对成熟。召回一个系统中不可能只有一路召回，平日里相互竞争，召回结果重合度高，导致单路召回对大盘的影响有限；好处是，相互冗余，有几路出问题，也不至于让排序饿肚子。召回处于整体推荐链条的前端，其结果经过粗排、精排两次筛选，作用于最终业务指标时，影响力就大大减弱了。受限于巨大的候选集和实时性要求，召回模型的复杂度受限，不能上太复杂的模型。平日里，最简单的基于统计的策略，比如ItemCF/UserCF表现就很不错，改进的动力也不那么急迫。用于召回的基础设施不完善。比如，接下来，我们会提到，召回建模时，需要一些压根没有曝光过的样本。而线上很多数据流，设计时只考虑了排序的要求，线上的未曝光样本，线下不可能获取到。总之，我感觉，排序更受关注，很多问题被研究得更透彻。而召回，尽管"召回不存，排序焉附"，地位相当重要，但是受关注少，有好多基本问题还没有研究清楚。比如接下来，我们要谈到的，诸如“拿什么样的样本训练召回模型”这样的基本问题，很多人还存在误区，习惯性照搬排序的方法，适得其反。在这种情况下，2020年Facebook最新的论文《Embedding-based