全文检索技术研究与应用论文.docx

全文检索技术研究与应用论文.docx

《全文检索技术研究与应用论文.docx》由会员分享，可在线阅读，更多相关《全文检索技术研究与应用论文.docx（22页珍藏版）》请在冰豆网上搜索。

全文检索技术研究与应用论文

摘要

全文检索是现代信息检索技术的一个非常重要的分支，它是处理非结构化数据的强大工具，也是搜索引擎的核心技术之一。

本文对中文全文检索的有关技术进行了较为深入的研究。

在基于字表的全文索引方面，本文提出了一种改进的倒排索引结构，同传统索引结构相比，更便于索引的构建、维护、更新。

本文的重点放在了全文检索技术的应用上，对如何利用新技术、改善检索系统的结构、提高检索系统的性能和效率、加快检速度、不断适应网络信息发展等方面做了重点研究。

全文检索是一种IO密集型的应用，以往的全文检索系统的开发多在关系数据库的基础上进行。

本文针对全文数据库的特点，深入讨论此法弊端与不足，并提出了在文件系统上构建的解决方案。

由于目前全文检索系统的开发平台并不多见，本文介绍了一种全文检索引擎工具包一Lucene，它功能强大，小巧精悍，便于嵌入各种应用。

近年在世界各地被广泛使用，诸如IBM等公司都使用其核心代码。

作为一个开源软件，它为我们学习搜索引擎的核心技术提供了绝佳的机会，对其剖析研究、进行二次开发，是一件很有意义的事情。

在应用方面，本文主要工作是本校学位论文全文数据库的设计与实现。

关键字：

全文检索倒排文件Lucene全文数据库自动分词

THERESEARCHANDIMPLEMENTATION

OFFULL-TEXTRETRIEVALSYSTEM

（ABSTRACT）

Full-textretrievalisanimportantinformationretrievaltechnology.Itisapowerfultoolfordealingwithnonstructuraldata,andisoneofthekeytechnologiesofthesearchengine.ThispaperdeeplyresearchonChinesefull-textretrievaltechnology.Inthefiledoffull-textindexbasedonwordinvertedtable,aimprovedword-basedChineseinvertedindexstructureisproposedwhichhasabetterperformancethantraditionalapproaches,andconvenientforconstructing,maintainingandupdatingindex.According.toitscharacteristic,wedesignitscorrespondingoptimizedsearchmethod.Analysisshowsthatbetterdynamicperformanceandhighindexingspeedispossibleusingthisstructure.Thispaperpaysmoreattentioninapplicationoffull-textretrievaltechnologies.Howtousenewtechnique,optimizethestructureofretrievalsystem,improveperformanceandefficiency,quickensearchspeedandadaptthedevelopmentofcurrentwebisalsodiscussedinthispaper.

Full-textretrievalisanI/Ointensiveapplication..Itspreviousdevelopmentsarecarriedonthebasisofrelationdatabase.Thispaperdeeplydiscussestheabuseanddeficiencyofthismodeaccordingtoitscharacteristic.Becausethedevelopmentplatformoffull-textretrievalisabsentcurrently,Lucene,afull-textsearchenginetoolkit,isintroducedintothepaper.Ithaspowerfulperformance.anditsbodyiscabinet,capableandvigorous.thisconvenientforitembeddedapplications.Atpresent,Luceneisemployedworldabroad,sothatmanyprofessionalcompaniessuchasIBMalsouseitscorecode.Asanopensourcecodesoft,Luceneofferasuperexcellentchancetostudysearchenginekeytechnology.Itisworthfultotakeaparse.researchandcarryseconddevelopmenttoit.

Intheapplicationaspect,thispaperworkmostlyinthedesignandimplementofthedegreedissertationfull-textdatabaseinuniversity.

KEYWORDS:

Full-text，InvertedFile，Lucene，Full-textDatabase

DividedSyncopation

目录

一、全文检索技术简介1

1.1论文研究背景1

1.2什么是全文检索1

1.3全文检索与关系数据库2

1.4全文检索需要解决的问题3

二、建立索引库4

2.1索引文件分类4

