推荐系统技术文档,详细的新闻客户端推荐系统技术文档

目录

第一章          综述......................................................................................... 1

1.1         项目背景............................................................................... 1

1.2         应用场景............................................................................... 1

第二章          总体架构............................................................................... 3

2.1         算法概述............................................................................... 3

2.2         主要问题............................................................................... 6

第三章          推荐算法............................................................................... 8

3.1         相似新闻推荐...................................................................... 8

3.2         用户画像推荐.................................................................... 10

3.3         协同过滤推荐.................................................................... 12

第四章          总结回顾............................................................................. 15

第五章          附录:.................................................................................. 17


 

第一章       综述

1.1       项目背景

在过去传统的门户网站、互联网产品等领域,存在基于编辑或者运营人员手动进行配置推送的信息推送,但这样的方式效率低下,推荐效果有待商榷。随着互联网对大数据、算法模型的进一步应用,逐渐有算法机器替代人工进行推荐,并且达到诸如“千人千面”、“个性化”推荐的效果。

基于大数据的推荐系统,核心是基于基础数据+算法模型+计算过程的技术流程,旨在帮助用户解决在海量信息中、目的不是很明确的情况,快速获取信息、主动筛选信息的痛点,以此来提升用户的进一步转化。其中,最核心的问题是要推的准、推的及时、推的恰到好处,否则就是反作用(信息冗余,客户逆反心理)。

1.2       应用场景

很多耳熟能详的推荐算法,解决的往往某种特定情况下的推荐机制问题,一般情况下,一个完整的推荐系统应该是复合了多种推荐算法,相互补充、相互完善,综合来说,各种理论逻辑、算法机制是构建推荐系统的核心支撑。

在新闻推荐的时候,我们不仅要根据读者兴趣进行个性化推荐,同时需要考虑到兴趣的迁移、兴趣的提升,不能完全被兴趣羁绊,在算法设计上就要打破这样的桎梏,在兴趣的周围做一些尝试,更要兼顾热点新闻,当然,热点新闻可能与兴趣关系不大,综合考虑多种场景,这样才可能 是一个比较完善的新闻推荐系统。

故此,在客户端我们可以简单的做这样的设计,看过这篇文章的人还看了、猜你喜欢、为你推荐等等这样的场景。

第二章       总体架构

     

LLaMa lora权重文件如何合并_数据

 

 

2.1       算法概述

 

1.   推荐算法概述-基于内容属性相似的推荐

从原始数据依赖的层面来说,常见的有基于内容属性的推荐机制,这种推荐逻辑很简单,只是单纯的依赖物品之间的属性相似来构建推荐关系,容易理解,有些场景中是有一定效果的,但实际上很多时候会存在这几种情况,导致了这种原始推荐失效。

u  如果用户浏览当前的新闻本身就不是用户的菜,甚至是一个非优质信息(当前主体不可控),再基于当前物品进行推荐就是个伪命题。

u  基于上面这条,即使当前主体是用户的目标,但再推类似主体会造成信息冗余,即当前主体信息已经解决了用户的问题。

所以,由于用户行为的不可控,基于内容属性相似的推荐,风险还是挺高的,这是导致了这种原始直接的机制并不会得到广泛的推广。但与乱推荐相比,还是有一定正向作用的,毕竟用户浏览的主体是自身选择的结果,本身用户对于其选择的信息主体是有一定偏好性的

2. 推荐算法概述-基于用户画像的推荐

基于物品本身属性的推荐,与个性化是没有确定关系,毕竟推荐候选集只跟物品主体有关,与用户行为轨迹无关,严格来说算不了个性化。

而基于用户画像(基于用户标签)的推荐,则更大程度上依赖于用户的画像属性来推荐,这就体现了用户偏好信息,根据偏好信息来选择候选集。

这是一种很通用的做法,并且在大规模数据集情况下,很多实际的产生过程中喜欢使用这种机制。而用户的画像,或者更具体点用户的兴趣标签如何构建呢?其实就是依赖用户累积的行为数据了,通过行为数据生成用户的兴趣标签。

