作者｜Divye Kapoor
译者｜核子可乐
编辑｜Vincent

作为服务于全球超过 5 亿用户的专业社交网络，领英已经成为专业交流的首选平台。为了为领英会员提供切实有效的评论内容，领英的研发团队构建起一套具备可扩展能力的评论排名系统。该系统利用机器学习技术为访问领英内容生态系统的每一位会员提供个性化的会话体系。在今天的文章当中，来自领英的技术专家将详尽介绍自己的设计思路、面临的可扩展性挑战与解决办法，以及系统运行中必须承受的有限延迟空间。

作为服务于全球超过 5 亿用户的专业社交网络，领英已经成为专业交流的首选平台。这里提供多种多样的职位选项，吸引到大量会员参与，其中部分文章更是拥有极高人气。但面对大量的受众与评论内容，人们往往发现有价值信息被快速淹没在干扰性内容当中。

为了为领英会员提供切实有效的评论内容，领英的研发团队构建起一套具备可扩展能力的评论排名系统。该系统利用机器学习技术为访问领英内容生态系统的每一位会员提供个性化的会话体系。在今天的文章当中，来自领英的技术专家将详尽介绍自己的设计思路、面临的可扩展性挑战与解决办法，以及系统运行中必须承受的有限延迟空间。

发展历史

领英馈送内容丰富多样，可供各类会员根据需求随意使用。其中一部分由会员有机生成（例如由领英公司创始人 Reid Hoffman 撰写的新文章等等），也有一部分来自第三方网站。研发团队需要确保能够定期发布高质量内容。这些文章将根据观点与偏好倾向吸引到广泛而热烈的会员参与，但就在不久之前，领英还没有能力将这种参与行为转化为平台之上真正具备现实意义的会员间对话。

领英馈送评论排名机制采取的默认模式为按新鲜度排序：如果您是最后一位在某热门主题之下发表评论的用户，则您的评论将被显示在顶端。由于无法理解评论的具体内容，因此无法建立起个性化概念，更遑论解析评论内容与参与度之间的实际关联。

领英的技术团队从 2016 年开始对这个问题加以关注。他们建立起一款简单的最低可行产品（简称 MVP），尝试利用其根据获得的“赞”数对评论进行排名（即简单利用这一数字作为评论内容质量的判断依据）。这款 MVP 获得了一定程度的左转，因为其确实能够将有价值评论优先显示在顶端。然而，其也暴露出依据单一且缺少个性化因素的弱点：只有在得到足够的交互评判之后，评论才会得到较高评价。在理想情况下，技术团队希望能够提前找出那些值得一读的评论内容。另外，延迟与规模化等问题也进一步阻碍开发团队将其引入实际生产系统。


根据从 MVP 当中汲取到的经验，领英建立起一套可扩展机器学习服务系统，其负责利用一套富特征集对评论内容进行个性化排名。评论特征——包括评论的实际内容、获得的参与度水平以及评论发布者的相关信息等——都将通过 Samza 流处理工具进行提前运算。在此之后，其特征将被预先判定，并快速与反射索引系统（FollowFeed）中的评论进行关联。当某一请求要求为特定查看者获取相关评论时，预先计算完成的特征与查看器将实现对接，而后运行一套机器学习模型以提供符合个性化要求的评论排名。在过去几个月中，已经通过实践证明，这套系统每秒能够支持数千次查询（简称 QPS），平均时长为 60 毫秒，且第 99 百分位延迟为 190 毫秒。

在接下来的内容当中，作者将就这套系统的具体构建细节进行探讨。
 
了解领英的对话机制

在馈送方面，每条评论通常都会产生一条 Comment Viral Update（即评论更新提醒），并通过评论者连接进行发布。技术团队利用这种评论更新提醒的方式建立领英新闻馈送中最具吸引力的更新术语，具体效果如下图所示：


当您发布在某篇文章或者某条状态下的评论生成大量参与度——包括点赞或者后续评论——时，更新评论更新提醒会显示在您的馈送内容当中。在全部馈送更新中，评论更新提醒会得到最高的参与度。每条评论更新所生成的交互次数相当于关联更新的 2.5 倍（这里的更新是指您个人专业网络中出现的新连接），亦相当于连接内点“赞”参与度的 1.8 倍。
 
2017 年，领英迎来了创纪录的参与水平。与馈送内容相关的社交操作（包括点赞、分享以及评论等）实现 60% 以上的同比增长。如今领英会员们正以前所未有的热情进行交互，而这些交流线索也将带来极为可观的价值。然而，规模庞大的评论内容也给技术团队带来了新的挑战。

与互联网上的其它事物类似，评论线索也存在“长尾效应”。从列表的角度来看，少量长期拥有讨论热度的职位持续出现在会员们的眼前，并极大占用了其在网站上浏览的时间。具体来讲，1% 此类长线索吸引到超过 40% 的会员进行访问。很明显，以反向时间排序方式从头查看成百上千条评论内容绝对不会是令人愉快的使用体验。领英需要一种更为个性化的评论排名方法，以确保每位会员都能够从其关注的长线索评论当中获得最大价值。

MVP 架构

