前言
第一部分，推荐模块技术点结合实际工作分选品、召回、排序、策略、干预、外显模块叙述各部分使用到的算法和策略。在1.6部分结合自己做过的一个推荐平台设计的初衷。
第二部分，评估指标体系结合实际将推荐指标分为离线指标、业务指标、消费度指标、主观指标、系统指标五部分。其中，业务指标和消费度指标从实际电商、视频业务的角度进行思考和总结。系统指标从场景上线和大促资源运维角度进行分析。
第三部分，对文章内容做了简单总结，陈述个人观点。
一、推荐模块技术点
1.1 选品
选品直接影响推荐效果，常包括活动招商选品和运营圈选。其中活动招商选品要求参与商家满足活动要求，需人工审核，商品量在几千以内，一般多轮分批次凑齐，只是用几千个招商商品做推荐，推荐效果难以理想。招商商品存在大额度优惠，业务指标一般不错。比如，在活动中做个性化流量和非个性化流量的调控结果并不会比纯个性效果差，这是因为非个性化流量中存在大量质优价廉的商品。
日常业务以规则选品为主，运营给定业务场可以出现的商品类目，对类目下商品进行排序凑齐规定数量的选品规模，规模在几十万及以上。选品规则人工制定，后期根据投放效果迭代优化。在首页及重要场景，对于涉黄、涉恐、涉政、涉暴的商品格外敏感，一般需要接入品控数据。
早期，选品是业务方给定规则，研发同学写脚本跑出商品多轮迭代。平台完善之后可建设选品平台。业务方在平台界面上进行常用需求勾选，后台实时跑出数据呈现给业务方。通过随机抽样可视化+数据统计由业务方自行评估和校准。平台化选品的另一个优势是业务方可以可视化进行兜底数据的选择和排列。保证最低展示效果避免开空白页。另外，在toB业务团队，小规模种子商品通过相似度计算扩展商品池。
1.2 召回
召回不作为推荐的技术重点，但召回商品直接决定推荐效果。常用召回方法有
多路召回( 长短期兴趣+热门召回+社交召回+新品召回 )，每一路召回类似于单特征模型，每一路召回数量作为超参根据在线ab分桶实验效果进行调整。在早期，多路召回+层间固定排序+层内ctr单独预估是弥补模型不足的常用手段。由于多路召回每一路数量难以控制，使用Embedding+LSH+粗排ranking的方式进行统一召回，粗排rank须与精排rank优化目标一致。
上面提到Embedding，不同Embedding对应不同业务场景。对于文本、词条等序列数据，使用word2vec/item2vec。商品侧等网路化数据使用GraphEmbedding，其中node2vec找到的同质性相同的是同品类、同属性或经常被一同购买的商品，这种方式在购后feed流场景使用较多。node2vec找到的结构性相同的是各品类的爆款、最佳凑单商品等拥有相似结构的商品，用在活动场景效果好。EGES通过补充信息Embedding+Attention机制在一定程度上完成新商品冷启动。总之，要根据业务场景，从用户的角度思考想看什么，想要什么，然后有针对性地进行模型选型，要业务驱动而不能拿着锤子找钉子。
召回侧最后一路是热门兜底，需要尽可能跨多类目。对于冷启用户一旦点击兜底商品，利用itemcf可以快速完成用户冷启操作。
关于平台化的思考，召回本质是找相似商品。每个业务每个实验有不同的召回数据会造成资源浪费。用全网数据生成一个尽可能大的相似商品矩阵，每个业务或者实验通过圈选的商品池在大矩阵上找到各自的相似召回数据，减少重复存储数据量。由于各业务场相似度计算存在一些差异。平台化召回+粗排模型的方式最为常用，一般粗排模型是简单统计模型或轻量级粗粒度lr模型。通过召回侧数量控制减轻排序侧精排计算压力。
1.3 精排
精排模型是推荐研究的重点，但要在算法先进性和系统维护性之间做权衡。更重要的是理解用户场景，熟悉数据特点。面对什么样的用户，能拿到什么样的数据，决定了模型选型。
在2016年之前传统浅层模型包括 协同过滤(itemcf/usercf/mf), 逻辑回归(LR/LS-PLM),因子分解机( FM/FFM ), 组合模型(gbdt+lr)。 从2016年开始,深度学习在推荐上改变网络复杂度(deep crossing)，改变特征交叉方式(NeuralCF/PNN)，模型组合(W&D/DCN/DeepFm)和深度Fm模型(NFM/FNN/AFM), 以及最近两年重心放在用户历史数据的深度利用上，衍生出注意力机制类(AFM/DIN)，序列模型类(DIEM/MIMN)，强化学习类(DRN)等。
模型种类繁多，但仍要从业务的角度思考问题。个人认为，在众多深度模型出现之前，问题和解决办法早已存在。比如在选择用户历史商品的时候，通过时间衰减调整历史商品权重，就加入了时间序列的思考。对不同用户历史商品的不同行为分类(点击/购买/收藏/加购)分别进行召回处理，与现在MIMN的思想较为相似。
1.4 策略
策略后处理主要用于生态构建。常有商品打散和疲劳度控制，有基于规则的、统计的、模型的方法。一线公司每年都有相应论文发出，不再累述。
值得一提的是，不同业务场景之间需要有一个平台级的统一后处理控制。不仅在单个场景内做打散过滤降权，同一个展示页面的不同业务之间也需要做打散过滤降权。这样才能保证整个app展示的多样性，提升用户体验。
1.5 冷启动&EE
冷启包括商品冷启、用户冷启、系统冷启。具体方法分为基于规则的冷启，丰富模型特征的冷启、利用主动学习、迁移学习、探索与利用机制的冷启。方法繁多且直接拿来用效果未必好。需要针对业务场景和数据特点进行改造，比如E&E的核心是倾向于高得分和新商品的透出，基于这种思想和业务特点，简历中softmax bandit更有针对性解决业务特点。
大部分实际业务在工作中不存在冷启问题。出于kpi的原因，实际选品多是热门高质量选品。冷启和探索利用机制更多用于用户增长业务和新场景预热。
1.6 推荐流程平台化
几乎所有推荐业务都是选品-->召回-->排序-->后处理-->干预平台-->前端展示-->监控指标构成的数据闭环。第一步选品和最后一步前端展示与业务强耦合，其余环节相似。通过模块解耦实现推荐框架平台化。
选品平台设计：将产品和运营常用的选品规则罗列出来，通过运营勾选规则方式自动运行脚本，准实时产出业务选品池。加入可视化采样和各维度统计来帮助运营校准迭代。
召回平台设计：构建全网多路召回数据(几十路)，用选品池join各路召回数据得到业务选品的多路召回数据。最后加业务粗排模型进行粗选过滤。为提升业务效果，允许运营自定义召回数据替换默认召回数据。
排序平台设计：根据需求的不同分为统计排序和模型排序。统计排序常用在商品数较少的非个性化业务场，包括价格排序、销量排序、轮播排序等。模型排序因场景业务不同，模型优化目标不同。视频业务以播放时长和播放完成度为优化目标，新闻业务以ctr为优化目标，电商业务以ctr、cvr、客单价为优化目标，活动预热期以ctr为目标，活动当天以cvr为目标。大型场景一般会综合考虑，比如ctr*cvr*客单价最为最终排序得分。无论是传统模型、深度模型，还是多目标优化模型，都需要综合考虑业务特点、数据特点和模型收益来完成模型选型。没有最好的模型，只有最合适的模型。在平台提供全网通用模型，并允许业务方自行替换业务定制模型。
后处理平台设计：后处理有定坑需求和疲劳度控制。定坑是在指定坑位投放指定商品完成流量保量。疲劳度控制用于生态构建。通过曝光降权、曝光过滤、品牌打散、类目打散、店铺打散等方式来提升用户体验。常用的方法包括滑动窗口打散、固定窗口打散、KL散度打散，也包括YouTube等公司的模型特征降权方法等。
干预平台设计：干预平台决定场景的安全稳定，用于对推荐结果的实时干预。常用的方法有基于标题关键词的删除和基于id的删除。干预平台只保证指定商品不外显，但依旧会存在商品池中，需要每日在离线数据中将干预平台的数据彻底删除掉。
前端展示设计：以电商为例，常见的展示形式有单列feed流、双列feed流、楼层一带多、纯店铺展示、纯平台展示等各种形式。但都是以商品为推荐对象，最终将商品映射回店铺或者品牌。在我做过的店铺推荐业务中，如果以店铺为最小推荐粒度，效果远不如先推商品后推店铺。这前端展示设计中，只需要枚举出常用的展示样式，用一个转换插件完成不同外显形式的转换。
二、推荐评估指标整理
2.1 模型评估指标
准确率预估 accuracy：正确分类样本数 / 总样本数。将推荐问题看做点击率预估rating的分类问题。但样本类比不均衡时，占比大的类别是影响准确率率主要因素。
P-R曲线：将推荐看做rank操作，把推荐结果看做推荐序列。采用TopN排序结果的准确率Precision@N和召回率Recall@N来衡量排序模型性能。用P-R曲线更全面反映模型好坏，与P-R曲线相对应的是ROC曲线，当正负样本比例发生变化时，P-R曲线会发生明显的变化，但ROC曲线形状基本不变。因此ROC曲线能尽量降低不同测试集带来的干扰，客观衡量模型本身的性能，广泛用于排序、推荐、广告。P-R曲线更多看模型在特定数据集上的表现，更直观反映其性能。
ROC曲线：直接评估推荐序列的离线指标，纵轴真阳性率，横轴假阳性率。ROC曲线下面积就是AUC，是最常用的离线模型评估指标，没有之一。
均方根误差(RMSE)：ctr预估样本为正样本的概率，使用RMSE进行评估。RMSE反映的是回归模型预测值与真实值的偏离程度，但易受到个别离群点影响，鲁棒性更强的指标有平均绝对百分比误差(MAPE)，相当于对每个点做了归一化处理，降低个别离群点对绝对误差的影响。
对数损失LogLoss：将ctr预估看做二分类问题，LogLoss直观反映模型损失函数变化，适用于观察模型收敛情况。
平均精度均值(mAP)：对平均精度AP的再平均。对每个用户进行样本排序，先对每个用户计算一个AP值，再对所有用户的AP值进行平均，得到mAP值。mAP不同于P-R曲线和ROC曲线，mAP对每个用户样本进行分用户排序，而P-R曲线和ROC曲线对全量样本进行排序。
需注意：离线评估的目的是快速定位问题，快速排出不可能的思路，为线上评估找到靠谱的候选者。因此根据业务场景选择2-4个有代表性的离线指标，进行高效的离线实验才是离线评估的正确打开方式。
2.2 内容评估指标
用户满意度：主要通过问卷调查得到。
覆盖率：考察挖掘长尾商品能力，是推荐出商品数占总商品数的比例。可以用信息熵或基尼指数来定量定义覆盖度指标。一定程度上可以衡量系统对展示疲劳度控制的好坏。
多样性：描述推荐物品之间的两两不相似性。物品之间相似性度量有多种方法。需要注意的是度量方式尽量满足距离定义：正定性、对称性、三角不等性。
新颖性：利用商品的平均流行度来计算，越冷门商品新颖性越好。新颖性度量可以反映对用户疲劳度的控制好坏。
惊喜性：推荐结果与用户历史兴趣不相似，但让用户感觉满意，即推荐结果的惊喜性高。目前还没有明确的公式进行定义。
实时性：包括根据用户的实时行为改变推荐结果，和将新商品推荐给用户。对于第一点，系统具备实时获取用户行为商品的能力，再结合item2item矩阵即可。对于第二点，涉及新商品冷启，常用的冷启策略、探索和利用机制、Embeding方法的EGES，深度强化网络DRN框架中的DQN网络可以在一定程度上解决新商品推荐问题。
健壮性：更多是代码的健壮性，代码质量、空结果率、响应时间rt、单机qps等。合理设计离线存储格式可以降低IO耗时和存储空间，熟练掌握在线框架能将推荐系统设计极致，合理的机器分配保障集群安全和分发效率，基于业务场景的在线方案设计保证方案简洁而有效。所有这些都是在对工具栈熟悉和业务理解到位的基础上进行的。
2.3 业务评估指标
(结合近几年工作总结整理)
推荐技术作为完成kpi的抓手，对不同业务场采用不同业务指标衡量收益。在prd评审中业务指标可归纳为总体指标、点击率指标(新闻、电商关注)、转化率指标(电商关注)、金额指标(电商关注)、失效率指标(上线关注)、消费度指标(视频、电商、新闻均关注)等，联调上线前后还会特别关注系统指标。工作中不能过于迷恋指标，也不是指标越多越好，最重要的是从用户的角度体验业务产品，判断推荐结果是否符合业务规划的初衷。
§ 2.3.1 总体指标
日活DAU：单日活跃用户数，最反映用户喜好，是业务的终极目标，但受多因素影响不易算法建模。
访问次数：算法侧被调度次数，与场景位置和app用户数有关。访问次数多则对方案和工程要求高。可用qps进行衡量，活动场景qps达10w以上，需做好熔断和降级处理。
点击次数：一些特殊业务对点击次数比较关注，比如push业务会比较关注点击次数。
浏览深度：电商feeds流的浏览深度与视频的用户播放时长比较相似，体现用户对产品的沉浸程度。很多下滑式场景浏览深度在3屏以内，限制了商品实际曝光机会。加大召回力度可以有效提升浏览深度。
§ 2.3.2 点击率指标(新闻、电商关注)
pv点击率：点击pv/总pv，计算难度低，常作为实时性指标来用。但有些业务存在大幅自然增长/下跌，pvctr不能完全反映阶段性成果。且部分高活用户对pvctr影响很多，在线ab实验需参考Netflix公司的interLeaving+abTest框架，或者AA+AB方式。另外，以ctr为优化目标的模型会有标题党问题和分发头部效应，因此pctr一般不做最终指标使用。
uv点击率：点击uv/总uv，计算难度比pvctr高，但更可靠。反映算法在一段时间内的真实贡献。uvctr在一定程度上体现算法吸引用户的能力，提升难度也较大。
曝光点击率：点击量/曝光次数，适用于上下翻页的feeds流产品，实际计算与pctr有差异。
人均点击次数：点击量/点击uv，体现用户消费深度，有客单价指标、停留时长指标相似。
§ 2.3.3 转化率指标(电商关注)
pv转化率：成交pv/曝光总pv，衡量点击价值，转化率低的业务有下线风险。
uv转化率：成交uv/曝光uv，作用同pv转化率，衡量用户转换，吸引用户消费的能力，是消费宽度指标。
§ 2.3.4 金额指标(电商关注)
客单价：曝光pv/业务总gmv，体现曝光uv价值，客单价从金额方面衡量用户转换能力。在线上排序中，常与点击率、转化率一起综合打分作为商品排序分cvr*cvr*kdj。
支付笔数：单日付款成交交易数，这个指标业务关注度较低。
支付金额：单日真实成交金额(与gmv对应)，在活动场景比较关注支付金额指标。
直接引导gmv：通过业务场景直接成交的gmv额度。gmv金额是用户下单金额，未必真实成交。一般活动场景的对外口径是gmv金额。
全引导gmv ：用户点击场景内商品后，在当日任何场景购买该商品，都算作该场景的全引导gmv。该指标关注度较少。
§ 2.3.5 失效率指标(上线关注)
失效次数：服务端访问场景没有得到反馈结果的次数。一般在业务联调时失效次数较多，需捞取日志query做问题复现。
失效率：算法空结果次数/算法被访问次数。失效率由多方面原因导致，包括服务端和算法端传参问题，代码中有bug，数据源返回空结果，线上计算超时(单次访问大于200ms)。失效率高的业务场景需修复后上线。需注意在活动业务当日，高峰值qps下失效率可能会突增，此时需要熔断机制+工程降级+模型降级+资源调度多管齐下。
§ 2.3.6 消费度指标(视频、电商、新闻均关注)
留存率：多日后仍活跃用户数/多日前用户数，体现场景把用户留下来的能力。留存率和日活DAU一样都是业务最重要的指标。但由于统计周期长，影响因素多，因此不易作为算法建模目标。
停留(播放)时长：视频类业务最核心的衡量指标。当ctr作为优化目标存在通过标题党和劲爆图欺骗点击的漏洞。播放时长是业务模型更真实可靠的优化目标，YouTube等公司在2016年论文中将播放时长作为深度学习优化目标。各视频网站也将增加用户播放时长最为终极目标。工业界场景点击率ctr和播放时长ts做联合优化，方法有样本加权、label加权、基于Embedding的多目标融合等。
播放完成率：播放时长/视频时长。停留(播放)时长指标对长视频有偏，可辅助参照播放完成率。需注意播放完成率指标对短视频有偏，因此需要2-4个指标综合衡量业务效果。
§ 2.3.7 系统指标
响应时间rt：接到服务端query到返回推荐结果的时间，即单次访问平均时长。重要业务一般控制在200ms以内，活动场景控制在80ms~120ms以内。可以通过代码优化、代码优化和方案降级来降低rt，但并不是rt越小越好，需在分发效果和rt之间做权衡。
空结果率：算法方案没有返回结果的比例。如果没有前端静态数据兜底，空结果会导致业务空白页，属于重大事故。导致空结果有代码问题有逻辑问题，还可能是资源问题。唯有捞取日志复现bug。
单机qps：做业务资源预估时，峰值qps/单机qps为场景机器资源数。单机qps通过压测得出。代码优化和方案降级可提升单机qps，在集群升级资源也能提升单机qps。
集群cpu使用率和load数：业务场景部署集群分为独立集群和长尾集群。大业务单独部署独立集群，中小规模业务共用长尾集群。长尾集群的部署需要着重考虑业务部署位置和业务峰值qps时间点。对于业务部署位置，避免业务内存泄露压垮首页场景的故障。尽量将相同峰值qps时间点的业务放在不同长尾集群中，降低集群峰值qps下机器数量。一般集群cpu使用率超过50%，load大于4的时候就需要往集群调度机器。
三、总结
不谋全局者，不足谋一域。只有有了全局才能在管理“一域”时找到最佳的解决方案，做到真正的全局最优。
从用户的角度思考业务，理解业务场景，熟悉数据特点。制定合理的策略并根据业务所处阶段和资源配比构建最合适的模型。从推荐业务收益的角度看，优化收益从高到低为召回、特征、数据、算法、样式、工程。只有多方共同发力才能共同提升一个业务场景的整体效果，并要从不同考察角度选择多个指标综合评估业务效果。