这看似是一种相对靠谱的做法,毕竟如果把用户的爱好都分析清楚了,主动给用户做推荐不就显得很个性化了吗?但在实际的场景中,还是有很多不足之处:

l  首先,并不是所有用户的行为都足够用来表征其兴趣偏好的,即我们会高估用户的行为集合,从而产生有偏差的画像属性,更甚者,如果用户完全没有行为怎么办呢?

l  其次,通常来说,用户的兴趣爱好是会随时间迁移而改变的,所以,把我用户的兴趣程度以及其变化并不是一个容易的事情,更何况用户实际的选择还会受很多因素影响,比如,我当前查找的一个信息并不是我之前掌握的信息,那意味着这些信息偏好在我的历史轨迹中都体现不出来,那单纯的通过我的兴趣去推荐就显得不靠谱了。

但不管怎么说,根据用户的偏好来做推荐,大方向肯定是没有问题的。

3. 推荐算法概述-基于协同过滤的推荐

协同过滤,作为推荐领域典型案例的存在,它不会去研究物品的本身属性,甚至也没有空去构建用户的画像标签,正如他的名字描述的一样,他严重依靠于用户的行为以及其周边用户的协同行为。举个例子,为一个用户推荐信息,那么我只需要参考其周边用户在看什么信息,就给他推荐什么信息就好了。

重点在于,如何限定周边这个范围,比如根据两个用户的行为,去构建相关关系,从而判断用户之间的相似程度,把相似用户的行为推荐给当前用户,这就是协同中典型的基于用户推荐。

而如果以新闻推荐为维度,以用户的浏览记录为向量,则可以构建新闻的相似度量,针对于每一个待推荐选项,用户的历史轨迹就是其向量构成,就可以判断该用户历史的轨迹信息与当前的待选新闻的向量相关度了,从而判断是否要推荐,这就是基于物品的协同逻辑。

与基于用户画像的推荐对比,这种推荐有一定几率可以发现新物品,即并不严格依赖用户的兴趣。举个例子,假设几个信息的层级是ABC,并且ABC是层级递进关系,并不是同一个东西,对于一个用户来说,他掌握的是A,则意味着他的兴趣偏好大多偏向于A,根据兴趣标签,其实是很难推荐这种递进相关的信息。

但是,如果其他用户的学习轨迹都是A->B->C这种轨迹,这意味着ABC三者之间本身就有前后潜在逻辑关系存在的,基于协同,即可为该用户在掌握A的基础上,推荐BC的内容,这也是基于兴趣所做不到的地方。

当前,基于协同行为的推荐,除了基于物品还有基于用户,还有其他诸如基于模型的协同,典型如最近邻模型、基于矩阵分解、以及基于图关系模型的构建的推荐机制。

2.2       主要问题

1. 冷启动问题的解决

所谓冷启动,即在推荐系统初期时,没有任何用户与物品的交集信息,即无用户的行为轨迹,无法通过类似协同或者用户偏好等方式进行推荐,这种时候,我们就称推荐系统处于冷启动状态。

这种情况,我们需要尽快的累积起第一批用户行为轨迹。我们可以通过基于内容的推荐,或者做一些其他类似的操作,快速有效的进行物品推荐。一段时间后,累积到一定的用户行为时,整个系统就能够正常使用协同过滤等方式进行推荐了。

但是,针对于新加入的用户,或者新加入的物品,同样也是出于冷启动状态的,这个时候,我们通过需要对这种物品或者用户做特殊的处理。

除了基于内容属性的推荐,我们还有其他的一些策略用于弥补这种行为数据不足的情况,比如典型的热度模型,推荐热点信息这种行为虽然low,但是从整体的反馈来看,还是有一定效果的,此外,还可以根据一些统计学上的结论,进行基于统计分析结论的推荐。

除此之外,我们也可以通过其他渠道收集用户的数据,比如用户注册的时候所填写的个人资料,这些都是可以作为推荐的原始依赖数据。

2. 马太效应

马太效应或者说长尾效应,即热者愈热,实际举例来说就是,在实际的购买场景中,由于你推荐的次数越多,部分优质的商品购买或者点击的次数就越多,形成的用户购买轨迹就越多,所以得到的推荐机会就越多,进而产生的推荐也越多,变得越热。

