理解推荐的三个层次, 理解工业界推荐系统，需要依次理解到如下三个层次
1.解放人力
2.聚焦目标
3.平衡体验
推荐系统不仅是一种流量的遥控器，从产品角度来看, 平衡平台方的业务目标和用户的用户体验十分重要.
综上, 推荐系统可被拆分为两件事情:
1.确立一种分发的机制
2.基于设计好的分发机制，相依地调整体验平衡机制
搜索 v.s. 推荐 v.s. 广告
三者在业务目标, 技术实现上有如下差异
召回 Match
召回决定了推荐系统效果的天花板, 召回的目标是丰富且有效, 召回环节质量过低则排序无从谈起 值得注意的是, 召回的结果是丰富和有效之间的一种trade off.
丰富: 丰富有两个层面的目标
1.召回宽度, 算法”见世面”的能力.
2.召回深度, 算法”以点带面”的能力.
有效: 在保证丰富性的情况下, 相关性不能太低
召回的层次与融合: 召回结果的相关性和发现性是另一对需要被平衡的trade off.
相关性： U2I >= U2I2I >= U2X2I/other
新颖性/发现性: U2X2I/other >= U2I2I >= U2I
item-based CF的四宗罪和不放弃它的原因
原始的item-based CF存在以下问题
1.聚集性: 哈利波特天天见, 建模物品相关关系时, 向热门商品或者具有高频行为的用户聚集, 故需要显示地进行热门物品或者热门用户的打压.
2.无向性: 从你到我 != 从我到你. co-currence建模不具备方向性, 因此对任意关系统计, 两个item之间的作用相等，但在实际业务中往往物品体系之间存在一定逻辑结构. 例如存在推荐结果: trigger: “iphone12” => rec_result: “iphone12手机壳”
3.有偏性: 存在即合理，不存在就不合理? 实际业务中存在较多的
4.失准性: 脑洞
不放弃 item-CF 的原因
1.co-currence 始终是一种朴素而有效关系建模方式, 具备实现简单服务效率高的特点(离线索引), 众多实验证明swing等改进版item-CF是一个不错的Baseline.
2.item-CF 优化最佳实践: 其公式如下
排序 Rank
排序战略地位: 排序在整个推荐链路处于倒数第二个阶段，在召回侧足够丰富且有效的情况下，排序侧是直面用户的最重要的阶段. 排序公式设计原则:
1.对齐业务目标
2.足够简单
3.权值化
CTR 预估的核心问题
Feature Interaction
1.特征交互（特征交叉）是提升CTR预估准度的关键问题. 从建模方式上常见分两种: GBDT 和 DNN (详情对比见), 简言之
2.GBDT: 依赖人工特征抽取, 但在数据量不过大, id 类 dim 不太高的 Tabular Data 场景具备很强的 Fit 能力和一定的解释性
3.DNN: 通过 NN 自动捕捉 Feature Interaction, 且具备 generalization 能力. 对于 Feature Interaction 的优化主要是通过不同的网络设计实现 (FM, Attention), 研究见下图
Sparsity
稀疏性和场景紧密相关.
Sequence Modeling
序列建模主要对时序信息进行单独建模, 但个人认为序列建模适用场景有限，偏向于Session Based推荐场景, 即具备显著如下特点
Local Activation (局部激活): 在预估时，Sequence item和Target item之间具备较强的相关性. 因此对于用户相对独立的, 离散的或者跨时间较长的范围甚至有负向作用.
CVR预估的三大挑战
1.Sample Sparsity 样本稀疏性
2.Sample Selection Bias 样本选择偏差
3.Delay FeedBack 延迟反馈
多任务/多目标学习 Multi-Task/Multi-Objective
相关性
冷启动 Cold Start
质量保证 Quality
核心项目必须指定唯一PM
唯一PM对所有线上问题负责，必须熟悉项目背景和方案实现细节, 时刻把控项目迭代过程中的维护CheckList
CheckList维护
为什么CheckList? 质量保证的作用在于: 去除软件系统对于“工程师对于质量的细心程度和对于系统的熟悉程度”依赖, 换句话说: 通过检查机制实现项目质量, 永远不依赖工程师的”意识”, “责任感”, “经验”或者”细心习惯”检查问题
CheckList 的迭代过程: 从需求文档开始构建 v1.0 版本 CheckList, 测试开始之前进行更新，直到上线前持续更新
CheckList 样例模板(更新中…)
| id | Check项 | 负责人 | 实现方法 | latest check time |
|---|---|---|---|---|
| 1 | 过滤虚拟类目商品 | 张三 | 1.投放禁用虚拟类目配置id:9527 2.实时召回过滤逻辑,code:http://git@gitlab.com | 2020-10-10-15:30 |
| 2 | 过滤预售商品 | 李四 | 1.投放禁用预售配置id:9528 2.实时召回过滤逻辑,code:http://git@gitlab.com | 2020-10-10-16:30 |
| 3 | 过滤黑名单商品 | 李四 | 1.投放禁用黑名单配置id:9529 2.实时召回过滤逻辑,code:http://git@gitlab.com | 2020-10-10-16:50 |
足够及时的Review
Review 的进行间不能超过 3 天，一般为线上问题发生当天之后第二天最合适. 当天或当天后一天需要专注于处理线上问题保证问题第一时间得到解决，及时当天问题得到解决，也需要给工程师一个缓冲的时间冷静下来思考为什么会产生这样的原因.
Review 先要对问题进行分类，是在哪个环节出了问题？在测试过程中哪个环节没有测试到?
转载请注明来源, from goldandrabbit.github.io
