全文检索引擎（精选7篇）
全文检索引擎 篇1
1 概述
随着Internet网上的信息呈几何级数式的增长,搜索引擎已经成为用户浏览网络信息的首选。传统的通用搜索引擎(Google、Yahoo以及国内的Baidu等),作为一个辅助用户查找信息的工具已经成为大多数互联网用户访问网络的入口。但是,这些通用性搜索引擎存在着一定的不足,例如:通用搜索引擎的信息量较大、搜索深度不够、查询不太准确等问题。在这种情况下,为了解决这些问题,垂直搜索引擎应运而生。垂直搜索引擎是针对某一领域或行业的专业搜索引擎,是搜索引擎的延伸,可以为搜索用户提供符合专业用户操作行为的信息服务方式。它的特点是“专、精、深”,并且具有较强的行业色彩,和通用搜索引擎的海量信息无序化相比,垂直搜索引擎更加具体和深入。该文主要阐述开源的Lucene技术和Heritrix技术的基本原理和使用方法,提出了整合Lucene与Heritrix使其与J2EE平台完全融合的方案,并实现了一个手机产品垂直搜索引擎系统。
2 全文检索引擎开源框架
2.1 全文搜索工具包Lucene
Lucene是一个用Java编写的高效率、可扩展的全文索引的引擎工具包。它是目前最受欢迎的开源信息检索包。Lucene定义了平台无关的索引文件结构,保证了平台无关性。它的另外一个优秀之处在于设计结构十分优良,将所有的核心类库设计成抽象基类,用户使用Lucene时再具体实现其对应的抽象类。此外,Lucene使用类进行包装,然后进行基于面向对象的多层封装,最后形成一个低耦合、与平台无关的、可以进行二次开发的开源框架。要想使用Lucene来进行我们的开发,首先需要对Lucene的内部结构有比较清楚的了解。Lucene的结构图如图1所示。
目前已经有较多的应用程序(例如Eclipse的帮助系统的搜索功能)的搜索功能是基于Lucene的,Lucene可以为文本类型的数据建立索引,只要把要索引的数据格式转化的文本类型的数据格式,Lucene就可以对该文档进行索引和搜索。例如如果要对一些HTML文档或PDF文档进行索引,首先就需要把这些文档转化成文本格式的,再将转化后的内容交给Lucene进行索引,然后将创建好的索引文件保存到内存或磁盘中,最后根据用户输入的查询条件在索引文件上进行所需的查询。由于Lucene不需要指定将要索引的文档的格式,所以它基本上能够适用于所有的搜索应用程序。Lucene工具包的索引机制架构如图2所示。
2.2 开源web爬虫框架Heritrix
Heritrix是一个开源的由Java开发的Web网络爬虫框架,用户使用它可以从网络上抓取想要搜索的资源。Heritrix来自于开源组织www.archive.org,它的最出色之处在于可扩展性,开发者可以根据自己的需要,通过扩展它的各个组件来实现自己的抓取逻辑。Heritrix是一个开源的可以添加多种可交互组件的爬虫框架,各种不同的组件提供不同的功能,通过对基础框架的扩展,我们可以实现满足自己需要的定制爬虫程序。Heritrix架构示意图如图3所示。
Heritrix框架的各主要部件功能描述如下:
(1)抓取任务CrawlOrder组件:CrawlOrder是整个抓取任务的开始,在一次抓取过程中包含很多的属性,最简单的一种就是根据默认的配置文件order.xml来配置。Heritrix提供了XMLSettingsHandler类,它可以用来帮助读取order.xml。
(2)中央控制器CrawlController:CrawlController是Heritrix的核心组件,它控制决定着一个抓取任务的开始和结束。
(3)Frontier链接制造工厂:Frontier的主要功能是为线程提供URL链接的处理工厂,按照一定的复杂算法将网页中的URL进行处理,将需要处理的URL链接送入到处理器链中,同时还提供一定的日志和状态报告功能。Heritrix本身已经提供了非常强大的链接处理功能,该文中就不再对其进行扩展处理。
(4)Heritrix的多线程ToeThread和ToePool:Java语言对于多线程提供了良好的支持,heritrix是基于java语言开发的爬虫框架,自然对多线程的处理也提出了独特的方案。它提供了用于管理所有的抓取线程的一个标准的线程池ToePool,线程池本身在创建的时候并没有创建实例对象,只有在调用其Set()方法时才会根据传入参数的不同创建实例,管理线程池中线程数量的增减。ToeThread线程是为更有效更快速的抓取网页内容而设计的,因为爬虫抓取,分类,处理是一个异步的过程,只有使用多线程才能让多个处理部分同时工作,提高效率。
3 系统设计及实现
3.1 系统架构设计
为了阐述基于Java的开源框架Lucene和Heritrix在全文搜索系统中的应用,该文实现了一个简单的手机产品的搜索引擎系统。用户通过本系统在网站上搜索他们所需要的手机的详细信息,并可以从搜索结果中打开一个页面进行浏览,了解手机的详细信息。在我们这个应用中,首先需要通过网络爬虫Heritrix将这些手机信息抓取下来,进行组织和整理,构建手机产品数据库,同时为手机的各种内容(如手机图片、手机详细资料等),利用Lucene来建立索引,以便提供给用户来进行查找。Web用户接口主要通过Spring,Struts等流行web框架来设计。完整的手机搜索系统的整体结构框架如图4所示。
3.2 系统实现
系统的设计步骤如下:
首先需要对目标页面的结构进行分析,获取爬虫程序的资源抓取清单,爬虫程序对页面抓取完毕后,使用HTMLParser等超文本分析工具对抓取的网页进行解析,获取手机名称,型号,属性信息,图片地址等内容,利用这些内容生成手机信息文件,并对所有手机产品构建出一个关于手机产品信息的词库,这个词库包含了被抓取的所有手机的型号与品牌,用户输入关键词时就能够搜索到这些信息。产品信息词库建立好后,再将这些信息插入到数据库中,建立Lucene的索引。系统运行效果如图5所示。
4 总结
垂直搜索引擎技术越来越受到众多开发者的重视,用户通过它可以获得更有效准确的信息检索服务。该文分析了Lucene的索引机制,探讨了Heritrix的结构框架,最后设计开发了一个简单的手机产品的搜索引擎系统,利用Lucene和Heritrix,在应用程序添加高效的索引和搜索能力成为可能。随着当前互联网和实际应用中大量数据的出现,用户更加需要从这些海量数据中提取出有用的信息,搜索引擎将变得越来越重要,基于和的全文搜索系统将得到更加广泛的应用。
参考文献
[1]Otis Gospodnetic,Erik Hatcher.Lucene in Action(中文版)[M].北京:电子工业出版社,2007.
[2]Apache Lucene Project[EB/OL].http://jakarta.apache.org/lucene/.2009.
[3]Apache Software Foundation.Lucene Query Syntax[EB/OL].http://lucene.apache.org/java/docs/.2009.
[4]卢亮.搜索引擎原理、实践与应用[M].北京:电子工业出版社,2007.
[5]Baeza Yates R,Ribeiro Neto B.Modern Information Retrieval[M].北京:机械工业出版社,2004.
[6]刘汉兴,刘财兴.主题爬虫的搜索策略研究[J].计算机工程与设计,2008(29).
全文检索引擎 篇2
说实话，这本书看了好几遍都是看不懂的，虽然说这本书是搜索引擎方面的入门书籍，我还是感觉这本书讲得比较详细，里面涉及到的知识点太多了，短期内很难吃透，所以一般平时我都是看这本书的，当然也攻克了许多难点，从梁斌的那本走进搜索引擎书中学到的比较简单的东西或是方法，然后运用到这本书上时感觉顿时明白了许多。下面就一点一点的总结一下自己看过的内容，或是看了过后有些感触的知识点。全书共分为11章，不算多，大部分内容一般的信息检索书中也有讲到，搜索引擎的参考书中也会介绍部分。这本书叫做实践，说明要求我们参与实践的环节，书中介绍了一种开源的搜索引擎，我也上网找过一些，看了相关的代码，不是看的很懂，或是看不懂。
全文检索引擎 篇3
1 Lucene是什么?
Lucene目前已经被广泛应用于全文索引/全文检索的项目。值得注意的是Lucene并不是一个完整的全文检索引擎, 而是一个全文检索引擎的架构, 是Apache软件基金会Jakarta项目组的一个子项目, 是一个开放源代码的全文检索引擎工具包。Lucene提供了完整的查询引擎和索引引擎, 部分文本分析引擎 (英文与德文两种西方语言) 。Lucene的目的是为软件开发人员提供一个简单易用的工具包, 以方便的在目标系统中实现全文检索的功能, 或者是以此为基础建立起完整的全文检索引擎。
2全文检索系统
全文检索是指计算机索引程序通过扫描文章中的每一个词, 对每一个词建立一个索引, 指明该词在文章中出现的次数和位置, 当用户查询时, 检索程序就根据事先建立的索引进行查找, 并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
全文检索系统是按照全文检索理论建立起来的用于提供全文检索服务的软件系统。一般来说, 全文检索需要具备建立索引和提供查询的基本功能, 此外现代的全文检索系统还需要具有方便的用户接口、面向WWW的开发接口、二次应用开发接口等等。功能上, 全文检索系统核心具有建立索引、处理查询返回结果集、增加索引、优化索引结构等等功能, 外围则由各种不同应用具有的功能组成。结构上, 全文检索系统核心具有索引引擎、查询引擎、文本分析引擎、对外接口等等, 加上各种外围应用系统等等共同构成了全文检索系统。图1.1展示了上述全文检索系统的结构与功能。
在上图中, 我们看到:全文检索系统中最为关键的部分是全文检索引擎, 各种应用程序都需要建立在这个引擎之上。一个全文检索应用的优异程度, 根本上由全文检索引擎来决定。因此提升全文检索引擎的效率即是我们提升全文检索应用的根本。另一个方面, 一个优异的全文检索引擎, 在做到效率优化的同时, 还需要具有开放的体系结构, 以方便程序员对整个系统进行优化改造, 或者是添加原有系统没有的功能。比如在当今多语言处理的环境下, 有时需要给全文检索系统添加处理某种语言或者文本格式的功能, 比如在英文系统中添加中文处理功能, 在纯文本系统中添加XML或者HTML格式的文本处理功能, 系统的开放性和扩充性就十分的重要。
二、Lucene的应用和优势
1 Lucene的应用
作为一个开放源代码项目, Lucene从问世之后, 引发了开放源代码社群的巨大反响, 程序员们不仅使用它构建具体的全文检索应用, 而且将之集成到各种系统软件中去, 以及构建Web应用, 甚至某些商业软件也采用了Lucene作为其内部全文检索子系统的核心。apache软件基金会的网站使用了Lucene作为全文检索的引擎, IBM的开源软件eclipse的2.1版本中也采用了Lucene作为帮助子系统的全文索引引擎, 相应的IBM的商业软件Web Sphere中也采用了Lucene。Lucene以其开放源代码的特性、优异的索引结构、良好的系统架构获得了越来越多的应用。
2 Lucene的优势
Lucene作为一个全文检索引擎的架构, 其具有如下突出的优点:
(1) 索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式, 使得兼容系统或者不同平台的应用能够共享建立的索引文件。
(2) 在传统全文检索引擎的倒排索引的基础上, 实现了分块索引, 能够针对新的文件建立小文件索引, 提升索引速度。然后通过与原有索引的合并, 达到优化的目的。
(3) 优秀的面向对象的系统架构, 使得对于Lucene扩展的学习难度降低, 方便扩充新功能。
(4) 设计了独立于语言和文件格式的文本分析接口, 索引器通过接受Token流完成索引文件的创立, 用户扩展新的语言和文件格式, 只需要实现文本分析的接口。
(5) 已经默认实现了一套强大的查询引擎, 用户无需自己编写代码即使系统可获得强大的查询能力, Lucene的查询实现中默认实现了布尔操作、模糊查询 (Fuzzy Search) 、分组查询等等。
面对已经存在的商业全文检索引擎, Lucene也具有相当的优势。
首先, 它的开发源代码发行方式 (遵守Apache Software License) , 在此基础上程序员不仅仅可以充分的利用Lucene所提供的强大功能, 而且可以深入细致的学习到全文检索引擎制作技术和面相对象编程的实践, 进而在此基础上根据应用的实际情况编写出更好的更适合当前应用的全文检索引擎。在这一点上, 商业软件的灵活性远远不及Lucene。
其次, Lucene秉承了开放源代码一贯的架构优良的优势, 设计了一个合理而极具扩充能力的面向对象架构, 程序员可以在Lucene的基础上扩充各种功能, 比如扩充中文处理能力, 从文本扩充到HTML、PDF等等文本格式的处理, 编写这些扩展的功能不仅仅不复杂, 而且由于Lucene恰当合理的对系统设备做了程序上的抽象, 扩展的功能也能轻易的达到跨平台的能力。
最后, 转移到apache软件基金会后, 借助于apache软件基金会的网络平台, 程序员可以方便的和开发者、其它程序员交流, 促成资源的共享, 甚至直接获得已经编写完备的扩充功能。最后, 虽然Lucene使用Java语言写成, 但是开放源代码社区的程序员正在不懈的将之使用各种传统语言实现 (例如.net framework) , 在遵守Lucene索引文件格式的基础上, 使得Lucene能够运行在各种各样的平台上, 系统管理员可以根据当前的平台适合的语言来合理的选择。
对于中文用户来说, 最关心的问题是其是否支持中文的全文检索。由于Lucene良好的架构设计, 对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。在最新的Lucene1.5版本中, 就已经加入了对中文等亚洲语言的支持。
三、Lucene的结构
1 Lucene的包结构
Lucene是开放源代码的工具包, 可以在jakarta项目组的相关主页中查找到它的下载。Lucene源码中总共包括7个子包 (又称模块) , 分别是analysis、document、index、query Parse、search、store、util, 每个包都完成特定的功能, 见下表:
通过对源码的功能分析我们可以进一步得出Lucene的核心类包主要有3个, 即为org.apache.lucene.analysis、org.apache.lucene.index、org.apache.lucene.search这三个。
其中org.apache.lucene.analysis主要用于切分词, 切分词的工作由Analyzer的扩展类来实现, Lucene自带了StandardAnalyzer类, 我们可以参照该写出自己的切词分析器类, 如中文分析器等。
org.apache.lucene.index主要提供库的读写接口, 通过该包可以创建库、添加删除记录及读取记录等。
org.apache.lucene.search主要提供了检索接口, 通过该包, 我们可以输入条件, 得到查询结果集, 与org.apache.lucene.query Parser包配合还可以自定义的查询规则, 像google一样支持查询条件间的与、或、非、属于等复合查询。
2 Lucene的系统结构组织
Lucene的功能很强大, 但从根本上说, 主要包括两块:一是文本内容经切词后索引入库;二是根据查询条件返回结果。下图为Lucene系统的结构组织, 并给出系统结构与源码组织图。
从图中我们清楚的看到, Lucene的系统由基础结构封装、索引核心、对外接口三大部分组成。其中直接操作索引文件的索引核心又是系统的重点。Lucene的将所有源码分为了7个模块 (在java语言中以包即package来表示) , 各个模块所属的系统部分也如上图所示。需要说明的是org.apache.lucene.query Paser是做为org.apache.lucene.search的语法解析器存在, 不被系统之外实际调用, 因此这里没有当作对外接口看待, 而是将之独立出来。
从面象对象的观点来考察, Lucene应用了最基本的一条程序设计准则:引入额外的抽象层以降低耦合性。首先, 引入对索引文件的操作org.apache.lucene.store的封装, 然后将索引部分的实现建立在 (org.apache.lucene.index) 其之上, 完成对索引核心的抽象。在索引核心的基础上开始设计对外的接口org.apache.lucene.search与org.apache.lucene.analysis。在每一个局部细节上, 比如某些常用的数据结构与算法上, Lucene也充分的应用了这一条准则。在高度的面向对象理论的支撑下, 使得Lucene的实现容易理解, 易于扩展。
Lucene在系统结构上的另一个特点表现为其引入了传统的客户端服务器结构以外的的应用结构。Lucene可以作为一个运行库被包含进入应用本身中去, 而不是做为一个单独的索引服务器存在。这自然和Lucene开放源代码的特征分不开, 但是也体现了Lucene在编写上的本来意图:提供一个全文索引引擎的架构, 而不是实现。
四、Lucene的倒排文档索引原理
1 Lucene的索引存储
Lucene存放索引信息的是文件。它的索引存储文件设计的比较通用, 输入输出结构都很像数据库的表→记录→字段, 所以很多传统应用的文件、数据库等都可以比较方便地映射到Lucene的存储结构/接口中。它的索引存储文件结构描述如下:
1) 基本定义。
Lucene的基本概念为:索引 (Index) 、文档 (Document) 、字段 (Field) 、术语 (term) 。索引由一个文档序列组成;文档由一个个字段序列组成;字段由一个命名的术语序列组成;术语由字符串构成。
2) 字段类型。
Lucene中的字段有三个重要的属性:
A可分词性:表示字段内容被分成多个可被索引的词 (token) 。每个词是一个术语。当某个字段不分词时, 整个字段内容作为一个术语。
B可存储性:表示字段内容是直接按字词存放, 而不是以到排形式存放。
C可索引性:表示字段内容以到排形式存放, 即:记录了字段的每个术语在某一文档的出现频率。
这三个属性不具有互斥性, 字段可以同时被到排、索引和分词。
3) 段
Lucene索引可以由多个子索引 (即:段) 组成。每段是个完全独立的索引, 可以被独立搜索。索引可以通过两种方式演化:为新增加的文档创建新的段;合并已存在的段。每个段索引包含有:字段名 (Filed names) :在索引中所用到的字段名的集合;存储字段值:存储字段值的集合 (存储字段值是文档的一些辅助存储属性, 如:title, url) ;术语字典 (Term Dictionary) :存放用在所有文档中的所有索引字段的术语, 也包含了拥有该术语的文档数, 和指向该术语频率数据与位置数据的指针;术语的频率数据:包含每个术语的文档数和该术语在文档中的频率;术语位置数据:对在字典中的每个术语, 记录了术语在每个文档中的位置;标准化因子:对每个文档的每个字段, 该值与它的得分值相乘得到最后的分值;删除表:记录了已被逻辑删除但没有物理删除的文档。段都存放在一个索引目录下。
2 Lucene索引结构和算法
Lucene使用的是倒排文件索引结构。该结构及相应的生成算法如下:
首先设有两篇文章1和2
文章1的内容为:Tom lives in Guangzhou, I live inGuangzhou too.
文章2的内容为:He once lived in Shanghai.
4.2.1索引关键词的获取
由于lucene是基于关键词索引和查询的, 首先我们要取得这两篇文章的关键词, 通常我们需要如下处理措施:
a.我们现在有的是文章内容, 即一个字符串, 我们先要找出字符串中的所有单词, 即分词。英文单词由于用空格分隔, 比较好处理。中文单词间是连在一起的需要特殊的分词处理。
b.文章中的“in”, “once”, “too”等词没有什么实际意义, 中文中的“的”“是”等字通常也无具体含义, 这些不代表概念的词可以过滤掉。
c.用户通常希望查“H e”时能把含“he”, “H E”的文章也找出来, 所以所有单词需要统一大小写。
d.用户通常希望查“live”时能把含“lives”, “lived”的文章也找出来, 所以需要把“lives”, “lived”还原成“live”。
e.文章中的标点符号通常不表示某种概念, 也可以过滤掉。
在lucene中以上措施由Analyzer类完成。
经过上面处理后 (关键词用[]括起) ,
文章1的所有关键词为:[tom][live][guangzhou][i][live][guangzhou]
文章2的所有关键词为:[he][live][shanghai]
4.2.2建立倒排索引
有了关键词后, 我们就可以建立倒排索引了。上面的对应关系是:“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来, 变成:“关键词”对“拥有该关键词的所有文章号”。文章1, 2经过倒排后变成:
但是仅知道关键词在哪些文章中出现还不够, 我们还需要知道关键词在文章中出现次数和出现的位置, 通常有两种位置:a) 字符位置, 即记录该词是文章中第几个字符 (优点是关键词亮显时定位快) ;b) 关键词位置, 即记录该词是文章中第几个关键词 (优点是节约索引空间、词组 (phase) 查询快) , lucene中记录的就是这种位置。
加上“出现频率”和“出现位置”信息后, 我们的索引结构变为:
以live这行为例我们说明一下该结构:live在文章1中出现了2次, 文章2中出现了一次, 它的出现位置为“2, 5, 2”这表示什么呢?我们需要结合文章号和出现频率来分析, 文章1中出现了2次, 那么“2, 5”就表示live在文章1中出现的两个位置, 文章2中出现了一次, 剩下的“2”就表示live是文章2中第2个关键字。
以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的 (lucene没有使用B树结构) , 因此lucene可以用二元搜索算法快速定位关键词。
参考文献
[1].车东, 在应用中加入全文检索功能——基于Java的全文索引引擎Lucene简介, http://www.chedong.com/tech/lucene.htm
[2].高琰, 《基于Lucene的搜索引擎设计与实现》, 微机发展, 2004 (10)
[3].开放源代码的全文检索引擎Lucene——介绍、系统结构与源码实现分析, http://www.lucene.com.cn/about.htm
[4].Lucene倒排索引原理, http://www.lucene.com.cn/yanli.htm
[5].周宁, 《基于Lucene/XML的全文检索机制研究》, 图书情报知识, 2005 (6)
全文检索引擎 篇4
所谓跨语言信息检索(Cross-language Information Retrieval, CLIR) ，系指用户以一种语言(通常是自己的母语)提问，检出另一种或几种语言描述的信息资源的信息检索技术和方法。CLIR中，用户用以表达自己的信息需求、构造检索提问式的语言称为源语言(Source Language)，被检索的信息资源所使用的语言称为目标语言(Target Language)。网络用户检索信息主要通过搜索引擎来达到其目的。就中国来说，CNNIC最新发布的《第25次中国互联网络发展状况统计报告》显示，截至2009年12月31日，中国网民规模达到3.84亿人。目前搜索引擎用户规模达到2.8亿人，年增长率为38.6%。搜索引擎的使用率为73.3%，较2008年增加了5.3个百分点，超过了即时通信成为网民使用互联网的第三大应用[1]。然而，网络资源语种的多样性和差异性成为了网络用户存取信息的巨大障碍。网络信息语种分布和网络用户语言分布不平衡。据Internet World Stas统计，截止2009年12月31日，目前全球18亿多网络用户所使用的语言依次为：英语27.7%，中文22.6%，西班牙语7.8%，日语5.3%，葡萄牙语4.3%，德语4.0%，阿拉伯语3.3%，法语3.2%，俄语2.5%，韩语2.1%，其他语言17.2%。虽然笔者没有找到最近Web网页所使用的语言比率，根据Netcraft统计显示，截止2010年6月全球共有2亿多个网站[2]。而根据《第25次中国互联网络发展状况统计报告》统计结果，中国网站数量仅为232万个，比率刚刚超过10%，由此可见一斑。因此，CLIR是全球知识共享的关键因素，是跨越地理和语言障碍获取信息的技术需求。而且，网络用户需要CLIR工具，用其查找、检索和获悉任何语言和形式的相关信息[3]。
2 跨语言信息检索在搜索引擎中的应用现状
搜索引擎按语种分为单语种搜索引擎、多语种搜索引擎和跨语言搜索引擎等。它主要涉及信息检索和机器翻译两个领域的知识，但又不是这两种技术的简单融合。跨语言综合搜索引擎是在一般的搜索引擎基础上加了两个功能：不同语言提问的翻译和不同搜索引擎检索结果的集成。
2.1 跨语言搜索引擎
2.1.1 国内外概况。
国外多数主流的搜索引擎一般具有跨语言检索的功能，如Google、Yahoo!、AltaVista和ixquick等。另外，对检索结果的翻译功能是CLIR技术的一个有机组成部分，是检验CLIR是否成熟以及是否具有实用性的重要指标[4]。此外，Google和AltaVista还能够实现网页翻译，极大地便利了网络用户浏览外文网站。如AltaVista的Babel Fish翻译个人网页多达10000个，当用户点击链接时，链接的网页也会自动翻译。
而具有CLIR功能的中文搜索引擎则较少。就笔者所知的只有传承自Yahoo!的雅虎中国搜索。另外，搜狗具有在线翻译功能[4]。
2.1.2 支持语种数量。
Google Translate目前支持52种语言之间的任何翻译，Yahoo!也可以进行13种语言之间翻译整个网站的文字或短文的检索，AltaVista则可以在19种语言之间进行翻译。但是这些标榜CLIR的搜索引擎大多其实只是多个单语言模式搜索的集合，只有Google Translate可以算是真正意义上的跨语言搜索引擎。这仍将是CLIR发展的一个重要方向[5]。
2.1.3 工作流程。
跨语言搜索引擎的工作流程可以简单的概括为：用户向系统提交检索词，形成一个源语言的搜索式。系统对搜索式进行语言识别，识别出语种后，就进行提问式的词法分析和结构分析，然后把这些分析过的搜索式翻译成各种语言的搜索式。最后把这一系列的搜索式提交给系统进行检索。系统再将检索到的结果反馈给用户。
Google Translate则在它的帮助文档中提到的：“Google Translate是一个自动翻译器，也就是说，它不受人类翻译的干预，而是以国家最先进的技术代替。现在大多数使用中的商业机器翻译系统已经开发了基于规则的方法，并且需要大量的工作来定义词汇和语法。我们的系统采用不同的方法，我们提供数十亿字词的文本给计算机，同时包括目标语言的集成文本，和由各种语言之间人类翻译实例构成的对齐文本。然后，我们应用统计学技术，来建立一个翻译模型。”可见，不同于传统的基于规则的方法，Google Translate的检索策略是基于语料库的方法。它用统计学方法从大规模语料中分析和归纳语言现象和规律，再用得到的统计规律或语言模型来处理自然语言。不过在实际使用中，效果差别不大。
2.2 搜索引擎的在线翻译工具
无论搜索引擎是否具有跨语言检索功能，但是它们提供的各种各样的翻译资源也是很重要的研究工具。除了现有的各种词典外，还有不少的在线翻译工具。另外，如AltaVista提供的在线翻译工具Babel Fish，可以为用户翻译一段字数多达150字的文本。搜狗百宝箱中的在线翻译也可起到辞典和翻译短文的作用。
3 不足与改进建议
跨语言搜索引擎现正处于方兴未艾的状况，因此也存在许多不足与缺陷。找出它们的问题所在，并提出改进的建议，才是推进CLIR的实际措施。
3.1 跨语言搜索引擎的不足
3.1.1 实用性方面，如今CLIR的技术已经取得了长足的进步，但即使是最好的CLIR系统的性能整体上和发展成熟的单语言检索系统仍有差距。在真实语境下跨语言检索系统及其相关工具还是非常缺乏，现有技术离真正的实用化还有一段距离[6]。
3.1.2 交互性方面，大多数跨语言搜索引擎都没有做到与用户的良好互动。单语言搜索引擎在检索结果下方显示相邻和相关词汇的功能，跨语言搜索引擎就不具备。在急需词义消歧的情况下，搜索引擎的交互性显得更加重要。
3.1.3 准确性方面，由于使用商业机器翻译系统，跨语言搜索引擎和在线翻译工具的翻译准确程度显然跟不上用户的需求，当翻译语法结构复杂的文本时更是如此。而真正意义上的CLIR应该是在文档层次进行翻译的。翻译精度不高往往会造成用户对检索结果难以理解。
3.1.4 灵活性方面，传统的基于规则的方法灵活性较差，容易忽略语言中那些经验性的、小粒度的知识，难以覆盖各种复杂纷繁的语言现象。
3.2 改进建议
3.2.1 加强跨语言搜索引擎的系统交互性，采用查询扩展。许多检索词在双语词典中的译项并不唯一，且这些译项所表达的意思有时相差甚远。查询扩展则是在用户输入检索提问后，采取一定策略，对用户的检索要求进行扩充。这样一来，就可以提高检索结果的检全率。同时，要建立用户反馈机制，以求改善CLIR系统。
3.2.2 加强通用商业机器翻译软件的研究，提高机器翻译的质量。在CLIR中，解决语言障碍的基本方法是两种语言之间的翻译，而所有的翻译方法都离不开机器翻译、双语词典、语料库等作为翻译的语言基础。目前的通用商业机器翻译软件普遍质量较低。成为制约CLIR在搜索引擎中广泛应用的一个关键因素。同时，要逐步从限制性强的基于规则的策略过渡到基于语料库的策略。
3.2.3 加强Web语料库的建设。语料库是大量文本的集合，由相互对应的两种语言的素材构成。通过建立语料库收集大量单语或双语语料和词典，可以从中获取语言知识和翻译知识。另一方面，还要克服Web资源种类繁多、数量庞大、所涉及的语种众多，以及Web资源版权保护等给Web语料库建设带来的困难。
4 结语
CLIR研究真正活跃起来并取得成果，是在Internet迅猛发展的20世纪90年代后期，一些实验性CLIR技术相继问世[7]。然而经过十几年的发展，跨语言搜索引擎还是很少，效果也不尽如人意。但是相信随着网络的发展、信息技术的进步和对CLIR技术研究的深入，CLIR能够在将来普遍应用于搜索引擎之中。如今垂直跨媒体搜索引擎发展的如火如荼的良机之下，将来CLIR内容也不会局限于文档检索，而是扩展到跨语言图像检索、跨语言语音检索、跨语言视频检索、跨语言交互式检索、跨语言问答系统、跨语言新话题发现和跟踪等。
摘要：简单介绍了跨语言信息检索在搜索引擎中应用的必要性、重要性和最近的国内外应用状况。指出了对应用中存在的不足和缺陷, 并相对应提出了改进建议。最后对跨语言信息检索在搜索引擎中的应用趋势进行了展望。
关键词：跨语言信息检索,CLIR,搜索引擎
参考文献
[1]中国互联网络信息中心.第25次中国互联网络发展状况统计报告.2010 (1) .
[2]Net craft.June2010Web Server Survey.http://news.Net craft.com/archives/2010/06/16/june-2010-web-server-survey.ht ml#more-2249.2010-06-16.
[3]吴丹.多语言处理技术——数字图书馆的关键技术, 2010 (5) .
[4]华薇娜.搜索引擎的最新进展述要.图书与情报, 2009 (6) .
[5]郭华庚, 赵英.跨语言信息检索研究与应用.现代情报, 2008 (9) .
[6]杨丽.国外跨语言信息检索的技术研究综述.情报杂志, 2008 (7) .
全文检索引擎 篇5
随着技术的发展和计算机、互联网的广泛应用, 信息种类及数量呈现快速增长的态势。
按信息结构化程度来划分可以把信息数据分成三类[1]:第一种完全结构化数据, 如面向对象和关系型数据;第二种无结构数据, 如纯文本的信息;第三种半结构化的数据, 它的最大特点就是结构不规则以及数据可变, 代表性的就是XML结构数据。前两种结构数据其管理技术已经非常成熟, 对于类似XML的半结构数据目前还没有特别好的管理方式。因此, XML信息检索[2]是一个热门的研究方向。
可以使用信息检索方式来查询XML信息。由于其结构性, 不能单纯以文本形式处理, 因此建立索引和搜索使用的算法是管理XML的一种比较理想的方法。XML的信息检索有两种方式:结构查询和关键字查询。本文XObject检索引擎算法是先对关键词构造结构查询路径, 然后在BDB XML执行Xquery查询并返回结果。
1 核心技术概述
1.1 Berkeley DB XML概述
Berkeley DB[3]是一些轻量级目录访问协议服务器, 数据库系统以及其他商业开源应用的底层存储系统。它具有更简单的体系结构, 由访问数据库的程序自主定义数据如何存储在记录里, 每条记录只有key-value两部分。记录和它的键可以达到4G字节的长度, 并支持简单数据类型和Object对象的复杂类型。Berkeley DB也支持很多高级数据库特性, 比如对ACID数据库事物的处理, 细粒度锁, XA接口等特性。
Berkeley DB XML[4], 是一个可嵌入的开源XML数据库, 可基于XQuery接口访问存储在容器中的文档, 并对其内容进行索引。其原理机制如图1所示。
1.2 VTD-XML解析技术
VTD-XML的原理[5]并不复杂, 它将XML文件以二进制形式原封不动的读入内存中, 无需解码, 然后在byte数组上解析每个element位置, 并记录节点信息, 遍历操作在record结果类型进行, 如果需要提取XML内容就利用record中位置信息在原始byte数组上进行解码并返回字符串。
VTD的超能力在于它能将XML这种树形数据结构简单转换成对一个byte数组进行操作, 这样任何对于byte数组的操作都方便的应用在XML上。正是因为读进来的XML是二进制的, VTD则记录着每个element位置等访问信息, 当需要操作VTD时, 只需要提供offset和length等信息就可以对原始byte数组进行任何的操作, 举例来说, 如果想删除某个element, 只要找到element的VTD, 然后将VTD从VTD数组中删除即可, 其效率非常高, 这就是所谓的增量更新。
1.3 Trie树
Trie Tree, 简称字典树, 单词查找树。可用于存储大量的字符串以便支持快速模式匹配[6]。
标准Trie树结构:所有含有公共前缀的字符串都将挂在树种同一个节点下。实际上Trie简明存储了存在于串集合中的所有工作前缀。对于英文单词查找, 完全可以在内部节点中建立26个元素, 组成一个指针数组。如果查找字母a, 只要在内部节点的指针数组中找第0个指针即可, 时间复杂度为O (1) 。当然, 当查找集合中所有的字符串两两都不共享前缀的话, Trie中就会出现最坏的情况。除了根之外, 所有内部节点都只有一个子节点。此时的查找时间复杂度蜕化为O (d* (n2) ) 。
2 XObject检索算法设计与实现
2.1 多文档XObject检索算法概述
XObject检索算法是先对关键词构造结构查询路径, 然后在BDB XML执行Xquery查询并返回结果, 具体步骤描述为: (1) 对XML文档进行预处理, 包括XML文档解析和XML文档结构聚类; (2) 对于给定的查询关键词, 根据索引结构动态构建结构查询路径; (3) 根据结构查询路径构造Xquery, 并在BDB XML上执行查询; (4) 排序查询结果并通过前台页面展示给用户。
2.2 BDB存储设计
Berkeley DB[3]在多文档XObject检索算法中, 主要存储XML文档结构、聚类结构、倒排表、常用输入词和同义词词库, 具体的存储形式如下:
(1) 数据库名:my All Xml Stru DB
键对名:
描述:my All Xml Stru DB数据库存储所有被检索文档的路径信息
Xml File Name表示XML文档名
Elem Path#Freq表示路径及其频率
其中Elem Path由elem&is Object Tag形式拼接而成。
(2) 数据库名:my+clusterN ame+ClusterS tru DB
键对名:
描述:my+cluster Name+Cluster Stru DB存储所有文档聚类结构信息
cluster Name表示聚类类名
labeled Elem表示标记后的Element名称,
形式如elem&isO bjectT ag-labeled Number
parent-labeled Elem#freq表示labeled Elem的父节点及其频率
(3) 数据库名:my ElemI nvertL istD B
键对名:
描述:my Elem Invert List DB存储Element的倒排表
(4) 数据库名:my ElemS yn SetD B
键对名:
描述:my Elem Syn Set DB存储所有Element的同义词
(5) 数据库名:my FrequentI nputD B
键对名:
描述:my Frequent Input DB存储常用输入词, 用于自动补全和相关搜索
(6) BDB XML存储
ContainerN ame:ClusterN ame
描述:用聚类类名来表示Container名, 每个Container存储该类下的所有XML文档, 用于多文档Xquery查询。
2.3 基于Trie匹配的结构聚类
为度量两个文档结构的Trie[7]的相似度, 首先要给出如下三个定义。
定义1:XML文档结构Trie路径总长度Lp。
对于给定的XML文档d, 若d有n条路径, 每天路径长度为li, 则总长度为
定义2:基于Trie前缀匹配的路径总长度Lpp。
对于给定的两XML文档d1、d2, 设d1为被匹配对象, d2为匹配对象, 则d2的前缀匹配的路径总长度为Lpp=∑in=1pmi, 其中n表示d2的路径总数, pmi表示路径pi在d1的Trie中的前缀匹配路径长度。
定义3:两XML文档结构的相似度为θ (d1, d2) 。
对于给定的两XML文档d1、d2, 设d1为被匹配对象, d2为匹配对象, d1的Trie路径总长度为Lp1, 前缀匹配的路径总长度为Lpp, 则两文档结构相似度 。
若θ (d1, d2) >θthreshold, 则认为两文档结构相似, 可聚成一类, 反之结构不相似。其中0<θthreshold≤1, θthreshold由用户自己定义, 越大相似度越高, 对聚类要求越高, 反之相似度越低, 对聚类要求越低。
基于Trie匹配的XML结构聚类算法步骤描述如下。
输入:文档集D={d1, d2, …, dn}, 对应的结构信息为S={s1, s2, …, sn}
输出:文档集P={p1, p2, …, pk}及其对应的类结构信息CS={cs1, cs2, …, csn}
(1) 定义数组current Xml Files, 用于记录当前未被聚类的XML文档名, 初始化为全部文档名, L为数组current Xml Files的长度。
(2) 取current Xml Files里第一个文档d2的路径集s1构建d1的Trie1。
(3) 取文档di (i=2, L) 的si, 对于si的每条路径pi, 在Trie1中进行查询匹配, 得到前缀匹配的最大路径总长度为Lpp, 若 (此算法中θthreshold=0.5) , 则转步骤 (4) ;否则若i
(4) 对于si的每条路径pi, 若路径在Trie1完全匹配, 则在Trie1中置该路径频率为fcur+fi;否则利用构建Trie方式将路径pi插入到Trie1中, 即逐步记录该类的所有路径以及其频率信息, 并从current Xml Files中删除d1, 将d1加入当前的类c中。若i
(5) current Xml File一次扫描结束, 保存一次聚类的结构信息Trie1和属于该类的文档名集合c, 若current Xml Files数组不为空, 继续步骤 (2) , 否则聚类结束。
基于Trie匹配的结构类聚的优点在于:可以统计该类的频繁路径并可完整保存类结构信息。
假设有N个待聚类的XML文档, 分析基于Trie匹配结构类聚的时间复杂度, 最理想情况是这N个文档聚成一类, 一次扫描即类聚结束, 时间复杂度为O (N) 。最差的情况为N个文档聚类成N类, 需要扫描N次, 时间复杂度为O (N2) , 因此分析可得基于Trie匹配的结构聚类时间复杂度为O (N*m) , m为聚类后类的总数。
2.4 聚类文档BDB XML存储
便于聚类结构查询以及BDB XML文档存储, 本文将聚类的结果封装成一个clusterResult类, 其属性如下:
private String cluster Name;//记录类名
private Array List
private Standard Trie cluster Trie;//记录类结构
将属于一个类别的XML文档放到相同的container容器里面并以该类的cluster Name命名, 以便查询路径后与Xquery命名一致。
2.5 预处理与动态构建查询路径
为了正确构建查询路径, 首先需要对用户输入的关键词进行预处理[7], 预处理流程如图2所示。
关键字预处理完成后, 动态构建查询路径算法为: (1) 根据element倒排表定位到关键词所在的cluster, 并保存在数组cluster Names中; (2) 对于每个cluster, 运用哈希双亲键动态构建从根到查询关键字的路径; (3) 若为单个关键字, 则需直接保存该cluster下的路径和频率, 转步骤 (4) , 否则, 运用Trie查询匹配来求得公共前缀路径, 并保存在cluster下的公共前缀路径和其频率, 转步骤 (4) ; (4) 重复步骤 (2) , 直到数组cluster Names中每个cluster都能够被方访问, 转步骤 (5) ; (5) 对于所有路径, 要根据它们出现的频率大小进行降序排列, 为接下来的Xquery查询结果提供一级排序。
3 XOject算法测试与结果分析
为了测试基于Trie查询匹配的结构聚类的效果, 本文采用Index Terms Page、Ordinary Issue Page以及Proceedings Page三个不同DTD的各1000个XML文档作为测试数据集。
本文采用了信息检索所常用的两种指标来评估聚类实验效果[8]:召回率 (Recall) 和精确率 (Precision) 。对于给定类别的ci, 令Ai为正确聚类到ci的文档数量, Bi为错误聚类到ci的文档数量, Ci为本应该属于ci但却聚类到别类的文档数量, 精确率和召回率分别定义如下:
精确率和召回率越大说明其聚类效果和质量越好。实验中设定θthreshold=0.5, 将三类不同DTD3000个文档混合在一起进行结构聚类, 聚类效果如表1所示。
从结果上可以看出, 该结构聚类算法的召回率和精确率均为100%, 聚类效果十分显著。
4 结束语
本文设计并实现了基于BDB的XObject检索引擎核心算法, 在底层技术、算法优化、结构聚类以及存储处理上都有一定创新之处, 实现了本地XML的关键字检索。若要拓展成互联网搜索引擎就要添加相应的网络爬虫技术, 对于海量页面数据信息的处理, 就有必要实现分布式检索。
在本算法设计和实现的过程中, 本文注重了接口设计以及功能效率, 由于时间有限, 提出了对于未来分布式检索的理念和想法, 希望在时间和精力充沛的情况下, 将该检索算法与检索平台相结合开发出有实用价值的互联网XML检索引擎。
摘要：XML作为互联网数据交换及数据表现的标准, 其重要性日益凸显, 如何从大量的XML中挖掘有效信息已成为目前亟待解决的问题。设计并实现一个基于BDB的XML检索引擎算法XObject, 通过构造关键词结构查询路径、进行结构聚类, 并最终在BDB XML执行Xquery查询实现本地XML的关键字检索, 从而解决XML信息挖掘中的关键技术课题——XML信息检索。
关键词：Berkeley DB,XML结构聚类,XObject
参考文献
[1]Zhang L, Li Z, Chen, et al.Structure and content similarity for clustering XML documents[J].Web-Age Information Management, 2010:116-124.
[2]Altingovde I S, Atilgan D, Ulusoy O.Exploiting Index Pruning Methods for Clustering XML Collections[J].Focused Retrieval and Evaluation, 2010:6203, 379-386.
[3]Rosenmüller M, Apel S, Leich T, et al.Tailor-made data management for embedded systems:A case study on Berkeley DB[J].Data&Knowledge Engineering, 2009, 68 (12) :1493-1512.
[4]Xu Yu, Yannis Papakonstantinou.Efficient keyword search for smallest LCAs in XML databases[C].Proceedings of the 2005 ACM SIGMOD international conference on Management of data.ACM, 2005.
[5]Zhang J.VTD-XML:XML processing for the future (Part I) [J].The Code Project, 2008:8.
[6]Doeringer W, Dykeman D, Karjoth G, et al.Variable length data sequence backtracking a trie structure:U.S.Patent:5, 787, 430[P].1998 (7) :5, 430-787.
[7]De Vries C, Geva S, De Vine L.Clustering with random indexing Ktree and XML structure[J].Focused Retrieval and Evaluation, 2010:407-415.
全文检索引擎 篇6
随着Internet和WWW的迅速发展, Internet上的资源越来越丰富, 基于Internet的各类信息检索服务随之诞生并获得了迅速的发展。在中国, 出现了非常优秀的中文、英文搜索引擎, 如Google、Baidu等, 但是这些搜索引擎没有解决少数民族语言文字特征方面的关键问题 (民文在线输入及显示, 标准字符编码, 网页布局及书写方向, 关键词语处理等) , 完全不能满足少数民族语种的网络信息检索需求。到目前为止, 针对维吾尔文、哈萨克文、柯尔克孜文 (以下简称维、哈、柯文) 等少数民族语言的搜索引擎的研究还处在空白阶段, 还没有一个比较成熟的搜索引擎。新疆是个多民族、多语言、多文字、多元文化的地区。为了使新疆少数民族人民适应时代和经济的发展, 已经有许多人或机构纷纷创建各种类型的自己语言的网站 (主要是维、哈、柯文三种语言) , 传播本民族信息, 促进本民族经济发展。为了能够在网上快速检索以本民族语言发布的信息页而开发一个多文种搜索引擎是新疆少数民族面临的一个急待解决的重要问题。因此, 开发一个比较完整的少数民族语种的搜索引擎, 为广大的少数民族网络用户民文信息检索提供方便, 对于发展少数民族地区教育和经济, 提升社会的信息化水平有着非常重要的意义。
1 系统总体设计
如图1 所示。本搜索引擎由四个服务模块组成[1]。
维、哈、柯全文搜索引擎中各模块的主要功能如下:
(1) 数据采集模块[2] (Crawler)
下载维、哈、柯文网页并存储到html文档库中。
(2) 文档处理模块[3] (Analyzer)
从html文档库中读取已下载的页面数据, 并提取页面正文, 将正文字符转换成标准Unicode字符, 再经过分词 (关键词) 、去除停用词和常用词、词根切分等处理之后生成索引关键词序列并存储到索引库中。
(3) 索引模块[4] (Indexer)
负责根据索引库的内容和Page rank值在内存中建立到排索引表, 并根据查询关键词给检索服务模块 (Retrieval Server) 返回关键词有关索引信息。
(4) 检索服务模块[5,6] (Retrieval Server)
负责接受用户查询, 对查询关键词进行预处理和进行数据库检索, 并将结果展现给用户。
2 前期工作
因为使用新疆少数民族文字建立的网站 (主要是维、哈、柯文) 比起使用中文或英文的网站少得多, 所以首先统计这些网站, 收集他们的种子URL地址 (首页地址) 、网站性质和他们所使用的字符编码标准、语种等信息。据我们统计, 现在访问率较高的维、哈、柯文网站大概有250多个, 其中大概有四分之一的网站使用非标准的字符编码 (主要有三种非标准字库) 。因此, 对这些网站中被爬行到的网页还需要进行额外的字符代码标准化工作, 否则无法正常显示搜索结果。同时收集了大量的维、哈、柯文单词、词根、停用词, 分别创建了维、哈、柯文词语库、词根库和停用词库等必要的语料库在后继开发中使用。
3 主要功能模块的实现
3.1 数据采集模块的实现
所有爬行器都首先获取某一个网站的入口网页然后对它进行分析并把分析的结果作为下次爬行的前提, 我们的爬行器也使用这种思路, 并且为了提高爬行器的工作效率我们使用了多线程策略。一般下载页面的方法有三种, 其第一种方法是直接使用开发环境提供的类库, 如:Visual Studio.Net中的HttpWebRequest, HttpWebResponse等。操作简单, 但是某些页面 (实用保护技术) 不能下载。第二种方法是开发人员自己实现Http协议, 但具体实现Http协议的过程太复杂了, 编程难度大。第三种方法, 也就是我们选用的方法是使用操作系统提供的WinInet (Win32 Internet Function) API 函数, 是一个易用的网络编程接口, 可以大大简化编成难度。数据采集模块的工作流程如图2所示。
其中URL处理模块主要用来对待下载的URL利用某种策略进行排序, 并根据一定的策略向协议处理模块分配URL。协议处理模块主要通过各种Web 协议来完成页面的下载。重复内容检测主要用来消除一些镜像页面的影响, 然后把非重复页面 (页面ID, 语种, 地址, 更新日期, HTML代码等) 存放到下载页面库中。URL提取和过滤完成的就是从页面中提取超链并将所需的URL提交给URL处理模块进行处理的功能。
3.2 文档处理模块的实现
对已下载的页面进行分析和处理, 从而得到一系列重要信息是整个搜索引擎的核心。本模块中主要实现的功能有:
1) 从html文档库中读取已下载的网页并进行网页去噪和正文提取。
2) 确定正文所使用的字符编码标准是哪一种编码标准 (标准还是非标准) , 如果是非标准的, 则将正文字符转换成标准Unicode (维、哈、柯文) 字符。
3) 正文分词, 通过我们预先建立好的停用词 (stop words) 库删除其中的停用词, 然后对剩下的关键词进行词根切分, 并对同根词进行压缩生成检索关键词序列。形成的结果是文档号到索引词的对应关系表。每条记录中包括文档编号、索引词编号, 索引词在文档中的位置、出现次数、长度等信息。最后把以上得到的数据存储到索引库中。维、哈、柯全文搜索引擎文档处理模块结构如图3所示。
3.3 索引模块的实现
到目前为止, 维、哈、柯文网页的总数目大约在5万个左右, 相对于英文、中文网页来说, 数目非常小。再考虑系统硬件资源, 我们设计的索引器模块运行在一台Sun Sparc服务器上, 其所具有的内存容量为8GB, 这足以将索引表全部建立在服务器的内存中。针对维、哈、柯文网页所具有的实际情况, 以及构建维、哈、柯多语种全文搜索引擎所拥有的硬件资源, 在设计中将倒排索引作为索引结构, 在内存中建立索引表。这样可以充分利用硬件资源, 提高效率。
针对以上情况, 设计中采用Hash链表作为倒排索引模块的数据结构。在倒排索引的具体实现中, 将数组作为Hash链表的表头, 对于每一个关键词首先通过Hash函数来计算得到一个key值, 然后用key值同数组大小进行取模运算, 这样就可以将一个关键词映射到某一个特定的Hash链中。Hash链表的节点中存储了每个关键词的倒排索引信息, 包括关键词、包含此关键词的网页编号、此关键词在包含它的网页中的位置信息等内容。倒排索引的组织形式如图4所示。
倒排索引模块启动后 (其工作流程如图5所示) , 连接Oracle数据库, 从索引库中读出关键词序列并建立到排索引表, 索引建立完毕后, 就可以接受检索服务模块的查询请求了。当检索服务模块有查询请求到来时, 就从倒排索引表中查找相对应的关键词, 进行一些必要的处理后, 将查询结果返回给检索服务模块, 之后立即断开与检索服务之间的Socket连接, 并继续等待检索服务的其他查询请求。
3.4 检索服务模块的实现
检索服务模块负责接受用户查询、对查询关键词进行预处理和进行数据库检索、并将结果展现给用户, 是本搜索引擎的用户接口。因为该模块的实现牵涉到一系列少数民族语言计算机处理技术问题, 因此, 如果这些问题没有得到彻底的解决, 将会明显降低搜索引擎的查准率和查全率。维、哈、柯全文搜索引擎Retrieval Server模块结构如图6所示。
· 关键词检错 维吾尔语、哈萨克语、柯尔克孜语中的一个词是由若干个字母前后相连的字母联体, 字符集中相似字母较多, 拼写出错率较高, 再加上各地人民发音习惯上的差异, 很容易产生拼写错误。因此, 为了快速、正确地搜索相关内容的网页, 对用户输入的关键词进行检错 (拼写检查) 是很有必要的。在研究中我们收集了大量的词语, 分别创建了维吾尔语词语库、哈萨克语词语库和柯尔克孜语词语库作为检错依据。从词语库中查找每一个关键词, 如找到则是正确的, 否则是错误的。
· 关键词纠错 (候选词选择) 当用户输入的关键词出现拼写错误时, 搜索引擎Retrieval Server应该给用户返回拼写错误提示或者给用户返回若干个候选关键词让用户再次确定, 保证搜索关键词是正确的, 搜索结果也是正确的。
在研究中, 为了提高纠错效率, 我们统计并收集了一般拼写出错率95%以上的大约六千个单词的错误拼写和正确拼写, 并建立了对照词语库。我们的算法是:首先从对照词语库中查找拼写错误的关键词, 如找到, 则直接得到正确的关键词, 如果不在对照词语库中, 那么用最小编辑距离算法和长度优先算法找到与用户输入的关键词最接近的若干个 (本算法中限定为5个) 候选词并返回给用户。两个符号串之间的最小编辑距离是指把一个符号串转换为另一个符号串时所需的最小编辑 (插入、删除和替换) 操作次数。例如, “”和“”之间的编辑距离是1 (一个字符替换操作) , 我们根据最小编辑距离的大小和字符长度匹配, 给用户返回匹配概率最大的5个候选词, 让用户再次确定。
· 词根切分 维吾尔语、哈萨克语和柯尔克孜语都是一种黏性语言, 在这一类语言中词 (word) 是最小的独立运用的语言单位。词是由词根和附加成分构成。如:用户输入的维吾尔文关键词“” (中国的人口) , 其中, 搜索引擎应该能够搜索包含词根“” (中国) 和“” (人口) 的所有网页。因此, 设计高准确率的切分算法对关键词进行词根切分, 能够给用户提供比较全面的搜索结果是本搜索引擎Retrieval Server关键技术之一。 在设计中, 分别创建了维吾尔文词根库、哈萨克文词根库和柯尔克孜文词根库作为主要的切分依据。
· 同化 (弱化) 处理 如果关键词没有拼写错误或者有错误但是已经纠正过来以后, 通过词根切分算法还是找不到词根, 那就表明该词中产生同化现象。同化是指有的维、哈、柯文词根连接某些词缀时其词根最后一个音节的有些字母 (元音或辅音) 被替换成另外一些字母。如:维文词根连接某些词缀时其词根最后一个音节的“”, “”字母被替换成“”或“”字母, 这种现象称元音同化。解决同化问题是维、哈、柯文搜索引擎Retrieval Server的技术重点也是难点。在我们的算法中首先进行音节分解, 然后从最后一个音节开始检查, 如音节中有元音字母“”或“”, 分别替换成“”和“”, 这一过程我们称复原。对复原过来的音节再进行重组, 然后再进行词根切分。
· 提取网页相关内容、格式处理、返回搜索结果 用户提交关键词并经过关键词预处理模块并提取关键词词根之后, Retrieval Server激活通信模块跟索引器 (Indexer) Socket连接, 将关键词词根发送给索引器并从索引器得到与关键词相关的索引值, 包括该关键词出现的网页个数, 前十个网页在数据库中的ID号, 每一个网页中关键词出现的个数、位置、长度等信息, 然后交给本模块处理。本模块根据索引信息从数据库提取每个网页ID号对应的网页标题、URL和网页内容。然后再根据关键词在本网页中的出现次数、出现位置、长度等信息提取前五个关键词和每个关键词前后部分内容构成长度为600个字符的网页摘要, 再加上网页标题、URL等内容生成搜索结果页面返回给用户。
4 结束语
该搜索引擎已经以www.tapkak.com为域名开始提供维、哈、柯文信息检索服务, 得到了广大维吾尔族、哈萨克族、柯尔克孜族网络用户的认可, 成为了新疆地区唯一的少数民族语种的全文搜索引擎, 弥补了新疆地区民文网络信息检索技术领域中的空白。
总的来说, 我们设计的这个搜索引擎系统除了包含现有信息检索技术的很多方面, 还涉及到少数民族语言文字计算机处理关键技术。尽管有些方面做得不是很好, 但是我们会在进一步的工作中对它们进行改进和优化, 并对其功能进行扩充, 例如对用户查询的处理添加语义理解, 使得检索结果更加精确, 对文档的索引机制进行改进等。
参考文献
[1]李晓明, 闫宏飞, 王继民.搜索引擎——原理、技术与系统[M].科学出版社, 2005, 4 (1) :20-27.
[2]杜亚军, 严兵, 宋亮.爬行虫算法设计与程序实现[J].计算机应用, 2004, 24 (1) :33-35.
[3]吴鹏飞, 孟祥增, 刘俊晓, 等.基于结构与内容的网页主题信息提取研究[J].山东大学学报:理学版, 2006, 41 (3) :131-134.
[4]贾崇, 陆玉昌, 鲁明羽.一种支持高效检索的即时更新倒排索引方法[J].计算机工程与应用, 2003, 29:198-201.
[5]米吉提.阿不力米提.在多文种环境下的维吾尔语文字校对系统的开发研究[J].系统工程理论与实践, 2003, 23 (5) :117-124.
全文检索引擎 篇7
关键词：信息检索,中文搜索引擎,存在的问题,发展方向
随着Internet信息资源的迅速增长, 如何在浩瀚的信息海洋中准确、方便、快速地找到自己所需的信息, 成了迫切需要解决的问题, 从1995年开始出现的信息检索工具——搜索引擎很好地解决了这一问题。然而各种搜索引擎, 特别是尚处于发展初期的中文搜索引擎还存在着很多的缺陷有待改进, 本文旨在分析目前中文搜索引擎存在的主要问题, 并为解决此类问题提出一些建议和方法。
一、搜索引擎的概念和及类型
搜索引擎又称检索引擎, 是指运行在Internet上, 以信息资源为对象, 以信息检索的方式为用户提供所需数据的服务系统, 主要包括信息存取、信息管理和信息检索三大部分。
目前, 中文搜索引擎主要有三种类型:目录式搜索引擎、机器人搜索引擎 (又称全文搜索引擎) 和元搜索引擎。
1. 目录式搜索引擎。
目录式搜索引擎是以人工或半人工方式收集信息, 建立数据库, 由编辑人员在访问了某个web站点后, 对该站点进行描述, 并根据站点的内容和性质将其归为一个预先分好的类别。由于目录式搜索引擎的信息分类和信息搜集有人的参与, 其搜索的准确度较高, 导航质量也不错。但因其人工的介入, 维护量大, 信息量少, 信息更新不及时都使得人们利用它的程度有限。国内著名的新浪、搜狐、中文雅虎都属于这种类型。
2. 机器人搜索引擎。
这是一种目前运用较广泛的搜索引擎。国内以百度, google、天网为代表。它是使用自动采集软件Robot, 搜集和发现信息, 并下载到本地文档库, 再对文档内容进行自动分析并建立索引。对于用户提出的检索要求, 通过检索模块检索索引, 找出匹配文档返回给用户。
机器人搜索引擎具有庞大的全文索引数据库。其优点是信息量大, 范围广, 较适用于检索难以查找的信息或一些较模糊的主题。缺点是缺乏清晰的层次结构, 检索结果重复较多, 需要用户自己进行筛选。
3. 元搜索引擎。
元搜索引擎是一种调用其他搜索引擎的引擎。它是通过一个统一的用户界面, 帮助用户在多个搜索引擎中选择和利用合适的搜索引擎来实现检索。中文元搜索引擎开发较少, 较成熟的则更少, 万纬搜索是目前有一定影响的中文元搜索引擎。
二、现阶段中文搜索引擎存在的主要问题
1. 信息覆盖面有限。
现阶段搜索引擎所覆盖的数据库的规模是非常有限的, 据美国科学期刊Natures一篇报告中称, 全球最大的搜索引擎也只能覆盖现有网页的16%。中文搜索引擎因起步慢、中文信息所占互联网全部信息的比例小 (只占全部网络信息的5%) 等原因在这方面尤为突出。
2. 查全率不高。
查全率是指检索出的相关信息量与存储在检索系统中的全部相关信息量的百分比, 是判断检索系统质量的度量之一。
国内绝大多数的网站组织的信息大多都是通过浏览方式获得内容。即使是经过精心组织、编排非常合理的网站, 也会有70%~80%的网页不能被搜索引擎检索到。中文目录式搜索引擎因需人工介入、维护量大, 在这方面表现较明显。
3. 查准率较低。
查准率更是判断检索系统质量的重要尺度。是指系统所检索到的真正与查询内容相关的文档占检索出的所有文档数的百分比。
造成查准率低的原因是, 部分搜索引擎的分类体系与科学知识体系之间缺乏内在联系;类目之间逻辑关系模糊, 导致检索路径与搜索引擎类目错位;信息加工深度不够;检索功能单一;检索词的专指性较差;大部分的检索结果是题录式而非全文式, 其内容简单等等。机器人搜索引擎的分类和索引缺乏人工的参与, 其查准率不如目录式搜索引擎, 且检索结果中还含有大量的重复、虚假的信息。
4. 专业性的搜索引擎发展迟缓。
专业性的搜索引擎是为专门收录某一行业, 某一主题的信息而建立, 能够提供专题信息查询服务的搜索引擎。目前中文搜索引擎大多是综合性的, 能同时收录各行业、各学科的多种信息, 但在反映某一行业或某一专题的信息方面很难做到全面、精确, 不能给用户提供特定的信息服务。这就使得专业人员, 特别是某一领域的学者、专家不愿意利用中文搜索引擎去查询资料。
5. 检索功能方面存在缺陷。
一是检索中符合布尔逻辑运算符的搜索引擎极为有限;二是关键词检索输出的结果相关度排序方式杂乱, 不能根据用户需要来选择信息输出的方式;三是多数的搜索引擎是面向主题搜索不是面向用户搜索, 不能重复利用用户检索过的成果, 更不能对特定的用户进行定题跟踪服务;四是检索网站的主页不规范, 有些太简, 有些又太繁, 而且广告内容太多, 无法进行有效检索。
三、中文搜索引擎的发展方向
1. 提高查全率。
首先是需要开发分布式的系统。这种系统可以把各个接点当作是新的信息资源, 扩大数据库的规模, 正在兴起的元搜索引擎属于这种系统, 它在接受了用户的查询命令后, 可同时用多个搜索引擎进行查询;二是把专业数据库资源纳入自己的检索范围。除了Web信息资源外, 网上还有大量的非Web信息资源, 如联机检索系统、光盘检索系统、专业数据库系统。如中文搜索引擎能把这些Web和非Web资源结合起来使用, 即使有的只能查到题录、文摘等内容, 也大大扩展了检索范围, 能为用户提供较全面的检索需求。
2. 提高查准率。
需解决以下几个难关:首先需提高搜索引擎的信息过滤功能。在对网络信息进行集中的搜集之后, 搜索引擎还需对这些信息进行鉴别和过滤, 即剔除大量的无用信息, 而把有效的信息提炼出来并加以聚集;第二则是需对专家过滤后的信息进行一定的检索标引, 并给予相关的标识符号, 如关键词、分类号、主题词等各种标识, 其关键是利用智能检索技术, 提高准确性;把检索的结果存储在相应的数据库中, 并由URL与Internet建立链接供用户使用;还需注意信息定期更新, 以保证信息的新颖性和链接的可靠性。
3. 建立垂直化专业领域的搜索引擎。
网络用户所从事的职业千差万别, 不同的用户对信息搜索往往有不同的要求。综合性的搜索引擎收录的范围太广、太大无法满足某一特定的需求。垂直化专业搜索引擎则可解决这一难题。它只面向某一特定的领域, 专注于自己的特长和核心技术, 能保证对该领域的信息的收录齐全与更新迅速。在提供专业信息方面有着大型综合搜索引擎无法比拟的优势, 所采用的技术都是些较成熟的技术。
中文垂直化专业搜索引擎的发展已取得了一定的成功, 如新浪的新闻搜索, 博客搜索、雅虎的个性化旅行路线搜索、百度的MP3搜索、Google的学术搜索, 航班搜索等都为用户提供了较好的搜索功能, 为今后的继续发展奠定了基础。
4. 搜索引擎的智能化发展。
智能搜索引擎是未来搜索引擎的发展趋势。可以通过自然语言与用户交互, 最大限度地了解用户的需求。智能检索一是表现在搜索引擎技术的智能化, 研究重点放在自然语言处理技术和人工智能技术的研究上;另一表现是体现在搜索引擎面向检索者的智能化, 它致力于通过分析检索者的检索和浏览行为来学习检索者的需求, 利用搜索引擎现有的服务有选择地为检索者提供个性化的服务。
5. 加强搜索引擎的检索功能。
首先需强化全文检索功能。利用Robot实现对站点页面文字内容的全面检索技术。比起目录检索, 全文检索提供了全新的检索功能, 可以直接根据文献资料的内容进行检索, 支持多角度、多侧面地综合利用信息资源, 全面、准确、快速是衡量全文检索系统的关键指标;同时改善用户检索界面, 设计简洁、明白的界面引导用户进入检索状态;更方便、实用的检索技巧的利用, 中文搜索引擎需简化和统一语法规则, 如布尔逻辑检索符号的利用:空格或“*”代替“与”、“+”代替“或”、“-”代替“非”, 规范语法符号, 节省用户的检索时间;还需研发查询图像、声音、图片和电影的搜索引擎。
6. 完善元搜索引擎。
元搜索引擎弥补了独立搜索引擎不全的特点, 提高了检索的全面性。现开发出的中文元搜索引擎的数目很少, 还有诸多缺陷, 需在各方面进一步改进。
元搜索引擎要对各独立的信息特色进行较细致的调查, 以确定自己要收录的范围;在对目标搜索引擎的组织中突出独立搜索引擎的检索特色, 并设计各搜索引擎之间的检索方式的转换算法, 提高用户检索行为的针对性;建立更为灵活的, 面向用户的信息检索服务。检索界面要统一和友好, 检索方法的设置要提供给用户更多的自由空间, 使用户可以按照自己的意愿合理的组织检索式;在检索结果的显示中要开发出一个有效的检索结果去重、选择、排序和优化算法, 这是中文搜索引擎开发中的一个重点和难点。
参考文献
[1]孙建军 成 颖:信息检索技术[M].北京:科学出版社, 2004