多角度审视推荐系统
在推荐系统中，特征的本质其实是对某个行为过程相关信息的抽象表达。尽可能地让特征工程抽取出的一组特征能够保留推荐环境及用户行为过程中的所有有用信息，尽量摒弃冗余信息。
常用特征： 1.用户行为数据 2.用户关系数据 3.属性、标签类数据 4.内容类数据，一般来说，内容类数据无法直接转换成推荐系统可以“消化”的特征，需要通过自然语言处理、计算机视觉等技术手段提取关键内容特征，再输入推荐系统。 5.上下文信息，上下文信息(context)是描述推荐行为产生的场景的信息。最常用的上下文信息是“时间”和通过GPS 获得的“地点”信息。 6.统计类特征统计类特征是指通过统计方法计算出的特征，例如历史CTR、历史CVR、物品热门程度、物品流行程度等。统计类特征一般是连续型特征，仅需经过标准化归一化等处理就可以直接输入推荐系统进行训练。 7.组合类特征
在权衡计算速度和召回率后，目前工业界主流的召回方法是采用多个简单策略叠加的“多路召回策略”。所谓“多路召回策略”，就是指采用不同的策略、特征或简单模型，分别召回一部分候选集，然后把候选集混合在一起供后续排序模型使用的策略。
模型的实时性是与模型的训练方式紧密相关的，模型的实时性由弱到强的训练方式分别是全量更新、增量更新和在线学习
冷启动问题根据数据匮乏情况的不同，主要分为三类：(1)用户冷启动，新用户注册后，没有历史行为数据时的个性化推荐。(2)物品冷启动，系统加入新物品后（新的影片、新的商品等），在该商品还没有交互记录时，如何将该物品推荐给用户。(3)系统冷启动，在推荐系统运行之初，缺乏所有相关历史数据时的推荐。
主流的冷启动策略归为以下三类：(1)基于规则的冷启动过程。(2)丰富冷启动过程中可获得的用户和物品特征。(3)利用主动学习、迁移学习和“探索与利用”机制。
“探索与利用”机制在推荐系统中的应用： (1)物品冷启动。(2)发掘用户新兴趣。(3)增加结果多样性。
工程实现
从工程的角度来看推荐系统，可以将其分为两大部分：数据部分和模型部分。数据部分主要指推荐系统所需数据流的相关工程实现；模型部分指的是推荐模型的相关工程实现，根据模型应用阶段的不同，可进一步分为离线训练部分和线上服务部分。
方法并行处理海量数据。“分布式存储+Map Reduce”的架构只能批量处理已经落盘的静态数据，无法在数据采集、传输等数据流动的过程中处理数据，因此被称为批处理大数据架构。
流计算架构中“滑动窗口”的概念非常重要，在每个“窗口”内部，数据被短暂缓存并消费，在完成一个窗口的数据处理后，流计算平台滑动到下一时间窗口进行新一轮的数据处理
Lambda 架构的数据通道从最开始的数据收集阶段裂变为两条分支：实时流和离线处理。实时流部分保持了流计算架构，保障了数据的实时性，而离线处理部分则以批处理的方式为主，保障了数据的最终一致性，为系统提供了更多数据处理的选择
Kappa架构秉持着——“Everything is streaming（一切皆是流）”的原则，在这个原则之下，无论是真正的实时流，还是离线批处理，都被以流计算的形式执行。也就是说，离线批处理仅是“流处理”的一种特殊形式
在现有实际条件的制约下，以工程完成和技术落地为目标，寻找并实现最优的解决方案。正是因为工程师永远以“技术落地”为目标，而不是炫耀自己的新模型、新技术是否走在业界前沿，所以在前沿理论和工程现实之间做权衡是一名工程师应该具有的基本素质。
评估
线上系统的某些商业指标在离线评估中无法计算。离线评估一般针对模型本身进行评估，无法直接获得与模型相关的其他指标，特别是商业指标。以新的推荐模型为例，离线评估关注的往往是ROC曲线、PR曲线等的改进，而线上评估可以全面了解该推荐模型带来的用户点击率、留存时长、PV访问量等的变化。这些都要由A/B测试进行全面评估。
总结
推荐系统整体知识架构图。熟悉架构概览的最佳方式：多看大厂实践、论文。
一名推荐工程师的技术能力基本可以拆解成以下4个方面
知识：主要指推荐系统相关知识和理论的储备，比如主流的推荐模型、Embedding的主要方法等。
工具：运用工具将推荐系统的知识应用于实际业务的能力，推荐系统相关的工具主要包括TensorFlow、PyTorch 等模型训练工具，Spark、Flink 等大数据处理工具，以及一些模型服务相关的工具。
逻辑：举一反三的能力，解决问题的条理性，发散思维的能力，聪明程度，通用算法的掌握程度。
业务：理解推荐系统的应用场景、商业模式；从业务中发现用户动机，制定相应的优化目标并改进模型算法的能力。
