百度搜索研发部

时间 2019-11-12

标签百度搜索研发繁體版

原文原文链接

首页php
关于咱们css

百度开发者中心百度开放V计划百度技术沙龙html

基于机器学习的知道推荐—Enlister (2012-11-07 06:11:29)前端

标签：分类：未分类html5

基于机器学习的知道推荐—Enlistermysql

— trisunlinux

Enlister—最大的中文问答网站“百度知道”的问题推荐系统名字。这个由几个百度一线工程师研发的系统，自2012年1月上线以来，承担着百度知道千万级登陆用户的问题推荐计算。nginx

问题的开始web

百度知道这样的问答社区型网站有个典型特色：有些用户在平台上提出问题，这些问题被另外一些用户发现，其中有能力且有意愿的人回答了这几个问题。这几个问题及其解答在平台上沉淀下来，持续给后来有相关问题的搜索用户提供着解答，并激励着更多用户将本身的问题发布在平台上。算法

像这样的系统就是一个自生态系统，有人生产，有人消费（如图1）。若其中一个环节出现问题，都会致使这个生态异常。在如今的百度知道上，每日有几十万的新问题正在提出，又有近百万左右的在涌现，而浏览这些知识的人天天有上亿。最可能出问题的地方在于，问题被提出之后，解答没法知足甚至鲜有人问津，这不利于解决提问者的疑惑和知识的沉淀。

图1

面对这样问题，提高回答量是最直接的办法，回答量上升了，有价值的回答数量就会成比上涨。“回答”是一个高门槛的事，是contribute而非consume。排除这个问题，若用户自己在发现待回答问题上，还须要太高的付出（例如搜索、或按分类查找，如图2），那着实让大量有能力和意愿但不想花更多时间在查找问题上的人望而却步。而推荐，就是咱们一把杀手锏。

图2

说到推荐

有了推荐，就有了地基，如何设计楼宇有更多细节须要解决。作推荐须要密切结合产品，是恒古不变的真理。详细了解了知道的产品和目标后，咱们提出了三个该系统核心：

一、基于内容

新问题一旦被提出，其解决就刻不容缓。高时效性要求了必需要以准确的内容分析为基础。

二、 CTR预估(Click Through Rate，点击率预估)

为了提高回答量，咱们可考虑提高点击量，在用户量和回答率不变的基础上，间接提高了回答量。另外，CTR预估是咱们擅长的技术，是咱们的一大优点。

三、流式计算

为了适应新问题实时推送，咱们设计了以问题数据为主数据流的推荐系统，保证了新问题在分钟级时效性内推送给目标（如图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值来进行排序，则使得整个列表看起来同质化比较严重：

一、很多问题的标题很接近，在列表中排序也可能很邻近；

二、用户可能包含几个兴趣点，但最终列表（特别头部）集中了大量问题只属于一个兴趣；

实验代表，这些问题会严重影响用户体验，下降用户持续回答的欲望。咱们则采用了一种多样化列表构建方法，以CTR为基本排序依据，但在列表头部尽量的保证推荐的相关性。当一个新问题插入头部时，只要和周围标题不是很是接近均可插入，让用户能首先看到的列表前部看起来推荐很“准”；而在非头部区域，则增强对邻近问题类似过滤，让更多的兴趣点能得以展示，用户看起来以为很“多样化”(如图9)。

图9

总体系统

除了以上几点须要考虑以外，咱们作一个线上的推荐系统还须要考虑如spam屏蔽、某些业务逻辑、用户反馈等问题。如图，在多样化列表构建时，加入业务逻辑模块，过滤spam问题，对一些高价值问题的展示进行优先或对用户点击删除或不太喜欢的关键词进行屏蔽、降权。图10中RP部分是推荐引擎，iknow部分是产品线。

图10

图11是系统上线前与上线后（201201）回答量的一个对比。原有推荐系统基于中心词计算距离类似进行推荐，日均回答量不足8万。Enlister上线后回答量持续攀升，至6月份后稳定在19万左右。

图11

蔡晶/文

阅读全文>

阅读(30,235) ┆ 评论(0)

解析nginx负载均衡 (2012-7-27 06:07:57)