2.1.1、顺排档结构4

2.1.2、倒排档结构4

2.2倒排索引压缩6

2.2.1倒排索引压缩初步实现6

2.2.2动态文本集的倒排索引压缩方案7

2.2.3Lucene压缩技术8

2.3索引增量更新9

2.3.1利用B树实现倒排索引的更新9

2.3.2Dual-Structure索引结构10

2.3.3Lucene索引过程优化11

三、中文分词研究12

3.1什么是中文分词12

3.2为什么需要中文分词12

3.3中文分词技术14

3.3.1、基于字符串匹配的分词方法14

3.3.2基于理解的分词方法17

3.3.3基于统计的分词方法18

3.4分词中的难题18

3.4.1歧义识别19

3.4.2新词识别19

四、索引数据库的搜索21

4.1词库查找方法21

4.2lucene搜索算法21

4.3搜索过程优化23

参考文献25

致谢26

一、全文检索技术简介

1.1论文研究背景

信息时代产生了大量数字信息,而这些信息大致可分为两类：

结构化数据和非结构化数据，结构化数据指的是诸如企业财务帐目和生产数据、学生的分数数据等等，非结构化数据的则是一些文本数据、图象声音等多媒体数据等等。

据统计，非结构化数据占有整个信息量的80%以上。

对于结构化数据，用RDBMS（关系数据库管理系统）技术来管理是目前最好的一种方式。

但是由于RDBMS自身底层结构的缘故使得它管理大量非结构化数据显得有些先天不足，特别是查询这些海量非结构化数据的速度较慢。

而通过全文检索技术就能高效地管理这些非结构化数据。

国内外对全文检索的研究方兴未艾，己有一些较成熟的商用产品相继问世。

中文全文检索与英文检索相比，由于自然语言体系不同，索引机制也不完全相同。

英文以词为单位建索引，与字母无关，而中文以字为最小单位。

再者，英文的分词以空格和标点为分界符，而汉字的分词往往依赖于词库。

因而中文全文检索与英文实现相比困难些。

不得不承认目前国内的研究水平与国际上还有较大差距，坐等国外成果，然后加以移植改造的老路是行不通的，因此在国内进行全文检索的研究非常必要。

1.2什么是全文检索

全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。

这个过程类似于通过字典中的检索字表查字的过程。

全文检索是指以文本为检索对象，允许用户以自然语言根据资料内容而不仅是外在特征来实现信息检索的手段。

全面、准确和快速是衡量全文检索系统的关键指标。

全文检索不仅可以实现对数据资料的外部特征的检索，诸如标题、作者、摘要、附录等，而且还能直接根据数据资料的内容进行检索，实现了支持多角度、多侧面地综台利用信息资源。

总之，全文检索技术是现代信息检索的一项重要技术。

1.3全文检索与关系数据库

全文检索提出基于文件系统的全文数据库，使用文件系统存储文档建立全文库时，文本的添加，删除，更新可以通过全文数据库管理系统来实现，因此可以说是实现了一个微型的专门为全文检索设计的数据库系统。

所谓微型的，是因为它只实现数据的增、删、改、查找、获取，而不涉及复杂的事务处理等。

使用文件系统构建全文数据库的根据如下:

（1）无论关系数据库还是全文数据库最终数据都是以文件的形式存在的。

数据库实现的基础是文件，对数据库的任何操作最终要转换为对文件的操作。

当前占主流的关系数据库是文件系统的发展。

文件系统中每个文件存储同质实体的数据，各文件是孤立的，没有体现实体之间的联系，关系数据库中，数据的物理组织必须体现实体之间的联系，支持数据库的逻辑结构，因此数据库要存储四方面的数据:

数据描述（即数据外模式，模式，内模式）、数据本身、数据之间的联系和存取路径，这四个方面的数据都要采用一定的文件组织方式组织存储起来[1]。

而全文数据库可以说是介于文件系统和关系数据库之间的体系结构，它一般包含的实体少，实体间的关联也少，结构相对简单，对事务性和并发性要求不高。

