基于机器学习的知道推荐—Enlister (2012-11-07 06:11:29)
标签: 分类:未分类
基于机器学习的知道推荐—Enlister
— trisun
Enlister—最大的中文问答网站“百度知道”的问题推荐系统名字。这个由几个百度一线工程师研发的系统,自2012年1月上线以来,承担着百度知道千万级登录用户的问题推荐计算。
问题的开始
百度知道这样的问答社区型网站有个典型特点:有些用户在平台上提出问题,这些问题被另一些用户发现,其中有能力且有意愿的人回答了这几个问题。这几个问题及其解答在平台上沉淀下来,持续给后来有相关问题的搜索用户提供着解答,并激励着更多用户将自己的问题发布在平台上。
像这样的系统就是一个自生态系统,有人生产,有人消费(如图1)。若其中一个环节出现问题,都会导致这个生态异常。在现在的百度知道上,每日有几十万的新问题正在提出,又有近百万左右的在涌现,而浏览这些知识的人每天有上亿。最可能出问题的地方在于,问题被提出以后,解答无法满足甚至鲜有人问津,这不利于解决提问者的疑惑和知识的沉淀。
图1
面对这样问题,提升回答量是最直接的办法,回答量上升了,有价值的回答数量就会成比上涨。“回答”是一个高门槛的事,是contribute而非consume。排除这个问题,若用户本身在发现待回答问题上,还需要过高的付出(例如搜索、或按分类查找,如图2),那着实让大量有能力和意愿但不想花更多时间在查找问题上的人望而却步。而推荐,就是我们一把杀手锏。
图2
说到推荐
有了推荐,就有了地基,如何设计楼宇有更多细节需要解决。做推荐需要密切结合产品,是恒古不变的真理。详细了解了知道的产品和目标后,我们提出了三个该系统核心:
1、 基于内容
新问题一旦被提出,其解决就刻不容缓。高时效性要求了必须要以准确的内容分析为基础。
2、 CTR预估(Click Through Rate,点击率预估)
为了提升回答量,我们可考虑提升点击量,在用户量和回答率不变的基础上,间接提升了回答量。另外,CTR预估是我们擅长的技术,是我们的一大优势。
3、 流式计算
为了适应新问题实时推送,我们设计了以问题数据为主数据流的推荐系统,保证了新问题在分钟级时效性内推送给目标(如图3)。
图3
基于内容
基于内容,意味我们需要用模型准确地描述“问题”和用户。考虑我们的推荐场景,一个新问题产生并被推荐给目标用户后,用户看到的是一个推荐列表与里面的问题标题(如图4)。此时,影响一个用户是否点击该问题的因素大致有:问题的具体内容、问题的分类及分类的回答活跃度、问题的地域性。其中,问题分类活跃度是一个实际观察得到的因素,某些分类,如情感,的回答活跃度会远远高于其他分类。而用户因素则有:用户内容偏好、回答时间、了解地域、最近行为偏向与最近推荐活跃度。其中,除了内容偏好与了解地域这类用户长期兴趣,一些短期偏好如时间、最近行为和最近对推荐的活跃度作为context信息也被考虑在内,以便提高推荐时机准确性。
图4
根据以上因素,我们对问题进行了如下建模:获取问题标题、切词并从标题中抽取中心词,构建plsa主题模型,利用分类器获取问题分类(分类结构可见知道主页上“问题分类”)与该分类最近点击、回答量,问题推荐的时间与问题地理关键词。
而用户的建模包括了:用户在知道的个人中心定制的关键词、问题分类,用户历史回答问题标题中挖掘的中心词分布与权重及这些中心词的plsa模型,用户最近回答问题的时间,最近回答的问题标题,以及用户最近对推荐问题的点击与回答量。
利用以上的数据,我们基本对问题、用户有了准确的描述。不仅涵盖了用户关注的问题且能解答的兴趣方向,同时刻画了最近用户的回答兴趣偏向与推荐场景信息。
CTR预估
CTR预估自然就会使用到最大熵模型。该模型是经典的分类模型,在工业界有很多成功的使用案例,不仅可以进行线性计算以满足实时推荐需求,也不用考虑变量间独立性关系,可将所有的特征(包括context信息)构造成向量加入模型中。在我们的问题中,希望利用及其有限规模的设备来获得优质的推荐服务,自然就涉及到需要定期更新训练模型且样本数不能过大(训练本地化),特征维度不宜过高。因此,我们尽可能利用用户与问题模型构造组合的高级特征,以提高特征的覆盖度和泛化能力(如图5)。
图5
为了保持模型的新鲜性,我们自动更新模型周期为5天。在5天之内采样登录用户的几百万点击数据作为正样本。常规情况下,本可采用推荐列表中展示但未被点击的问题作为负样本,但预测结果并不令人满意,究其原因可能为:由于列表上问题方向由一定重复性,另外用户每天回答能力有上限,所以列表上其他问题可能由于用户未看到或已经不想再继续回答而未点击,不能代表其为真正的负样本。所以,负样本采用从与正样本时间一致的同一批问题里随机抽取。而正负样本比例则尝试了多种比例组合,最终1:1的比例在精确率(accuracy)上优于其他组合(如图6)。
图6
流式计算
流式计算,是相对于离线批量计算和当用户访问时实时为其计算推荐而言的。当新问题产生时,我们需要及时为其发现目标用户,并为这批目标用户构建新的推荐列表,包含了巨大的计算量及存储量。如图7,当我们在question pre-process端接收到新问题时,立即对其进行秒级建模运算;而在user action pre-process端,我们利用分布式计算实现了用户模型小时级更新,保持用户模型的新鲜性。通过BMQ系统(Baidu Message Queue)将建好模的问题发送到几十台click predict运算模块中(每台包含不同的用户分片)。click predict内部也是多线程并行流水线处理,保持高并发性(如图8)。当click predict接收到一个问题,会先根据问题中心词拉取用户倒排,获取一个该问题关联用户的候选集(pre-process),淘汰部分不合格用户。在prediction阶段,对问题和关联到的全部用户(千量级)计算点击率,并淘汰低点击率。最后再re-rank阶段对用户原有列表插入该新问题。
图7
图8
列表构建
在上一节最后提到了将一个新问题插入到原有用户列表中。若只简单考虑利用CTR值来进行排序,则使得整个列表看起来同质化比较严重:
1、 不少问题的标题很接近,在列表中排序也可能很邻近;
2、 用户可能包含几个兴趣点,但最终列表(特别头部)集中了大量问题只属于一个兴趣;
实验表明,这些问题会严重影响用户体验,降低用户持续回答的欲望。我们则采用了一种多样化列表构建方法,以CTR为基本排序依据,但在列表头部尽可能的保证推荐的相关性。当一个新问题插入头部时,只要和周围标题不是非常接近都可插入,让用户能首先看到的列表前部看起来推荐很“准”;而在非头部区域,则加强对邻近问题相似过滤,让更多的兴趣点能得以展现,用户看起来觉得很“多样化”(如图9)。
图9
整体系统
除了以上几点需要考虑之外,我们做一个线上的推荐系统还需要考虑如spam屏蔽、某些业务逻辑、用户反馈等问题。如图,在多样化列表构建时,加入业务逻辑模块,过滤spam问题,对一些高价值问题的展现进行优先或对用户点击删除或不太喜欢的关键词进行屏蔽、降权。图10中RP部分是推荐引擎,iknow部分是产品线。
图11是系统上线前与上线后(201201)回答量的一个对比。原有推荐系统基于中心词计算距离相似进行推荐,日均回答量不足8万。Enlister上线后回答量持续攀升,至6月份后稳定在19万左右。
图11
蔡晶/文
解析nginx负载均衡 (2012-7-27 06:07:57)
标签: nginx , webserver , 负载均衡 分类:未分类, 贴吧技术
摘要:对于一个大型网站来说,负载均衡是永恒的话题。随着硬件技术的迅猛发展,越来越多的负载均衡硬件设备涌现出来,如F5 BIG-IP、Citrix NetScaler、Radware等等,虽然可以解决问题,但其高昂的价格却往往令人望而却步,因此负载均衡软件仍然是大部分公司的不二之选。nginx作为webserver的后起之秀,其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注。本文将以工业生产为背景,从设计实现和具体应用等方面详细介绍nginx负载均衡策略。
关键字:nginx 负载均衡 反向代理
漫谈社区PHP 业务开发 (2012-7-26 03:07:20)
标签: lamp , 子系统拆分 , 开发框架 分类:大型网站架构, 未分类
在当前这个互联网业务飞速发展时期,新的产品如雨后春笋般涌出,老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。
一、基础运行环境
针对新产品的开发,必须能够快速搭建一套LAMP架构。那么无外乎选择一个webserver,选择一个php版本,选择一个mysql版本,再选择一个PHP开发框架和选择一些php通用扩展和基础库等。这个过程读者可能觉得已经很快了,能不能更快?
选择的过程要求研发同学对相关技术方向有一定的积累,权衡利弊和优先点,又是一番调研和学习。如果有一键安装程序,提供自动化安装webserver,php,mysql,以及携带高性能灵活的php开发框架,并提供标准化、安全、常用的配置文件,可以大大缩短产品线LAMP系统调研的成本,缩短工作周期。
使用Weka进行数据挖掘 (2012-7-26 03:07:26)
1.简介
数据挖掘、机器学习这些字眼,在一些人看来,是门槛很高的东西。诚然,如果做算法实现甚至算法优化,确实需要很多背景知识。但事实是,绝大多数数据挖掘工程师,不需要去做算法层面的东西。他们的精力,集中在特征提取,算法选择和参数调优上。那么,一个可以方便地提供这些功能的工具,便是十分必要的了。而weka,便是数据挖掘工具中的佼佼者。
Weka的全名是怀卡托智能分析环境(Waikato Environment for Knowledge Analysis),是一款免费的,非商业化的,基于JAVA环境下开源的机器学习以及数据挖掘软件。它和它的源代码可在其官方网站下载。有趣的是,该软件的缩写WEKA也是New Zealand独有的一种鸟名,而Weka的主要开发者同时恰好来自新西兰的the University of Waikato。(本段摘自百度百科)。
Weka提供的功能有数据处理,特征选择、分类、回归、聚类、关联规则、可视化等。本文将对Weka的使用做一个简单的介绍,并通过简单的示例,使大家了解使用weka的流程。本文将仅对图形界面的操作做介绍,不涉及命令行和代码层面的东西。
前端重构实践(二) —— 模块化开发 (2012-7-26 03:07:58)
前言:
在上一篇文章中我介绍了我们对N产品性能优化的整个历程,主要偏重优化方法。本篇我将介绍在这一过程中,我们的代码出现了什么样的问题,以及我们是如何通过前端重构来解决掉这些问题,并产生了哪些收益。
痛点:
按需加载为我们的页面带来了很大的性能提升,但同时也为代码结构带来了很大的冲击,很多直接调用的方式被改为了模块化的调用形式(先判断模块是否存在,不存在就先加载对应的js,再执行回调)。
Gecko架构浅析之编码检测和转换 (2012-7-16 02:07:59)
标签: Gecko , 编码检测 , 编码转换 , 网络排版引擎 分类:浏览器技术
一:前言简介
Gecko是一套网络排版引擎,由来已久,为当年大名鼎鼎的netscape网络浏览器流传而来,后面也成为了firefox浏览器,thunderbird等等软件的基础。详细的发展历程在这里就不展开做具体介绍了,读者可以自行查阅百度百科,维基百科等资料。
在这一章我们重点介绍一下gecko中是如何对全球各种不同的网页文档的编码方式来做出识别和转换的。
我们知道,netscape或者firefox是面向全球用户的,并且,在互联网的世界,并没有什么界限妨碍一个美国的用户访问中文或者日文的网页。所以,在这种场景下,浏览器是否能正确识别每个地区的网页的编码格式,并正确地显示出来,就尤为重要了。
诡异提交失败问题追查 (2012-7-13 08:07:52)
摘要:
自四月份以来,贴吧遇到了发帖失败的问题,现象比较诡异。经过追查发现是操作系统刷磁盘时,阻塞write系统调用导致。本文主要分享问题追查过程,希望对大家日常工作中定位问题有一定帮助。
TAG:
提交、问题追查、脏页
1 背景
很久前知道上有个问题:“从前天开始,跟帖就是发帖失败,换个ID开始能发,后来又变成发帖失败,很迷惑。谁知道怎么回事么。是系统问题么,还是网络问题?”最佳答案是:“很大部分是网络出现问题,你可以重新提交下就可以了”。
前段时间,贴吧的提交UI老是报警,晚上的时候手机叮叮咣咣地响,每次看都是apache进程数上千hold不住了,只好逐台重启。后来OP怒了,直接写了个脚本,发现apache进程数上来就自动重启。
好景不长,某天图1被PM截下来发到群上,自己发几个贴测试下居然复现了!看来真不是网络的问题,必须好好追查下了。
浅析App Engine (2012-7-12 01:07:02)
标签: app engine , paas , 云服务 分类:贴吧技术
摘要:
在国内外,云计算正在大步的走向商业化的道路,也得到了越来越多公司的重视。其中平台即服务(Platform-as-a-Service PaaS)已经称为业界探讨云计算的热点方式之一,采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式。本文主要是对App Engine的背景、特点、需求等进行分析整理,并据此对业界主要的App Engine进行了调研分析。最后对一个完善的App Engine进行了需求的细化分解、架构设计,并针对App Engine的部分核心技术问题提出了解决方案。
关键字:App Engine、PaaS、SAE、Nginx、scribe、Hadoop、Storm、Ptail、Scribe
HTML5技术的调研以及贴吧应用总结 (2012-7-12 01:07:21)
贴吧在进行HTML5技术应用的过程中,进行了一系列的技术调研;本文对HTML5的技术调研进行总结,尽可能客观的分析解答对HTML5技术的一些疑问,给出产品、技术上的一些决策建议。
对于文中的内容以及表述,也热切希望能得到大家进一步的指正和交流。
1. HTML5的发展现状及趋势
1.1 HTML5简介
HTML5是一套技术标准、规范,它定义了一系列的API编程接口和HTML规范(本文中将CSS3也默认涵盖到HTML5的技术范畴);HTML5的运用和推广,需要依赖于各个浏览器厂商对HTML5的支持力度。
详细介绍请参看百度百科:
http://baike.baidu.com/view/951383.htm
无线webapp安装更新机制 (2012-7-12 01:07:07)
摘要
为了满足移动终端:节省流量、减少请求、提高客户端性能的需求,我们设计了webapp安装更新程序,把js、css、html和图片这些资源,序列化为字符串存入客户端本地存储,并带上版本号来实现资源细粒度更新。
TAG
webapp 安装启动 性能优化
1、概述
我们认为webapp是一站式的应用,在一个页面里能完成整站的功能。所以,以前通过页面全刷的跳转,现在变成了通过底层框架来支持的局刷和切换动画。为了支持这些功能,会多出不少的代码,再加上app里的功能代码,我们统称为资源,包括底层库js(zepto、iscroll、baiduTemplate等),通用ui组件和app功能性的js、css、html和图片。
如何处理一个页面里的这么多资源,才能降低对性能的影响呢?为此,我们设计了webapp安装更新程序,可以做到减少资源请求,节省流量,提升客户端性能。
lbs技术 (1)
分布式基础 (1)
前端技术 (13)
图像处理 (2)
多媒体技术 (3)
大型网站架构 (4)
存储技术 (1)
搜索引擎技术 (2)
搜索技术 (16)
数据挖掘 (3)
数据结构与算法 (3)
无线客户端技术 (1)
未分类 (11)
架构 (1)
框计算 (5)
浏览器技术 (1)
相关性算法 (1)
系统底层 (1)
编程技术 (15)
自然语言处理 (6)
贴吧技术 (21)
运维技术 (1)
©All Rights Reserved搜索研发部官方博客 Powered by WordPress Comments RSS Entries (RSS)