先一句话回答：在与搜索相关的基础技术方面，百度距离 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 的故事是个很好的警示，人很容易为类似「双三」这样的成就沾沾自喜，而对实打实的基础技术差距视而不见，不图进步，那前景就相当危险了。幸好据我所知的情况，百度可没有这么不争气。
补充一个实际例子来说明不同技术条件下两个公司做事思路的区别。
有人提到百度的分词技术，这确实是「百度更懂中文」的一个集中体现。百度当年做分词的时候很可能是这样的：先从一个人工编辑好的字典开始，用这个字典跑一些网页，观察分析里面的 bad case —— 可能是分词过细，或者是中文人名没分出来，然后就尝试根据中文语法规律加入规则或添加词表解决这些 bad case, 如此往复，直到有满意的结果。上线应用，发现有新的 bad case 就再研究加规则，当然也有自动流程发现和确认如「人艰不拆」之类的新词。
Google 做分词的话就是把问题看成一个概率问题：如果中文网页中哪些字经常一起出现，那么它们很有可能就是一个词。看哪些词后面会跟的地得，的地得后面有常跟哪些词，语法结构也就出来了。(具体的模型参见吴军《数学之美》)。解题思路就是把所有抓到的中文网页往 MapReduce 里一丢，参数算出来就好了。评估分词质量的方法也很简单，就拿新模型放到网页检索的模型里，做个实验看质量有没提升就行。这套方法结果之好，基本把中文分词做成了一个没有多少悬念的简单问题，而且基本不需要中文语言专家的参与(自然也没有谁更懂中文的问题)。同时这也就是 Google 做 Translate 的思路。这里面基本方法其实非常简单，没什么秘密可言，但是你得先有这么多的网页数据，还得有大机群，有分布计算框架，还有可复用的模型……
我认为在技术受限的条件下，人工微调优化结果是一个恰当的产品思路，但这个产品思路会与技术发展路线相互影响。对于长尾头部的一千个热词，完全可以用人工编辑的方法做出非常好的结果，而短期内改进通用的机器模型达到人工编辑的效果几乎不可能。这时候，人工调整可能会受鼓励，而通用模型的技术改进可能就得不到足够的重视 —— 虽然即使以中国的人力成本，对所有搜索结果人工调优也绝无可能，但能搞定长尾头部也不错了不是?Google 的主流技术思路则是骨子里不相信人工调整，什么事情都非得弄出个自动通用可扩展的模型来不可，这种思路可能一开始在那一千个热词上怎么都比不过勤劳接地气的编辑，但通过积累数据调整模型，假以时日，整体结果质量就会显著提升 —— 我就是这么看 2009 年时 Google 搜索质量给我们的压力的。这种思路在具体的产品运营上不一定对，不是人人都有 Google 的资源来花时间做通用技术，但 Google 确实就在这种「技术碾压一切」的(错误?)道路上越走越快。
[1] Mikoyan-Gurevich MiG-25
[2] The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines, Second Edition
[3] Dremel: Interactive Analysis of Web-Scale Datasets