阅读本篇文章首先要对“词汇文档矩阵”和“倒排索引”有个基本的认识,要了解相关的知识可以阅读上一篇文章:搜索引擎概述之倒排索引。
布尔检索是最基础,也是使用最广泛的信息检索模型了。所谓布尔查询就是通过AND、OR、NOT等逻辑操作符将检索词连接起来的查询。比如:
李白 AND (杜甫 OR 白居易) NOT 苏轼
那么,布尔检索时如何利用倒排索引进行查询的呢?我们还是先从词汇文档矩阵说起吧~
从词汇文档矩阵说起我们先假设我们有一个词汇文档矩阵,如下所示:
当我进行布尔查询的时候,其实本质就是在为文档矩阵中的每行1和0组成的二进制数做布尔逻辑运算。
李白 AND 杜甫
=110001 AND 110100
=110000
AND操作就是,相同的位同时为1,则结果为1,否则为0。李白 AND 杜甫最终得出的结果就是文档1和文档2。
杜甫 OR 白居易
=110100 OR 110111
=111111
OR操作就是,相同的位有一个位1,则结果为1,都为0结果才是0。杜甫 OR 白居易最终得出的结果就是所有的文档。
李白 NOT 苏轼
=110001 NOT 010000
=110001 AND 101111
=100001
NOT操作就是先将NOT之后的内容取反,再进行AND操作。李白 NOT 苏轼最终得出的结果就是文档1和文档6。
我们可以发现使用词汇文档矩阵的话,进行布尔检索十分简单。但是我们在“搜索引擎概述之倒排索引”(回复“倒排索引”查看)中说过,词汇文档矩阵是稀疏的,极其浪费空间资源,使用这种结构存储大量的数据是不现实的。因此,我们要使用的是倒排索引。
倒排索引的布尔查询那么在倒排索引中我们如何进行布尔查询呢?首先我们先将上边的词汇文档矩阵转换为倒排索引:
那么,如果我们进行:“李白 AND 白居易”的查询则会进行如下操作:
- 在词典中定位“李白”
- 返回其倒排记录:“1,2,6”
- 在词典中定位“白居易”
- 返回其倒排记录:“1,2,4,5,6”
- 对另个倒排记录表求交集
最终的得到的结果就是“1,2”,也就是文档1和文档2。
同理,OR查询就是取并集,NOT查询就是从从第一个倒排记录中排除第二个倒排记录的内容。为了高效的完成交集,并集和排除操作,一般我们会要求倒排记录中的文档id是有序的。
下面我们以三种操作中比较复杂的求交集为例,来说一下布尔查询的算法实现。一种比较常见的倒排记录求交集的算法如下面伪代码所示:
我们的倒排记录是有序的。我们依次比对两个倒排记录中文档id的值。如果,如果两者id一样则输出该id,然后同时比对下一个文档id。如果两者id不一样,则较大的那个不变,之后去和较小的id的下一个id去做比对。这个算法的时间复杂度是O(x+y),也就是O(N),要远优于无序列表依次作比对的O(N²)。
优化查询优化——从小到大
李白 AND 白居易 AND 苏轼
当我们去查询一种多个AND组成的查询时,其实本质上就是依次取交集。而且我们很容易知道,对于上边所述的算法来说,如果其中一个集合越短,那么计算可能就越快。因此一个启发式的优化方法就是,在取多个交集的时候,不是去依次的计算,而是先将倒排记录表按照长度从小到大排列,我们先合并最短的两个倒排记录表。这样所有的中间结果的大小都不会超过最短的倒排记录表。因为多个集合的交集元素个数,一定不会大于其中任何一个集合的元素个数。
查询优化——二分查找
如果两个倒排记录表的元素个数差距极大的时候(比如比较极端的:1和10000),我们就没必要依次去比较它们的元素了。采用对短列表中的全部元素分别在长列表中做二分查找的方式,可能会更快。
查询优化——跳表
另外,使用跳表的方式去实现倒排记录表,也可以加快倒排记录表求交集的速度。但是,由于跳表是一种用空间换时间的数据结构,因此会占用更大的空间。同时,虽然现代计算机的cpu运算速度很快,但是磁盘的访问速度依旧很慢。在这样的前提下,如果是一个将所有索引数据都存在内存中的搜索引擎,使用跳表会加快速度;但如果是将索引数据存储在硬盘上的搜索引擎,反而可能会大大的降低速度。由于篇幅有限,我无法在这里详细的介绍跳表这种数据结构的实现。在未来的文章中我会单独介绍这种数据结构,到时候会再次深入的讨论这个问题。
布尔查询的缺点无法排序
布尔查询的本质只是查询了某些词汇在文档中的有无,但是却无法告诉用户哪些是更相关的,哪些是不那么相关的。也就是说,布尔查询本身无法按照相关度进行排序。
正确率和召回率难以均衡
评价搜索引擎的最重要的两个指标就是正确率和召回率。
- 正确率:返回的结果真正的和用户信息需求相关的文档所占的比率。
- 召回率:所有和用户 信息需求真正相关的文档中检索系统返回的百分比。
比如说如果每次查询,我都将所有的文档返回,召回率必然是100%(所有的文档中必然包含所有的相关文档),但是正确率就会很低很低(100万文档中只有1万文档真的和需求相关)。而如果我每次只返回一条数据,而且保证这条数据百分之百和用户需求相关,那么正确率就是百分之百(共返回1篇文档,有1篇和用户信息相关,因此是百分之百) ,但召回率很低(1万篇相关文档之返回1篇)。
使用布尔查询在实际应用中会遇到这样的问题:
如果我要查一篇名字为“Semantic information retrieval research based on co-occurrence analysis”的文章,如果我将所有的空格都识别为AND,这时就只会返回标题为这篇文章的文档,用户无法获得任何其他相关信息。此时正确率很高,但召回率很低。同样,如果我将所有的空格都识别为OR,这时我虽然会获得相关信息了,但是很可能很多相关信息只和information有关,但这并不是我想要的。因此此时虽然召回率很高,但是正确率很低。布尔检索在召回率的问题上很容易走两个极端,很难达到理想的均衡状态。
然而在检索引擎几十年的发展中,已经有很多方案在完善这些问题,或者说在增强布尔查询的能力。而另一方面,也有了一些新的检索模型或技术(如,自由文本查询)来解决这些问题。这些我都将在未来的文章中,慢慢的介绍给大家。
共同学习,写下你的评论
评论加载中...
作者其他优质文章