在我发表了《3B大战的启示》一文后，一些江湖上的技术高手对我说，我描述的那种元搜索现象虽令人不屑，但在现实中是不使用的。除了道义层面的原因之外，多网站同步等待和实时整合耗时等技术原因，会使用户体验变得很差。实际上，时代不同了，如今完全可以有更好的技术方案。

    听下来，方案大体是这样的：如果你是浏览器厂家，你可以使用浏览器log。当搜索用户向任何一个搜索引擎发送了搜索指令之后，在传回的结果页面上再行点击（“点出”），浏览器不仅记录下来了你去哪儿，同时也记录下来了你去的那个地方与前面搜索关键词的关联。只要把这个信息传回浏览器厂商自家的搜索引擎，就可以提高搜索效果。

    使用浏览器log和使用浏览器本地缓存的搜索结果页面的差别，有这么几个：第一，传输的数据量小了很多；第二，无关信息噪音信息得到了极大的过滤；第三也是最重要的，用户的“点出”动作是在返回结果的基础之上增加了用户自身的选择和判断，相当于给出了“相关反馈”。

    虽然没传输原来的结果页面，但是这个相关反馈单独拿来用，质量已经优于结果页面了，更何况浏览器厂家可以八方汇聚——任何其他用户对同一组关键词的相关反馈都会汇聚在服务器端，相当于利用群体智慧的“众包的”相关反馈。这样得到的相关反馈集合，当然比结果页面更加精纯。

    好了。技术方案讲完了。拍手叫好之余，我们来分析一下它的实质。

    无论是用户首次发起、结果被服务器用于受理后续搜索请求的元搜索，还是服务器主动发起、结果被服务用于受理后续搜索请求的元搜索，都有一个特点，即元搜索在先、离线，搜索服务在后，在线，但后者使用前者积累的缓存数据。这两种，都属于搜索与元搜索结合，实时与离线结合的范畴。我的观点是，这种技术路线有它独特的技术含量，有增值。但是，缓存使用带来的保鲜性管理问题，用户数据使用带来的法律问题，其他搜索引擎智力成果使用带来的法律问题都一个不少。合理分配各方的利益，是解决的关键。

    比起我讲到的那些方案，这个使用浏览器log的方案，本质上并没有脱离“搜索与元搜索相结合、实时与离线相结合”的范畴。源搜索引擎（注意！此“源”非彼“元”）对于查准率的贡献是主要的，没有初次的返回结果，用户的相关反馈就无从谈起。虽然在传输上回避了直接使用初次的返回结果，但促使用户做出自己的相关反馈的最初信息来源，是源搜索引擎的返回结果列表。巧妇难为无米之炊，用户的相关反馈虽然形式上独立于源搜索引擎的返回结果列表，但是后者构成前者的“巨人的肩膀”。假如不给源搜索引擎以相应回报，反而分散其流量，用“过河拆桥”来形容这种做法，并不为过。

    用户本人对于相关反馈的选择，也对最终的查准率做出了贡献。一个用户的贡献度或许微小，为同一组关键词提供相关反馈的用户群体的贡献是难以估量的。而且，当用户群体扩大到足够规模时，这种众包行为对查全率也有不可低估的贡献。用户的智力活动沉淀为用户的访问记录，用户的访问记录原本是用户的私密数据。而今，这样的数据在用户不知情的状态下，被汇聚起来形成一种商业服务，但在利益分配中并没有显性地给用户以回报。这在法律上是怎样一种情形，相信大家都会做出判断。

    汇聚后的用户相关反馈，仍然是一种离线数据。这种离线数据本质上仍然是元搜索的缓存，只不过是通过众包过滤后的缓存。这种缓存一样要有保鲜期管理机制，当然比起爬虫爬下来的内容的保鲜期管理，相关反馈的保鲜期管理要轻便许多。

    另外，正像一些朋友所指出的，这种方法只对热词效果明显。遇到长尾查询，还是需要真功夫，爬虫、索引、排序，一个也少不了。

    综上所述，这种基于浏览器log优化搜索效果的方案，仍然属于“搜索和元搜索相结合、实时与离线相结合”的范畴。纯从技术上讲它有精妙之处。但它也要面对一些明显的技术问题和隐含的法律问题。不管事实如何，不管国外如何，在竞争中，个人建议还是慎用。