所以一般情况下，基本的检索过程应采用文件系统来实现，这样使得查询直接、快速，有效提高执行速度。

（2）全文数据库不需要事务支持

考虑到全文数据库系统的操作主要是读数据，写操作主要是插入新数据，删除和修改几乎没有。

插入数据往往是间隔一段日期，待积累了一定的新文献数后才进行。

而且即使有数据插入，也不需要锁住读操作，因为用户只是查询文献，暂时看不到新加入的文章，以往的数据照样可以使用。

所以，数据库根本不需要事务支持，而对事务的管理恰恰是很费时间的，这样在效率上就能得到很大提高。

实际上，当前各大搜索引擎，其后台存储的主流设计都是基于自设计的文件系统。

1.4全文检索需要解决的问题

一套完整的全文检索一般包括：

1对不同文本的统一处理；

2索引的建立，考虑索引压缩率，是否支持动态索引更新等问题；

3对汉语词语进行正确的切分；

4检索问题，考虑检索效率，查全率，查准率等问题；

5排序问题。

本文就围绕以上5个问题进行分析与研究。

二、建立索引库

2.1索引文件分类

2.1.1、顺排档结构

顺排档文档是以DocID为主序的，每一文档下存放各自出现的词的ID及各词所出现的次数和具体位置信息，各数据项的存储长度固定[2]。

2.1.2、倒排档结构

1）、一级索引：

一级索引文件属于记录式文件，每一记录大小固定，共有三个数据项构成，WordID、文档数、第一个文档开始位置。

其中WordID是词典中词条的ID，文档数是指这个词总共在多少个文档中出现，文档开始位置是一个文件指针指向二级索引中出现当前词的文档集中的第一个文档存储位置，这个指针是一个长整形值相当于指明了是二级索引文件中的第几条记录，因为各记录长度也是固定大小。

通过这个指向可以直接定位到二级索引文件读取位置，然后读取nDocs个记录即可，因为它们是存放在连续的地址空间上。

2）、二级索引：

二级索引也是一种记录式文件，每一记录有三个数据项组成，DocID、出现次数、第一个Hit位置。

其中DocID是文档的ID，出现次数指的是当前文档中某一个词出现的次数，第一个Hit位置也是一个指针，指向Hits文件中的某一位置。

通过这个指针就可以直接定位到Hits位置中的读取位置，这样连续读取nHits个记录就可以将所有当前词在当前文档中的出现的位置信息都读入。

这些文件将属于同一WordID下的所有文档记录按其词在整个文档的权值从大到小排列。

3）、Hits位置信息文件：

这些文件每一记录只有一个数据项，即Hit位置信息，只记录了各词在文档中出现的位置。

将同一词在同一文档中的出现位置按出现的先后排列。

这样在读取文档并提取摘要时只需对字符串从头到尾扫描一边即可，不需要来回扫描。

2.2倒排索引压缩

2.2.1倒排索引压缩初步实现

一个倒排索引通常由字典表文件（dictionaryfile）和记录文件（postingsfile）两部分组成。

字典文件记录了文本集中出现的每个单词及其倒排列表在记录文件中的位置和大小等信息。

一个单词对应的倒排列表可以表示为：

>,…,>,…,>>

n表示单词在n个文档中出现，di为文档ID，fi为单词在文档di中出现的词频，是单词出现在某个文档中的位置列表。

事实上，一个倒排列表可拆分为三部分。

1.一个文档ID序列（1≤i≤n）。

2.n个位置序列。

3.一个词频序列。

其中，第1和第2两个序列都是递增的整数序列。

鉴于这种递增的特性，可以用间隔di+1-di和pik+1-pik来代替序列中的值，那么上边三个整数序列就转化为如下形式。

1.一个文档ID间隔序列。

？

2.n个位置间隔序列。

3.一个词频序列。

转化成间隔后，没有损失任何信息，因为初始倒排列表总是可以通过计算间隔的和还原，此外，还给序列的取值带来了两个影响：

样本空间缩小、概率分布不均衡性扩大，因此预示着存在基于概率分布的高效压缩方法。

目前己经提出了一些模型描述整数值的概率分布，适用于对以上任一序列的压缩。