那么，领英是如何最终实现为会员提供相关信息的目标的？在回答这个问题之前，需要首先聊聊最低可行产品（简称 MVP）的实际架构。

设计

MVP 的架构其实非常简单：

iOS 与 Android 移动应用会与 Voyager-API（一个基于 REST 的应用层）进行通信，旨在为特定馈送内容上的某项活动请求相关评论。Voyager-API 会将此请求转发至 Feed Mixer（排名与混合层），用以生成一份相关评论列表。

Feed Mixer 通过向用户信息库扇出请求的方式获取对方的一级连接，从而实现 MP 评论关联性算法。而评论线索库则将获得一份关于特定线索的完整评论列表。该评论线索库为领英 NoSQL 存储库 Espresso 的真相库来源。对于该线索之上的每一条评论，Espresso 都会存储一项示例特征（即合并后的点赞次数）。各评论依靠这样的特征进行排名，并被发送回 Voyager-API 以实现面向观看者的结果显示。

可扩展性挑战

通过架构图可以看到，当用户等待相关评论列表时，会出现在线特征加入的问题。在这种情况下，系统会因延迟问题而导致可排名评论数量受限。极高的计算量与由评论特征检索及处理带来的延迟会令 Espresso 库的后台延迟超过 800 毫秒，这无疑会引发严重的站点性能下滑。可以肯定的是，领英无法将此作为长期性解决方案。

尽管如此，此 MVP 仍然算得上成功。其能够显示排名评论的价值，而不仅仅是根据时间顺序进行简单呈现。另外，其也暴露出这种简单处理方式的弱点——高质量评论可能单纯因为得到的赞较少而被低质量评论所淹没，而且新近发布的评论由于没有足够的时间积累赞与回复而在线索判断层面处于劣势。凭借着积累到的这些宝贵经验，技术团队开始着手对该系统进行生产化调整。

可扩展生产架构

2016 年 8 月，领英决定推出一套不存在上述在线特征生成问题的架构方案。他们还借此机会尝试进一步提升评论排名的实际效果。
 
特征管道

在起步阶段，技术团队选择了一套能够有效描述评论的特征列表以及作为特征获取来源的数据源。其规模要远远超过只具备单一功能的 MVP。为了实现这项目标，他们从以下三个角度着手：

关于评论者的特征 ;

关于评论内容本身的特征 ;

关于评论参与度的特征。

上述各项特征皆通过对各数据存储库进行近实时查询的方式获取。这些特征通过一条特征添加管道进行推送，而此添加管道又由评论创建与交互进行驱动。另外，这一特征添加管道利用 Apache Samza 构建而成（领英的近线流处理系统）。

最终，技术团队得到了一份已添加特征的可用列表，其中包含每条评论的对应交付系统的单一 SSD/ 内存查找结果。另外，以上全部特征皆驻留在 HDFS 当中以备离线分析与模型训练。

交付基础设施

为了保证评论内容的相关性，需要一套能够满足以下要求的交付子系统：

这套系统应具备一份索引，用以立足某一评论线索（快速）检索全部评论内容。

立足该线索快速访问添加特征列表当中的每条评论。

有能力以规模化方式支持成千上万 QPS 并立足馈送内容为每条请求生成相关评论。

虽然（1）与（2）两项任务比较简单，但（3）才是这项设计的核心驱动因素。以规模化方式交付成千上万 QPS 大大缩小了可选范围，因此最终选项被固定在两套子系统当中：Galene（文档划分式搜索堆栈）以及 FollowFeed（术语划分式馈送堆栈）。

这两套系统在各自的领域中皆拥有良好的实际表现：Galene 为领英的搜索流量与多站点功能（例如工作推荐、人员搜索等）提供支持，而 FollowFeed 则支撑着馈送体系中的全部用户生成内容。在经过审议与一系列基准测试之后，研发人员决定采用 FollowFeed，因为其已经与馈送生态系统完美结合起来。不过这又带来了其它一些值得讨论的设计取舍。

这里解释一下，FoolowFeed 是一套术语划分系统（其中每个叶节点负责存储与某一主要术语相关的文档）。在 FollowFeed 当中，各术语属于围绕 actor（例如会员、企业等等）建立而成的概念以及一份由该 actor 所执行社交操作的列表（评论、赞、分享等）。为了保证 FollowFeed 始终返回相关评论，需要对基础进行重新调整。

重整系统以接入可进行评论的各类条目

与能够在领英生态系统内部生成评论内容的少数 actor 不同（例如会员、高校、企业），这里研发团队面对的是更为广泛的会员可评论对象（例如文章、长篇帖子、分享、纪念活动以及视频等等）。FollowFeed 的核心数据结构能够将每个 MemberID 同一系列活动关联起来。技术专家们以这套数据结构为基础，而后构建起另一套能够将帖子 ID 同一份评论活动列表相关联的数据结构。从概念层面讲，这只是一项小小的调整，但在大型生产系统当中实现这项调整却需要耗费远超想象的时间。

修正前 N 条与扇出概念

