2014.06.23：不知為什麼這個答案下突然多了很多讚和評論，來補充信息答謝觀眾。 關於繁體字問題，我是廣東人，看香港電視長大，簡繁體對我閱讀沒有什麼影響，在我眼裡更無高下之別，我用繁體字寫這篇回答的唯一原因就是當時輸入法的狀態是繁體…… 為保持一致正文補充依然為繁體，盼見諒。
前百度員工，現 Google 員工，在兩個公司做的都不是搜索相關項目。
先一句話回答：在與搜索相關的基礎技術方面，百度距離 Google 仍有很大的差距，但今天是否還存在量級上的差距存疑。
開頭先扯個不相干的領域，蘇聯 1960 年代裝備的 Mig-25 [1] 截擊機，這是世界上第一款能飛雙三（三倍音速，30000米升限）的戰鬥機。西方世界面對這變態的性能參數驚詫莫名，推斷蘇聯在航空技術上已全面超越西方。直到別連科駕駛 Mig-25 叛逃西方，他們終於有機會接觸真機，才發現它使用的技術其實沒那麼先進，變態的性能指標都是用普通的技術基礎硬幹上去的，飛機非常笨拙以至有「直線戰鬥機」的稱號，可憐的發動機要真飛一次三倍音速落地就得報廢。蘇聯的航空技術並沒有他們想象的這麼逆天。
2009 年我在百度，面對 Google 公開的技術資料和百度的內部系統，我首先想起的就是 Mig-25. 就跟這臺戰機一樣，當時的百度，在中文搜索結果質量的各項指標上，對比 Google 還是有優勢。百度的工程師非常聰明，也非常努力，在某些點上也做得很細很出色，但是在與搜索相關的基礎技術上，百度還是全面落後。百度的搜索質量提高，有很大部分是依靠人工做大量細緻的策略調整硬拉上去的。
用普通技術飛上雙三，Mig-25 本身是個了不起的工程成就。下一代戰機，不管是蘇聯的 Su-27 還是美國的 F-15, 乃至四代機 F-22, 都沒有能飛出雙三來的，但這些下一代戰機在技術水準和整體性能上，無疑遠勝 Mig-25, 這應該能算得上題主所說的量級差異。技術的量級差異不能拿某個特定指標或孤例評估（Mig-25 還曾擊落過 F/A-18 呢），也不能只比較某些技術點上的優劣，而往往是決定於基礎技術水平。
在 2009 年，我可以很肯定地說百度搜索相關的基礎技術對比 Google 有量級差距。據我了解，這些年百度在基礎技術方面進步很快，當然同時 Google 也在快速進步。它們在今天是否有量級的差異，我不確定。
下面列幾個重要的而且公開資料較多的基礎技術：
大規模機群建設與管理。Google 的情況可以參見 [2] 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 感覺最爽的事情是我可以很容易獲得大量的計算資源，做以前無法想象的大規模數據分析。要驗證一個想法，我可以基於一整天的搜索記錄做分析，只需幾分鐘就能得到結果（參見 [3]），進行調整和下一步分析；而如果沒有這套基礎軟件和可以隨意使用的硬件資源，我可能得等一整天才能有結果，或者只能分析小規模的抽樣數據。在我自己的知識和技術水平不變的前提下，Google 這套系統極大地提高了我的工作效率，讓我能做到以前完全無法想象的事情。
我覺得作為一個技術人員，黑或者捧哪個公司毫無意義，技術的事情很直接的，身在哪個公司都無法影響基本判斷。還在百度的時候，我就經常想，Mig-25 的故事是個很好的警示，人很容易為類似「雙三」這樣的成就沾沾自喜，而對實打實的基礎技術差距視而不見，不圖進步，那前景就相當危險了。幸好據我所知的情況，百度可沒有這麼不爭氣。
2014.06.23: 補充一個實際例子來說明不同技術條件下兩個公司做事思路的區別。
評論中有朋友提到百度的分詞技術，這確實是「百度更懂中文」的一個集中體現。百度當年做分詞的時候很可能是這樣的：先從一個人工編輯好的字典開始，用這個字典跑一些網頁，觀察分析裡面的 bad case —— 可能是分詞過細，或者是中文人名沒分出來，然後就嘗試根據中文語法規律加入規則或添加詞表解決這些 bad case, 如此往復，直到有滿意的結果。上線應用，發現有新的 bad case 就再研究加規則，當然也有自動流程發現和確認如「人艱不拆」之類的新詞。
Google 做分詞的話就是把問題看成一個概率問題：如果中文網頁中哪些字經常一起出現，那麼它們很有可能就是一個詞。看哪些詞後面會跟的地得，的地得後面有常跟哪些詞，語法結構也就出來了。（具體的模型參見吳軍《數學之美》）。解題思路就是把所有抓到的中文網頁往 MapReduce 裡一丟，參數算出來就好了。評估分詞質量的方法也很簡單，就拿新模型放到網頁檢索的模型裡，做個實驗看質量有沒提升就行。這套方法結果之好，基本把中文分詞做成了一個沒有多少懸念的簡單問題，而且基本不需要中文語言專家的參與（自然也沒有誰更懂中文的問題）。同時這也就是 Google 做 Translate 的思路。這裡面基本方法其實非常簡單，沒什麼祕密可言，但是你得先有這麼多的網頁數據，還得有大機群，有分佈計算框架，還有可復用的模型……
我認為在技術受限的條件下，人工微調優化結果是一個恰當的產品思路，但這個產品思路會與技術發展路線相互影響。對於長尾頭部的一千個熱詞，完全可以用人工編輯的方法做出非常好的結果，而短期內改進通用的機器模型達到人工編輯的效果幾乎不可能。這時候，人工調整可能會受鼓勵，而通用模型的技術改進可能就得不到足夠的重視 —— 雖然即使以中國的人力成本，對所有搜索結果人工調優也絕無可能，但能搞定長尾頭部也不錯了不是？Google 的主流技術思路則是骨子裡不相信人工調整，什麼事情都非得弄出個自動通用可擴展的模型來不可，這種思路可能一開始在那一千個熱詞上怎麼都比不過勤勞接地氣的編輯，但通過積累數據調整模型，假以時日，整體結果質量就會顯著提升 —— 我就是這麼看 2009 年時 Google 搜索質量給我們的壓力的。這種思路在具體的產品運營上不一定對，不是人人都有 Google 的資源來花時間做通用技術，但 Google 確實就在這種「技術碾壓一切」的（錯誤？）道路上越走越快。