这些模型可以分成两类。

1.全局模型，所有序列使用相同的压缩参数。

2.局部模型，对于不同序列，其压缩参数是不同的，这个参数通常是单词的出现频率。

局部模型的压缩效率一般高于全局模型，且在解码速度方面也很有优势，但实现更复杂。

2.2.2动态文本集的倒排索引压缩方案

我们考虑文本集动态性时，将文本内部的动态调整用两次文本层次的调整代替，即对一个文本作文字改动视为删除旧文本和增加新文本，因此一般只考虑文本层次的索引动态同步调整。

上文3.1节提到一个倒排列表可拆分成三部分序列，事实上这三部分的动态特性并不相同，根据这一特点，我们可以采用混合编码的方案，对三部分序列实施不同的压缩方法，力求在满足动态性的前提下，尽可能地实现高压缩率。

位置序列记录的是某单词在一个文本内部的位置，由于只考虑文本层次的增加、删除，所以该序列内部的值不会发生任何的改动，它是静态的，可以采用压缩率较高的任何压缩方法。

与文档ID序列和词频序列相比，位置序列占用的索引空间往往多于二者，故而位置序列的压缩对整个倒排索引的压缩率起决定性作用。

到目前为止，压缩率最高的首推二进制内插编码，虽然它的压缩与解压比较耗时，但与由压缩减少的I/O时间相比，可以忽略，因此我们可以对位置序列采用二进制内插编码。

与位置序列不同，文档ID序列和词频序列会随文档的增加、删除而增删序列的元素，所以必须采用支持动态性的压缩方法。

二进制内插编码虽然有较高的压缩率，但它不支持序列的动态更新，所以不能采用。

能够支持动态序列的压缩方法主要有：

可变字节编码、γ编码、和δ编码。

三者中压缩率最高的是δ编码，所以对两个序列都采用δ编码。

需要指出的是，由于文档ID序列是递增序列，所以多将其先转化成间隔序列后再进行压缩，这就给后续的增加元素操作带来了困难。

例如，文档ID序列<3,8,9,11,12,13,17>，它对应的间隔序列为<3,5,1,2,1,1,4>，对该序列进行压缩，如果今后增加一个文档19，则需要知道文档ID序列最后一个文档ID的值17才能求两者的间隔值2=19-17，而由间隔序列得出17必须从头到尾解压整个序列，然后求总和才能得到，这就需要额外的I/O时间和解压时间，尤其是对于较长的序列来说更是一笔可观的开销。

为避免这一问题，我们可以把文档ID当前的最大值存放到单词表里该倒排列表对应单词信息中。

词频序列不是递增序列，不用转化为间隔形式，因此不存在类似文档ID序列的问题。

从文档ID间隔序列中删除一个元素则比较简单，只需修改其后的一个元素值为两者的和即可。

如上例中的文档ID序列，如果删除文档9，则间隔序列修改为<3,5,3,1,1,4>。

（第三个3=1+2）

2.2.3Lucene压缩技术

为了减小索引文件的大小，Lucene对索引也使用了压缩技术。

首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：

当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。

其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。

例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。

注意是“上一个词”。

由于词典是按顺序排列的，这种压缩方法的效果会非常显著。

2.3索引增量更新

2.3.1利用B树实现倒排索引的更新

文献[3]提出在倒排索引的字典表上建一个B树索引，以支持字典表的扩充。

B树的索引项就是单词，一个单词对应的倒排列表放在一个B树块中，如果一个块装不下，则在堆文件（heapfile）中分配一片连续的空间，再从B树叶子节点链一条指针到堆文件中。

此后，若倒排列表还要膨胀，超出了已有空间，则重新在堆文件（heapfile）中分配一片空间，把原倒排列表迁移到新空间中，再将新增倒排列表合并到后面，然后将旧空间标记为空闲。

对这个堆文件的管理可以采用动态存储空间分配的算法，如伙伴系统。

使用堆文件来处理溢出，会增加查询时的I/O的时间。

由于使用伙伴系统管理堆文件可能导致频繁地申请和释放空间以及频繁地迁移索引数据。

