目录html
信息检索就是从信息集合中找出与用户需求相关的信息。被检索出的信息除了文本外,还有图像、音频、视频等多媒体信息。程序员
目前信息检索技术可分为3类:数据库
全文检索的通常过程apache
全文检索出现的目的就是为了更快地查找信息;数据库查询效率低(例如拿一本字典来一页一页找,效率确定很低)。全文搜索是按索引来找,效率高(从字典的索引找,再找到哪一页,效率会高)架构
全文检索工具通常由索引部分、分词部分和检索部分构成。工具
流程以下:
假设:个人文档集合里面有100篇文档,为了方便表示,咱们为文档编号从1到100,获得下面的结构
左边保存的是一系列字符串,称为词典。
每一个字符串都指向包含此字符串的文档(Document)链表,此文档链表称为倒排表(Inverse List)。
有了索引,便使保存的信息和要搜索的信息一致,能够大大加快搜索的速度。
好比说,咱们要寻找既包含字符串“lucene”又包含字符串“solr”的文档,咱们只须要如下几步:
1. 取出包含字符串“lucene”的文档链表。
2. 取出包含字符串“solr”的文档链表。
3. 经过合并链表,找出既包含“lucene”又包含“solr”的文件。
看到这个地方,有人可能会说,全文检索的确加快了搜索的速度,可是多了索引的过程,二者加起来不必定比顺序扫描快多少。的确,加上索引的过程,全文检索不必定比顺序扫描快,尤为是在数据量小的时候更是如此。而对一个很大量的数据建立索引也是一个很慢的过程。
然而二者仍是有区别的,顺序扫描是每次都要扫描,而建立索引的过程仅仅须要一次,之后即是一劳永逸的了,每次搜索,建立索引的过程没必要通过,仅仅搜索建立好的索引就能够了。
这也是全文搜索相对于顺序扫描的优点之一:一次索引,屡次使用。
From:http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623594.html
全文检索的索引建立过程通常有如下几步:
第一步:一些要索引的原始文档(Document):为了方便说明索引建立过程,这里特地用两个文件为例:
第二步:将原始文档传给分词组件(Tokenizer):分词组件(Tokenizer)会作如下几件事情(此过程称为Tokenize):
对于每一种语言的分词组件(Tokenizer),都有一个停词(stop word)集合。
通过分词(Tokenizer)后获得的结果称为词元(Token)。
在咱们的例子中,便获得如下词元(Token):
“Students”,“allowed”,“go”,“their”,“friends”,“allowed”,“drink”,“beer”,“My”,“friend”,“Jerry”,“went”,“school”,“see”,“his”,“students”,“found”,“them”,“drunk”,“allowed”。
第三步:将获得的词元(Token)传给语言处理组件(Linguistic Processor)。
语言处理组件(linguistic processor)主要是对获得的词元(Token)作一些同语言相关的处理。
对于英语,语言处理组件(Linguistic Processor)通常作如下几点:
Stemming 和 lemmatization的异同:
相同之处:Stemming和lemmatization都要使词汇成为词根形式。
语言处理组件(linguistic processor)的结果称为词(Term)。
在咱们的例子中,通过语言处理,获得的词(Term)以下:
“student”,“allow”,“go”,“their”,“friend”,“allow”,“drink”,“beer”,“my”,“friend”,“jerry”,“go”,“school”,“see”,“his”,“student”,“find”,“them”,“drink”,“allow”。
也正是由于有语言处理的步骤,才能使搜索drove,而drive也能被搜索出来。
第四步:将获得的词(Term)传给索引组件(Indexer)。
索引组件(Indexer)主要作如下几件事情:
1. 利用获得的词(Term)建立一个字典。
在咱们的例子中字典以下:
Term |
Document ID |
student |
1 |
allow |
1 |
go |
1 |
their |
1 |
friend |
1 |
allow |
1 |
drink |
1 |
beer |
1 |
my |
2 |
friend |
2 |
jerry |
2 |
go |
2 |
school |
2 |
see |
2 |
his |
2 |
student |
2 |
find |
2 |
them |
2 |
drink |
2 |
allow |
2 |
2. 对字典按字母顺序进行排序。
Term |
Document ID |
allow |
1 |
allow |
1 |
allow |
2 |
beer |
1 |
drink |
1 |
drink |
2 |
find |
2 |
friend |
1 |
friend |
2 |
go |
1 |
go |
2 |
his |
2 |
jerry |
2 |
my |
2 |
school |
2 |
see |
2 |
student |
1 |
student |
2 |
their |
1 |
them |
2 |
3. 合并相同的词(Term)成为文档倒排(Posting List)链表。
在此表中,有几个定义:
因此对词(Term) “allow”来说,总共有两篇文档包含此词(Term),从而词(Term)后面的文档链表总共有两项,第一项表示包含“allow”的第一篇文档,即 1号文档,此文档中,“allow”出现了2次,第二项表示包含“allow”的第二个文档,是2号文档,此文档中,“allow”出现了1次。
到此为止,索引已经建立好了,咱们能够经过它很快的找到咱们想要的文档。
并且在此过程当中,咱们惊喜地发现,搜索 “drive”,“driving”,“drove”,“driven”也可以被搜到。由于在咱们的索引 中,“driving”,“drove”,“driven”都会通过语言处理而变成“drive”,在搜索时,若是您输入“driving”,输入的查询 语句一样通过咱们这里的一到三步,从而变为查询“drive”,从而能够搜索到想要的文档。
到这里彷佛咱们能够宣布“咱们找到想要的文档了”,仅仅是找到了,可是并非“理想”的结果。
然而事情并无结束,找到了仅仅是全文检索的一个方面。不是吗?若是仅仅只有一个或十个文档包含咱们查询的字符串,咱们的确找到了。然而若是结果有一千个,甚至成千上万个呢?那个又是您最想要的文件呢?
打开Google吧,好比说您想在微软找份工做,因而您输入“Microsoft job”,您却发现总共有22600000个结果返回。好大的数字呀,忽然发现找不到是一个问题,找到的太多也是一个问题。在如此多的结果中,如何将最相关的放在最前面呢?
固然Google作的很不错,您一下就找到了jobs at Microsoft。想象一下,若是前几个所有是“Microsoft does a good job at software industry…”将是多么可怕的事情呀。
如何像Google同样,在成千上万的搜索结果中,找到和查询语句最相关的呢?
如何判断搜索出的文档和查询语句的相关性呢?
这要回到咱们第三个问题:如何对索引进行搜索?
搜索主要分为如下几步:
查询语句同咱们普通的语言同样,也是有必定语法的。
不一样的查询语句有不一样的语法,如SQL语句就有必定的语法。
查询语句的语法根据全文检索系统的实现而不一样。最基本的有好比:AND, OR, NOT等。
举个例子,用户输入语句:lucene AND learned NOT hadoop。
说明用户想找一个包含lucene和learned然而不包括hadoop的文档。
第二步:对查询语句进行词法分析,语法分析,及语言处理。
因为查询语句有语法,于是也要进行语法分析,语法分析及语言处理。
1. 词法分析主要用来识别单词和关键字。
如上述例子中,通过词法分析,获得单词有lucene,learned,hadoop, 关键字有AND, NOT。
若是在词法分析中发现不合法的关键字,则会出现错误。如lucene AMD learned,其中因为AND拼错,致使AMD做为一个普通的单词参与查询。
2. 语法分析主要是根据查询语句的语法规则来造成一棵语法树。
若是发现查询语句不知足语法规则,则会报错。如lucene NOT AND learned,则会出错。
如上述例子,lucene AND learned NOT hadoop造成的语法树以下:
3. 语言处理同索引过程当中的语言处理几乎相同。
如learned变成learn等。
通过第二步,咱们获得一棵通过语言处理的语法树。
此步骤有分几小步:
虽然在上一步,咱们获得了想要的文档,然而对于查询结果应该按照与查询语句的相关性进行排序,越相关者越靠前。
如何计算文档和查询语句的相关性呢?
不如咱们把查询语句看做一片短小的文档,对文档与文档之间的相关性(relevance)进行打分(scoring),分数高的相关性好,就应该排在前面。
那么又怎么对文档之间的关系进行打分呢?
这可不是一件容易的事情,首先咱们看一看判断人之间的关系吧。
首先看一我的,每每有不少要素,如性格,信仰,爱好,衣着,高矮,胖瘦等等。
其次对于人与人之间的关系,不一样的要素重要性不一样,性格,信仰,爱好可能重要些,衣着,高矮,胖瘦可能就不那么重要了,因此具备相同或类似性格,信仰,爱好的人比较容易成为好的朋友,然而衣着,高矮,胖瘦不一样的人,也能够成为好的朋友。
于是判断人与人之间的关系,首先要找出哪些要素对人与人之间的关系最重要,好比性格,信仰,爱好。其次要判断两我的的这些要素之间的关系,好比一我的性格开朗,另外一我的性格外向,一我的信仰佛教,另外一个信仰上帝,一我的爱好打篮球,另外一个爱好踢足球。咱们发现,两我的在性格方面都很积极,信仰方面都很善良,爱好方面都爱运动,于是两我的关系应该会很好。
咱们再来看看公司之间的关系吧。
首先看一个公司,有不少人组成,如总经理,经理,首席技术官,普通员工,保安,门卫等。
其次对于公司与公司之间的关系,不一样的人重要性不一样,总经理,经理,首席技术官可能更重要一些,普通员工,保安,门卫可能较不重要一点。因此若是两个公司总经理,经理,首席技术官之间关系比较好,两个公司容易有比较好的关系。然而一位普通员工就算与另外一家公司的一位普通员工有血海深仇,怕也难影响两个公司之间的关系。
于是判断公司与公司之间的关系,首先要找出哪些人对公司与公司之间的关系最重要,好比总经理,经理,首席技术官。其次要判断这些人之间的关系,不如两家公司的总经理曾经是同窗,经理是老乡,首席技术官曾是创业伙伴。咱们发现,两家公司不管总经理,经理,首席技术官,关系都很好,于是两家公司关系应该会很好。
分析了两种关系,下面看一下如何判断文档之间的关系了。
首先,一个文档有不少词(Term)组成,如search, lucene, full-text, this, a, what等。
其次对于文档之间的关系,不一样的Term重要性不一样, 好比对于本篇文档,search, Lucene, full-text就相对重要一些,this, a , what可能相对不重要一些。因此若是两篇文档都包含search, Lucene,fulltext,这两篇文档的相关性好一些,然而就算一篇文档包含this, a, what,另外一篇文档不包含this, a, what,也不能影响两篇文档的相关性。
于是判断文档之间的关系,首先找出哪些词(Term)对文档之间的关系最重要,如search, Lucene, fulltext。而后判断这些词(Term)之间的关系。
找出词(Term)对文档的重要性的过程称为计算词的权重(Term weight)的过程。
计算词的权重(term weight)有两个参数,第一个是词(Term),第二个是文档(Document)。
词的权重(Term weight)表示此词(Term)在此文档中的重要程度,越重要的词(Term)有越大的权重(Term weight),于是在计算文档之间的相关性中将发挥更大的做用。
判断词(Term)之间的关系从而获得文档相关性的过程应用一种叫作向量空间模型的算法(Vector Space Model)。
下面仔细分析一下这两个过程:
1. 计算权重(Term weight)的过程。
影响一个词(Term)在一篇文档中的重要性主要有两个因素:
注意:TF-IDF=TF*IDF。某一特定文件内的高词语频率,以及该词语在整个文件集合中的低文件频率,能够产生出高权重的TF-IDF。所以,TF-IDF倾向于过滤掉常见的词语,保留重要的词语。
例子:有不少不一样的数学公式能够用来计算TF-IDF。这边的例子以上述的数学公式来计算。词频 (TF)
是 一词语出现的次数除以该文件的总词语数。假如一篇文件的总词语数是100个,而词语“母牛”出现了3次,那么“母牛”一词在该文件中的词频就是 3/100=0.03。一个计算文件频率(DF) 的方法是测定有多少份文件出现过“母牛”一词,而后除以文件集里包含的文件总数。因此,若是“母牛”一词在1,000份文件出现过,而文件总数是 10,000,000份的话,其逆向文件频率就是log(10,000,000 / 1,000)=4。最后的TF-IDF的分数为0.03 * 4=0.12。
容易理解吗?词(Term)在文档中出现的次 数越多,说明此词(Term)对该文档越重要,如“搜索”这个词,在本文档中出现的次数不少,说明本文档主要就是讲这方面的事的。然而在一篇英语文档 中,this出现的次数更多,就说明越重要吗?不是的,这是由第二个因素进行调整,第二个因素说明,有越多的文档包含此词(Term), 说明此词(Term)太普通,不足以区分这些文档,于是重要性越低。
这也如咱们程序员所学的技术,对于程序员自己来讲,这项技术掌握越深越好(掌握越深说明花时间看的越多,tf越大),找工做时越有竞争力。然而对于全部程序员来讲,这项技术懂得的人越少越好(懂得的人少df小),找工做越有竞争力。人的价值在于不可替代性就是这个道理。
道理明白了,咱们来看看公式:
这仅仅只term weight计算公式的简单典型实现。实现全文检索系统的人会有本身的实现,Lucene就与此稍有不一样。有关Lucene计算公式能够参考官方文档(V4.0)。
咱们把文档看做一系列词(Term),每个词(Term)都有一个权重(Term weight),不一样的词(Term)根据本身在文档中的权重来影响文档相关性的打分计算。
因而咱们把全部此文档中词(term)的权重(term weight) 看做一个向量。
Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, …… ,weight N}
一样咱们把查询语句看做一个简单的文档,也用向量来表示。
Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… , weight N}
咱们把全部搜索出的文档向量及查询向量放到一个N维空间中,每一个词(term)是一维。
如图:
咱们认为两个向量之间的夹角越小,相关性越大。
因此咱们计算夹角的余弦值做为相关性的打分,夹角越小,余弦值越大,打分越高,相关性越大。
有人可能会问,查询语句通常是很短的,包含的词(Term)是不多的,于是查询向量的维数很小,而文档很长,包含词(Term)不少,文档向量维数很大。你的图中二者维数怎么都是N呢?
在这里,既然要放到相同的向量空间,天然维数是相同的,不一样时,取两者的并集,若是不含某个词(Term)时,则权重(Term Weight)为0。
相关性打分公式以下:
举个例子,查询语句和三篇文章共有11个Term。其中假定各自的权重(Term weight)以下表格。(注意:没有详细计算,只是找了一些数据做为样本数据,具体的计算过程不一样的问题能够采用不一样的算法,如前面的log函数能够采用不一样的底数等。)
t1 |
t2 |
t3 |
t4 |
t5 |
t6 |
t7 |
t8 |
t9 |
t10 |
t11 |
|
D1 |
0 |
0 |
.477 |
0 |
.477 |
.176 |
0 |
0 |
0 |
.176 |
0 |
D2 |
0 |
.176 |
0 |
.477 |
0 |
0 |
0 |
0 |
.954 |
0 |
.176 |
D3 |
0 |
.176 |
0 |
0 |
0 |
.176 |
0 |
0 |
0 |
.176 |
.176 |
Q |
0 |
0 |
0 |
0 |
0 |
.176 |
0 |
0 |
.477 |
0 |
.176 |
因而计算,三篇文档同查询语句的相关性打分分别为:
因而文档二相关性最高,先返回,其次是文档三,最后是文档一。
到此为止,咱们能够找到咱们最想要的文档了。
说了这么多,其实尚未进入到Lucene, 而仅仅是信息检索技术(Information retrieval)中的基本理论,然而当咱们看过Lucene后咱们会发现,Lucene是对这种基本理论的一种基本的的实践。因此在之后分析 Lucene的文章中,会经常看到以上理论在Lucene中的应用。
在进入Lucene以前,对上述索引建立和搜索过程所一个总结,如图:
此图参照http://www.lucene.com.cn/about.htm中文章《开放源代码的全文检索引擎Lucene》
从图中咱们清楚的看到,Lucene的系统由 基础结构封装、索引核心、对外接口三大部分组成。其中直接操做索引文件的索引核心又是系统的重点。Lucene的将全部源码分为了7个模块(在java语 言中以包即package来表示),各个模块所属的系统部分也如上图所示。须要说明的是org.apache.lucene.queryPaser是作为 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的索引文件的概念结构描述。 Lucene索引index由若干段(segment)组成,每一段由若干的文档(document)组成,每个文档由若干的域(field)组成,每 一个域由若干的项(term)组成。项是最小的索引概念单位,它直接表明了一个字符串以及其在文件中的位置、出现次数等信息。域是一个关联的元组,由一个 域名和一个域值组成,域名是一个字串,域值是一个项,好比将“标题”和实际标题的项组成的域。文档是提取了某个文件中的全部信息以后的结果,这些组成了 段,或者称为一个子索引。子索引能够组合为索引,也能够合并为一个新的包含了全部合并项内部元素的子索引。咱们能够清楚的看出,Lucene的索引结构在 概念上即为传统的倒排索引(倒排文件或倒排索引是指索引对象是文档或者文档集合中的单词等,用来存储这些单词在一个文档或者一组文档中的存储位置,是对文 档或者文档集合的一种最经常使用的索引机制。)结构。
1. 索引过程:
2. 搜索过程:
转载自 http://www.cnblogs.com/bluepoint2009/archive/2012/09/25/lucene-information-retrieval-and-fulltext-retrieval.html