标签： nginx , webserver , 负载均衡分类：未分类, 贴吧技术

摘要：对于一个大型网站来讲，负载均衡是永恒的话题。随着硬件技术的迅猛发展，愈来愈多的负载均衡硬件设备涌现出来，如F5 BIG-IP、Citrix NetScaler、Radware等等，虽然能够解决问题，但其高昂的价格却每每使人望而却步，所以负载均衡软件仍然是大部分公司的不二之选。nginx做为webserver的后起之秀，其优秀的反向代理功能和灵活的负载均衡策略受到了业界普遍的关注。本文将以工业生产为背景，从设计实现和具体应用等方面详细介绍nginx负载均衡策略。

关键字：nginx 负载均衡反向代理

阅读全文>

阅读(36,571) ┆ 评论(0)

漫谈社区PHP 业务开发 (2012-7-26 03:07:20)

标签： lamp , 子系统拆分 , 开发框架分类：大型网站架构, 未分类

在当前这个互联网业务飞速发展时期，新的产品如雨后春笋般涌出，老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。

1、基础运行环境

针对新产品的开发，必须可以快速搭建一套LAMP架构。那么无外乎选择一个webserver，选择一个php版本，选择一个mysql版本，再选择一个PHP开发框架和选择一些php通用扩展和基础库等。这个过程读者可能以为已经很快了，能不能更快？

选择的过程要求研发同窗对相关技术方向有必定的积累，权衡利弊和优先点，又是一番调研和学习。若是有一键安装程序，提供自动化安装webserver，php，mysql，以及携带高性能灵活的php开发框架，并提供标准化、安全、经常使用的配置文件，能够大大缩短产品线LAMP系统调研的成本，缩短工做周期。

阅读全文>

阅读(20,822) ┆ 评论(0)

使用Weka进行数据挖掘 (2012-7-26 03:07:26)

标签： Weka , 数据挖掘分类：数据挖掘

1.简介

数据挖掘、机器学习这些字眼，在一些人看来，是门槛很高的东西。诚然，若是作算法实现甚至算法优化，确实须要不少背景知识。但事实是，绝大多数数据挖掘工程师，不须要去作算法层面的东西。他们的精力，集中在特征提取，算法选择和参数调优上。那么，一个能够方便地提供这些功能的工具，即是十分必要的了。而weka，即是数据挖掘工具中的佼佼者。

Weka的全名是怀卡托智能分析环境（Waikato Environment for Knowledge Analysis），是一款免费的，非商业化的，基于JAVA环境下开源的机器学习以及数据挖掘软件。它和它的源代码可在其官方网站下载。有趣的是，该软件的缩写WEKA也是New Zealand独有的一种鸟名，而Weka的主要开发者同时刚好来自新西兰的the University of Waikato。（本段摘自百度百科）。

Weka提供的功能有数据处理，特征选择、分类、回归、聚类、关联规则、可视化等。本文将对Weka的使用作一个简单的介绍，并经过简单的示例，使你们了解使用weka的流程。本文将仅对图形界面的操做作介绍，不涉及命令行和代码层面的东西。

阅读全文>

阅读(18,885) ┆ 评论(0)

前端重构实践（二） —— 模块化开发 (2012-7-26 03:07:58)

标签： js代码压缩 , 前端 , 性能分类：前端技术

前言：

在上一篇文章中我介绍了咱们对N产品性能优化的整个历程，主要偏重优化方法。本篇我将介绍在这一过程当中，咱们的代码出现了什么样的问题，以及咱们是如何经过前端重构来解决掉这些问题，并产生了哪些收益。

痛点：

按需加载为咱们的页面带来了很大的性能提高，但同时也为代码结构带来了很大的冲击，不少直接调用的方式被改成了模块化的调用形式（先判断模块是否存在，不存在就先加载对应的js，再执行回调）。

阅读全文>

阅读(7,922) ┆ 评论(0)

Gecko架构浅析之编码检测和转换 (2012-7-16 02:07:59)

标签： Gecko , 编码检测 , 编码转换 , 网络排版引擎分类：浏览器技术

一：前言简介

