微博推荐算法简述<转>

在介绍微博推荐算法之前，我们先聊一聊推荐系统和推荐算法。有这样一些问题：推荐系统适用哪些场景？用来解决什么问题、具有怎样的价值？效果如何衡量？

推荐系统诞生很早，但真正被大家所重视，缘起于以”facebook”为代表的社会化网络的兴起和以“淘宝“为代表的电商的繁荣，”选择“的时代已经来临，信息和物品的极大丰富，让用户如浩瀚宇宙中的小点，无所适从。推荐系统迎来爆发的机会，变得离用户更近：

快速更新的信息，使用户需要借助群体的智慧，了解当前热点。

信息极度膨胀，带来了高昂的个性化信息获取成本，过滤获取有用信息的效率低下。

很多情况下，用户的个性化需求很难明确表达，比如“今天晚上需要在附近找一个性价比高、又符合我口味的餐馆“。

推荐系统的适用场景还有很多，不再一一列举；其主要解决的问题是为用户找到合适的item（连接和排序），并找到一个合理的理由来解释推荐结果。而问题的解决，就是系统的价值，即建立关联、促进流动和传播、加速优胜劣汰。

推荐算法是实现推荐系统目标的方法和手段。算法与产品相结合，搭载在高效稳定的架构上，才能发挥它的最大功效。

接下来我们说一下微博推荐，微博本身的产品设计，使得即使没有推荐系统，仍然会形成一个大的用户关系网络，实现信息快速传播；而衡量一个事物的价值，一个简单的方法是对比看看保留它和去掉它时的差别。微博需要健康的用户关系网络，保障用户feed流的质量，且需要优质信息快速流动，通过传播淘汰低质信息。微博推荐的作用在于加速这一过程，并在特定的情况下控制信息的流向，所以微博推荐的角色是一个加速器和控制器。

最后回到微博推荐算法中来，上面扯了那么多，只是为了让大家能对微博推荐算法有更好的理解。我们的工作，是将微博推荐的目标和需要解决的问题，抽样为一系列的数学问题，然后运用多种数据工具进行求解。

接下来首先用一个图梳理下我们用到的方法和技术，然后再逐一介绍。





基础及关联算法

这一层算法的主要作用是为微博推荐挖掘必要的基础资源、解决推荐时的通用技术问题、完成必要的数据分析为推荐业务提供指导。

这一部分中常用的算法和技术如下：

分词技术与核心词提取

是微博内容推荐的基础，用于将微博内容转化为结构化向量，包括词语切分、词语信息标注、内容核心词/实体词提取、语义依存分析等。

分类与anti-spam