随着不断迭代,子子孙孙无穷尽也,这样得到推荐的商品就会集中在少部分商品中,而大部分长尾商品是沉寂的,一个推荐系统如果长时间处于长尾效应中,造成推荐疲劳,其推荐效果就会减弱。

所以,一个好的推荐系统,要考虑到适当的挖掘长尾商品,通过真的个性化,把适当的长尾商品送到真正需要他们的人手里,在实际的操作过程中,我们可以适当的进行热度降权,从而让一些中下层的商品得到更多的曝光机会,当然前提是保证点击率的情况下。

另外一个场景会形成马太效应的是热度模型,即我们的热度榜单,长时间的高居榜首,一定会获得更多的点击,而点击越多其热度越高,但我们的信息是需要保持新鲜度的,不然点击率迟早会下架的。

所以,我们使用一些机制让处于头部的商品或者信息降权,时间衰减是一个比较通用的做法,即随着时间的迁移,其整体热度会不断的下降,至于说下降的方式,速率就看模型的设计了。

第三章       推荐算法

3.1       相似新闻推荐

   

LLaMa lora权重文件如何合并_推荐系统_02

                                     图 整体技术架构

  1. 相似计算的过程

相似的计算有很多算法可以选择,每一种都有各自的特点以及适用的场景。相似计算中使用最多的有欧式距离、余弦相似等,余弦相似也就是余弦夹角可以有效规避个体相同认知中不同程度的差异表现,更注重维度之间的差异,而不注重数值上的差异,而欧式距离则是对个体异常数值会比较敏感。

这意味着,在我们需要区分异常样本时,使用距离计算会更恰当,聚个栗子,比如电商领域中高价值与低价值用户的区分,其实我们核心是想把他们的差异性拉大的,得以体现出对比,这个时候使用余弦就是不合理的。

在回归到距离上说,市面上除了欧式距离,还有好几种距离度量,诸如马氏、曼哈顿距离等等,其实其度量侧重都是不一样的,我们需要结合实际的场景去使用。还有更偏向于相关度量的皮尔森相关系数等。

  1. 计算矩阵过大的问题

按照标准流程,假设有1万条新闻,则对于每条新闻来说,需要与其他新闻计算与其的相似度或者相关度,然后再排个序,取TopN形成自身的待推荐列表。那么,简单的数学题来了10000*10000=10000万次计算,这显然是不合理的。

所以,优化这个过程是必然的。核心思想其实就是初筛,把不同层级把关系不大的直接删掉,省掉计算相似的过程,节省资源。如何筛选?一个比较常见的做法是,寻找核心关键影响因素,保证关键因素的相关性。

比如,在相似新闻推荐过程中,先按照频道进行初筛,已经过滤掉很多数据,然后对目标数据集进行倒排索引,其实已经能把大部分相关度很低的候选集给过滤掉,对于整体计算量级来说,计算复杂度直接下降。

  1. 多影响因子权重权衡(暂时不予考虑)

基于属性计算相似,从整体上来看,其实一般主体都不止一个属性,那么计算相关的时候到底看那个属性呢?或者说哪些属性应该占有更高的权重,哪些因素是次要因素。

比如在电影推荐的过程中,电影标签只是其中的一个维度,其他的还有定影的类别、年代、导演等其他的因子。

回到常规问题,如何确定影响权重是个操作难题。最简单并且实际上还挺有效的一种方式就是专家评判法,即通过权威经验来划定影响因子的权重,还有就是通过标注的样本进行反向拟合每种因素的占比权重。除此之外还有一些其他学术上的方法,包括什么主成分分析法,层次分析法,还有什么熵权法,其实都是找因子影响能力的主次关系。

最终确定好了影响因素,在实际上线回收到数据之后,依然是需要逐步的进行权重影响调整的,我们可以通过结果的样本数据,进行LR的回归拟合,寻找最合适的权重配比。

3.2       用户画像推荐

     

LLaMa lora权重文件如何合并_LLaMa lora权重文件如何合并_03

                               基于用户画像的个性化推荐策略