Gecko是一套网络排版引擎，由来已久，为当年大名鼎鼎的netscape网络浏览器流传而来，后面也成为了firefox浏览器，thunderbird等等软件的基础。详细的发展历程在这里就不展开作具体介绍了，读者能够自行查阅百度百科，维基百科等资料。

在这一章咱们重点介绍一下gecko中是如何对全球各类不一样的网页文档的编码方式来作出识别和转换的。

咱们知道，netscape或者firefox是面向全球用户的，而且，在互联网的世界，并无什么界限妨碍一个美国的用户访问中文或者日文的网页。因此，在这种场景下，浏览器是否能正确识别每一个地区的网页的编码格式，并正确地显示出来，就尤其重要了。

阅读全文>

阅读(6,113) ┆ 评论(0)

诡异提交失败问题追查 (2012-7-13 08:07:52)

标签： linux内核 , 系统调优分类：贴吧技术

摘要:

自四月份以来，贴吧遇到了发帖失败的问题，现象比较诡异。通过追查发现是操做系统刷磁盘时，阻塞write系统调用致使。本文主要分享问题追查过程，但愿对你们平常工做中定位问题有必定帮助。

TAG:

提交、问题追查、脏页

1 背景

好久前知道上有个问题：“从前天开始，跟帖就是发帖失败，换个ID开始能发，后来又变成发帖失败，很迷惑。谁知道怎么回事么。是系统问题么，仍是网络问题？”最佳答案是：“很大部分是网络出现问题，你能够从新提交下就能够了”。

前段时间，贴吧的提交UI总是报警，晚上的时候手机叮叮咣咣地响，每次看都是apache进程数上千hold不住了，只好逐台重启。后来OP怒了，直接写了个脚本，发现apache进程数上来就自动重启。

好景不长，某天图1被PM截下来发到群上，本身发几个贴测试下竟然复现了！看来真不是网络的问题，必须好好追查下了。

阅读全文>

阅读(9,116) ┆ 评论(0)

浅析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

阅读全文>

阅读(9,781) ┆ 评论(0)

HTML5技术的调研以及贴吧应用总结 (2012-7-12 01:07:21)

标签： html5 , 前端开发分类：贴吧技术

文档简介：

贴吧在进行HTML5技术应用的过程当中，进行了一系列的技术调研；本文对HTML5的技术调研进行总结，尽量客观的分析解答对HTML5技术的一些疑问，给出产品、技术上的一些决策建议。

对于文中的内容以及表述，也热切但愿能获得你们进一步的指正和交流。

1. HTML5的发展示状及趋势

1.1 HTML5简介

HTML5是一套技术标准、规范，它定义了一系列的API编程接口和HTML规范（本文中将CSS3也默认涵盖到HTML5的技术范畴）；HTML5的运用和推广，须要依赖于各个浏览器厂商对HTML5的支持力度。

详细介绍请参看百度百科：

http://baike.baidu.com/view/951383.htm

阅读全文>

阅读(7,424) ┆ 评论(0)

无线webapp安装更新机制 (2012-7-12 01:07:07)

标签： webapp , 无线分类：贴吧技术

摘要

为了知足移动终端：节省流量、减小请求、提升客户端性能的需求，咱们设计了webapp安装更新程序，把js、css、html和图片这些资源，序列化为字符串存入客户端本地存储，并带上版本号来实现资源细粒度更新。

TAG

webapp 安装启动性能优化

一、概述

咱们认为webapp是一站式的应用，在一个页面里能完成整站的功能。因此，之前经过页面全刷的跳转，如今变成了经过底层框架来支持的局刷和切换动画。为了支持这些功能，会多出很多的代码，再加上app里的功能代码，咱们统称为资源，包括底层库js（zepto、iscroll、baiduTemplate等），通用ui组件和app功能性的js、css、html和图片。

如何处理一个页面里的这么多资源，才能下降对性能的影响呢？为此，咱们设计了webapp安装更新程序，能够作到减小资源请求，节省流量，提高客户端性能。

阅读全文>

阅读(5,218) ┆ 评论(0)

第 1 页，共 10 页12 3 4 5 »10...最旧 »