用于微博内容推荐候选的分析，包含微博内容分类和营销广告/***类微博识别；

内容分类采用决策树分类模型实现，共3级分类体系，148个类别；营销广告/***类微博的识别，采用贝叶斯与最大熵的混合模型。

聚类技术

主要用于热点话题挖掘，以及为内容相关推荐提供关联资源。属于微博自主研发的聚类技术WVT算法（word vector topic），依据微博内容特点和传播规律设计。

传播模型与用户影响力分析

开展微博传播模型研究和用户网络影响力分析（包含深度影响力、广度影响力和领域内影响力）。

主要推荐算法

1. Graph-based 推荐算法

微博具有这样的特点：用户贡献内容，社会化途径传播，带来信息的爆炸式传播。之所以称作graph-based 推荐算法，而不是业界通用的memory-based 算法，主要原因在于：

我们的推荐算法设计是建立在社交网络之上，核心点在于从社交网络出发，融入信息传播模型，综合利用各类数据，为用户提供最佳的推荐结果；比如很多时候，我们只是信息传播的关键环节，加入必要的推荐调控，改变信息传播通路，后续的传播沿着原来的网络自然的传播。

Feed流推荐（我们称作趋势），是我们最重要的产品，而结果必须包含用户关系。

从graph的宏观角度看，我们的目标是建立一个具有更高价值的用户关系网络，促进优质信息的快速传播，提升feed流质量；其中的重要工作是关键节点挖掘、面向关键节点的内容推荐、用户推荐。

对这部分的算法做相应的梳理，如下面的表格

算法	说明	应用举例
User-based CF	依据相似用户的群体喜好产生推荐结果	用户推荐、赞过的微博、正文页相关推荐
KeyUser-based CF	依据相似专家用户的协同过滤推荐，利用少数人的智慧；推荐的信任来自好友和社会认同	用户推荐（兴趣维度）、热点话题
Item-based CF	依据用户的历史item消费行为推荐	实时推荐、用户推荐
Edgerank	群体动态行为的快速计算	智能排序、错过的微博
Min-hash/LSH	用于海量用户关系的简化计算	用户关注相似度、粉丝相似度计算
归一化算法	Weight的归一运算，如类idf计算、分布熵，量化节点和边的价值	面向关键节点的内容推荐、用户推荐

这里的困难点在于graph的“边”怎样量化与取舍，依据多个“边”与“节点”的综合评分计算，以及与网络挖掘分析结果的融合。

这部分的算法研发中，产出了如下的数据附产品：

数据	说明
用户亲密度	衡量user A对其follow user B的喜爱程度，是个单向分数，依据A与B的互动行为，以及A对B的主动行为计算，随着时间会逐步衰减
用户影响力	用户在微博信息传播过程中的社会化影响力，分广度影响力、深度影响力、领域影响力
关注相似度	为用户计算与其关注口味相似的用户列表，是user-based CF的基础资源
粉丝相似度	为用户计算与其具有粉丝相似的用户列表，应用于用户推荐的实时反馈
关键节点	影响信息传播的关键用户，以及具有连续优质内容生产能力的用户。通过节点信息的传播效率来计算。
兴趣协同用户	采用LDA模型对用户关系网络进行聚类分析，挖掘得到相同兴趣能力的用户。

2. Content-based 推荐算法

Content-based 是微博推荐中最常用也是最基础的推荐算法，它的主要技术环节在于候选集的内容结构化分析和相关性运算。

正文页相关推荐是content-based 应用最广的地方，以它为例，简要的说一下





内容分析的很多点已在前面描述过了，这里重点说2个地方：

内容质量分析，主要采用微博曝光收益+内容信息量/可读性的方法来综合计算。微博曝光收益是借助用户群体行为，衡量内容优劣；内容信息量计算比较简单，即是微博关键词的idf信息迭代；对于内容可读性的衡量，我们做了一个小的分类模型，分别以可读性较好的新闻语料和可读性较差的口语化语料为训练样本，通过提取里面的各类词搭配信息，计算新微博具有良好可读性的概率。

词扩展，content-based的效果取决于内容分析的深度。微博的内容比较短，可提取的关键信息比较少，做相关运算时容易因为数据稀疏而导致推荐召回率和准确率的难以权衡；我们引入word2vec技术，优化了词扩展效果，后面又以此为基础开展词聚类的工作，实现了推荐召回率和准确率的同步提升。

相关计算的技术点在于向量的量化和距离度量，我们通常使用“tf*idf权重量化 + 余弦距离”或者“topic 概率 + KLD距离“的两种方法。

3. Model-based 推荐算法

微博作为中国最大的社会化媒体产品，具有海量的用户和信息资源；这就给推荐带来了2个挑战：

来源融合与排序

候选的极大丰富，意味着我们有更多的选择，于是我们推荐结果的产生包含两层：多种推荐算法的初选与来源融合排序的精选，为了得到更客观准确的排序结果，我们需要引入机器学习模型，来学习隐藏在用户群体行为背后的规律。

内容动态分类和语义相关

微博UGC的内容生产模式，以及信息快速传播和更新的特点，意味着之前人工标注样本，训练静态分类模型的方法已经过时了，我们需要很好的聚类模型把近期的全量信息聚合成类，然后建立语义相关，完成推荐。

Model-based 算法就是为了解决上述的问题，下面是我们两块最重要的机器学习工作：

3.1 CTR/RPM（每千次推荐关系达成率）预估模型，采用的基本算法为Logistic regression，下面是我们CTR预估模型整体的架构图





这部分工作包含样本选择、数据清洗、特征提取与选择、模型训练、在线预估和排序。值得一提的是，模型训练前的数据清洗和噪音剔除非常重要，数据质量是算法效果的上界，我们之前就在这个地方吃过亏。

Logisitic regression是一个2分类概率模型





优化的目标在于最大化“样本正确分类概率的连乘值“；我们借助yahoo 研发的vowpal_wabbit机器学习平台来完成模型特征值求解的最优化过程。

3.2 LFM（Latent Factor Model）：LDA、矩阵分解（SVD++、SVD Feature）

LDA是2014年初重点开展的项目，现在已经有了较好的产出，也在推荐线上产品中得到了应用；LDA本身是一个非常漂亮和严谨的数学模型，下面是我们一个LDA topic的例子，仅供参考。





至于矩阵分解，2013年的时候做过相应的尝试，效果不是特别理想，没有继续投入。

隐语义模型是推荐精度最高的单一模型，其困难在于数据规模大时，计算效率会成为瓶颈；我们在这个地方开展了一些工作，后续会有同学专门介绍这一块。

混合技术

三个臭皮匠顶个诸葛亮，每一种方法都有其局限性，将不同的算法取长补短，各自发挥价值，是极为有效的方式。微博推荐算法主要采用了下面的混合技术：

时序混合：

即在推荐过程的不同时间段，采用不同的推荐算法；以正文页相关推荐为例，在正文页曝光的前期阶段，采用content-based + ctr预估的方法生成推荐结果，待产生的足量可信的用户点击行为后，再采用user-based 协同过滤的方法得到推荐结果，如下图所示：



这样利用content-based很好的解决了冷启动的问题，又充分发挥了user-based CF的作用，实现1+1>2的效果。

分层模型混合：

很多情况下，一个模型无法很好的得到想要的效果，而分层组合往往会取得比较好的效果，分层模型混合即“将上一层模型的输出作为下层模型的特征值，来综合训练模型，完成推荐任务“。比如我们在做微博首页右侧的ctr预估排序时，采用分层逻辑回归模型，解决了不同产品间特征天然缺失与样本量差异、曝光位置带来的效果偏差等问题。

瀑布型混合：

这类混合技术思路非常简单，即在推荐候选非常丰富的情况下，采用逐层过滤的方法的得到推荐结果，通常将运算快、区分度低的算法放在前面，完成大量候选集的筛选；将运算慢、区分度高的算法放在后面，精细计算剩下的小规模集合。这类混合在微博推荐中大量使用，我们采用各种轻量算法完成候选集粗选，然后采用ctr预估做精细化排序。

交叉混合：

各类推荐算法中子技术，可以在另外的推荐算法中综合使用，比如content-based在相关性计算中积累的距离计算方法，可以很好的应用在协同过滤的量化计算中。实际的例子，我们将研究LDA时积累的向量计算方法成功的应用到用户推荐中。

Online 与 offline

微博数据的特点（海量、多样、静态与动态数据混在一起），决定了大部分推荐产品的结果需要同时借助online和offline的计算来完成。从系统和算法设计的角度，这是一个“重”与“轻”的问题，计算分解和组合是关键，我们需要将对时间不敏感的重型计算放在offline端，而将时间敏感性强的轻型快速计算放在online端。几种我们常用的方式如下图：






Online需要简单可靠的算法，快速得到结果；简要说明下上面的图，如下

半成品有以下的3中形式

1）计算过程拆解的离线部分，如user-based CF中的用户相似度，online通过数据库读取后在线计算完成user-based 推荐。

2）离线挖掘的优质候选集，如正文页相关推荐的内容候选集，online通过索引获取到数据后，再通过相关性和ctr预估排序生成推荐结果。

3）具有较高相似度的推荐结果集，如offline计算好粉丝相似高的用户，在线对用户行为做出实时反馈，实时补充推荐与其刚关注用户相似的用户。

静态推荐结果，是指那些与时间关联小的推荐item，如我们的用户推荐95%的结果来自离线计算。

机器学习模型，这是一个计算过程时序性上的拆解；offline完成模型的训练，在线调用model完成item排序，当然也可以通过online-learning或实时特征值完成模型的实时更新。同时，model在线计算时，需要注意缺失特征值的补全，保证offline与online环境的一致性。

此外，我们也有直接online计算完成的推荐结果，如首页右侧话题推荐，由于用户对话题需求的差异非常小，它基本上是一个排行榜的需求，但热门微博也可以有精巧的设计，我们采用了一个曝光动态收益模型，通过上一段时段的（点击收益-曝光成本）来控制下一时段的item曝光几率，取得了非常好的效果，ctr和导流量有3倍以上的提升。

不同类型的推荐结果，要辅以不同的推荐理由，这一点需要前端的多种展示尝试和offline的日志分析。

效果评测

算法效果的度量方式决定了大家努力的方向，而对于不同类型的推荐，最好根据产品的定位和目标，采用不同的标准体系去衡量工作结果。实际效果的评测分为3个层次：用户满意度、产品层指标（如ctr）、算法层指标，我们的效果评测也会分为人工评测、线上A/B测试、离线算法效果评测3种。

产品指标的制定，应该从产品期望达成的目标出发，体现用户满意度。

对算法离线评测而言，关键的是找到一套合理的算法评测指标去拟合产品层指标，因为算法离线评测总是在上线前进行，这个对应做的越好，算法的优化成果才能更好的转化为线上的产品指标。

下图为我们的算法离线效果评测的架构图





常用的离线评测指标有：RMSE、召回率、AUC、用户内多样性、用户间多样性、新颖性等。对于不同的产品有不同的组合指标去衡量，比如用户推荐中“用户间多样性”非常重要，而热点话题却可以允许用户间有较大的结果重合度。

耐得住寂寞，才守得住繁华。

Posted in 算法与策略
| 2
Comments

微博推荐引擎体系结构简述

2014 年 7
月 23 日

这里有个“道术孰优”的问题，何为“道”？何为“术”？举个例子的话，《孙子兵法》是道，而《三十六计》则为术。“道”所述，是宏观的、原理性的、长久不变的基本原理，而“术”则是在遵循基本原理基础上的具体手段和措施，具有易变性。技术也是如此，算法本省的细节是“术”，算法体现的基本思想则是“道”，知“道”而学“术”，两者虽不可偏废，但是若要选择优先级的话，无疑我会选择先“道”后“术”——张俊林《这就是搜索引擎》

上一篇文章介绍了推荐产品，给大家有一个初步的认识：微博推荐的目标和使命、推荐产品有哪些以及推荐的分类角度。本文将会给大家描述当前微博推荐的体系结构。

任何不拿出干货的技术文档都是耍流氓，首先上体系结构图，如图所示，在整体体系结构上，微博推荐可以被划分为4层：前端展现层、应用层、计算层以及数据层，其中我们把数据日志、统计、监控以及评估也都分在数据层。接下来我会逐一介绍他们的目的，作用、技术与发展。更为细致的描述应该会在以后的博客中体现。





1、推荐前端RFront

RFront主要目的是展现以及渲染微博内容，由于当前微博推荐在web以及客户端都有相对应的产品，展现差异较大，但数据和方法却是通用的。那么，需要有这么易于维护、拥抱变化的一层高效地响应产品需求。当然在微博推荐实际业务中，由于产品形态的多样以及策略的负责性，RFront做了不少工作以及相关的应用技术很多，在接下来的文章中会有相关的同学着重介绍这一块工作。

2、推荐应用RApp

RApp主要目的是为前端提供候选以及起到部分排序功能。该层利用通用框架【nginx + lua 以及apache + python两个版本】提供应用接口服务。这些应用包括：内容、用户、服务、feed推荐频次以及辅助功能。

在这里有一个工具叫做通用推荐框架（CRF, common recommon framework），它主要的作用是：融合推荐资源、规范推荐应用接口以及统一工作流。早期版本使用的是apache+mod_python的形式，后来在RApp的定位上，认为它是一个数据通路，同时需要获取各种协议的数据内容，因而将其扩展到nginx + lua的版本。

CRF是一个二次开发框架，无论是早期的apache+mod_python版本还是nginx+lua版本，其核心思想是相似的，它们的目标都是为了较为快速进行推荐策略开发，快速的使用既有推荐存储数据。主要的体现在：

通过透明化不同协议的存储数据获取方法，方面获取推荐资源。比如，获取mc、redis以及openapi的数据方式是一致的，get以及mget是一个标准的获取方法。

通过建立project的概念，以继承的方式让二次开发者建立自己的项目，同时将project中work_core暴露出来，完成主体业务。当然其中也有一个小的技巧，比如global_data以及并行化获取数据等等。

通过暴露出来的common_recom的核心接口来定义推荐的统一接口，我们整理和抽象了所有推荐的接口数据形式，在一定程度上进行了规范和定义，这样方面了进行接口管理以及对应。比如obj【多用来表示访问者】，tobj【多用来表示访问对象】，from【来源】，appkey【分配key】，num【数量】，type【类型，用来区分同一个项目中不同接口】，pid【区分项目】等等。

以下图是其三层目录结构【apache+mod_python】：





其中我们通过data_interface来实现数据透明化，通过work_interface来管理项目，my_interface二次开发者开发属于自己的project。同时需要配置文件【data以及project】进行数据和项目的对应。这样会带来一个好处，通过这个框架将所有的资源整合起来了，在推荐早期项目中起到了比较明显的作用：快速响应算法和产品策略、项目迭代比较迅速同时让业务人员在一定程度上关注业务，后来也推动了后来推荐存储架构的诞生。通过不断的优化，这个逐渐被lua以及c/c++版本的通用框架取代。

3、推荐计算层RCompute

推荐计算层的职责是做高效运算，比如二度关系运算、用户之间桥梁关系运算、CTR预估等等CPU密集型的功能模块。同时在RApp以及RFront有一些离线数据采用远程访问以前比较低效的，因此我们需要一个更加高效的通用框架来满足上述要求，lab_common_so孕育而生。

Lab_common_so是基于woo框架的【感谢曾经的同事支持，这是一个轻型的通讯框架，通讯协议以及日志系统比较完善】一个业务流框架，同时兼有了CRF的特点——整合融入数据资源、规范业务流程、统一接口形态，还具有了数据本地化功能。其实在在线demo c/c++开发框架中有很多，在这里主要介绍一些自身特点：

通过c++的一些特性，让二次开发者在工作流上尽可能减少关注其他架构以及通讯包括存储客户端的事情，下图是主要的类结构图【UML的一套傻傻的不会，大家凑合看吧。】





通过global_data以及data的类实现获取数据的透明化

在后期的改造中，将work独立出来，有开发方自己进行编写具体实现和具体类，进行so化支持线上更新

在计算层中有一个模块是RTaining，主要用来进行模型更新以及线上学习的，前期主要用在点击反馈或者实时模型上。

4、数据RStore

推荐数据对于推荐而言是基础，决定了性能也决定了效果。因此在数据存储上花的精力较多。微博推荐存储的数据拥有以下特点：

种类繁杂，比如需要存储挖掘的静态数据，还有用户实时行为的动态数据，有为提升性能而存储的属性缓存也有离线运算的直接结果数据

存储选型上也不能一概而论，动态数据以及静态数据的要求是不一样，统一都用高效的内存存储浪费资源，不宜扩展，都用离线的静态存储又达不到性能要求

多个外部门的数据，沟通和写作方式各式各样

某些数据量较大，同时在某些数据的实时性要求上较高。

针对上述特点，推荐抽象解决IN/OUT/STORE三部分。下图详细的描述了推荐数据的结构图：





IN：输入的关键是解决统一和，因此通过建立基于ckestral的统一入口来解决数据规范的事情，同时在日志以及实时数据上也有相应的解决方案，统一入口为RIN。

OUT：输出的关键是需要透明化，对于业务方而言不需要关系如何进行的服务器分配以及存储类型，而能够方面快速稳定地获取到数据就好。

STORE：这一块主要解决数据类型繁杂的工作，推荐的经验是离线使用lushan以及mapdb，在线使用redis/mc，如果有特殊需求，比如批量高效压缩存储特征数据，也会使用一些自己定制的数据存储形式。

在这里面，需要特别强调的是离线静态数据存储，在性能以及成本上找到一定的平衡点是推荐比较有特色的地方，lushan以及mapdb会在之后做专题介绍。同时在推荐发展的过程中,hadoop的引入在一定程度上解决了很多候选以及排序的问题，因此一些map-reduce的结果数据如何放置于线上，推荐系统的r9项目很好的解决了这个问题。

5、数据值辅助工具：日志、监控、评估以及报警

推荐日志系统主要为了解决离线数据分析以及在线监控使用。当前推荐系统针对离线的分析来自于两块，一个是来源于自己的日志系统，另外一个是来自于公司的hadoop集群【几乎涵盖了非业务方的全局数据】，也在考虑将这两部分进行整合归并。

推荐监控系统是去年建设起来的，主要分为三部分：

性能监控，主要查看应用、计算以及存储的性能服务指标，同时与报警体系联动，及早发现问题、解决问题。目标是实时以及准实时，现在是分钟级别的。

效果监控，主要跟踪效果的优化和改进，当前重点业务线的效果均在监控系统中

对比测试监控，主要针对线上的A/B测试，进行分维度数据展示和对比

以下是我们监控的一些信息：

曝光以及性能监控：







效果监控：





推荐评估系统，当前主要以demo实验、下线评估以及线上评估三个体系构成，其中线上评估体系主要跟着监控体系来的。而下线以及demo主要是一套前端的展示框架，几乎涵盖了推荐所有的接口以及对比测试数据。

推荐报警体系，微博本身是有的，不过由于性能指标以及效果指标存在一定上的定制化需求，这一块正在花精力解决。

好了，这一篇就到这里，推荐体系结构的介绍基本上告一段落了，其中涉及到的比较细节的工作将会在专题中进行介绍。也请大家多多捧场。

还是老规矩：

Simple is Beautiful! 设计复杂的系统不是难事，难的是用简单的东西满足复杂业务，大家共勉！



Posted in 引擎架构
| 3
Comments

我们从这里开始

2014 年 7
月 21 日

——谨以此文献给曾经努力过以及正在努力的微博推荐团队成员



推荐系统就是自动联系用户和物品的一种工具，它能够在信息过载的环境中帮助用户发现令他们感兴趣的信息，也能将信息推送给对它们感兴趣的用户。——项亮《推荐系统实践》

本文作为该博第一篇，在这里暂时不会做更多的技术细节讲解，先给大家初步介绍一下微博推荐的相关产品。介绍之前，先看看微博是啥，微博推荐要干啥？微博将信息通过用户关系进行传播，而微博推荐需要做的是合理构建用户关系，推动信息在用户之间的高效传播。

首先从被推荐实体的分类上将推荐业务划分为用户、内容以及服务三种。

* 用户推荐：在不同的场景下为用户提供关系推荐，促进用户之间良好关系的构建。

Web端的主体产品是首页右侧“可能感兴趣的人”。“可能感兴趣的人”主要以社交图谱为主，兴趣图谱为辅，同时扩充了属性、以及热门推荐。同时响应用户操作：换一换，加关注补充、不感兴趣沟通以及下拉悬停。那个给新任女友推荐出ex的就是从这个模块产生的，当然我不会告诉你们这个模块的工程师是谁的。：）





Web端的另外一个产品是用户profile页面的“他的粉丝也关注”以及加关注之后的弹层页，粉丝也关注，主要是通过关注协同运算得到的结果。





客户端的用户推荐场景会更多一些，其中最为重要的产品是feed流中的好友关注。这个是基于社交图谱的计算方法，同时在产品的展现形式上会比较多样。

比如：





再比如：





相比较pc端的profile页粉丝也关注而言，客户端profile页也有这个推荐形式，当添加一个用户的关注之后，产生如下图所示的弹层：





另外“新的好友页”以及找人中可能感兴趣的人也是属于用户推荐的范畴。





* 内容推荐：拉近用户与内容之间的距离，提升有效内容的传播效率。

内容推荐典型的推荐产品有四个：

> 正文页推荐：为访问单条微博的用户提供阅读延伸和扩展，这个项目的推荐集合中包括相关微博、话题、用户、电影、音乐、文章等等。主要的候选方式是content-based推荐。在web端也有相同的项目，只不过候选呈现多一些。









> 赞过的微博：以社交图谱为基础将优质微博在好友间传播，扩大赞行为的影响力，满足用户对优质内容的消费需求。





>错过的微博：信息突起【feed dumping】的一种表现形式，对用户的需求进行挖掘，满足用户对重要的错过信息的消费需求。





>Web首页右侧推荐：首页右侧包含了“可能感兴趣的人”、“热门话题”、“热门微博”、“热门音乐”以及“热门电影”5个模块，通过机器学习以及人工策略的方式来对每个人进行个性化的推荐。其中模块的位置以及种类每个人各不相同。





* 服务推荐：通过社交图谱向用户推荐垂直类的微博产品，满足用户各类兴趣需求，比如电影、音乐、图书、短视频、话题、图片以及商品等等。它主要集中在feed中，比如：





其次我们按照场景进行区分，会分成feed流内推荐以及feed流外推荐。

feed流中推荐我们称之为趋势，趋势中的推荐类型是比较多，初步计算应该有9-10中，由于feed使用户最为重要的消费渠道，也结合推荐自身社交媒体的属性，趋势要求推荐必须有关系桥梁。因此feed内的推荐基本上都是基于社交图谱的。趋势还在会根据每个用户消费行为动态决定每种类型出现的频次以及当前出现的种类。





对于feed流外的推荐就没有了关系这个限制，推荐的方式方法也是多种多样的，有基于内容的，比如正文页推荐；有基于协同的，比如粉丝也关注；有基于兴趣的比如web首页右侧微博推荐等等。

最后按照推荐方法进行区分，我们将微博推荐划分为四类：基于社交图谱的推荐、基于兴趣图谱的推荐、基于内容上下文的推荐以及基于行为上下文的推荐。

* 基于社交图谱的推荐：契合微博的社交属性，发挥社交优势，在一定程度上难度不大，但是效果比较好。举例：趋势中的好友关注、赞过的微博推荐。桥梁类型识别、桥梁权重、用户质量判别、多权重计算方式以及整体架构是其中主要的挑战点。

* 基于兴趣图谱的推荐： 由于媒体属性的存在，微博用户在一定程度上会体现其对某类事务或者话题的亲睐，这些兴趣是可以进行挖掘乃至利用的。其根本的难度在于如何在信息碎片化比较严重的微博中准确挖掘用户兴趣，现在我们发现通过关系来映射兴趣是一个事半功倍的工作。

* 基于内容上下文的推荐：同样的用户来微博主要是为了消费内容，通过内容上下文做推荐来辅助用户做延展阅读就显得比较自然了。在正文页推荐中的经验证明，用户在碎片化消费内容的同时也会对相关内容消费有比较大的倾向。其中的难点在于内容向量的提取、相关性的提升等等。

* 基于行为上下文的推荐：这是在2013年下半年之后微博推荐着重倡导的一件事情，由于微博在时间上的高敏感度，微博用户天然对于实效有一定的接受度，因此如果让微博推荐和用户形成了好的交互将会大大提升推荐效果。而基于行为上下文的推荐就是想利用用户的行为最短的时间反映到推荐系统中，我们称之为场景融入式的实时推荐。比如好友关注中的近期关注、可能感兴趣的人加关注之后的补充以及趋势内容赞过之后的微博推荐都在该范畴之内。其中的难度在于了解环境、实时性的把握以及短时兴趣的分析和挖掘。

第一篇内容就到这里了，其中涉及到的架构以及算法的事情将会在以后的微博中给大家阐述