《Introduce to IR》布尔检索模型
- 格式:doc
- 大小:127.50 KB
- 文档页数:5
档案学中的信息检索模型与算法档案学是一门研究如何有效管理和利用各类档案信息的学科。
在信息时代的今天,随着信息量的爆炸式增长,如何快速准确地检索所需信息成为了档案学的重要研究方向之一。
信息检索模型与算法是档案学中的重要组成部分,它们通过建立一套系统性的理论框架和算法方法,帮助人们更好地获取和利用档案信息。
一、信息检索模型信息检索模型是信息检索系统的基础,它描述了信息检索过程中的各个环节和关键要素。
传统的信息检索模型主要包括布尔模型、向量空间模型和概率模型。
布尔模型是最早被提出的信息检索模型之一,它基于布尔代数的逻辑运算,将检索问题转化为逻辑表达式的求解。
布尔模型简单直观,适用于处理简单的检索问题,但对于复杂的检索需求,其表达能力较弱。
向量空间模型是一种基于向量空间理论的信息检索模型,它将文档和查询表示为向量,通过计算向量之间的相似度来判断文档的相关性。
向量空间模型具有较强的表达能力,能够处理复杂的检索需求,但在处理大规模数据时,计算量较大。
概率模型是一种基于概率统计的信息检索模型,它通过建立文档和查询之间的概率模型,计算文档的相关性概率。
概率模型考虑了文档和查询之间的语义关系,能够更准确地判断文档的相关性,但对于查询的理解和语义分析要求较高。
二、信息检索算法信息检索算法是实现信息检索模型的具体方法和技术。
常见的信息检索算法包括倒排索引、TF-IDF算法和PageRank算法。
倒排索引是一种常用的信息检索算法,它通过将文档中的关键词和对应的文档ID建立映射关系,快速定位包含关键词的文档。
倒排索引具有高效的检索速度和灵活的扩展性,是大规模信息检索系统的核心技术。
TF-IDF算法是一种用于衡量关键词在文档中重要性的算法,它通过计算关键词的词频和逆文档频率,得出关键词在文档中的权重。
TF-IDF算法能够准确地反映关键词的重要性,提高检索结果的准确性。
PageRank算法是一种用于评估网页重要性的算法,它通过分析网页之间的链接关系,计算网页的权重。
[信息检索]第⼀讲布尔检索BooleanRetrieval第⼀讲布尔检索Boolean Retrieval主要内容:1. 信息检索概述2. 倒排记录表3. 布尔查询处理⼀、信息检索概述什么是信息检索?Information Retrieval (IR) is finding material (usually documents) of an unstructured nature (usually text) that satisfies an information need from within large collections (usually stored on computers).信息检索是从⼤规模⾮结构化数据(通常是⽂本)的集合(通常保存在计算机上)中找出满⾜⽤户信息需求的资料(通常是⽂档)的过程。
Document –⽂档Unstructured – ⾮结构化Information need –信息需求Collection—⽂档集、语料库⼆、倒排记录表1、什么是布尔查询?布尔查询是指利⽤ AND, OR 或者 NOT操作符将词项连接起来的查询如:信息 AND 检索2、⼀个信息检索的例⼦(莎⼠⽐亚全集)不到100万单词,假设每个英⽂单词平均长度为8字节,则整个全集不到10MB查询需求:莎⼠⽐亚的哪部剧本包含Brutus及Caesar但是不包含Calpurnia?查询的布尔表⽰:Brutus AND Caesar AND NOT Calpurnia解决⽅案:⽅法⼀:暴⼒⽅法从头到尾扫描所有剧本,对每部剧本判断它是否包含Brutus AND Caesar ,同时⼜不包含Calpurnia不⾜之处:速度超慢 (特别是⼤型⽂档集)处理NOT Calpurnia 并不容易(不到末尾不能停⽌判断)不太容易⽀持其他操作 (e.g., 寻找靠近countrymen的单词Romans)不⽀持检索结果的(灵活)排序 (排序时只返回较好的结果)优点:实现简单很容易⽀持⽂档动态变化⽅法⼆:倒排记录表词项-⽂档(term-doc)关联矩阵若某剧本包含某单词,则该位置为1,否则为0.关联矩阵的每⼀列(对应⼀篇⽂档)都是 0/1向量,每个0/1都对应⼀个词项关联矩阵的每⼀⾏(对应⼀个词项)也可以看成⼀个0/1向量,每个0/1代表该词项在相应⽂档中的出现与否给定查询Brutus AND Caesar AND NOT Calpurnia取出三个词项对应的⾏向量,并对Calpurnia 的⾏向量求反,最后按位进⾏与操作110100 AND 110111 AND 101111 = 100100.问题:当出现更⼤的⽂档集假定N = 1 百万篇⽂档(1M), 每篇有1000个词(1K)假定每个词平均有6个字节(包括空格和标点符号),那么所有⽂档将约占6GB 空间.假定词汇表的⼤⼩(即词项个数) M = 500K此时,词项-⽂档矩阵将⾮常⼤矩阵⼤⼩为 500K x 1M=500G但是该矩阵中最多有10亿(1G)个1:词项-⽂档矩阵⾼度稀疏(sparse)更好的办法:仅仅记录1的位置,即倒排索引对每个词项t, 记录所有包含t的⽂档列表.每篇⽂档⽤⼀个唯⼀的 docID来表⽰,通常是正整数,如1,2,3…磁盘上,顺序存储⽅式⽐较好,便于快速读取内存中,采⽤链表或者可变长数组⽅式倒排记录表按docID排序索引构建过程:1、词条序列:<词条,docID>⼆元组2、排序按词项排序,然后每个词项按docID排序1. 词典&倒排记录表某个词项在单篇⽂档中的多次出现会被合并拆分成词典和倒排记录表两部分每个词项出现的⽂档数⽬(doc frequency, DF)会被加⼊3、布尔查询的处理假定索引已经构建好了,如何利⽤索引来处理查询?AND查询的处理:考虑如下查询(从简单的布尔表达式⼊⼿):Brutus AND Caesar在词典中定位 Brutus返回对应倒排记录表(对应的docID)在词典中定位Caesar再返回对应倒排记录表合并(Merge)两个倒排记录表,即求交集合并过程:每个倒排记录表都有⼀个定位指针,两个指针同时从前往后扫描, 每次⽐较当前指针对应倒排记录,然后移动某个或两个指针。
《Introduce to IR》索引创建文章分类:互联网该系列文章是《An Introduce to Information Retrieval》Chapter 4 的读书笔记。
对于大规模数据的信息检索,倒排索引的建立其实并没有想象中的那么简单。
在实际应用中,倒排索引的建立算法必须考虑到硬件的约束。
可以这样说:计算机硬件的参数性能是促动IR系统的设计发展的决定因素。
索引创建(Index construction)要点:(1) 介绍BSBI 算法建立大规模数据的倒排索引(2) 分布式索引的建立算法4.1 硬件基础介绍下图是2007年典型计算机的系能参数:参数符号性能指标统计值s 磁盘数据定位时间5ms=5*10^(-3)s(在磁盘中查找数据所在的位置)b 每字节数据传输时间0.02us=2*10^(-8)s(从磁盘传入1字节数据进内存)CPU时钟周期10^(-9)sp 内存大小several GB磁盘大小1TB or more(1) 内存中读取数据远比磁盘中读取数据要快的多。
从内存中读取1byte数据只需要几个CPU时钟周期(大概5*10^(-9)s),而从磁盘中读入1byte数据需要2*10^(-8)s。
因此,我们要尽可能的让更多的数据保存在内存中,特别是使用频率高的数据。
将使用频率高的磁盘数据保存在内存中的技术叫做缓存(caching)。
(2) 磁盘数据读取的代价主要花费在磁盘数据定位的时间上(5*10^(-3)s)。
而磁盘每次定位到一个磁盘存储块(详见《外部存储器——磁盘》)。
定位1byte数据和定位一个磁盘存储块(可能是8,16,32或64KB)的时间是一样。
因此,需要一起读取的数据块应该连续存储在磁盘上。
这样,我们把一整块磁盘存储块数据读入内存中的连续空间叫做缓冲区(buffer)。
举个例子:假设我们要读入磁盘中的10M数据,这些数据连续存储在100个磁盘存储块中。
那么所花费的时间代价:从磁盘中读入内存中的时间:t1=10^(7)*2*10^*(-8)=0.2s在磁盘中定位数据的时间:t2=100*(5*10^(-3))=0.5s总代价为: t=t1+t2=0.7s当然,如果10M数据分散存储在1W个存储块中(而且这些存储块分散在杂乱无章的磁道和柱面上),那么可能要多付出几个数量级的t2代价。
《Introduce to IR》布尔检索模型
文章分类:互联网
该系列文章是《An Introduce to Information Retrieval》Chapter 1 的读书笔记。
IR的概念很广泛,即使从钱包中拿出一张信用卡并输入卡号也是一种形式的信息检索。
在学术领域,我们这样定义IR:
信息检索(IR)就是一种从大量数据集合中(通常指存储在计算机中文档)寻找满足信息需求的非结构化(通常指文本)得数据(通常指文档)。
布尔检索模型(Boolean Retrieval)
要点:(1) 倒排/反向索引模型inverted indexes
(2) 简单的布尔表达式如何处理这些索引
1.1 词—文档的关联矩阵索引 a term-document matrix
(1) Unix/Linux grep- 命令
这个命令或许大家都用过,它是Unix/Linux中用于在指定文件中查找特定的搜索字符串的命令。
它的原理是利用正则表达式在文档集合中进行线性顺序扫描(sort of linear scan)。
这种方式对于现代计算机的运行速度而言,在有限的数据规模下做简单的查询足够应付了。
(2) Web data 的搜索面临的现实问题
▲ 网络在线数据量(web data/online data)巨大,其增长的速度远大于计算机的硬件发展速度。
如何快速的检索需要查询的内容?这一点线性顺序扫描时永远做不到的。
▲ web搜索面临的是广大用户群,其查询表达式的方式灵活多样(并不一定是布尔表达式)。
甚至有的时候并没有准确的查询含义。
比如查询query:Romans NEAR courtyman。
这里的NEAR到底是指Romans,courtyman 这两词需要在文章中同一个句子里出现,还是相隔若干词。
如何更好的响应用户的灵活多变的查询方法,提供更加人性化得服务呢?
▲ 检索结果的排序问题也是一个现实问题。
用户需要看到的是最满意的答案,那么查询返回的若干文档,到底哪些与用户查询最相关呢?
(3)布尔模型的词—文档关联矩阵索引模型
线性顺序扫面对于web data来说是不可能的。
目前,解决高效检索大量非结构化的信息的公认最好手段就是建立索引(indexes)。
下面就是一个简单的索引模型——关联矩阵。
1. 词—文档关联矩阵如下图,列表示文档,行表示文档中的词。
其中如果Term1出现在Doc1中,则矩阵(1,1)标示为1,否则为0。
2. 建立布尔查询表达式(boolean query)。
Antony and Brutus not Caesar 也就是我们需要找到包含Antony ,Brutus同时不包含Caesar 词语的文档。
3. 使用位运算: Antony and Brutus not Caesar = 110001 & 110100 & (~110111) =000000. 很可惜,一篇都没有。
(4) 关联矩阵模型的缺陷
上面这个简单索引模型并不适合Web data的检索。
对于大数据量而言,这个矩阵实在是太大了,不可能全部放进内存。
而且更严重的是矩阵太稀疏了。
况且对于检索结果的排序问题也是解决不了的。
1.2 倒排索引inverted index
倒排索引绝对是一个伟大的发现。
当前很多搜索引擎或者开发包都使用了这个模型,比如Lucene。
(1) 倒排索引结构:1. 词语组成的字典结构——Dictionary如下图左侧
2. 文档组成的位置链—— Postiong 如下图右侧
(2) 创建过程
1. 将每一个文档中的词语与文档ID(唯一标示文档)组成一个Pair,存入index。
如左图A
2. 将index中的词语按字典序排序。
如中图B
3. 如果相同词语来自同一个文档,则只记录一次。
相同词语来自不同文档,则合并成进posting。
如右图C
(3) 索引存储方法
很显然,对于倒排索引,我们必须把Dictionary和Posting都存储起来。
一般Dictionary可以全部加载进内存中,而Posting存放在磁盘中,当需要查找Posting的时候,再会将某一个词语所指向的Posting加载进内存。
Dictionary in menory
很多时候使用Hash表的形式,也用连续存储的数组结构。
Posting in menory:
1. 单链表( singly linked lists) ,在将新文档插入Posting中的时候付出的代价较少。
这一点很适合高频率从网上抓取内容并更新文档。
2. 可变长数组(variable length arrays),节约了指针所需要的额外空间。
并且对于拥有内存缓存区的现代计算机而言,连续内存的结构无疑会增加查询的速度。
3. 跳跃表(skip lists),一种很先进的存储结构。
除了需要额外耗费一些指针空间之外,查找效率极高。
Lucene就是用了这种结构。
1.3 布尔查询表达式的处理
(1) Posting的合并算法(merge algorithm)
假如我们需要在倒排索引上查找这样一个表达式:Brutus AND Calpurnia。
很明显我们需要下面几个步骤:
1. 在Dictionary中定位Brutus.
2. 检索Brutus所指向的Posting:1、2、4、11、31....
3. 在Dictionary中定位Calpurnia.
4. 检索Calpurnia所指向的Posting:2、31、54....
5. 合并两个Posting.
对于两个有序表的合并算法,可以采用下面的算法:时间复杂度为O(m+n)
C代码
//指针P1,P2分别指向两个Posting链
2Posting intersect(p1,p2){
3
4Posting answer;
5while(p1!=null&&p2!=null){
6if(p1==p2){
7add(answer, p1->docID);
8p1=p1->next;
9p2=p2->next;
10}
11if(p1>p2) p2=p2->next;
12if(p1<p2) p1=p1->next;
13
14}
15}
(2) 布尔表达式的优化
Brutus AND Caesar AND Calpurnia
表达式的AND顺序按照每一个词的文档频率递增进行优化。
比如Brutus‘s Ducument Frequence(Brutus 所在文档的数量,符号表示DF(Brutus))。
DF(Brutus)=1000,DF(Caesar)=10000,DF(Calpurnia)=100。
那么查询表达式可以优化成:(Calpurnia AND Brutus) AND Caesar。
理由很简单,Calpurnia AND Brutus的时间复杂度(利用上面的合并算法)为O(1100),其合并后的中间结果R=DF(Calpurnia AND Brutus)<DF(Calpurnia)=100。
此时将这个中将结果R AND Caesar 的时间复杂度不会超过O(100+10000)。
而且最后结果页不会操作DF<DF(Calpurnia AND Brutus)<100。
总的时间复杂度为O(1100+10100)=O(11200)
如果使用原表达式,Brutus AND Caesa的时间复杂度为O(11000),且中间结果为R=DF( Brutus AND Caesa )< DF(Brutus)=1000。
然后R AND Calpurnia的时间复杂度可能达到O(1000+100)。
两次AND操作的总时间复杂度为O(11000+1100)=O(12100)
明显优化之后的时间复杂度会少。
如果查询表达式更长,查询词语的DF差距更大,那么优化的效率会更明显。
根据上面的优化原理,对于更加复杂的查询表达式(madding OR crowd) AND (ignoble OR strife) AND
(killed OR slain)。
我们一般都会估算OR操作两个词的DF之和的数量,然后进行AND递增排序。
事实上,对于任意的布尔表达式,每一次操作的中间结果(intermediate)越小越好。
这是我们进行优化的原则所在。
(3) 自然语言查询AND 布尔查询表达式
为什么我们对布尔表达式的操作只将AND,很少说OR或NOT呢?
在搜索引擎实际应用的环境下,用户的查询都是自然语言叙述的,很少直接用布尔表达式(你不能要求所有的用户必须逻辑思维缜密吧)。
那么对于用户提交的这些查询,都是纯粹的合并操作。
正是这个原因,现实中很多搜索引擎的应用已经退化成了只有AND的布尔模型了。