推荐系统的整体流程架构解读

首先去加深对你的数据进行一个宏观的理解，人为的找出一词多义的词语

人为的找出这个一词多义的词语，找到词的各个的语义找出所对应的上下文

eg

一词多义、

苹果（水果）

苹果（手机）

按业务去写规则

对文本进行相关的替换

根据上下文，把和这个词的相关的数据进行一定程度上的进行一个处理，之后当我们的语料处理完成之后，就会产生word2vec

根据这个苹果的一个词就把这个词处理成为了相关的两个词

苹果1====高科技，乔布斯

苹果2====葡萄，西瓜

花一部分的成本去处理一部分的数据

多词一种意思

电脑，计算机====可以都去映射成为一个字符串

把多个词语简单化成为一个单词

特殊的场景，语料很少的场景

约定俗成的规则性本身很长的场景

时间要求是十分紧迫的场景

这个就是我们要去对这业务十分的熟悉

规则是快速开发的场景

当我们快速上线的时候，我们可以去使用比较多的规则

规则就像是一个补丁

衣服偶尔烂洞了，那么我们就可以去打一个相关的补丁，

但是如果这个衣服遍地都是补丁的时候，这个时候就是会出现问题的，我们的补丁越多，对于之后的开发场景就要去不断地修改

这样的话我们就很难根据场景进行相关的变化

这样我们就会考虑换一件新的衣服

进行新的机器学习，方便我们之后的程序不断地进行

整体的思想：用周边的词去预测这个中心词（CBOW），也可以去中心词预测周边词，（skip-gram）

把输入词的向量按位去累加成为这个一个向量

训练之前，我们的每一个词向量都是随机初始化的

用相加之后的向量对目标词进行相关的预测

预测的时候，以为我们的类别过多，导致了我们不可以直接去使用这个softmax，而是因此我们使用huffman树或者是ns

网络训练的时候，包括输入，即每个词对应的词向量

这最终的真正的使用的是，输入中，每个词对应的向量

然而整个的模型几乎是不去拿来使用的，所以说这个huffman或者是这个ns只是在训练的时候需要去使用

类别过多的时候，我们是不可以去使用这个softmax

训练完成之后

最直接的应用：就是每个词对应的一个词向量，可以去用来要求词之间的距离

目前来说，这个互联网行业，把应用扩大了极大的拓展，特别是在相关的推系统中的

Word2vec的实现的工具有很多

1.谷歌原生

2.Gensim

3.facebook python实现  比较少消耗内存的

数据之间是解耦的时候，这个我们是可以使用spark的

谷歌原生中是存在多个多线程的

推荐系统

计算机的出现是要去解决这个信息的相关的存储的问题

互联网的出现就是解决了这个信息的传播的问题

传统的互联网中：信息生产者是十分的少的，大部分都是信息的相关的消费者的

网民寻找信息之后：

yahoo，信息分类网站

之后出现了信息的相关的搜索引擎

Google，百度，满足这个用户在海量的数据信息中主动地去寻找相关的信息

移动互联网出现的时代

在自媒体出现了之后，信息的相关的生产者越来越多，信息剧增，用户对信息是茫然的

推荐系统就是去处理信息过载的相关问题

信息：

各种电商，小视频，新闻

||
||
||
内容的分发系统（将这个信息和人进行相关的连接）（个性化）

||

||

||

使用者：

海量的用户

推荐系统的架构是什么样子的呢

数据源：用户上传UGC

        权威的媒体的生产PGC

进行相关的内容的审核（各种不正规的相关的产品）

不使用机器学习，就是要去使用这个关键词匹配（关键词漏洞），人工审核（成本极高）

内容的理解

对于内容的关键词进行匹配

对于内容进行理解，对于内容进行相关的理解

没有机器学习就是要去进行依赖这个用户进行标题的自己进行相关的上传，和人工的审核

用户难以去理解这个原本的本意，会去用错相关的分类

还会存在这个凑热点的问题，出现了相关的虚假的信息

内容的分发：

召回：从圈梁的数据之中，找到相应的数据候选集

从百万级到百级，从全量的数据之中找到相对的小的候选集

没有机器学习，就是要去根据地点，或者是一些相关的消费习惯
 

排序

把召回的相关的信息按照一定的规则去进行相关的排序打分，推荐出来用户最感兴趣的几条信息

按照热度进行排序，时间，和运维人员认识的最好的

效果是很难去达到准确的，而且会存在这个人力的成本是极高的

养了一个庞大的团队

在这个地方这个机器学习和深度学习就发挥了相关的强大的相关的作用

spark是搞不了这个深度学习的

我们最佳重要的是要去搭服务的

有机器学习的相关的程序下是怎么处理的呢？

内容审核就是一个相关的分类的系统，将数据进行一个多分类的情况，

使用机器学习不再是内容之间进行相关的检索，而是把这个相关的内容进行相关的分类

文本分类的合格之后：

对于这个时效性较强的内容之中，运营之后即审核进行相关的通过，在这个机器学习的相关的领域之中，我们也要去明白这个文本之间也是具有文本信息处理相关的快慢之分的

对于相关的热点信息，这个机器学习也是会去区分出来，之后就会把这个相关的信息进行分类进行相关的处理，把热点信息去优先的进行处理

之后我们在会把这个时效性不是很强的相关的内容，机器学习审核之后，会去先小批量的分发，之后如果没有人进行相关的举报，再去全流量进行相关的分发，整个过程中是只会存在这抽查这个相关的过程的，而不是回想这个热点性极高的信息一样全面进行检查

分类系统中也会存着着多级分类

文本分类的相关特征就是进行一些关键词的进行提取、

标题加这个新闻类的相关的首段

召回机器学习

协同过滤：

有三个人，是存在这很多的相关性的

基于内容的召回

用多路召回的原因

每一类的召回都是存在着自身的相关的缺陷的，行为类召回对新用户，新产品是表现的比较的差的，甚至是没有办法去做的

内容类的相关的召回

1.信息茧房

2，视频类的一些内容是做内容理解的成本是比较的高的，或者是一些相关的商品

几乎是没有标签的，我们是要把各种的相关的信息都要去拿回来的

召回是在准确和数量上进行一个相关的平衡的

内容进行相关的排序

曝光过滤，看见的东西进行一个相关的过滤、

内容的特征，用户的画像

把这两个相关的特征进行一个结合，进行训练出来一个模型

每一个内容都可以去得到一个相关的分数

在深度学习出来之前大量的使用这个逻辑回归lr，在深度学习出来之后，有部分去采用这个深度学习

点击率预估是十分的消耗相关的资源的，有些公司知道这个点击率好，深度学习好，但是真的用不起

排序这个运算量是十分的大的

点击率预估只能去动态的计算

我们事先是无法提前计算这个用户去点击哪一个的

召回：

量大，相对的粗糙，可以离线进行计算

排序

实时进行相应

lr算的很快

dl算的相对是比较的慢的

一般来说，在成熟的推荐的系统来说

重点的品类就是以人工运营为主，机器学习为辅助

一般品类，大量的机器学习推荐

事实取决于架构判断

spark：

每天会产生相关的大量的日志

用户的曝光点击日志

spark,Hadoop之类的大数据系统一般用来这个对日志进行相关的统计，生成各种的报表，提供产品，运营观看

对数据进行相关的清理，整理成为想要的数据的相关的形式的

提供这个机器学习进行讲过的训练

hive+spark