在馈送领域当中，技术团队面临的挑战在于如何为特定用户挑选最适合的前 N 条帖子。他们需要根据特定会员及其连接列表生成这些与其需求最契合的前 N 条推荐内容。具体来讲，需要提取该会员的连接集，并根据该会员的每一条连接扇出请求，最终给出前 N 条帖子推荐结果。
不过在评论方面，需要将以上提到的 1：N 扩大到 M：NM。其中的 M 为帖子 ID，而每篇帖子都需要生成前 N 条最佳评论。

尽管可以在 FeedMixer 层上进行 N 次请求扇出并对 FollowFeed 进行 N 次查询，但这显然不是最佳解决方案。
 
方差和法则告诉技术团队，N 个独立延迟量彼此为加和关系。这意味着：


因此在 FeedMixer 层上进行请求扇出将极大提升延迟水平。最终的尾延迟不仅包含由 FollowFeed-Storage（最底层交付基础设施层）产生的方差，亦包括来自 FollowFeed-Query 层的方差。然而，如果首先对 FollowFeed-Query 执行单批次请求，而后再对 FollowFeed-Storage 进行一次扇出，则可有效控制尾延迟水平。
 
提供、发布及访问新特征，并利用其进行评论排名
 
这套系统尚处于早期开发阶段，因此还无法顺畅处理各类特征。在各个交付节点之上设置并使用特征存储库，在各节点间合理发布数据，并根据特定键进行划分。这一流程在基础设施工程层面非常简单：在出现数据时，技术专家们会利用 FollowFeed 出色的模型执行能力对来自机器学习模型内的相关评论进行排名。
 
领英使用的机器学习模型

为了实现个性化评论排名，领英训练出一套逻辑回归模型，用以预测查看者对于各条评论的参与度水平。这套模型利用领英 Photon ML 库当中的广泛特征储备训练而成。
 
这套机器学习模型从查看者、评论者以及评论内容处获取特征。任何查看者特定特征（例如评论者与查看者间的亲密度）都会以每日方式被添加至离线 Hadoop 工作流内。这些特征被从 HDFS 中推送至一套在线 Voldemort 存储库以供查询。评论相关特征（例如评论的语言表达）则在评论创建时由一款近线 Samza 处理工具负责生成。如前文所述，这些特征将在 FollowFeed 中进行索引以实现在线交付，并通过 ETL 流程
引入以供离线模型训练使用。
 
评论者特征包含每一位评论者的声誉以及受欢迎程度（基于其个人资料视图中的查看次数及影响力状态等）。领英的这套模型还会根据行业、职位以及其它共享属性对评论者与查看者进行匹配。在领英，能够凭借各类成熟的机器学习信号资源发现两位会员之间的交互关系。技术专家们会考量双方的联系 / 关注关系，其各自个人资料的相似性以及以往馈送内容中的互动记录。这些信号属于关键性输入信息，能够帮助技术团队为每位查看者选定最具个性化考量的高质量评论内容。
 
而在实际评论内容层面，领英的技术专家利用自己的内部自然语言处理（简称 NLP）库来表达语言、评论长度、语法结构、主题标签的存在 / 不存在以及其它内容特征。他们还尝试推断评论当中是否有提及其他领英会员或者其它职能实体。
馈送信息当中的社交参与特征会根据不同行业进行细分，旨在保证机器学习模型能够准确找到只对特定一部分会员具有吸引力的评论内容。
评论新鲜度特征则源自针对当前评论的近期操作。技术专家们会捕捉评论的创建时间戳、最后回复以及最后点赞。查看者一般更倾向于阅读新鲜评论或者最近进行讨论的话题。
 
说到这里，还仅仅涉及这项任务的表面。在捕捉并实现在线排名功能的过程当中，实际使用到近 100 项特征，并利用机器学习模型进行特征训练以准确预测会员们对特定评论内容的参与度。对于每一位会员，都会利用其它机器学习模型对评论中的垃圾信息与低质量内容进行分类与检测，并最终选出最适合查看者的内容。
 
性能指标
 
这套系统拥有稳定的运行效果：可以看到，其第 50 百分位尾延迟水平为 15 毫秒，第 99 百分位延迟则为 65 毫秒。在获取会员特征时，整体系统的中位数延迟为 60 毫秒，而第 99 百分位端到端延迟则为 190 毫秒。具体来讲，这套系统相较于原本的 MVP，能够仅利用四分之一时间生成高达两倍的评论排名结果——这无疑解决了后者原本的最大短板。

 
结论
 
评论关联性这类长期基础设施项目拥有一段有趣的生命周期：首先是孕育期，而后是一段时间的持续评估，接下来投入具体执行，并最终进行稳定生产。回顾此前完成的这一系列工作，同时考虑到领英超过 5 亿会员得以借此获取价值，通过观察，会发现会员们阅读评论、参与内容馈送以及同领英生态系统当中其他会员进行交互与对接的效果皆有所改善。
 
系统的个性化与资讯启发式发现能力得到了会员们的肯定，领英技术团队的工作也取得了良好的反响。

在调整之后，回复当中“赞”的数量开始快速提升。目前 iOS 平台上馈送内容的评论数量增长了 22%，而 Android 平台则提升 14%。
 

原文链接
https://engineering.linkedin.c ... works