<?xml version="1.0" encoding="gb2312"?>
<rss version="2.0">
<channel>
<title><![CDATA[OSSou-开源搜索引擎研究]]></title>
        <image>
        <title>http://hi.baidu.com</title>
        <link>http://hi.baidu.com</link>
        <url>http://img.baidu.com/img/logo-hi.gif</url>
        </image>
<description><![CDATA[聚集网络上追求自由,热爱搜索的朋友,一起来做开源的搜索引擎!]]></description>
<link>http://hi.baidu.com/ossou</link>
<language>zh-cn</language>
<generator>www.baidu.com</generator>
<ttl>5</ttl>


<item>
        <title><![CDATA[开源搜索引擎论坛]]></title>
        <link><![CDATA[http://hi.baidu.com/ossou/blog/item/257a4eed203282d4b21cb174.html]]></link>
        <description><![CDATA[
		
		<p >开源搜索引擎论坛</p ><p ><a href="http://groups.google.com/group/osse" >http://groups.google.com/group/osse</a ></p ><p >今天在网上找到的一个相关论坛,虽说现在没什么人气,但我相信会有更多的朋友加入进来的,发出来,希望有这方面兴趣的朋友,加入到这个行列中来!</p > 
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/ossou/blog/category/%D5%BE%B5%E3%C8%D5%D6%BE">站点日志</a>&nbsp;<a href="http://hi.baidu.com/ossou/blog/item/257a4eed203282d4b21cb174.html#comment">查看评论</a>]]></description>
        <pubDate>2006-07-27  14:24</pubDate>
        <category><![CDATA[站点日志]]></category>
        <author><![CDATA[ossou]]></author>
		<guid>http://hi.baidu.com/ossou/blog/item/257a4eed203282d4b21cb174.html</guid>
</item>

<item>
        <title><![CDATA[我收集的不错的开源社区]]></title>
        <link><![CDATA[http://hi.baidu.com/ossou/blog/item/c6cf253fc43372ec55e72368.html]]></link>
        <description><![CDATA[
		
		<p >1.LUPA开源社区:&nbsp;<a href="http://www.lupaworld.com/index.html" >http://www.lupaworld.com/index.html</a ></p ><p >2.共创联盟:http://cosoft.org.cn/</p > 
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/ossou/blog/category/%CB%D1%CB%F7%D4%D3%C2%D2">搜索杂乱</a>&nbsp;<a href="http://hi.baidu.com/ossou/blog/item/c6cf253fc43372ec55e72368.html#comment">查看评论</a>]]></description>
        <pubDate>2006-07-27  14:01</pubDate>
        <category><![CDATA[搜索杂乱]]></category>
        <author><![CDATA[ossou]]></author>
		<guid>http://hi.baidu.com/ossou/blog/item/c6cf253fc43372ec55e72368.html</guid>
</item>

<item>
        <title><![CDATA[基于P2P的分布式知识网络(ZT)]]></title>
        <link><![CDATA[http://hi.baidu.com/ossou/blog/item/b5232a7384efba1c8601b06e.html]]></link>
        <description><![CDATA[
		
		<table class="fixedTable blogpost" cellspacing="0" width="100%" border="0" ><tbody ><tr ><td class="ellipse" ><span class="bvTitle" ><strong ></strong ></span ></td ></tr ><tr ><td class="bvh8" ><strong ></strong ></td ></tr ><tr ><td ><div ><div ><p >1、互联网2.0，并不止是“编辑方式改变”这么简单。</p ><p >2、网络媒体的特性在于信息易于大量生产、复制和传播。未来网络媒体特性还要加一条：大量冗余。这不光是前三条的附属品，它符合基于P2P的分布式知识网络的存储传播特性。</p ><p >3、基于P2P的知识网络，将对内容型网站实施沉重打击。无论原创式、拷贝式、精编式的内容站点，都会受其影响。</p ><p >4、Blog是“去中心化”过程中的一个阶段，但并非终极形式。从技术的角度来看，Blog内容本身将来可能也是分布式存储的。怎么删除？不知道，我只是提出一个预想。或者，到那时，就不用Blog了。</p ><p >5、每台电脑（或其他设备）上将有一个P2P终端。这个终端是分布式网络中的一个节点。它是搜索引擎、是浏览器、是IM、是SNS，或者也是其他一些应用。由所有节点加起来的整个分布式网络负责信息的存储和传递。</p ><p >6、信息将通过“漂流瓶”的模式传播。一种是主动式，一种是反馈式。主动式的例子：发表一篇文章、一条新闻；反馈式的例子：问一个问题。</p ><p >7、你的P2P节点将“主动抓住”流经本节点的、你可能关心的内容，例如，你朋友Blog的一篇新文章。通过新用户节点的信息量最大，因为它没有经过筛选。用得越久，阅读兴趣习惯就越被体现到过滤机制当中。如果你接受了一条信息，那么也有义务向其他节点传递这条信息。</p ><p >8、你的问题（或搜索请求）将被发送到其他节点，并得到反馈。反馈可能是人工的，也有可能是机器之间的握手。</p ><p >9、你可以发表一条信息（新闻？Blog？一段视频？一张相片？），该信息会在本节点存储，并向其他节点发送，当它被某个其他节点“抓住”时，也就在该节点上创建了一个冗余备份，该节点成为信息提供者。</p ><p >10、信息传递也许是多播的，但绝对不是广播的。简单的例子：源节点只随机向m个节点发送信息，这3个节点又分别向n个节点发送信息；为了保证请求不以几何级数扩张，在各个层级上，一些信息请求将依据某种规则“自动死亡”。信息回馈是直通的，即直接反馈给源头。</p ><p >11、基于P2P的分布式知识网络形成之日，就是内容型站点的沉没之时。去中心化的结果，就是自我中心化。你的P2P节点背后，是整个知识网络的存储。你可以按照自己的爱好、习惯和方式去组织内容，供自己阅读或是编辑后再传递出去。</p ><p >12、信用、评价和身份认证机制在该网络中至关重要。信用度高的用户，在网络中享有更高的权限。权限可能包括多播数量、在其他节点提取信息时的优先权等。</p ></div ></div ></td ></tr ></tbody ></table > <a href="http://hi.baidu.com/ossou/blog/item/b5232a7384efba1c8601b06e.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/ossou/blog/category/%BC%BC%CA%F5%D7%CA%C1%CF">技术资料</a>&nbsp;<a href="http://hi.baidu.com/ossou/blog/item/b5232a7384efba1c8601b06e.html#comment">查看评论</a>]]></description>
        <pubDate>2006-07-27  13:46</pubDate>
        <category><![CDATA[技术资料]]></category>
        <author><![CDATA[ossou]]></author>
		<guid>http://hi.baidu.com/ossou/blog/item/b5232a7384efba1c8601b06e.html</guid>
</item>

<item>
        <title><![CDATA[Nutch搜索引擎分析]]></title>
        <link><![CDATA[http://hi.baidu.com/ossou/blog/item/842250e749eb262eb838206d.html]]></link>
        <description><![CDATA[
		
		<span class="tpc_content" ><font size="2" >21世纪是信息的时代，也是网络的时代。不断通畅与进步的互联网在给人们带来浩如烟海的网络信息的同时，也容易使人在查询自己所需的有用的相关信息时陷入迷茫。搜索引擎正是为了满足人们网络信息搜索应运而生的网络工具，它是互联网信息查询的导航针。现在的商业搜索引擎不少，但都是保密的，不便研究。而Nutch 是一个开源Java 实现的搜索引擎，它提供了我们运行自己的搜索引擎所需的全部工具。<br /><br />&nbsp; &nbsp; Nutch是开放源代码的，因此任何人都可以查看他的排序算法是如何工作的。商业的搜索引擎排序算法都是保密的，我们无法知道为什么搜索出来的排序结果是如何算出来的。更进一步，一些搜索引擎允许竞价排名，比如百度，这样的索引结果并不是和站点内容相关的。因此 Nutch 对学术搜索和政府类站点的搜索来说，是个好选择。因为一个公平的排序结果是非常重要的。<br /><br />&nbsp; 了解一个大型分布式的搜索引擎如何工作是一件让人很受益的事情，但是我们并没有google的源代码，因此学习搜索引擎Nutch是个不错的选择。Nutch的核心部分目前已经被重新用 Map Reduce 实现，而Map Reduce 是一个分布式的处理模型，最先是从 Google 实验室提出来的。<br /><br />&nbsp; &nbsp; Nutch吸引了很多研究者，他们非常乐于尝试新的搜索算法，因为对Nutch 来说，这是非常容易实现扩展的。Nutch 非常灵活，它可以被很好地客户订制并集成到应用程序中。使用插件机制，Nutch可以作为一个搜索不同信息载体的搜索平台。当然，最简单的就是集成Nutch到你的站点，为用户提供搜索服务。<br /><br />&nbsp; 下面分析一下Nutch搜索引擎系统的特点。<br /><br />一、系统架构 <br /><br />&nbsp; 总体上Nutch可以分为2个部分：抓取部分和搜索部分。抓取程序抓取页面并把抓取回来的数据做成反向索引，搜索程序则对反向索引搜索回答用户的请求。抓取程序和搜索程序的接口是索引，两者都使用索引中的字段。抓取程序和搜索程序可以分别位于不同的机器上。下面详细介绍一下抓取部分。<br /><br />抓取部分： <br /><br />&nbsp; 抓取程序是被Nutch的抓取工具驱动的。这是一组工具，用来建立和维护几个不同的数据结构： web database， a set of segments， and the index。下面逐个解释这三个不同的数据结构： <br /><br />&nbsp; &nbsp; 1、The web database， 或者WebDB。这是一个特殊存储数据结构，用来映像被抓取网站数据的结构和属性的集合。WebDB 用来存储从抓取开始（包括重新抓取）的所有网站结构数据和属性。WebDB 只是被 抓取程序使用，搜索程序并不使用它。WebDB 存储2种实体：页面 和 链接。页面 表示 网络上的一个网页，这个网页的Url作为标示被索引，同时建立一个对网页内容的MD5 哈希签名。跟网页相关的其它内容也被存储，包括：页面中的链接数量（外链接），页面抓取信息（在页面被重复抓取的情况下），还有表示页面级别的分数 score 。链接 表示从一个网页的链接到其它网页的链接。因此 WebDB 可以说是一个网络图，节点是页面，链接是边。 <br /><br />&nbsp; &nbsp; 2、Segment 。这是网页的集合，并且它被索引。Segment的Fetchlist 是抓取程序使用的url列表，它是从 WebDB中生成的。Fetcher 的输出数据是从 fetchlist 中抓取的网页。Fetcher的输出数据先被反向索引，然后索引后的结果被存储在segment 中。 Segment的生命周期是有限制的，当下一轮抓取开始后它就没有用了。默认的 重新抓取间隔是30天。因此删除超过这个时间期限的segment是可以的。而且也可以节省不少磁盘空间。Segment 的命名是日期加时间，因此很直观的可以看出他们的存活周期。 <br /><br />&nbsp; &nbsp; 3、The index。索引库是反向索引所有系统中被抓取的页面，它并不直接从页面反向索引产生，而是合并很多小的segment的索引产生的。Nutch 使用 Lucene 来建立索引，因此所有Lucene相关的工具 API 都用来建立索引库。需要说明的是Lucene的segment 的概念和Nutch的segment概念是完全不同的，不要混淆。简单来说 Lucene 的 segment 是 Lucene 索引库的一部分，而Nutch 的Segment是WebDB中被抓取和索引的一部分。<br /><br />抓取过程详解：<br /><br />&nbsp; &nbsp; &nbsp; 抓取是一个循环的过程：抓取工具从WebDB中生成了一个 fetchlist 集合；抽取工具根据fetchlist从网络上下载网页内容；工具程序根据抽取工具发现的新链接更新WebDB；然后再生成新的fetchlist；周而复始。这个抓取循环在nutch中经常指： generate/fetch/update 循环。<br /><br /><br />&nbsp; &nbsp; 一般来说同一域名下的 url 链接会被合成到同一个 fetchlist。这样做的考虑是：当同时使用多个工具抓取的时候，不会产生重复抓取的现象。Nutch 遵循 Robots Exclusion Protocol, 可以用robots.txt 定义保护私有网页数据不被抓去。<br /><br />&nbsp; &nbsp; 上面这个抓取工具的组合是Nutch的最外层的，也可以直接使用更底层的工具，自己组合这些底层工具的执行顺序达到同样的结果。这是Nutch吸引人的地方。下面把上述过程分别详述一下，括号内就是底层工具的名字：<br /><br />&nbsp; &nbsp; &nbsp; 1、创建一个新的WebDB (admin db -create)。 <br /><br />&nbsp; &nbsp; 2、把开始抓取的跟Url 放入WebDb (inject)。 <br /><br />&nbsp; &nbsp; 3、从WebDb的新 segment 中生成 fetchlist (generate)。 <br /><br />&nbsp; &nbsp; 4、根据 fetchlist 列表抓取网页的内容 (fetch)。 <br /><br />&nbsp; &nbsp; 5、根据抓取回来的网页链接url更新 WebDB (updatedb)。 <br /><br />&nbsp; &nbsp; 6、重复上面3-5个步骤直到到达指定的抓取层数。<br /><br />&nbsp; &nbsp; 7、用计算出来的网页url权重 scores 更新 segments (updatesegs)。<br /><br />&nbsp; &nbsp; 8、对抓取回来的网页建立索引(index)。<br /><br />&nbsp; &nbsp; 9、在索引中消除重复的内容和重复的url (dedup)。<br /><br />&nbsp; &nbsp; 10、合并多个索引到一个大索引，为搜索提供索引库(merge)。<br /><br />&nbsp; &nbsp; &nbsp; 在创建了一个新的WebDB后，抓取循环 generate/fetch/update 就根据最先第二步指定的根 url 在一定周期下自动循环了。当抓取循环结束后，就会生成一个最终的索引（第7步到第10步）。需要说明的是：上面第 8 步中每个 segment 的索引都是单独建立的，之后才消重（第9步）。第10步就是大功告成，合并单独的索引到一个大索引库。<br /><br />&nbsp; &nbsp; Dedup 工具可以从 segment 的索引中去除重复的url。因为 WebDB 中不允许重复的url ， 也就是说 fetchlist 中不会有重复的url,所以不需要对 fetchlist 执行 dedup 操作。上文说过，默认的抓取周期是30天，如果已经生成的旧 fetch 没有删除，而又生成了新的fetch 这是还是会出现重复的url的。当只有一个抓取程序运行的时候是不会发生上述情况的。<br /><br />&nbsp; &nbsp; 从上面的介绍可以看出，一般情况下我们只要从头执行的程序就可以了，不需要接触底层的工具。但是搜索引擎有很多“意外”，很多的时间需要花费在维护上，所以底层的工具也是需要掌握的。</font ></span ><br /> <a href="http://hi.baidu.com/ossou/blog/item/842250e749eb262eb838206d.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/ossou/blog/category/%BC%BC%CA%F5%D7%CA%C1%CF">技术资料</a>&nbsp;<a href="http://hi.baidu.com/ossou/blog/item/842250e749eb262eb838206d.html#comment">查看评论</a>]]></description>
        <pubDate>2006-07-27  13:42</pubDate>
        <category><![CDATA[技术资料]]></category>
        <author><![CDATA[ossou]]></author>
		<guid>http://hi.baidu.com/ossou/blog/item/842250e749eb262eb838206d.html</guid>
</item>

<item>
        <title><![CDATA[搜索引擎设计实用教程-以百度为例(ZT)]]></title>
        <link><![CDATA[http://hi.baidu.com/ossou/blog/item/09ea6f604b0a8e44eaf8f86c.html]]></link>
        <description><![CDATA[
		
		<p >搜索引擎设计实用教程-以百度为例 </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 之一:查询处理以及分词技术 </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;中科院软件所 张俊林 </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2005年11月 </p ><p >&nbsp;随着搜索经济的崛起，人们开始越加关注全球各大搜索引擎的性能、技术和日流量。作为企业，会根据搜索引擎的知名度以及日流量来选择是否要投放广告等；作为普通网民，会根据搜索引擎的性能和技术来选择自己喜欢的引擎查找资料；作为技术人员，会把有代表性的搜索引擎作为研究对象. 搜索引擎经济的崛起，又一次向人们证明了网络所蕴藏的巨大商机。网络离开了搜索将只剩下空洞杂乱的数据，以及大量等待去费力挖掘的金矿。 </p ><p >但是,如何设计一个高效的搜索引擎?我们可以以百度所采取的技术手段来探讨如何设计一个实用的搜索引擎.搜索引擎涉及到许多技术点,比如查询处理,排序算法,页面抓取算法,CACHE机制,ANTI-SPAM等等.这些技术细节,作为商业公司的搜索引擎服务提供商比如百度,GOOGLE等是不会公之于众的.我们可以将现有的搜索引擎看作一个黑盒,通过向黑盒提交输入,判断黑盒返回的输出大致判断黑盒里面不为人知的技术细节. </p ><p >查询处理与分词是一个中文搜索引擎必不可少的工作,而百度作为一个典型的中文搜索引擎一直强调其”中文处理”方面具有其它搜索引擎所不具有的关键技术和优势.那么我们就来看看百度到底采用了哪些所谓的核心技术. </p ><p >我们分两个部分来讲述:查询处理/中文分词. </p ><p >一. &nbsp; 查询处理 </p ><p >&nbsp; &nbsp;用户向搜索引擎提交查询,搜索引擎一般在接受到用户查询后要做一些处理,然后在索引数据库里面提取相关的信息.那么百度在接受到用户查询后做了些什么工作呢? </p ><p >1. &nbsp; &nbsp; &nbsp; 假设用户提交了不只一个查询串,比如”信息检索 理论 工具”.那么搜索引擎首先做的是根据分隔符比如空格,标点符号,将查询串分割成若干子查询串,比如上面的查询就会被解析为:&lt;信息检索,理论,工具&gt;三个子字符串;这个道理简单,我们接着往下看. </p ><p >2. &nbsp; &nbsp; &nbsp; 假设提交的查询有重复的内容,搜索引擎怎么处理呢?比如查询”理论 工具 理论”,百度是将重复的字符串当作只出现过一次,也就是处理成等价的”理论 工具”,而GOOGLE显然是没有进行归并,而是将重复查询子串的权重增大进行处理.那么是如何得出这个结论的呢?我们可以将”理论 工具”提交给百度,返回341,000篇文档,大致看看第一页的返回内容.OK.继续,我们提交查询”理论 工具 理论”,在看看返回结果,仍然是那么多返回文档,当然这个不能说明太多问题,那看看第一页返回结果的排序,看出来了吗?顺序完全没有变化,而GOOGLE则排序有些变动,这说明百度是将重复的查询归并成一个处理的,而且字符串之间的先后出现顺序基本不予考虑(GOOGLE是考虑了这个顺序关系的). </p ><p >3. &nbsp; &nbsp; &nbsp; 假设提交的中文查询包含英文单词,搜索引擎是怎么处理的?比如查询”电影BT下载”,百度的方法是将中文字符串中的英文当作一个整体保留,并以此为断点将中文切分开,这样上述的查询就切为&lt;电影,BT,下载&gt;,不论中间的英文是否一个字典里能查到的单词也好,还是随机的字符也好,都会当作一个整体来对待.至于为什么,你用查询” 电影dfdfdf下载”看看结果就知道了.当然如果查询中包含数字,也是如此办理. </p ><p >到目前为止,一切很简单,也很清楚,百度怎么处理用户查询的呢?归纳如下:首先根据分割符号将查询分开,然后看看是否有重复的字符串,如果有,就抛弃多余的,只保留一个,接着判断是否有英文或者数字,如果有的话,把英文或者数字当作一个整体保留并把前后的中文切开. </p ><p >接着该干什么呢?该考虑分词的问题了. </p ><p >二. &nbsp; 中文分词 </p ><p >首先,讲讲百度的分词时机或者条件问题,是否是个中文字符串百度就拿来切一下呢?非也,要想被百度的分词程序荣幸的切割一下也是要讲条件的,哪能是个字符串就切割啊?你当百度是卖锯条的么? </p ><p >那么什么样的字符串才满足被切割的条件呢?简单说来,如果字符串只包含小于等于3个中文字符的话,那就保留不动,当字符串长度大于4个中文字符的时候,百度的分词程序才出马大干快上,把这个字符串肢解掉. </p ><p >怎么证明呢?我们向百度提交”电影下载”,看看返回结果中标为红字的地方,不难看出来,查询已经被切割成&lt;电影,下载&gt;两个单词了,说明分词程序已经开工了,如果是比4个中文字符更长的字符串,那分词程序就更不客气了,一定大卸八块而后快.我们来看看三个字符的情况,提交查询”当然择”,看起来这个查询不伦不类,那是因为我希望看到这个字符串被切分为&lt;当然,择&gt;,返回结果365篇相关页面,翻到最后一页,发现标红的关键字都是”当然择”连续出现的情况,好像没有切分,但是还不确定,那么再提交人工分好的查询”当然 择”看看,返回结果1,090,000篇,基本上可以确定没有进行分词了,当然另外一种解释是:对于三个字符先切分,然后将切分后的结果当作一个短语查询,这样看到的效果和没有切分是相似的.但是我倾向于判断百度对于少于3个字符的串没有切分,奥卡姆不是说了么”如无必要,勿增实体”,干吗做无用功呢.那么如果没有切分,会有一个随之而来的问题,怎么从索引库里面提取未切分的字符串呢?这牵扯到索引的问题,我觉得百度应该采取了两套索引机制,一种是按照单词索引,一种是按照N-GRAM索引,至于索引的具体问题,以后在详细论述. </p ><p >下面我们看看百度是采取的何种分词算法,现在分词算法已经算是比较成熟了,有简单的有复杂的,比如正向最大匹配,反向最大匹配,双向最大匹配,语言模型方法,最短路径算法等等,有兴趣的可以用GOOGLE去搜索一下以增加理解.这里就不展开说了.但是要记住一点的是:判断一个分词系统好不好,关键看两点,一个是消除歧义能力;一个是词典未登录词的识别比如人名,地名,机构名等. </p ><p >那么百度用的是什么方法?我的判断是用双向最大匹配算法.至于怎么推理得出的,让我们一步步来看.当然,这里首先有个假设,百度不会采取比较复杂的算法,因为考虑到速度问题. </p ><p >我们提交一个查询”毛泽东北京华烟云”,又一个不知所云的查询,尽管不知所云但是自有它的道理,我想看看百度的分词是如何消歧以及是否有词典未登录词的识别的功能,如果是正向最大匹配算法的话,那么输出应该是:”毛泽东/北京/华/烟云”,如果是反向最大匹配算法的话,那么输出应该是:”毛/泽/东北/京华烟云”,我们看看百度的分词结果:”毛泽东/北/京华烟云”,一个很奇怪的输出,跟我们的期望相差较多,但是从中我们可以获得如下信息:百度分词可以识别人名,也可以识别”京华烟云”,这说明有词典未登录词的识别的功能,我们可以假设分词过程分为两个阶段:第一阶段,先查找一个特殊词典,这个词典包含一些人名,部分地名以及一些普通词典没有的新词,这样首先将”毛泽东”解析出来,剩下了字符串”北京华烟云”,而”北/京华烟云”,可以看作是反向最大匹配的分词结果.这样基本说得通.为了证明这一点,我们提交查询”发毛泽东北”,我们期望两种分词结果,一个是正向最大匹配&lt;发毛,泽,东北&gt;,一个是上述假设的结果&lt;发,毛泽东,北&gt;,事实上百度输出是第二种情况,这样基本能确定百度分词采取了至少两个词典,一个是普通词典,一个是专用词典(人名等).而且是专用词典先切分,然后将剩余的片断交由普通词典来切分. </p ><p >&nbsp; 继续测验,提交查询”古巴比伦理”,如果是正向最大匹配,那么结果应该是&lt;古巴比伦,理&gt;,如果是反向最大匹配,那么结果应该是&lt;古巴,比,伦理&gt;,事实上百度的分词结果是&lt;古巴比伦,理&gt;,从这个例子看,好像用了正向最大匹配算法;此外还有一些例子表明好像是使用正向最大匹配的;但是且慢,我们看这个查询”北京华烟云”,正向最大匹配期望的结果是&lt;北京,华,烟云&gt;,而反向最大匹配期望的结果是&lt;北,京华烟云&gt;,事实上百度输出的是后者,这说明可能采用的反向最大匹配;从这点我们可以猜测百度采用的是双向最大匹配分词算法,如果正向和反向匹配分词结果一致当然好办,直接输出即可;但是如果两者不一致,正向匹配一种结果,反向匹配一种结果,此时该如何是好呢?从上面两个例子看,在这种情况下,百度采取最短路径方法,也就是切分的片断越少越好,比如&lt;古巴,比,伦理&gt;和&lt;古巴比伦,理&gt;相比选择后者,&lt;北京,华,烟云&gt;和&lt;北,京华烟云&gt;相比选择后者.还有类似的一些例子,这样基本可以解释这些输出结果. </p ><p >但是仍然遗留的问题是:如果正向反向分词不一致,而且最短路径也相同,那怎么办?输出正向的还是反向的结果?我们再来看一个例子.提交查询”遥远古古巴比伦”,这个查询被百度切分为&lt;遥远,古古,巴比伦&gt;,说明词典里面有”巴比伦”,但是是否有”古巴比伦”这个词汇不确定,此时看不出是正向切分还是反向切分得出的结果,换查询为”遥远古巴比伦”,此时被切分为”遥远/古巴比伦”,这说明词典里面有”古巴比伦”这个词汇,这说明了”遥远古古巴比伦”是正向最大匹配的结果.那为什么”遥远古古巴比伦”不会被反向切分为”遥/远古/古巴比伦”呢,百度的可能选择是这种情况下选择单字少的那组切分结果. </p ><p >当然还可以继续追问:如果切分后单字也一样多,那怎么办?最后看一个例子,查询”王强大小:”,百度将其切分为”王/强大/小”,是正向切分的结果,如果是反向的会被切分为”王/强/大小”,这说明有歧义而且单字也相同则选择正向切分结果. </p ><p >OK,看到这里可能头已经有些晕了,最后总结一下百度的分词算法,当然里面还是有猜测的成分,算法如下: </p ><p >首先查询专用词典(人名,部分地名等),将专有名称切出,剩下的部分采取双向分词策略,如果两者切分结果相同,说明没有歧义,直接输出分词结果.如果不一致,则输出最短路径的那个结果,如果长度相同,则选择单字词少的那一组切分结果.如果单字也相同,则选择正向分词结果.. </p ><p >百度一直宣传自己在中文处理方面的优势,从上面看,分词算法并无特殊之处,消歧效果并不理想,即使百度采取比上述分词算法复杂些的算法也难以说成是优势,如果说百度有优势的话,唯一的优势就是那个很大的专用词典,这个专用词典登录了人名(比如大长今),称谓(比如老太太),部分地名(比如阿联酋等),估计百度采用学术界公布的比较新的命名实体识别算法从语料库里面不断识别出词典未登录词,逐渐扩充这个专门词典.如果这就是优势的话,那么这个优势能够保持多久就是个很明显的问题. </p ><p >之二:Spelling Checker拼写检查错误提示(以及拼音提示功能)<br />　　<br />　　中科院软件所 张俊林 </p ><p >　　2005年11月 </p ><p ><br />　　拼写检查错误提示是搜索引擎都具备的一个功能,也就是说用户提交查询给搜索引擎,搜索引擎检查看是否用户输入的拼写有错误,对于中文用户来说一般造成的错误是输入法造成的错误.那么我们就来分析看看百度是怎么实现这一功能的.<br />　　我们分析拼写检查系统关注以下几个问题:<br />　　(1)系统如何判断用户的输入是有可能发生错误的查询呢?<br />　　(2)如果判断是可能错误的查询输入,如何提示正确的词汇呢?<br />　　<br />　　那么百度是如何做的呢?百度判断用户输入是否错误的标准,我觉得应该是查字典,如果发现字典里面不包含这个词汇,那么很有可能是个错误的输入,此时启动错误提示功能,这个很好判断,因为如果是一个正常词汇的话,百度一般不会有错误提示,而你故意输入一个词典不可能包含的所谓词汇,此时百度一般会提示你正确的检索词汇.<br />　　那么百度是怎么提示正确词汇的呢?很明显是通过拼音的方式,比如我输入查询” 制才”,百度提供的提示词汇为: “:制裁 质材 纸材”,都是同音字.所以百度必然维持着一个同音词词典,里面保留着同音词信息,比如可能包含着下面这条词条: “ zhi cai à制裁,质材,纸材”,另外还有一个标注拼音程序,现在能够看到的基本流程是: 用户输入” 制才”,查词典,发现没有这个词汇,OK,启动标注拼音程序,将” 制才”标注为拼音”zhi cai”,然后查找同音词词典,发现同音词” 制裁,质材,纸材”,那么提示用户可能的正确拼写.<br />　　整体流程看起来很简单,但是还有一些遗留的小问题,比如是否将词表里面所有同音词都作为用户的提示信息呢?比如某个拼音有10个同音词,是否都输出呢?百度并没有将所有同音词都输出而是选择一定筛选标准,选择其中几个输出.怎么证明这一点?我们看看拼音”liu li”的同音词,紫光输入法提示同音词汇有” 流丽 流离 琉璃流利”4个,我们看看百度返回几个,输入”流厉”作为查询,这里是故意输入一个词典不包含的词汇,这样百度的拼写检查才开始工作,百度提示: "琉璃刘丽 刘莉 ",这说明什么?说明不是所有同音词都输出,而是选择输出,那么选择的标准是什么?我能够猜测到的方法是对于用户查询LOG进行统计,提取用户查询次数多的那些同音词输出,如果是这样的话,上面的例子说明用户搜索”琉璃”次数比其它的都要高些,次之是” 刘丽”,再次是” 刘莉”,看来大家都喜欢查询自己或者认识的人的名字.<br />　　另外一个小问题:同音词词典包含2字词,3字词,那么是否包含4字词以及更长的词条?是否包含一字词? 这里一字词好回答,不用测试也能知道肯定不包含,因为你输入一个字,谁知道是否是错误的呢?反正只要是汉字就能在词表里面找到,所以没有判断依据.二字词是包含的,上面有例子,三字词也包含,比如查询 "中城药"百度错误提示:”中成药”,修改查询为"重城药",还是提示”中成药” ,再次修改查询 "重城要",百度依然提示”中成药”. 那么4字词汇呢?<br />　　百度还是会给你提示的,下面是个例子:<br />　　输入:静华烟云 提示 京华烟云<br />　　输入 静话烟云 提示 京华烟云<br />　　输入 静话阎晕 提示 京华烟云<br />　　那么更长的词汇是否提示呢?也提示,比如我输入: "落花世界有风军",这个查询是什么意思,估计读过古诗的都知道,看看百度的提示”落花时节又逢君”,这说明什么?说明同音词词典包含不同长度的同音词信息,另外也说明了百度的核心中文处理技术,也就是那个词典,还真挺大的.<br />　　但是,如果用户输入的查询由两个或者两个以上子字符串构成,那么百度的错误提示功能就罢工了,比如输入查询"哀体",百度提示”艾提 挨踢”,但是.输入为 "我 哀体",则没有任何错误提示.<br />　　还有一个比较重要的问题:如果汉字是多音字那么怎么处理?百度呢比较偷懒,它根本就没有对多音字做处理.我们来看看百度的一个标注拼音的错误,在看这个错误前先看看对于多音字百度是怎么提示错误的,我们输入查询"俱长",百度提示”剧场 局长”, “俱长”的拼音有两个:”ju zhang /ju chang” ,可见如果是多音字则几种情况都提示..现在我们来看看错误的情况, 我们输入查询”剧常”,百度提示”:剧场局长”,提示为”剧场"当然好解释,因为是同音字,但是为什么 "局长"也会被提示呢?这说明百度的同音字词典有错误,说明在”ju chang”这个词条里面包含”局长”这个错误的同音词.让我们顺藤摸瓜,这个错误又说明什么问题呢?说明百度的同音词典是自动生成的,而且没有人工校对.还说明在自动生成同音词典的过程中,百度不是根据对一篇文章标注拼音然后在抽取词汇和对应的拼音信息获得的,而是完全按照某个词典的词条来标注音节的,所以对于多音字造成的错误无法识别出来,如果是对篇章进行拼音标注,可能就不会出现这种很容易发现的错误标注. 当然还有另外一种解释,就是"局长"是故意被百度提示出来可能的正确提示词汇,因为考虑到南方人"zh'和 "ch"等前后鼻音分不清么,那么是这样的么?我们继续测试到底是何种情况.是百度有错误还是这是百度的先进的算法?<br />　　我们考虑词汇"长大 ",故意错误输入为"赃大",如果百度考虑到了前后鼻音的问题,那么应该会提示"长大",但是百度提示是"藏大".这说明什么?说明百度并没有考虑前后鼻音问题,根本就是系统错误. 我们输入查询"悬赏",故意将之错误输入为"悬桑",没有错误提示,说明确实没有考虑这种情况.前鼻音没有考虑,那么后鼻音考虑了么,我们输入”:经常”,故意改为后鼻音 "经缠",百度提示为"经产 经忏",还是没有考虑后鼻音.这基本可以确定是百度系统的错误导致.<br />　　根据以上推导, 我们可以得出如下结论:百度是将分词词典里面每个词条利用拼音标注程序标注成拼音,然后形成同音词词典,所以两个词典是同样大的,而且这个词典也随着分词词典的增长而在不断增长. 至于标注过程中多音字百度没有考虑,如果是多音字就标注成多个发音组合,通过这种方式形成同音词词典.这样的同音词词典显然包含着很多错误.<br />　　最后一个问题:百度对于英文进行拼写检查么?让我们试试看,输入查询”china”,不错,搜到不少结果,专注中文搜索的百度还能搜索到英文,真是意外的惊喜.变换一下查询”chine”,会更加意外惊喜的给我们提示”china”吗?百度提示的是: 吃呢持呢,原来是不小心触发了百度的拼音搜索功能了.那么拼音搜索和中文检查错误是否采用同一套同音词词典呢,让我们来实验一下,搜索”rongji”,百度提示” 榕基 溶剂 容积”,OK,换个中文查询”容机”,百度提示” 榕基 溶剂容积”,看来使用的是同一套同音词词典.也就是说百度的中文纠错和拼音检索使用的机制相同,中文纠错多了一道拼音注音的过程而已.难道这就是传说中那个百度的”事实上是一个无比强大的拼音输入法”的拼音提示功能么?<br />　　最后让我们总结归纳一下百度的拼写检查系统:<br />　　后台作业: (1)前面的文章我们说过,百度分词使用的词典至少包含两个词典一个是普通词典,另外一个是专用词典(专名等),百度利用拼音标注程序依次扫描所有词典中的每个词条,然后标注拼音,如果是多音字则把多个音都标上,比如”长大”,会被标注为”zhang da/chang da”两个词条.<br />　　(2)通过标注完的词条,建立同音词词典,比如上面的”长大”,会有两个词条: zhang daà长大” , chang daà长大.<br />　　(3)利用用户查询LOG频率信息给予每个中文词条一个权重;<br />　　(4)OK,同音词词典建立完成了,当然随着分词词典的逐步扩大,同音词词典也跟着同步扩大;<br />　　<br />　　拼写检查:<br />　　(1)用户输入查询,如果是多个子字符串,不作拼写检查;<br />　　(2)对于用户查询,先查分词词典,如果发现有这个单词词条,OK,不作拼写检查;<br />　　(3)如果发现词典里面不包含用户查询,启动拼写检查系统;首先利用拼音标注程序对用户输入进行拼音标注;<br />　　(4)对于标注好的拼音在同音词词典里面扫描,如果没有发现则不作任何提示;<br />　　(5)如果发现有词条,则按照顺序输出权重比较大的几个提示结果;<br />　　<br />　　拼音提示:<br />　　(1)对于用户输入的拼音在同音词词典里面扫描,如果没有发现则不作任何提示;<br />　　(2)如果发现有词条,则按照顺序输出权重比较大的几个提示结果; </p ><p >之三:对百度分词算法的进一步分析 </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 中科院软件所 malefactor </p ><p >&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 2005年11月 </p ><p >上面说过,经过分析得出百度的分词系统采用双向最大匹配分词,但是后来发现推理过程中存在一个漏洞,而且推导出来的百度分词算法步骤还是过于繁琐,所以进一步进行分析,看看是否前面的推导有错误. </p ><p >那么以前的分析有什么漏洞呢?我们推导百度分词有反向最大匹配的依据是百度将"北京华烟云"分词为&lt;北,京华烟云&gt;,从这里看好像采用了反向最大匹配,因为正向最大匹配的结果应该是&lt;北京,华,烟云&gt;,但是由此就推论说百度采用了双向最大匹配还是太仓促了,前面文章我们也讲过,百度有两个词典,一个普通词典,一个专有词典,而且是专有词典的词汇先切分,然后将剩余片断交给普通词典去切分.所以上面的"北京华烟云"之所以被切分成&lt;北,京华烟云&gt;,另外一个可能是:京华烟云这个词汇是在专有词典里面存储的,所以先分析,这样得出"京华烟云",剩下"北",没什么好切分的,所以输出&lt;北,京华烟云&gt;. </p ><p >这里只是假设,那么是否确实"京华烟云"在专有词典呢?我们再看一个例子"山东北京华烟云",百度切分的结果是&lt;山东,北,京华烟云&gt;,如果"京华烟云"在普通词典,如果是反向切分,那么结果应该是&lt;山,东北,京华烟云&gt;,如果是正向切分应该是&lt;山东,北京,华,烟云&gt;,无论如何都分不出&lt;山东,北,京华烟云&gt;.这说明什么?说明"京华烟云"是在那个专有词典,所以先切分出"京华烟云",然后剩下的"山东北"交由普通词典切分,明显是正向最大匹配的结果输出&lt;山东,北&gt;.当然按照我们在第一篇文章的算法推导"山东北"的切分也会得出&lt;山东,北&gt;的结论,但是明显比正向最大匹配多几个判断步骤,既然效果一样,另外一个更加简洁的方法也能说得通,那当然选择简便的方法了.所以初步判断百度采取的是正向最大匹配. </p ><p >我们继续测试采用何种分词算法,为了减少专有词典首先分词造成的影响,那么查询里面不能出现相对特殊的词汇,构筑查询"天才能量级",这里应该没有专有词典出现过的词汇,百度切分为&lt;天才,能量,级&gt;,看来是正向最大匹配的结果.另外,如果所有查询词汇都出现在专有词典,那么采取的是何种方法?这样首先就得保证词汇都出现在专有词典,这么保证这一点呢?我们构造查询"铺陈晓东方",百度切分为&lt;铺,陈晓东,方&gt;,可以看出"陈晓东"是在专有词典的所以先切分出来.另外一个例子 "山东京城",百度切分为&lt;山东,京城&gt;,说明"东京"是在普通词典的.OK,构造查询"陈晓东京华烟云",通过前面分析可以看出两个词汇都在专有词典里面,百度切分为&lt;陈晓东,京华烟云&gt;,说明对于专有词典词汇也是采取正向最大匹配或者双向最大匹配.那么使用反向最大匹配了吗?构造查询例子"陈晓东方不败",首先我们肯定"陈晓东"和"东方不败"都是在专有词典出现的,如果是正向切分,那么应该是&lt;陈晓东,方,不败&gt;或者&lt;陈晓东,方,不,败&gt;如果是反向切分则是&lt;陈,晓,东方不败&gt;,可以看出百度的切分是&lt;陈晓东,方,不败&gt;或者&lt;陈晓东,方,不,败&gt;,说明采用的是正向最大匹配.通过分析,百度的词典不包含"不败"这个单词,所以实际上百度的切分结果是&lt;陈晓东,方,不,败&gt;,很明显这和我们以前推导的算法是有矛盾的,所以以前的分析算法确实有问题,所以结论是百度采取的是正向最大匹配算法. </p ><p >重新归纳一下百度的分词系统:首先用专有词典采用最大正向匹配分词,切分出部分结果,剩余没有切分交给普通词典,同样采取正向最大匹配分词,最后输出结果. </p ><p >另外,GOOGLE也是采用正向最大匹配分词算法,不过好像没有那个专用词典,所以很多专名都被切碎了. </p ><p >从这点讲,GOOGLE在中文词典构建上比百度差些,还需要加把子力气才行,不过这也不是什么多难的事. </p > <a href="http://hi.baidu.com/ossou/blog/item/09ea6f604b0a8e44eaf8f86c.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/ossou/blog/category/%BC%BC%CA%F5%D7%CA%C1%CF">技术资料</a>&nbsp;<a href="http://hi.baidu.com/ossou/blog/item/09ea6f604b0a8e44eaf8f86c.html#comment">查看评论</a>]]></description>
        <pubDate>2006-07-27  13:34</pubDate>
        <category><![CDATA[技术资料]]></category>
        <author><![CDATA[ossou]]></author>
		<guid>http://hi.baidu.com/ossou/blog/item/09ea6f604b0a8e44eaf8f86c.html</guid>
</item>


</channel>
</rss>