zoukankan      html  css  js  c++  java
  • 《信息检索导论》第四章总结


    一、索引构建影响因素


    索引构建是指一篇文档转换成倒排索引的整个过程;

    (1)需要考虑的因素有内存大小、CPU时钟频率等;比如如果内存特别大,则能够把全部的文档都放入内存,并很快就能构建成倒排索引;

    (2)我们需要把尽可能多的内容放在内存;

    (3)需要考虑寻道时间,因此必须要把连续读取的数据放在连续的块中;

    将文档集变成term-->docID后,词项-文档ID对的数目是token的数目;


    二、BSBI


    我们这里考虑的是大文档集(不能把全部的文档都放入内存)。

    顾名思义,BSBI(Block Sorted-Based Indexing)是基于块排序的;操作流程如下:

    (1)把整个文档集分成大小相同的部分(每个部分正好是一个块大小)并放入内存;

    (2)把每个部分解析成词项ID->文档ID对;(我们为了能够使得索引构建的效率更高,我们用词项ID代替词项本身,当然同时需要维护一个词项->词项ID的映射表,并把他放入内存);

    (3)把这个块的词项ID->文档ID对按照词项排序,并对相同词项ID对应的文档ID构建临时posting;

    (4)将此结果写回磁盘,并进行下一个block的解析;

    (5)当全部的文档集都解析完毕后,对每个block的倒排索引进行合并,并最后成为一个完整的倒排索引;

    而BSBI的核心算法是(2),(3),因此其核心算法的复杂度为O(TlogT),在这个复杂度中并没有考虑(5)步的外部归并排序;因此只针对解析文档+生成临时posting;


    三、SPIMI


    BSBI缺点:需要维护词项->词项ID的映射表,如果文档集很大,则这个映射表也会很大;

    SPIMI(Simple Pass in memory indexing),操作流程如下:

    (1)把整个文档集都分割成词项->文档ID对;

    (2)把这个一系列的词项->文档ID对作为一个流,如果还有内存,则逐个进入内存;

    (3)内存中预先已经构建了一个dictionary(hash实现),因此只需要利用词项寻找到文档ID应该放入的位置,并放入文档ID即可;

    (4)当内存满时,将dictionary按照词项进行排序,并将排序后的dictionary和posting写回磁盘;

    (5)将全部的文档集解析完后在磁盘中应该有多个已排序的dictionary-posting;将这些合并即可;

    SPIMI的核心算法为(2)(3),因此算法复杂度为O(T);


    四、Map-reduce


    上面所讲的都只是针对一般大的文档集,但是如果是对于海量的文档集,则在一台机器处理明显是不行的;因此我们想到了分而治之的思想;

    主要思想:将文档集分布在计算机集群上进行处理,采用Master-Slave模式,Master电脑控制处理过程,比如一台计算机在处理文档集时突然坏了,则Master会将此电脑处理的文档集任务交给另一台机器处理;

    Map阶段:将文档集划分成n个数据片,并通过分析器进行处理,变成排好序的词项->文档ID对,这就是一般的BSBI或SPIMI算法;

    Reduce阶段:比如将每台机器的dictionary划分成a-i和j-z两个部分,然后将a-j部分统一交给一个倒排器完成,因此这里只需要两个倒排器即可;

    注意:

    (1)分析器和倒排器是一台计算机,并且一台机器既可以作为倒排器也可以作为分析器;

    Map阶段细化:

    (1)文档集存在一台独立的机器中,将文档集分成数据片,并分别传送到作为分析器的机器中(这里需要考虑IO时间);

    (2)进行BSBI或者SPIMI分成词项ID-->文档ID(涉及比较次数消耗时间);

    Reduce阶段细化:

    (1)将分区文件通过IO传送到倒排器中(这里需要考虑IO时间);

    (2)将每个倒排器中的词项ID-->文档ID排序   O(nlogn) n为词条数目;

    (3)将倒排记录表写到独立的机器中; (注意:这里需要考虑dictionary的大小和posting的大小,dictionary的大小是词项大小,posting大小是词条大小,并且注意IO时间);


    五、动态索引构建


    在以上讨论中,都是以文档不变化为前提,但实际上文档会更新、插入、删除等;因此我们需要引入动态索引;

    主要思想:主索引继续维护,构造一个辅助索引(表示添加的文档),维护一个无效位向量(表示删除的文档),当辅助索引足够大时,就和主索引合并;

    在检索时,我们必须要将主索引和辅助索引的检索结果合并,并在无效位向量中进行过滤即可;

    改进方法:

    引入log(T/n)个索引I0,I1,....Ii......;每个索引大小分别为(2^i)*n;

    这些索引构建过程:

    在内存中始终维护一个辅助索引;

    (1)一开始当辅助索引满时,就构建I0并将I0存入磁盘,清空辅助索引;

    (2)辅助索引第二次满时,和I0合并,并成为I1(I0被去除);

    (3)辅助索引第三次满时,构建I0;

    (4)辅助索引第四次满时,将I0、I1和辅助索引合并,成为I2(I0和I1被清除);

    以此类推,可以看到有一个规律:构建索引的过程是以二进制数增加的方式构建的;即:

    I3   I2  I1   I0

    0    0    0    0

    0    0    0    1

    0    0    1    0

    0    0    1    1

    0    1    0    0

    0    1    0    1

    0    1    1    0

    0    1    1    1

    在检索时,我们要合并从I0到In索引的结果,并过滤无效位向量,因此比较麻烦;


    六、访问授权


    一般倒排索引的posting都是按照文档ID进行排序,这样有助于压缩,而且插入数据时只需要在最后;但是对于ranked retrieval来说,需要按照权重进行排序,但是如果要添加数据,则需要扫描一遍确定插入位置;

    一般地,访问授权是指一个用户对于文档是否有权访问,通过ACL(Access Control List)进行处理,而访问控制表也可以用一个倒排索引结构进行组建;

    dictionary表示每个用户,而posting表示用户所能访问的文档ID;简单的来说就是一个用户-文档ID矩阵;

    作者:xiazdong
    出处:http://blog.xiazdong.info
    本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。
  • 相关阅读:
    leetcode教程系列——Binary Tree
    《Ranked List Loss for Deep Metric Learning》CVPR 2019
    《Domain Agnostic Learning with Disentangled Representations》ICML 2019
    Pytorch从0开始实现YOLO V3指南 part5——设计输入和输出的流程
    Pytorch从0开始实现YOLO V3指南 part4——置信度阈值和非极大值抑制
    Pytorch从0开始实现YOLO V3指南 part3——实现网络前向传播
    Pytorch从0开始实现YOLO V3指南 part2——搭建网络结构层
    Pytorch从0开始实现YOLO V3指南 part1——理解YOLO的工作
    让我佩服的人生 文章
    win8.1配置cordova+ionic等一系列东西
  • 原文地址:https://www.cnblogs.com/xiazdong/p/3058356.html
Copyright © 2011-2022 走看看