百度和Google的搜尋演算法 技術有何差異?

2022-10-04 10:57:37 字數 3320 閱讀 6789

網友提問:百度和 google 的搜尋技術是乙個量級嗎?

以下為網友布丁的回答:

先一句話回答:在與搜尋相關的基礎技術方面,百度距離 google 仍有很大的差距,但今天是否還存在量級上的差距存疑。

開頭先扯個不相干的領域,蘇聯 1960 年代裝備的 mig-25 截擊機,這是世界上第一款能飛雙三(三倍音速,30000公尺公升限)的戰鬥機。西方世界面對這**的效能引數驚詫莫名,推斷蘇聯在航空技術上已全面超越西方。直到別連科駕駛 mig-25 叛逃西方,他們終於有機會接觸真機,才發現它使用的技術其實沒那麼先進,**的效能指標都是用普通的技術基礎硬幹上去的,飛機非常笨拙以至有「直線戰鬥機」的稱號,可憐的發動機要真飛一次三倍音速落地就得報廢。蘇聯的航空技術並沒有他們想象的這麼逆天。

2023年我在百度,面對 google 公開的技術資料和百度的內部系統,我首先想起的就是 mig-25. 就跟這台戰機一樣,當時的百度,在中文搜尋結果質量的各項指標上,對比 google 還是有優勢。百度的工程師非常聰明,也非常努力,在某些點上也做得很細很出色,但是在與搜尋相關的基礎技術上,百度還是全面落後。百度的搜尋質量提高,有很大部分是依靠人工做大量細緻的策略cnarsj調整硬拉上去的。

用普通技術飛上雙三,mig-25 本身是個了不起的工程成就。下一代戰機,不管是蘇聯的 su-27 還是美國的 f-15, 乃至四代機 都沒有能飛出雙三來的,但這些下一代戰機在技術水準和整體效能上,無疑遠勝 mig-25, 這應該能算得上題主所說的量級差異。技術的量級差異不程式設計客棧能拿某個特定指標或孤例評估(mig-25 還曾擊落過 f/a-18 呢),也不能只比較某些技術點上的優劣,而往往是決定於基礎技術水平。

在 2009 年,我可以很肯定地說百度搜尋相關的基礎技術對比 google 有量級差距。據我了解,這些年百度在基礎技術方面進步很快,當然同時 google 也在快速進步。它們在今天是否有量級的差異,我不確定。

下面列幾個重要的而且公開資料較多的基礎技術:

大規模機群建設與管理。google 的情況可以參見《the datacenter as a computer: an introduction to the design of warehouse-scale machines, second edition》。 google 擁有世界上最大的計算機集群,論機器數量的話能在量級上超過所有其他公司。同時,它有一整套自動化管理軟體,以便工程師申請和使用這些硬體資源(大致可以理解成一套 amazon ec2)。就我的了解,現在在普通工程師使用機群硬體資源的方便程度和可以使用的量上,百度還是遠遠不及。

大規模計算與儲存。google **老三篇 gfs, mapreduce, bigtable 不再贅述,近年 google 在這些方面的研發和進步沒有停滯甚至在加快。當然百度也在努力追趕,百度不僅使用 hadoop, 而且基於 hadoop 做了大量改進和擴充套件,並貢獻回 hadoop 開源社群。百度在 ssd 儲存技術等方面也很有心得,比如 flash 儲存方面最近中了的一篇 asplos '14 sdf: software-defined flash for web-scale internet storage system.

機器學習和人工智慧。被吹得神乎其神的 deep learning 和 google brain 等等。在 deep learning 這個相對較新的領域,百度追趕的更快,水平也更接近。

機群管理的技術水平決定你能擁有和有效使用多少硬體資源,大規模計算與儲存決定你能在這些硬體上做多大規模的事情 —— 而最後,搜尋引擎本身就是一套大規模機器學習系統。

在純技術之外,我想特別提一點極大影響技術進步,而至少在 2009 年百度與 google 差距巨大的因素:普通工程師所能使用的工具水平。我在 google 感覺最爽的事情是我可以很容易獲得大量的計算資源,做以前無法想象的大規模資料分析。要驗證乙個想法,我可以基於一整天的搜尋記錄做分析,只需幾分鐘就能得到結果(可檢視:research.google.com/pubs/pub36632.html),進行調整和下一步分析;而如果沒有這套基礎軟體和可以隨意使用的硬體資源,我可能得等一整天才能有結果,或者只能分析小規模的抽樣資料。在我自己的知識和技術水平不變的前提下,google 這套系統極大地提高了我的工作效率,讓我能做到以前完全無法想象的事情。

