谷歌南非区原负责人斯塔福德·马斯不久前表示，谷歌传统搜索业务正在萎缩，其原因主要是人们正通过Facebook、Twitter和Tumblr等社交网站进行搜索查询。而最关键的是，他们获得了更加理想的结果。社会化媒体和搜索引擎的结合将如何演进？未来的搜索将如何改变人们的信息获取方式，并进而影响人们的生活。云云网技术副总裁孙峥表示搜索引擎现阶段还蕴藏着巨大潜力，需要我们慢慢摸索与研发。搜索中容纳社交化将会打造出更完善、优秀的搜索引擎，并且指出社交化搜索面临的挑战，阐述其云云网对挑战的解决方案。
搜索引擎蕴藏广阔的发展空间
以谷歌和百度为例，比较两个搜索引擎某些方面优势和劣势，很少有人说搜索不给力，没有达到要做的事。孙峥认为实际原因是，因为搜索是非常新的东西，我们用的过程中才知道搜索引擎给我们带来什么？在这个过程中我们对搜索引擎期待基本上仅限于他们给我带来的东西。可能有想象力的人有一部分延伸。但真正从搜索引擎来说，实际上我们真正刚开始，我们看到一块很可能就是冰山一角，还有很大的发展空间。
让我们看看谷歌搜索结果原则是什么？你把搜索结果通过邮件发给别人，别人点开后显示的结果基本上是没有变化。当然也可能存在一些小差异，比如语言设置不同，或者国家设置不同都会影响显示结果。
搜索引擎并不知道谁在使用，所以搜索引擎能依赖个性化信息很少。而搜索引擎公司也没有理由去收集个人个性化信息，因为内容少而且设计隐私。如果说个性化搜索，让每个看到搜索结果，看到每个搜索词贴近。中间有一个步骤，社交化搜索，为什么？因为你一个用户，在你的社交网络里面更加行为，包括你写什么？给谁交朋友，或者朋友说什么？从搜索引擎表露出来都是你的事，表现你对某一种信息倾向性。这些信息他是公众化，不是偷偷把你的搜索词都记下来，怎么样能够复制你的搜索结果。这些是公众化信息是可以用，总的来说这是比较公开化信息。 它为个性化搜索，个性化服务提供一个一定的基础，它能彻底解决个性化搜索，但是从一定角度解决了个性化搜索。
社交对搜索的帮助
第一点，社交关系，可分为单方向和双方向，对用户进行了一种切分，用户切分其实很重要。举一个例子，电影推荐，或者豆瓣，一些美国公司用这些东西，它对你个性化推荐。因为反胃比较窄，无论电子产品也好，电影也好，通过各种各样的是能够对你人进行切割，能知道你喜欢看恐怖电影，或者喜欢战争电影等。
但是，搜索是一个五花八门什么都可以搜，你不一定只能搜电影，你把那个区间扩大，发现这个东西其实很难做。怎么能够对你这个用户进行切分，这一点很困难。对搜索引擎来说，据我所知不会做这样的尝试。但是，用户的关系是一部分关系，我的关注周围朋友，这些朋友的关注点可能跟我关注点一致，至少一部分朋友跟你一样，否则你交的朋友的原则非常奇怪。
第二点，用户倾向。我希望看到什么样的东西？哪怕对同一个关健词希望看到什么样结果？什么类型结果，这个可能也是类似。搜索基本有几点：覆盖度，时效性，准确度。
覆盖度，搜索引擎能扩充多少个网页。在搜索中也存在遗漏的情况，可能是排序的问题。也可能是搜索引擎真的没看到这个网页，这个属于抓取问题。所谓的机器爬虫，他找认为重要的东西，给搜索过来。这个机器发现过程，其实可以给社交网络人工推荐和引用。
时效性搜索引擎也是很大的问题，因为我们知道所谓点击，影响搜索结果，这些东西都是需要积累。时效性能解决一定能够被社交网络解决，社交网络有很多东西，能够把一个很新东西立刻炒热。
准确度，搜索词虽然都一样，但是其中有一些主观信息，实际可以通过社交网络行为得出。
社交化搜索面临的难点：数量多，变化快，因素多
每一个网站或是网页，都装载着大量的信息量，搜索是如何抓取的呢？其实这是结构性的变化，结构复杂化。原来我们用户看到网页和网页之间的联系，网页搜索就是这么做，里面包括信息，以及其他网页指向它的信息，这两个基本构成网页搜索主要元素。
网页里面的字以及它们之间的关系，有很多搜索引擎优化都在这上面简单一些延伸。现在，我有很多网页，网页又有人，人又会说话，说话跟一些网页发生关系，这就比较复杂。人对这个网页有什么操作？涉及到人跟人的关系，这意味着在计算方面变的更为复杂。人跟人之间关系也不相同，有各种各样不同的圈子，有的是关系造成，有的不同的兴趣造成。
关健词和意见领袖也存有微妙的关系，我们搜索的时候，关健词加上其他信息，能得到一个很好的搜索结果，我们把他送到用户面前。现在，它有别的关系，当你在社交圈，或者用社交网络里面信息进行搜索，涉及到人，谁是意见领袖，这也很重要。
意见领袖涉及到他的方向，他的哪些方向是意见领袖，把这个事情搞的更复杂，搜索变成一个多方位东西。所以，重复刚才一点，数量大还是数量大，你还得社交化搜索，实际上是网页搜索一个延伸，网页搜索做的基本功必须做。但是社交内容变化比网页内容变化快很多。另外，因素多，有各种各样人的关系，是不是意见领袖，是不是关健词匹配，比原来网页搜索复杂了很多。
解决方案
怎么解决数量多，变化快，因素多的问题呢？
其实，数量大就是向我们做网页搜索一样，我们分库，一个搜索引擎几千台机器，每台机器只管一部分网页，所有拼在一起构成这个网页搜索。
变化快，结构分级。比如说这个可能是所谓基础库，是最重要一些网页，那么他不见得每天更新，可能是搁几天更新一次。这个所谓扩展库，大库，各个公司向显然有不一样的称呼。他更新更慢，或者十几天，或者1个月更新一次，但是他量比较大，他是主要的搜索引擎一个库。另外，需要做一个实时库，为此社交内容专门建一个社交的实时库。
因素多，怎么能够当你搜索词进来发送到各个不同的情况。我们有50条或者更多条的结果，需要挑选出最终10条结果给用户。你中间怎么选择，怎么把这些不同性质的结果融合在一起。首先需要你要具备网页搜索能力，因为我们最终做搜索，希望你的社交内容能够改善搜索。我们所有社交网络，他里面提供绝大多数信息部具备沉淀意义，它里面包含信息可能在网页搜索里面沉淀下来。社交网络提供很多信息，不具有沉淀，不具有能够改善搜索品质。那么，你要建一个社交网络基于信息沉淀，知识沉淀，这个需要自己做。总的来说你可能在现在尝试，你可能需要尝试做自己的搜索。
而云云网对社交化搜索做了一种尝试，现在属于测试阶段。我们是把社交和搜索做在一起，我们为什么要做社交？
第一，因为我们希望做出来是一个具有知识沉淀，又有广度，能够对搜索产生足够帮助一个库，并且有社交功能。我们认为百度知道里面的内容，已经太多了，但是它没有社交内容在里面，你并不知道你该去相信哪个结果。
第二，不知道怎么去搜索一个东西，很多人看到一个人的结果，能和他写的这个答案能够交互一下该多好。实际上他没有百分之百解决我的问题，但是他的答案给我应该知道我最终想要的问题某一个细节，社交化帮助你解决这个问题。
第三，基本信息单元，由网页变成网页加人，达到个性化，并不是意思说它把个性化搜索做到极致。社交化搜索只是个性化搜索中间某一个部分，从某种意义上来说门槛比较低。充分个性化表现在每个人搜索结果的时候，它的结果不一样，因为他有社交化的信息。SNS用户提供的内容主要分两种，一种就是分享，一种就是答案。他们通过话题组织和沉淀，通过这个来组织内容，这个能解决什么问题？解决我们UGC过于分散的问题，我们需要一个盒子进行组合。社交化搜索基于社交和搜索，搜索页面有很多社交内容，我们以后会加更多的社交内容。
提供技术上一个解决方案，所有搜索引擎都是前端跟后端，后端分成全网页库，可能他最终分更多的级。可能我们有一个高质量网页库，有一些更重要网站，我们爬的更频繁，我们建索引更频繁。它在搜索的时候，肯定会被优先检索。
第四，社交文档库。这些东西都是用户提交的内容，它从很多性质来说跟网页很不一样，虽然也说了那样一些话，说的话可能在另外一个网页里面完全一样，但是我们有他所有社交关系，有更多的信息，我们有很多网页搜索没有的信息，把他建一个单独的库，里面有不同的算法完全检索和排序。
第五，实时社交文档库。大家知道搜索从最基础概念来说，你建索引是静态还是动态，在某种意义上他是不可写。在此基础上为了完成时效性搜索，你会建一个更小子库。它就是比较小，更新频率高，它库里的内容会快速进来，过一段时间会被排到高量网页库。建一个比较完备搜索引擎，你可能还需要各种各样的其他子库，比如图象搜索库，比如视频搜索库，还有其他。对于实时文档里面的实时信息，需要针对每个人搜索、行为，通过数据挖掘以后，能够产生不同的参数。这些东西需要搜索整合层，基于我对用户的理解，需要那些库找相关的信息，然后拼凑起来。
开源检索系统Sphinx的定制化排序
SNS时代，对于传统的站内检索系统带来了新的需求。为适应这一需求，Coreseek创始人李沫南为我们介绍开源检索系统Sphinx在用户导向（个性化排序）方面的进展和优化方式。
李沫南首先谈到建立一个全文搜索需要的基本五步骤：第一步是内容采集问题；第二步需要对文本切分；第三步查询解析；第四步排序和过滤规则，第五步Harmony。
继而谈到，现在是微博时代，需要考虑进一步检索会出现哪些排序机制，所有信息排序历史归根到底引入一些外部信息量过程。
从第一步基本磁条信息，到第二步考察磁条文章长度，考察出现频率。第三步，UR和UF之间的的投标，第四步作者权威度。
为什么要这么做？以IBM为例，当时IBM中国区总裁他有一次在网络论坛上发一篇帖子，他一年下来整个帐户生命周期一共有几篇，但是这个重要度远远超过所有人的发言。因为老大很忙，他们很少发言，统一的排序就不是很好工作。
第二个，很本质的问题，计算机系统除了统计量以外，缺少很丰富的背景知识。我们基于传统排序，得到结果并不是永远最好。我们传统搜索技术也有了一个新的概念，就是分析，根据用户点击流进入一个重新的改善。这一部分来讲，我们检索开源的系统里面，这个排序我们做的工作。
一般做搜索引擎的时候，比如典型我们在做职位搜索的时候，可能按照地区做过滤，可能按照薪资要求过滤，在后续我们根据这个过滤这一块，把这部分先过掉，这个前后顺序并不一定在Field，也许有可能在TF/IDF之前。Filter这个来讲，这一块来讲解决这个问题，提供一两个接口。
这个是我们所经常看到一些为什么我们所需要做定制排序的原因。为什么做垂直搜索、网站搜索的时候，我们在传统相关度排序以后，我们依然要做其他一些定制排序，用按时间来排。怎么解决这个问题？
我们做搜索的时候，第一个匹配模式，第二个排序模式，这些所有匹配的文档应该按照什么样顺序排前后关系。在Sphinx按照用户表达来做排序，这个描述表达是什么？是第一部分变量，引入了这个文档计算出来一个全职。第二个部分引入作者，相当于我们带来作者他在这个领域里面权威度有多高，这是我们CPO来说的，或者某个专家。第三个，我们考察这个来讲有多少热门，可能冲到以前全职计算。所有这些东西，全部引入这个计算算以后，会得到一个新的全职，我们按照新的全职做一次排序，返回给终端用户。用这方法基于业务系统规则定制化排序。
这个东西来讲，在绝大多数垂直领域搜索是很好一件事情，但是仍然会有不足。典型是什么？第一个虽然来讲目前有一款书是世界是平的，但是事实来讲世界并不是平的，我们每个人看到世界是他所希望看到的样子，怎么解释？我们每个人看到世界，跟我们看世界的方法，比如我这个人近视，如果摘了眼镜什么也看不到，我们了解信息的世界取决于我们工具，取决于我们思想方法。这一块来讲，对应搜索来讲也是一样，我们每个人对于结果分析能力，取悦与自己的额外特性。
第二种，物以类聚，人以群分。比如我是一个生物学家，我希望输入结果全部是蟒蛇。在没解决这个问题，没有办法按照刚才通过统计的排序机制来做。比如我60多个分类，必然有一个古生物分类，有一个程序员分类，我们确定来讲程序员来讲，拿一个分类用他排序工程计算文档。再往后面，我们可以理解为一个产生意义上我们属于看中某一个人，谁过来以后，见人说人话，见鬼说鬼话。
再一个，我们处理社会化的问题。每个人的定位都不相同，我们从每个人大体上做分类，可以解决基本常见信息，每个用户是一类，这个时候来讲，传统搜索引擎可能不是太好办了。这个来讲对Sphinx特别简单，这一块如果解释清楚，可能大体上需要更进一步解释Sphinx里面，或者引擎内部构造。
在Sphinx这边来讲，他除了基本上到派索引以外，它把每个文档里面的属性，价格、点击量、类别这些东西作为属性，这样他把每个属性都存在内存中间，可以帮助我们修改他。但是在IPI调用里面，我们可以根据查询调查不同的属性。在工程上讲解决一部分问题，仍然会有其他额外的东西解决不了。
第一件事情，在目前这个接口上比较难处理的事情。
第二个问题，根据某些传统斗争经验，朋友的朋友是朋友，敌人的敌人也是朋友，这个时候我们简单通过一个EAPI调查，因为我没有确定根据朋友的朋友。
第三个问题，你的朋友未必靠谱，如果你是这个领域权威，和你交朋友这个人可能都是这个权威。
第四个问题，基于用户排序是否真有必要？
这个在产品上或者其他事情上是否有必要，具体来讲我们不是太会。举个例子，我们Sphinx这言来讲，在没有新浪微博之前，当时还在08年、09年的时候，曾经和上海一家公司合作，做了一个类似于SNS搜索，当时叫做找人搜索。这个公司产品理念什么？根据用户在互联网上留住蛛丝马迹，去计算这个人是否和你可以成为朋友，这个项目到后来来讲是很容易的失败了。有多方面原因，但是我们需要考虑，这种东西基于用户贡献内勤，是不是我们搜索需要通过他来做搜索。
我们回过头来看定制排序，和大家业务上比较有关系，定制排序第一个首先用户不同的搜索意图，决定不同的搜索规则。
典型来讲，我们用户输入一个词，一首歌的名字，可能更多时间或者搜他MV，或者MP3。我们对应来讲，对应网页库全部是下降，排序规则通过一个知识库系统来做。
第二个事情，任何情况下都没有完全的事情，比如说我们可能传统一台机器定制任务，我们现在可能需要更多，因为属性计算是内存完成，排序在内存里面完成。
第三个事情，一个非常数据量大应用，在专用场合可能需要户区别修改所有的结构，我们很典型一个例子，假定我们需要山寨新浪微博怎么办？一个核心问题在于我们怎么计算，在新浪里面实现两种模型，一种是推，一种是转，我们可以考虑把用户好友作为查询关健词，放在引擎里面搜，这个点做出来没有问题，但是性能可能有问题。是因为搜索引擎目前的结构，它的写的索引的顺序，倒排序从小到大，带来个问题，我们新用户新发内容，或者新发的微博会写到最后。
如果我们对索引没有做很好的切分，就会额外带来问题，我们每个词解这个倒拍索引表的时候，会导致他消耗特别长一个CPU时周，这种情况我们具体点到这一块很明确。在特别高数据量高树栽情况下，如果应用本身属于排序，很固定那种，不会用户选AB都可以，或者几种排序，根据这个情况去修改索引文件结构，根据可以修改倒排序存储方式。
发表评论 评论 (0 个评论)