业务处理的逻辑是,先根据行为数据,抽取用户浏览的新闻,然后根据做浏览的新闻的标签,映射到用户,进行用户画像的构建,最后根据新闻标签结合用户画像为用户进行信息推荐。注意,这里与之前的实例不同的是,我们是基于用户进行推荐的,而上个实例是在浏览某个内容的时候,进行相关内容推荐,这里以及进化到了根据人进行推荐了。

这里要重点介绍标签及其权重的提取:

TF-IDF算法(term frequency–inverse document frequency):TF-IDF是一种统计方法,用以评估一字词对于一个文件集或一个语料库中的其中一份

文件的重要程度。字词的重要性随着它在文件中出现的次数成正比增加,但同时会随着它在语料库中出现的频率成反比下降。

如何理解“字词的重要性”,以及“正比增加”与“反比下降”?

(1)“字词的重要性”:因为查找的是文本的关键词,所以要将文本中最“重要”,或者做最能体现文本内容独特性的那些词语找出来。

(2)“正比增加”:如果一个词在文本中出现的次数越多,那么我们就越有理由认为该词就属于文本的关键词之一。

(3)“反比下降”:但是有些词如“中国”、“社会”、“媒体”等词,可能是在各个新闻里都容易出现的高频率词,针对这样的词,我们就需要以一种方式降低它对于单独文档内容的独特性贡献。即若一个词在整个语料库的所有文档里都有出现,那么在计算单个文档的关键词时,我们就会相应地调整该词属于文档关键词的可能性。

  1. 用户画像注意的问题

基于用户画像的推荐机制在实际操作中,其实还有很多需要考虑的地方,并没有想象中简单。

首先,用户的行为并没有我们想象中靠谱。一方面用户的行为数据,有时候并不是其兴趣特点所表现,这点很显然,比如如果系统把一些信息故意放在很显眼的位置,那么对于一般用户来说,不点也得点了,所以就会造成这种用户数据其实是不那么靠谱的。另一方面是如果用户产生了行为数据,但是行为数据并不足够多,那么这个时候其实这些行为数据是有置信度的考量的,行为数据不够产生的描述是有可能形成偏差的,再根据有偏差的数据去做推荐,那结果只能是更离谱了。

其次,用户兴趣时效性问题,用户的兴趣是有一定时效性的。举个例子,我在一年前浏览新闻的记录,还适合放到现在做我的画像分析吗?不一定的,因为我的兴趣可能已经随时间偏移了,过去我所喜欢的东西,现在我已经不喜欢了。

所以,在一般实际操作的过程中,一定需要分辨用户的兴趣数据的有效性,一般情况下,我们会进行长期兴趣和短期兴趣的区分,人在一定时间内其兴趣是固定的,并且在一些很短暂的时间段内,比如一两天、甚至是一天内,其关注点是有一定意义的,这个时候其短期兴趣就生效了。

所以,我们在实际操作的时候,长期兴趣、短期兴趣的具体的应用就需要结合实际的场景的区分了,已经我们需要注意原始数据是否适合做兴趣描述的来源数据,是否已经失效。