在字典表上建一个B树，显然需要额外的硬盘空间存放B树索引块，而且每次查找倒排列表都需要从B树的树根遍历到叶子节点，因此增加了查找的时间。

2.3.2Dual-Structure索引结构

文献[3]提出了一种Dual-Structure索引结构，它动态地区分长、短倒排列表，并对长、短列表采用两种不同的存储结构及配套的检索、更新策略。

其一是针对短倒排列表的，某词通过静态散列函数映射到桶里，一个桶可以装多个倒排列表，桶数是固定的，且每个桶都只有一个存储块。

每个词的倒排列表初始都是短倒排列表，当某个桶溢出时，将桶中最长的倒排列表晋升为长倒排列表，在字典表中做上标记后，将它迁移到长倒排列表使用的存储结构中。

这样就动态地实现了长、短倒排列表的区分。

另一种是将长倒排列表放在变长的连续块中，且末尾预留一部分空闲空间，这些块不让其他词的倒排列表共享。

对于给定的词，可以通过查单词表来判定它是否对应一长倒排列表。

该方法有以下不足。

1.它只考虑了文档的插入操作，而忽略了删除操作。

2.采用静态散列函数，不管文档的多少，桶的大小及桶数都不能改变，且不同桶之间不能共享存储块。

这样，当文档量很少时，桶空间大量闲置，造成空间的浪费。

而当文档量很大时，即使是非高频词的倒排列表也会变得较大，桶数远远满足不了它们的需要。

所以，需要一种动态散列表的支持，使得桶的数量可变。

3.动态地区分长、短倒排列表的策略虽然简单，但也不尽合理。

只要发生桶溢出便把最长的倒排列表转移到长倒排列表的存储区，会误把相当数量的短倒排列表排挤到长倒排列表中。

4.对长倒排列表的管理采用的是绕开操作系统直接管理硬盘的方式，这样做不适合多任务操作系统，因为当还有其他程序要读写磁盘时，很难保证不发生错误。

2.3.3Lucene索引过程优化

大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，索引一般分2种情况，一种是小批量的索引扩展，一种是大批量的索引重建。

在索引过程中，并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作（文件I/O是一件非常消耗资源的事情）。

Lucene先在内存中进行索引操作，并根据一定的批量进行文件的写入。

这个批次的间隔越大，文件的写入次数越少，但占用内存会很多。

反之占用内存少，但文件IO操作频繁，索引速度会很慢。

在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。

根据我的使用经验：

缺省Indexer是每20条记录索引后写入一次，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左右。

三、中文分词研究

目前在中文搜索引擎领域，国内的搜索引擎已经和国外的搜索引擎效果上相差不远。

之所以能形成这样的局面，有一个重要的原因就在于中文和英文两种语言自身的书写方式不同，这其中对于计算机涉及的技术就是中文分词。

3.1什么是中文分词

众所周知，英文是以词为单位的，词和词之间是靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。

例如，英文句子Iamastudent，用中文则为：

“我是一个学生”。

计算机可以很简单通过空格知道student是一个单词，但是不能很容易明白“学”、“生”两个字合起来才表示一个词。

把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。

我是一个学生，分词的结果是：

我是一个学生。

3.2为什么需要中文分词

目前的搜索引擎，大多是基于一种称为倒排索引的结构[4]。

以什么做为索引的Key值，直接影响到整个搜索引擎的准确度、召回率、速度。

我们先看看不使用中文分词的情况。

如果不使用中文分词，可以采用单个汉字索引方式。

例如，雅虎，先索引"雅"字，然后再索引"虎"字。

同样，对于一篇文章，先把所有的汉字都单独索引一次，并记录他们的位置。

搜索过程中，也是先找"雅"字的所有文档，再找"虎"字的所有文档，然后做交叉"与"运算，即包含这两个字，而且位置连续的文档才会做为符合要求的结果。

这种方式是最基本的索引方式，现在有些小引擎中还在使用。

但这里存在一个很有挑战性的问题：

总共的常用汉字是3000多个，我们每次查询过程中，进行