百度搜索研發部

時間 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...最舊 »