最后,冷启动的问题。所有涉及到行为数据的推荐算法,都绕不开冷启动的问题,即一个用户是个新手,没有任何行为记录留下,这意味着我们就无法分析其画像了,这个时候就称之为该用户的冷启动。在前面,我们有提到过一些解决冷启动的机制,比如基于内容推荐,进行热点内容推荐(比如把最热门的一些新闻推给该用户,还比如根据整体数据做关联推荐这个后面再讲,方式很多,效果不一,需要根据具体情况来看了,再不行就想办法在用户注册的时候尽可能的收集用户的静态数据,再根据用户的静态画像数据来推荐,总比乱推的好。

3.3       协同过滤推荐

      

LLaMa lora权重文件如何合并_LLaMa lora权重文件如何合并_04

 

                             图4技术架构模块流程图

通过上面的学习,我们大致认识到了一个点,那就是如果要达到推荐个性化的目的,核心还是用户的行为数据,只有用户各自的行为数据才能反馈其与其他人所不一样的特性,从而有针对性的进行推荐。按上个章节的原话,大致就是这样的:

实际上基于用户画像的个性化推荐依然是有缺陷的,比如他不会做用户兴趣的升级,而实际上一些知识本身就是具有一定的阶梯性的。

举个例子就很容易理解了,比如,你对大数据的东西很感兴趣,于是系统根据你的兴趣偏好天天给你推Hadoop、大数据各种技术框架等信息,在某个时间段可能是合理,比如我对大数据领域已经熟知了呢?你还给我天天推送大数据相关的信息。

而我实际上是需要寻求大数据关联的信息,甚至是升级的信息,比如基于大数据的机器学习、数据挖掘相关的东西,这个机制是无法做到这一层的。

换句话说,基于用户画像的推荐,无法发现新知识(跟你之前的兴趣爱好相对比),推荐的候选集永远圈定在你的兴趣标签维度内,做不到认知的升级,而实际上认知是会进行升级的,特别是随着你捕获的知识信息越多的情况下,你就越会对更上层的其他知识感兴趣,不断的深入下去。

而基于协同过滤的推荐,或多或少能解决一点这类问题,最起码能够结合本身用户的行为,让你触达新的知识信息,并且这种递进是通过协同关系得到的,意味着是大部分人的共同选择,所以还是具有一定合理性的。

协同过滤又分为基于用户的协同(UserCF)、基于物品的协同(ItemCF),以及基于模型的协同(ModelCF)。在这里,我们主要用的是基于用户的协同过滤推荐(UserCF)。

基于用户的协同过滤,即我们希望通过用户之间的关系来达到推荐新闻的目的,于是,给某用户推荐新闻,即转换为寻找为这个用户寻找他的相似用户,然后相似用户喜的浏览的新闻,也可能是这个用户喜欢的新闻。

计算相似算法,一般来讲分为两种,距离和余弦夹角,有些时候,也可以添加一个维度,带有喜好程度的描述,比如对于某条新闻打多少分的这种表现形式。这样的话,针对于后一种情况,我们就需要在求在计算相似度时,加入程度的权重考量。

第四章       总结回顾

目前很多主流推荐系统都是基于用户的画像、兴趣爱好推荐的(这是一种相对靠谱,又容易在大规模用户场景中使用的策略),你越是被他推荐的东西牵着走,你后续就会越陷入其中,最终导致了你所获取的信息一直都是圈定在某个范围内的,这就是所谓的“信息茧房”。

其实要形成信息茧房一方面是由于推荐机制导致的,另一方面跟场景也是有很大关系的,比如如果用户被你所推荐的东西所推动,那么就容易陷入这种状态,如果用户获取信息的渠道有多种(比如导航、搜索等等),那么就不那么容易。

典型如今日头条,如果在前期你不小心点击了一些比较low的内容,然后它就越给你推类似的文章,结果你越看,它就越推,于是你所看到的东西都是一大坨类似离谱八卦了。从直观的角度看,今日头条重度依赖于用户的阅读行为,而头条又是一个重推荐场景的产品,所以会相对容易陷入“信息茧房”的这种情况。

从目前看,头条解决这个问题的途径是,给出热度频道,这个逻辑一定程度上降低用户的兴趣偏爱分析,这样用户能够接触到信息面就会更广,进而促使用户能够调整其兴趣,不断的更新其兴趣。

单纯从转化的角度看来,短期内可能对于系统侧来说是正向的,因为他才不会关注到底是不是“信息茧房”,他只关注转化有没有提升,但长期来说,对于用户就是一种损害。所以,我们在考虑设计推荐策略算法的时候,多多少少都会考虑推荐的新颖性。

但新颖性这东西就是一个双刃剑,新的东西意味着不确定,不确定意味着可能低的转化,所以好的推荐系统一定是在确保你兴趣的同时,又会考虑新颖,并且这是一种顺其自然的推荐信息主体的过渡,构建起你偏好信息与新信息之间的关联性,让你同样有欲望去点击那些新的东西,不过这就很难是了。

第五章       附录:

Hbase数据库(实时流处理结果)

 

LLaMa lora权重文件如何合并_数据_05

 

Hive数据仓库(历史数据)

 

LLaMa lora权重文件如何合并_推荐系统_06