推荐系统学习记录一

推荐的目的是啥:

推荐能给公司带来什么：

target：

带来点击（1,0），点击1，未点击0
y=model(user,item,context)
做推荐，一个基本点，货找人。
货：pgc， ugc
user：喜好，兴趣，标签
context：地点，ip，时间

模型：

使用监督模型：LR，GBDT, XGB, DNN, FM,FFM, DeepFM，
deep cross net，wide and deep
y: label
点击和未点击
example：针对短视频我们能抽取到哪些特征？
1.统计特征——最重要的特征
2.内容特征：title、标签、视频内容
3.用户特征：统计特征、用户的点击浏览记录，用户本身的属性（性别，年龄，号段（归属地）…）这个模型即为排序。
精排（learn to rank）：y=model(user,item,context)
粗排： y=model(item,context)
上述过程的点击率预估能否构成整个的推荐算法架构？
不能
从货的角度出发
短视频，假设每天新增加1000万
资讯，假设每天新增1亿
系统能不能撑住？
系统返回时间大于 0.1s，用户就会有感知，即latency>0.1s 将极大的影响用户体验 因此只有一个排序是不够的，由此衍生出召回。

召回：

推荐系统不是一定需要召回，召回的的主要目的是当我们面对百万级，千万级，甚至亿级候选样本的时候，我们模型的计算开销会很大，召回的作用是去平衡计算资源和推荐效率。
流程：召回——>“粗排”——>精排
粗排可以不要，因为精排包含粗排，直接产出top N 截断 n(20以内)
召回相当于数据结构里的 dict{}
cf，协同过滤（包含dnn）一系列的算法产生召回分支，算法产出的是 ->i to i、u to u、u to i，tag to i，city to i，category to i:item [key;value]
召回组的负责设计召回分支，设计召回算法，优化召回算法
召回：多类型key的字典
召回方法：多个分支召回后经过人工选定的截断top 例如1000（注每个召回分支产生一部分的item，单个召回分支内部产生的结果需要排序，不同召回分支之间是不需要排序的），去重后1000个候选送给排序模型进行排序
数据从哪里来？
数据从日志中来，日志 log
log的具体线上链路是什么？
以APP为例
app的客户端埋点->用户产生相应的点击，浏览，点赞，评论—>
回传服务器—>通过kalfka管道工具，无延迟的上传到实时的计算集群（storm）—>进行label拼接，形成log
然后我们根据数据建模。
精排之后是不是top N?
这里有一个rerank
rerank：实际业务场景有规则打散，业务逻辑，与算法关系不大。