推荐系统
intro
问题：given context, user, return item list，
目标是用户的留存，时长
如何解决：直接建模留存是困难的，影响因素不明确；改成对直接的目标建模，ctr，cvr；
发展历程：
- 模型能力的提高，（auc，uauc，rigloss，预估更准确）
- 另一方面在考虑如果优化留存：探索/利用，item 冷启动，多样性，多目标融合，
- 还有一些工程问题，在线系统要求的高吞吐低延迟（大量kv存储）、模型online learning （训练数据，机器学习平台）
解决方案&要点细节：
- 召回/粗排/排序
- 冷启动
- 多样性，模型和规则：判断什么是正确的方法，模型可以对什么建模，如果基于某目的不追求全局最优，才会加规则，比如打压低龄/低俗
模型视角：模型结构，特征工程，训练数据，训练，预估，（系统，不属于我的部分）
排序
从规则到机器学习，个性化排序，ctr模型；
模型演化：lr -> fm/ffm -> dnn -> wide&deep / deep fm, 多塔结构
object != ctr，标题党/引诱评论/... badcase，多目标做到极致（～20），分别建模，融合，（早期有label reweight方法，引入有人为规则，损失模型预估label可解释性，没有推广）；
ctr -> ctr * staytime / cvr -> multi object + unitility
1）模型结构
ctr 为例
模型
lr：模型能力依赖特征工程（session/profile/recent-item，dense+sparse，bias：style/time/model/），问题是交叉特征稀疏性
fmm：embeding 可以共享，记住历史行为；预估高效，相比lr 性能提升很大
+nn：nn ：nn， 其实也不深 3层，->1024 -> 128
更多算力更好的效果，边际收益，roi 机器/收益
2）多目标融合- cvr模型
问题：cvr label 更稀疏（正例 5% -> 0.01%)，简单实用ctr相同的模型，训练数据更少，可能不收敛
下采样效果无损，也不会提高，可以加快训练速度；cvr模型通常过滤click!=1的样本，假设全样本和点击后样本分布一致，训练数据更小，模型更小，加快速度，使用impr做负例没有收益；
最新的方案是，multitask，共享参数/数据 增加泛化能力，避免互相干扰，几种尝试：
- share id embeding / fm prod / bottom nn，要求目标一致
- mmoe，底部nn完全共享 * gate，
- tutor/student， 共享给student但是student的loss 不要回传给tutor；totuor可以很简单 但是能看到更多的数据；不限制任何模型结构，通用思路
- trick： 直接取大模型的user embeding 做特征，应用于小场景，不考虑数据泄漏等，效果就是有提升；
（模型过多的还会带来工程问题：模型裁剪，减少冗余特征/减少embeding，这里没有细看）
3）多目标融合 - 超参
对整体的价值需要仔细评估，推荐系统很复杂，可能存在aa效应，pgc/ugc，内容生产/消费，
一定以留存为最终判断；多目标存在兑换关系，需要经验+信仰；
如何做准指标很有学问，以数据驱动，相信统计，置信度/置信区间，指标敏感
如何融合（不同目标的值域不同，没有直接目标，调整便利性，超参数可解释性）
- \sum ( bias + beta * score)^alpha， 最大值影响
- \prod (bias + beta * score)^alpha，最小值影响
离线自动搜索超参数 todo：
在线自动搜参数
原始都是手动做online abtest实验，效率比较低，不可能对大量超参调整， black-box optimal problem，
grid search, random search, bayesian opt, pso...； 探索性的决定搜索参数
google vizier，模仿开源实现，
另一方面，离线调优算法，契合推荐场景用uauc衡量，准确性更好，来源不清晰；
冷启动
user 冷启动：泛化特征有效，user_id 没有作用，偏向全局热，没有个性化；online learning 下快速反馈，不需要做什么额外工作，系统自然就可以完成 | 少打扰/广告
item 冷启动：item_id，如何和热门内容排序出来，需要被优待，
目标是保量成功率+不同vv分层占比 + 减少impr 影响（线上ab实验监控消费测指标）；
工程问题较多，count要准确，避免超保，推荐流量很大；
方法的几个阶段：
随机：随机挑选一个
boost ：
精细化多阶段：差异阈值、 pid 动态控制boost、低 vv boost
todo：
损失更精细，
保量对系统影响，消费测/作者侧，
基于关注关系/内容理解，
召回
问题：从item亿量级挑出几千个候选，耗时 ～100ms；性能要求高，个性化、多样性，和排序模型场景有差异；
演化：
- 各式各样的热度/topic倒排，item-based 协同过滤（缺点，更新慢，冷启动，相似度衡量、稀疏、准确性低），已经被模型击败，再也不要在召回规则上浪费时间；
- 模型方法：model embeding + tree serving，
背景：
简言之，2016左右，排序模型从lr->fm/ffm，性能提升巨大；
lr （w' * x, sigmoid loss) 模型简单，拟合能力依赖特征工程，sparse id 特征空间巨大，dense feature， dense-id combine 过于稀疏，比如user_id-topic，dense-dense 还是有用的，已经能做ctr预估了；
fm && ffm，特征对应隐向量/embeding，然后内积，w' x + \sum \sum v_i * v_j，和推荐场景很match，item id有大量展现，有协同能力，user_id有记忆能力；
从ffm到召回：
user_id, item_id的fm，或者以user, item, context 3 field-fm，都可以改写成内积的形式，可以完美的应用在召回场景：ffm模型得到embeding向量，每次请求从item list里面取内积最大的top k；
关键：从诞生到成功
- 模型训练样本选择，以ctr为例，如果impr 做负例，clic做正例，效果不好，第一版上线是真实正例 + 负例从正例池随机采样，原因：select sample bias，impr 负例也是优秀的，只从impr数据train，无法在广大的候选中 挑出top，需要对广大候选有判断能力；打压热门，增加个性化，也存疑。后来演化为20%真实负例 + 80%随机采样，真实负例可以增加模型拟合能力；
- 工程实现：预先load item embeding，构建fast ball tree 加速query approximate top-k nearest neighbor；
更多发散：
- req user_id 置0，减少个性化，增加全局热，用作新用户冷启动；
- ball tree实际上对item做聚类，可以做有意思的工作； req user_id 置item_id，召回结果是相似item，使得动作反馈更及时，比如点赞了美女视频会立刻召回多个美女；
- user/context/group 简单做是对特征做sum pooling，可以由embeding+nn 产生；
- 多路召回，一个模型不能搞定搞定所有，类似排序的多目标；
业界
- dnn for youtube recommend，架构+技术类似；
- alibaba tdm，提高模型性能，复杂模型，头条没有测出效果；
Q：
- ball tree/ fast ball tree，手写一遍，体会他的好处，以及是否有其他数据结构，覆盖率？
- embeding，上面解释来自推荐系统的ffm，其实nn也可以；了解下在nlp 有更多应用，word2vec 的negative sample技巧，避免求softmax更新太多项，采样负例只更新这一部分。
- 如何离线评估召回性能，
