推荐系统概述
推荐的目标：是否点击（1，0）
y=model(user,item,context)
做推荐一个基本点：货找人
pgc，ugc
user：喜好，兴趣，标签
context：地点，ip，时间
监督模型：lr，gbdt，xbg，dnn，fm，ffm，deepfm，deep cross net，wide and deep
y：label 点击和未点击
针对短视频可以抽取哪些特征？
排序（learn to rank）：
点击率（预估一个item被点击的概率）预估能不能构成整个的推荐算法架构？（不）
1、item：统计特征（最重要的特征）
2、内容特征：title，标签，视频内容
3、用户特征：统计特征，用户的浏览点击记录，用户的本身的属性
因为从货出发，短视频每天新增1000万，咨询货每天新增1亿
latency超过0.1s，影响用户体验
精排（learn to rank）：y=model(user,item,context) 个性化排序模型
粗排：y=model(item,context)（粗排可以不要）
整体流程：召回-->“粗排”-->精排（直接产出topn<20以内>截断）
所以！！！
召回（平衡资源和效率）：
类似于一个字典dict()，key：value
cf（协同过滤的all），DNN，embedding -> i2i,u2u,u2i,tag2i,city2i,category2i [key:value] 召回分支
（只是key在更新，value不更新，用户更新的历史是key==item，key改了那么value就改了，每次召回的就不一样了？？？）
召回：多类型key的字典（工作目标 设计召回分支、设计召回算法，优化召回算法）
召回方法：多个分支召回后经过人工选定的阈值截断top1000，去重1000个候选送给排序模型进行排序。
召回的数据存在内存里~
最终检测结果：实验流量的点击率有没有涨！
i2i：item与item之间的相似度
feed流如何捕获实时信息？点击一个item，item通过埋点？传回服务器，服务器根据userid记录在服务器上，下次来请求的时候会根据item来查i2i的字典。
什么是feed流？产品形态，持续更新把推荐item聚合在一起，呈现给用户的无限下滑的信息流产品。
数据从哪里来？
数据从日志来（log）
log的具体线上链路是什么（log从哪里来）？（工程同学做）
app客户点埋点-->用户产生相应的点击，浏览，点赞，评论-->回传服务器-->通过管道工具kalfka，无延迟的上传到实时计算集群（storm）-->将用户行为进行label拼接，形成 log，然后根据数据进行建模。
rerank：规则打散，业务逻辑。
通过model优化选出top30，不是展现给用户的。因为model无法区分返回的候选之间的类别的。
强插而已！！！多样性靠打散逻辑保证
冷启动：
（3拿不到的）
长尾推荐？？
隐式负反馈：不能重复是第一层逻辑，第一次没点代表不感兴趣是第二层逻辑，统计特征最重要。
推荐系统评估
常用评估指标
当我们形式化为一个算法，基本都是auc。
- 实时学习是1h内的，不会一条一条的，来一条样本就算下梯度，真正的在线是不work的，因为抖动比较大。
回顾match和rank
- 定义：match基于当前user（profile、history）和context，快速在全库里找到topn最相关的item，给rank来做小范围综合多目标最大化。
- 通常做法：通常情况下，用各种算法做召回，比如user/item/model-based cf，content-based，demographic-based，DNN-embedding-based等等，做粗排之后交由后面的rank层做更精细的排序，最终展现topn item。
Recsys
疑问：转化率
作业
统计每列去重后的数量
cut -d ',' -f 1 data_1.csv | sort | uniq | wc -l