我覺得作為乙個技術人員,黑或者捧哪個公司毫無意義,技術的事情很直接的,身在哪個公司都無法影響基本判斷。還在百度的時候,我就經常想,mig-25 的故事是個很好的警示,人很容易為類似「雙三」這樣的成就沾沾自喜,而對實打實的基礎技術差距視而不見,不圖進步,那前景就相當危險了。幸好據我所知的情況,百度可沒有這麼不爭氣。

補充乙個實際例子來說明不同技術條件下兩個公司做事思路的區別。

評論中有朋友提到百度的分詞技術,這確實是「百度更懂中文」的乙個集中體現。百度當年做分詞的時候很可能是這樣的:先從乙個人工編輯好的字典開始,用這個字典跑一些網頁,觀察分析裡面的 bad case —www.cppcns.com— 可能是分詞過細,或者是中文人名沒分出來,然後就嘗試根據中文語法規律加入規則或新增詞表解決這些 bad case, 如此往復,直到有滿意的結果。上線應用,發現有新的 bad case 就再研究加規則,當然也有自動流程發現和確認如「人艱不拆」之類的新詞。

google 做分詞的話就是把問題看成乙個概率問題:如果中文網頁中哪些字經常一起出現,那麼它們很有可能就是乙個詞。看哪些詞後面會跟的地得,的地得後面有常跟哪些詞,語法結構也就出來了。(具體的模型參見吳軍《數學之美》)。解題思路就是把所有抓到的中文網頁往 mapreduce 裡一丟,引數算出來就好了。評估分詞質量的方法也很簡單,就拿新模型放到網頁檢索的模型裡,做個實驗看質量有沒提公升就行。這套方法結果之好,基本把中文分詞做成了乙個沒有多少懸念的簡單問題,而且基本不需要中文語言專家的參與(自然也沒有誰更懂中文的問題)。同時這也就是 google 做 translate 的思路。這裡面基本方法其實非常簡單,沒什麼秘密可言,但是你得先有這麼多的網頁資料,還得有大機群,有分布計算框架,還有可復用的模型……

我認為在技術受限的條件下,人工微調優化結果是乙個恰當的產品思路,但這個產品思路會與技術發展路線www.cppcns.com相互影響。對於長尾頭部的一千個熱詞,完全可以用人工編輯的方法做出非常好的結果,而短期內改進通用的機器模型達到人工編輯的效果幾乎不可能。這時候,人工調整可能會受鼓勵,而通用模型的技術改進可能就得不到足夠的重視 —— 雖然即使以中國的人力成本,對所有搜尋結果人工調優也絕無可能,但能搞定長尾頭部也不錯了不是?google 的主流技術思路則是骨子裡不相信人工調整,什麼事情都非得弄出個自動通用可擴充套件的模型來不可,這種思路可能一開始在那一千個熱詞上怎麼都比不過勤勞接地氣的編輯,但通過積累資料調整模型,假以時日,整體結果質量就會顯著提公升 —— 我就是這麼看 2009 年時 google 搜尋質量給我們的壓力的。這種思路在具體的產品運營上不一定對,不是人人都有 google 的資源來花時間做通用技術,但 google 確實就在這種「技術碾壓一切」的(錯誤?)道路上越走越快。

本文標題: 百度和google的搜尋演算法、技術有何差異?

本文位址:

百度 google的垂直搜尋

google 這樣的搜尋引擎裡面,其實已經包含了垂直搜尋的概念。1 天氣 ip 所在的城市的天氣。google 沒有直接返回。2 在google 中搜尋 五糧液 出現的是 000858 五糧液 深圳交易所 谷歌財經 網易財經 和訊東方財富 之星 金融界 27.32 0.33 1.19 4 月 29 ...

Google和百度的推廣策略

google的推廣策略是什麼呢?1 新聞推廣 google為什麼能夠這麼多新聞呢?1 google的核心文化就是創新,google需要讓使用者感覺到它在不斷的創新,所以google不斷的推出新的產品和服務,然後以公關稿的形式發出來。2 目前google已經非常大了,圍繞著google發生的事情也非常...

測試360 google 百度搜尋

圖 openstack中國行 深圳站 在3wcoffee舉行 圖 cosug社群負責人,sae技術經理 程輝 圖 香港數碼港雲計算工程師 駱文鐘bruce 駱文鐘負責香港數碼港科技中心openstack iaas公有雲平台開發和運營,目前其已經投入生產環境使用。bruce亦積極將開源雲軟體opens...