CN108475266B - 用来移除匹配文档的匹配修复 - Google Patents

Abstract

本文所描述的技术提供了匹配修复阶段，其移除针对搜索查询被标识为实际上不包含来自搜索查询的项目的匹配文档。每个文档的表示(例如，存储针对每个文档的项目列表的正向索引)被用来标识有效匹配文档(即，包含来自搜索查询的项目的文档)和无效匹配文档(即，不包含来自搜索查询的项目的文档)。从针对搜索查询的进一步处理和排名移除任何无效匹配文档。

Description

用来移除匹配文档的匹配修复

背景技术

因特网和其他电子资源上的可用信息和数字内容的量持续快速增长。考虑到大量的信息，已经开发了搜索引擎以促进搜索电子文档。特别地，用户或计算机可以通过提交搜索查询来搜索信息和文档，搜索查询可以包括例如一个或多个字。在接收到搜索查询之后，搜索引擎基于搜索查询来标识相关的文档。

在高层次上，搜索引擎通过对文档与搜索查询的相关性进行排名来标识搜索结果。排名通常基于大量的文档特征。考虑到文档集合很大，对针对搜索查询的所有文档进行排名是不可行的，因为这将花费不可接受的时间。因此，搜索引擎通常使用包括用来为最终排名过程而将文档从考虑中移除的初步操作的流水线。这一流水线传统上包括匹配器，匹配器过滤掉不具有来自搜索查询的项目的文档。匹配器使用搜索索引进行操作，搜索索引包括通过爬取文档或以其他方式分析文档以收集关于文档的信息而被收集的信息。搜索索引通常由针对在文档中发现的各种项目的发布列表(有时被称为反向索引)组成。针对特定项目的发布列表由包含该项目的文档的列表组成。当接收到搜索查询时，匹配器使用搜索索引来标识包含从搜索查询标识的项目的文档。然后可以通过流水线中的一个或多个下游过程来考虑匹配文档，一个或多个下游过程进一步移除文档并最终返回已排名的搜索结果的集合。

发明内容

提供本发明内容以便以简化的形式介绍将在以下具体实施方式中被进一步描述的对概念的选择。本发明内容不旨在标识要求保护的主题的关键特征或必要特征，也不旨在被用作确定所要求保护的主题的范围的辅助手段。

本文所描述的技术提供了匹配修复阶段以移除从位向量搜索索引返回的无效匹配文档。位向量搜索索引是使用位向量来索引关于在文档中包含的项目的信息的数据结构。每个位向量包括存储针对项目集的信息的位阵列。位向量中的每个位位置(或位)指示一个或多个文档是否包含来自项目集的一个或多个项目。此外，一个项目可以被包括在多个位向量中。通过从查询标识对应于(一个或多个)项目的位向量并且将所标识的位向量进行相交来标识针对搜索查询的匹配文档。匹配文档集合可能包括太多的匹配文档以至于把它们全部发送到最终排名器是不可行的，这在对于每个文档所需的处理量的意义上来说可能是昂贵的。此外，因为位向量搜索索引提供了概率方式，所以在这些文档不包含来自搜索查询的项目的意义上，一些匹配文档可能是无效匹配文档(即，误判)。因此，根据本文所描述的技术，搜索系统使用匹配修复阶段来移除无效匹配文档。一般而言，每个文档的表示被用来标识有效匹配文档和无效匹配文档。该表示例如可以是存储针对每个文档的项目列表的正向索引。任何无效匹配文档都被移除，从而使得它们不被最终排名器所考虑。

附图说明

下面参考附图详细描述本文所提供的技术的各方面，其中：

图1是图示出根据本文所描述的技术的一个方面的用于单个项目的位向量的图；

图2是图示出根据本文所描述的技术的一个方面的用于三个项目的组合的位向量的图；

图3是图示出根据本文所描述的技术的一个方面的将项目包括在多个位向量中的图；

图4A至图4C是图示出根据本文所描述的技术的一个方面对位向量进行相交以标识包括项目的文档的图；

图5是图示出根据本文所描述的技术的一个方面的每位具有不同数目的文档的位向量的图；

图6是图示出根据本文所描述的技术的一个方面用于使用位向量来生成搜索索引的方法的流程图；

图7是图示出根据本文所描述的技术的一个方面的使用位向量的简化搜索索引700的图；

图8是图示出根据本文所描述的技术的一个方面的用于匹配器标识与来自搜索查询的项目匹配的文档的方法的流程图；

图9是图示出根据本文所描述的技术的一个方面的用于首先使用短位向量来对位向量进行相交的方法的流程图；

图10是图示出根据本文所描述的技术的一个方面的针对来自搜索查询的项目而言可用的位向量的示例的图；

图11是图示出根据本文所描述的技术的一个方面对位向量进行排序以用于相交的图；

图12是图示出根据本文所描述的技术的一个方面形成查询计划的图；

图13是图示出根据本文所描述的技术的一个方面的针对查询计划的树的图，其中每个块对应于一个位向量；

图14至图17是图示出根据本文所描述的技术的一个方面的根据图13的针对查询计划的树的位向量的相交的图；

图18是图示出根据本文所描述的技术的一个方面的用于匹配器生成匹配器计划的方法的流程图，匹配器计划提供用于对位向量进行相交的高效顺序；

图19是图示出根据本文所描述的技术的一个方面用于使用加强行来对文档进行匹配的方法的流程图；

图20A至图20B是图示出根据本文所描述的技术的一个方面的使用针对短语的位向量的示例的图；

图21是提供长文档的示例的图；

图22是图示出根据本文所描述的技术的一个方面的用于使用位向量来生成针对搜索索引的分片的方法的流程图；

图23是图示出根据本文所描述的技术的一个方面的用于使用多个分片来执行搜索的方法的流程图；

图24是图示出根据本文所描述的技术的一个方面的用于生成诸如条带表的数据结构的方法的流程图，数据结构将项目特性映射到位向量配置；

图25是图示出根据本文所描述的技术的一个方面的用于使用明确映射和自组织信息来确定位向量存储位置的方法的流程图；

图26是图示出根据本文所描述的技术的一个方面的用于针对搜索查询的行修剪/扩充的方法的流程图；

图27是图示出根据本文所描述的技术的一个方面的用于针对搜索查询的行修剪/扩充的另一方法的流程图；

图28是图示出根据本文所描述的技术的一个方面的用于将文档添加到基于位向量的搜索索引的方法的流程图；

图29是图示出具有针对所标识的文档的“列”的具有变化长度的位向量的集合的简化搜索索引的图；

图30是图示出根据本文所描述的技术的一个方面的用于从位向量搜索索引移除文档的方法的流程图；

图31A至图31D是图示出根据本文所描述的技术的一个方面的从位向量搜索索引移除文档的图；

图32A和图32B是图示出将文档添加到阵列的图；

图33A至图33D是图示出将文档添加到阵列的另外的图；

图34A和图34B是分别图示出将文档复制到较大阵列并开始新阵列的图；

图35A至图35H是图示出将文档写入阵列并将文档从阵列复制到阵列的图；

图36是图示出在不同类型的存储装置上存储不同阵列的图；

图37是图示出根据本文所描述的技术的一个方面的用于使用累积缓冲器来在位向量搜索索引中对文档进行索引的方法的流程图；

图38是图示出根据本文所描述的技术的一个方面的提供初步排名的示例性系统的框图；

图39是图示出根据本文所描述的技术的一个方面的用于基于与搜索查询的相关性来对多个文档进行评分的方法的流程图；

图40是图示出根据本文所描述的技术的另一方面的用于基于与搜索查询的相关性来对多个文档进行评分的方法的流程图；

图41是图示出根据本文所描述的技术的一个方面的用于将针对项目的数据添加到分数表的空隙(slot)的方法的流程图；

图42是图示出根据本文所描述的技术的一个方面的用于使用匹配修复以从概率匹配器下游移除无效匹配文档的方法的流程图；

图43是图示出根据本文所描述的技术的一个方面的用于使用匹配修复以从概率匹配器下游移除无效匹配文档的另一方法的流程图；

图44是图示出其中可以使用本文所描述的技术的各方面的示例性搜索系统的框图；以及

图45是适用于在实现本文所描述的技术的各方面中使用的示例性计算环境的框图。

具体实施方式

本文所提供的技术的各方面的主题在本文中具有特异性地被描述以满足法定要求。然而，描述本身并不旨在限制本专利的范围。相反，发明人已经预期到，所要求保护的主题也可以结合其他当前或未来的技术以其他方式被体现，以包括与本文中所描述的步骤类似的不同步骤或步骤的组合。此外，虽然术语“步骤”和/或“块”在本文中可以用于暗示所使用的方法的不同元素，但是除非并且除了当明确描述各个步骤的顺序，否则这些术语不应当被解释为意味着本文所公开的各个步骤之中或之间的任何特定顺序。

本文所描述的每个方法可以包括使用硬件、固件和/或软件的任何组合而被执行的计算过程。例如，各种功能可以由执行被存储在存储器中的指令的处理器执行。还可以将该方法体现为被存储在计算机存储介质上的计算机可用指令。这些方法可以由独立应用、服务或托管的服务(独立或与其他托管的服务组合)、或者到另一产品的插件等来提供。

备选地或附加地，本文中所描述的功能性可以至少部分地由一个或多个硬件逻辑组件执行。作为示例而非限制，可以使用的说明性的硬件逻辑组件的类型包括现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统型系统(SOC)、复杂可编程逻辑器件(CPLD)等。

在评估搜索系统的设计时可能会考虑许多度量。一个度量是由搜索系统使用来索引关于文档语料库的信息的存储消耗。这一度量可以是在搜索系统(“D”)中的每台机器上可以被索引的文档数目的测量。另一个度量是针对搜索查询的处理速度。这一度量可以是由搜索系统(“Q”)处理的每秒查询次数的测量。在搜索系统的设计中的另一考虑是：它应该始终可用——即使需要周期性地更新搜索索引以索引关于文档变更和新文档的信息。在一些设计中，通过让成组的索引服务器关机以更新它们同时留下其他组的索引服务器运行来更新搜索系统，从而使得随着时间所有组都被更新。随着因特网上可用文档的持续增加，更新搜索索引的时间持续增加到了目前的设计可能变得不可行的点。最后，针对搜索系统的另一设计目标可以在新文档变得可用时快速更新搜索索引。这对于索引诸如新闻或社交馈送的信息是特别理想的，其中用户希望在信息变得可用时接近实时地看到信息。

在考虑上述设计度量时，发布列表(或反向索引)的传统使用呈现许多缺点，这些缺点既影响在搜索系统(D)中在机器上可以存储多少文档又影响查询(Q)的处理速度。发布列表保持是排序的，从而使得可以高效地执行两个发布列表的接合(或相交)然而，对发布列表进行重新排序使信息的即时更新变得不切实际，因为对于每次更新都必须重建大量的数据。因此，发布列表通常需要批量更新以分摊大量更新的排序成本。为了加速查询处理，已经向发布列表增加了一些复杂性，诸如当在搜索针对包含搜索查询项目的匹配文档的发布列表时，跳过列表提供了跳过文档的方式。此外，由于发布列表通常按文档排序，所以如果添加新文档，则可能必须将其插入在发布列表中的某个位置。鉴于这些复杂性，发布列表可能不允许快速插入新文档或文档变更，反而可能作为替代而要求重写发布列表。即使设计确实促进了插入新文档或文档变更，由于跳过列表和/或为了促进查询处理而添加到发布列表中的其他复杂性，插入它也可能是非常复杂的。因此，更新针对诸如经由因特网可用的文档之类的文档的大型语料库的搜索索引的时间可能会持续增加到一个它使搜索系统的可用性受到损害的点。此外，这些问题对搜索系统为新近可用信息(例如新闻、社交馈送等)提供实时搜索结果的能力产生了负面影响。

本文所描述的技术的各方面使用多种技术来在现有的搜索系统上产生效率的大幅增加(例如，在所有搜索引擎上是2-3倍并且在即时更新的搜索引擎上是10倍)。这包括用试图跨I/O通道将信息密度最大化的数据结构来替换发布列表。例如，在今天的至强计算机中，限制通道可能是从存储器到CPU的路径，其中存储器例如可以是双倍数据速率随机存取存储器(DDR RAM或DDR)、固态驱动(SSD)或硬盘驱动(HDD)。数据的组织大多数通过熵被优化，以便接近理论上的最大信息密度。本文所描述的技术的各方面使用概率方法，其允许在匹配过程期间发生误判结果。换言之，匹配器可能返回不包含来自搜索查询的项目的文档。这与发布列表形成对照，发布列表是准确的——匹配器将只返回包含来自搜索查询的项目的文档。然而，由本文所描述的各种配置所使用的技术所导致的效率改善如此深刻，即使虑及在后期阶段移除误判的成本，与利用发布列表的系统相比，用于匹配的总成本也显著降低。此外，虽然匹配器可能返回误判，但它将不会移除真正匹配的文档(除非当使用NOT运算符时)。

图44提供了示出提供本文所描述的特征概览的示例性搜索系统4400的框图。应该理解的是，本文所描述的这个布置和其他布置仅作为示例被阐述。除了所示出的那些之外或者替代所示出的那些，可以使用其他的布置和元件(例如，机器、接口、功能、顺序和功能组等)，并且一些元件可以被完全省略。此外，本文所描述的许多元件是功能实体，其可以被实现为分立或分布式组件或与其他组件结合并且在任何合适的组合和位置中被实现。本文中被描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件执行。例如，各种功能可以由执行被存储在存储器中的指令的处理器执行。虽然图44示出了具有许多不同特征的搜索系统4400，但是应该理解，搜索系统可以使用与本文讨论的其他特征无关的任何特征。

如图44中所示，搜索系统4400使用位向量搜索索引4410而不是使用发布列表的搜索索引。位向量搜索索引4410使用多个位向量来表示索引文档。如下面将更详细描述的，位向量是存储用于项目集的信息的位阵列。位向量中的每个位位置(或位)对应于一个或多个文档是否包含来自项目集的一个或多个项目的断言。如本文所使用的，“文档”是指信息可以被搜索系统索引的任何电子内容项目。电子内容项目不限于文本，并且可以包括例如图像、音频、视频、地理数据等。如本文所使用的，“项目”对应于关于文档的任何断言，包括文档包含一个或多个具体字的断言。在某些情况中，项目可以是单个字；而在其他情况中，项目可以是多字短语。“字”是指任何数目的符号(例如，字母、数字、标点符号等)或任何二进制数据(例如散列、索引、id等)。在某些配置中，项目可以是“元字”(metaword)，它可以对字或字集之外的其他类型的断言进行编码。例如，项目可以对应于用法语书写文档的断言。

因为位向量可以对应于项目集，所以在从单个位向量中的一个设定位不知晓这些项目中的哪个项目包含在对应于设定位的文档中的意义上来说，位向量包括噪声。为了解决这个问题，项目可以被包括在多个位向量中。为了标识包含给定项目的文档，标识与该项目对应的位向量并对其进行相交。包含该项目的文档被标识为与针对该项目的每个位向量中设置的某个位对应的文档。应该指出，本说明书的大部分讨论了位向量的相交。然而，配置也可以使用联合(union)和否定(negation)，并且因此在提及相交的情况下，可以作为替代执行联合(union)和否定(negation)。

位向量可以包括长位向量和短位向量。长位向量是其中每个位对应于单个文档的位向量。因此，长位向量中的一个位指示对应于该位的文档是否包含对应于该位向量的一个或多个项目。短位向量是其中每个位对应于两个或更多个文档的位向量。因此，短位向量中的位指示对应于该位的两个或更多个文档中的任何文档是否包含对应于该位向量的一个或多个项目。搜索索引可以存储变化长度的短位向量(例如，每位两个文档，每位四个文档，每位八个文档等)。

使用基于位向量的搜索索引提供了优于发布列表的许多益处。例如，通过使用位序列，该方式通过避免发布列表的复杂性(包括需要对文档进行排序和使用跳过列表)来产生非常高的效率。这尤其允许对搜索索引进行即时或近乎即时的更新，防止用来更新搜索索引的长停机并且促进实时或近乎实时地添加新的/变更的文档(例如，针对新闻、社交馈送等)。附加地，系统的设计可配置以满足Q和D设计目标。例如，该方式可以在不牺牲D的情况下提供极高的Q(即，高Q，同时D与现有系统相当)。作为另一示例，该方式可以在不牺牲Q的情况下提供高D(即，高D，同时Q与现有系统相当)。

在一些配置中，将基于位向量的搜索索引分成不同的分片4412，如图44中所表示的。每个分片对与不同范围的文档长度对应的不同文档集(例如，针对文档而被索引的独特项目的数目)进行索引。例如，第一分片可以索引具有0-100个项目的文档，第二分片可以索引101-200个项目的文档，第三分片可以索引201-300个项目的文档，等等。这解决了当极大变化长度的文档一起被存储时丢失效率的问题。例如，如果一个非常长的文档(即，很多项目被索引)与一个非常短的文档(即很少的项目被索引)一起被存储，则针对长文档的列将设置有很多位，而针对短文档的列将会设置有非常少的位。如本文所使用的，“列”是指对应于给定文档或文档组的每个位向量中的位。这使得难以在位向量中保持均匀的位密度(即，位的百分比被设置为“1”)。通过将相似长度的文档分组在分片中，可以按照更好地控制位密度的方式来配置项目的分布。

可以通过将不同的位向量配置指派给不同的项目来在一些配置中实现基于位向量的搜索索引中的项目的分布。针对项目的位向量配置表示被用于项目的位向量的数目和长度，并且还可以指定针对每个位向量的存储装置的类型(例如，DDR、SSD、HDD等)。根据本文所描述的技术的一些方面，可以基于项目特性将项目分组成条带，并且可以为每个条带指派特定的位向量配置。这避免了在每一项目的基础上指派位向量配置的复杂性，并且避免了对于所有项目使用单个位向量配置的一刀切解决方案的低效率。项目特性到位向量配置的映射可以由搜索系统4400存储在数据结构中，诸如在图44中所示的条带表4414中。

一些配置针对项目来寻址位向量的存储位置的标识。例如，当生成和更新搜索索引时，标识位向量存储位置。附加地，为了标识用于搜索查询的匹配文档的目的，当取回位向量时标识位向量存储位置。根据本文所描述的技术的一些方面，使用了用于标识位向量存储位置的混合方法。针对某些项目提供了明确映射。例如，这可以包括在搜索查询和/或文档中出现频率最高的项目。明确映射标识针对每个项目的具体位向量存储位置。明确映射可以由搜索系统4400存储在数据结构中，诸如图44中所示的项目表4416。对于其他项目，使用了自组织方式。特别地，可以为与特定项目特性对应的项目条带提供映射算法。可以使用针对每个条带的映射算法以用于得出针对具有被指派给每个对应条带的项目特性的项目的位向量存储位置。每个映射算法可以将存储位置例如确定为项目的散列的函数。映射算法与项目特性的对应关系可以由搜索系统4400存储在数据结构中，诸如在图44中所示的条带表4414中。

条带表4414和项目表4416可以在索引生成时间和查询时间被搜索系统4400使用。如本文所使用的，“索引生成时间”是指用来索引关于搜索索引中的文档的信息的过程。这包括最初生成搜索索引以及通过添加/更新/移除文档随时间逐步地更新搜索索引。如本文所使用的，“查询时间”是指处理搜索查询以返回搜索结果。条带表4414和项目表4416可以在索引生成时间被索引器4418使用以在位向量搜索索引4410的位向量中索引关于文档的信息。特别地，可以使用条带表4414和项目表4416来标识针对项目的位向量配置，并且在将文档信息添加到位向量搜索索引4410时标识针对项目的位向量位置。在查询时间，匹配器4404可以使用条带表4414和/或项目表4416来标识针对从接收到的搜索查询标识出的项目的位向量位置。

索引器4418可以可操作以从位向量搜索索引4410移除和/或添加文档。向位向量搜索索引4410添加文档可能只需要标识针对文档的“列”(即，每个位向量中与该文档对应的位)，并且基于该文档中的项目的存在来设置与该列对应的位向量中的位。在一些情况中，可以使用更快的存储设备(例如，DDR RAM)来存储位向量，并且可以一次一个地索引文档。在其他情况中，较慢的存储设备(例如，SSD；HDD)在写入位向量时可能呈现一些低效率。因此，一些配置使用在本文中被称为“累积缓冲器”的元素以将文档索引到较慢的存储设备以抵消低效率。通常，最初可以在累积缓冲器中的位向量中索引文档。一旦满足阈值(例如，基于时间；基于文档)，就从累积缓冲器将信息传送给另一存储设备。取决于设计目标，可以使用任何数目和尺寸的累积缓冲器来将文档索引到最终的存储设备。

图44图示出了用来为搜索查询4402提供排名的搜索结果4428的多阶段方式。当搜索系统4400接收到搜索查询4402时，基于搜索查询4402来标识项目。项目可以是完全如被包括在搜索查询中的项目和/或基于搜索查询4402中的项目所得出的项目。匹配器4404操作以基于来自搜索查询4402的项目来标识匹配文档集合4420。匹配器4404包括位向量选择组件4406，位向量选择组件4406通常操作以从位向量搜索索引4410选择用于项目的位向量。匹配器4406还包括位向量处理组件4408，向量处理组件4408操作以对所选择的位向量进行相交(或者执行联合(union)或排除(exclusion)(例如，否))以便标识匹配文档集合4420。

位向量选择组件4406可以使用多种技术来选择用于相交的位向量以便控制返回的匹配文档。本文所描述的技术的一些方面可以在其中可能返回太多匹配文档的情况中使用在本文中被称为“加强行”位向量的元素。“加强行”位向量是为了减少匹配文档的数目而被添加的用于相交的位向量以外的位向量。作为示例，加强行位向量可以基于文档的静态排名。特别地，位向量可以具有针对具有最高静态排名的文档(例如，基于静态排名的文档的前10％)被设置的位。添加这样的静态排名位向量将把匹配文档限制为具有与来自搜索查询4402的项目匹配的最高静态排名的文档。可以被使用的另一加强行位向量是标识文档中的非主体位置(例如，标题或锚文本)(而不是文档中的任何位置)中的项目的位向量。

位向量选择组件4406在选择位向量时可以使用的另一技术在本文中被称为行修剪/扩充。通常针对来自接收到的搜索查询的每个项目有多个位向量可用，并且可以将位向量存储在不同类型的存储装置(例如，DDR、SSD、HDD等)中。位向量选择组件4406可以决定针对来自搜索查询4402的项目的可用位向量中的哪一个来选择以用于相交。该选择可以基于某个相关性度量、期望被返回的匹配文档的数目的估计、每个位向量所处的存储装置的类型以及其他考虑。控制选择哪些可用位向量以用于相交，可以基于针对搜索系统4400的设计目标来调整匹配文档(例如，误判的数目)和处理速度的相关性。

由匹配器4404返回的匹配文档集合4420可能包括太多的匹配文档而不可能将它们全部发送给最终排名器4426，这在针对每个文档所需的处理量的意义上可能是昂贵的。附加地，由于位向量搜索索引提供了概率方式，因此在一些匹配文档4420不包含来自搜索查询的项目的意义上，这些文档可能是无效匹配文档(即误判)。因此，搜索系统4400可以在匹配器4404与最终排名器4426之间使用一个或多个阶段以在匹配文档到达最终排名器4426之前从考虑中移除匹配文档。

一个或多个初级排名器(诸如初级排名器4422)，可以提供较不昂贵的文档排名，以更快地从考虑中移除一些文档。通常，初级排名器可以使用来自发布列表中的信息。因为搜索系统4400不使用发布列表，所以可以使用其他方式。根据本文所描述的技术的一些方面，分数表4430可以被初级排名器使用来基于它们与搜索查询的相关性来对匹配文档进行评分。针对文档的分数表存储被用于得出文档中的项目和其他信息的频率的预先计算出的数据。因此，初级排名器4422可以针对每个匹配文档和来自搜索查询4402的项目使用分数表以确定针对每个匹配文档的分数。然后可以从进一步考虑中移除最低评分的文档。

搜索系统4400还可以使用匹配修复阶段来移除无效匹配文档。通常，匹配修复组件4424可以使用每个文档的表示来标识有效匹配文档和无效匹配文档。该表示例如可以是存储针对每个文档的项目的列表的正向索引。任何无效匹配文档都可以由匹配修复组件4424移除，从而使得它们不被最终排名器考虑。

使用位向量的搜索索引

在本文所描述的技术的各方面中的搜索索引使用位向量，而不是传统上由搜索索引所使用的发布列表。位向量包括位(即，1和0)的阵列。在其最简单的形式中，位向量可以对应于特定的项目，并且每个位对应于特定的文档。针对文档被设置的位指示该文档包含该项目。相反，没有针对文档被设置的位指示该文档不包含该项目。

图1概念性地图示出了针对项目A的位向量100。图1中所示的24个块中的每个块对应于阵列中的一个位，每个位对应于一个不同的文档。因此，位向量100对关于24个文档中的每个文档是否包含项目A的信息进行编码。在本示例中，用字母A标记的块102、104、106表示已经被设置的位，由此指示与那些位对应的文档包含项目A。因此，位向量100标识了在包含项目A的24个文档的集合中的三个文档。在概念上，位向量100被显示为一行，并且项目“位向量”和“行“在本文中可以互换地被使用。

在实践中，对于索引大文档集的搜索引擎，使用一个位向量来表示单个项目是不切实际的。特别地，位向量将包括与大文档集对应的非常大量的位，并且将需要扫描整个位阵列以发现已经被设置的位。对于许多项目来说，位向量将是非常稀疏的(即，只有一小部分位被设置)，因为只有一小部分被索引的文档包含该项目。作为结果，位向量将不会呈现紧凑的解决方案，并且作为结果，需要大量存储装置来存储索引，并且处理搜索查询将花费不可接受的时间量。

为了解决这个稀疏问题，使用在本文中被称为“行共享”的技术，其中将多个项目包括在一个位向量中以增加位向量的位密度(即，针对位向量被设置的位的百分比)。在概念上，这可以通过对每个项目采取一个位向量并创建这些位向量的联合(union)被完成。例如，图2图示出了用于项目A的位向量202、用于项目B的位向量204以及用于项目C的位向量206。包含项目A、B和C的位向量208可以作为位向量202、204和206的联合而被生成。正如可以从图2中所看到的那样，位向量202、204、206中的每一个仅设置有三个位，并且与设置有九个位的位向量208相比是稀疏的。如此，将三个项目组合在一个单个位向量中增加了位密度。代替如在每个位向量202、204和206中那样设置有三个位，位向量208设置有9个位。

在位向量中包含多个项目的一个后果是单个位向量没有提供足够的信息来基于针对文档在位向量中被设置的位来确定该文档包含哪个项目。在其中位向量包括项目A、B和C的图2的示例中，针对文档被设置的一个位指示文档包含A或B或C或者这些项目的某些组合。然而，不能从位向量中的单个位来确定文档包含项目中的哪一个。因此，需要一种机制来确定文档包含哪个项目。

本文所描述的技术的各方面通过将一个项目包括在具有不同项目的多个位向量中来解决了在位向量中具有多个项目而产生的这个问题。这种技术在本文中被称为“项目副本”。图3图示出了项目副本的概念。如图3中所示，三个位向量302、304和306均包括项目A。然而，其他被包括的项目在三个位向量302、304和306之中是不同的。特别地，除项目A之外，位向量302还包括项目B和C，位向量304还包括项目D和E，并且位向量306还包括项目F和G。

可以通过在本文中被称为“行相交”的技术来确定关于哪些文档包含特定项目的标识，其中对包含项目的位向量进行相交。对位向量进行相交移除了噪声(即，基于其他项目的存在而被设置的位)以标识哪些文档包含期望的项目。继续图3的示例，图4A是在三个位向量402、404和406中与其他项目一起被包括的项目A的另一表示。因此，存在具有相关信号(即，项目A的存在)和不相关噪声(其他项目B、C、D、E、F、G的存在)的三个位向量。在图4A的示例中，噪声位用阴影被示出。

一些噪声可以通过将位向量404和位向量406相交被移除。相交的结果是图4B中所示的位向量408，其具有仅在其中针对位向量404和406二者都设置了位的位置中被设置的位。这包括第四、第七、第十一、第十六和第十八位置。将这一位向量408与位向量402相交导致图4C中所示的位向量410，其包括仅在其中针对位向量408和402二者都设置了位的位置中被设置的位。如图4C中所示，位向量410包括针对第四、第十一和第十八位置而被设置的位。这些对应于包含项目A的文档。因此，通过标识包括项目A的位向量并且将那些位向量相交，包含项目A的文档被标识。虽然图4A至图图4C提供了其中只标识了包含特定项目的文档(即，没有误判)的简单示例，但是在实践中，行相交可以被设计以指数级地减少噪声(即误判)，尽管一些误判可能在行相交之后被呈现。

如果大量文档被索引并且位向量中的每个位对应于单个文档，则位向量将是长阵列，并且将位向量相交可能过于耗时。为了解决这个问题，可以使用每位包括多个文档的位向量。在每位具有多个文档的位向量中，如果共享一个位的文档中的一个或多个文档包含针对该位向量的项目之一，则设置该位。

图5图示出了每位具有不同数目的文档的位向量的概念。最初，位向量502图示出了先前讨论的位向量，其中每个位对应于单个文档。其中每位存在一个文档的位向量(诸如位向量502)在本文中被称为“长行”位向量。如图5中所示，位向量502包括对应于32个文档的32位。已经针对第四、第十九、第二十五和第二十七个文档设置了位。

位向量504、506、508在本文中被称为“短行”位向量，因为每个位包括两个或更多个文档，由此提供较短的位阵列。位向量504每位包括两个文档(总共16个位)、位向量506每位包括四个文档(总共八个位)，并且位向量508每位包括八个文档(总共四个位)。图5中所示的位向量504、506、508中的每个位对应于来自位向量502的项目和文档。较短位向量中的每个位对应于来自较长位向量的多个位。例如，对于位向量504(每位2个文档)，第一位(位位置0)对应于位向量502中的位位置0和16，并且第二位(位位置1)对应于位向量502中的位位置1和17，等等。对于位向量506(每位4个文档)，第一位(位位置0)对应于位向量502中的位位置0、8、16和24，并且第二位(位位置1)对应于位向量502中的位位置1、9、17和25，等等。对于位向量508(每位8个文档)，第一位(位位置1)对应于位向量502中的位位置0、4、8、12、16、20、24和28，并且第二位(位位置0)对应于位向量502中的位位置1、5、9、13、17、21、25、29，等等。

位向量504、506、508中的每个位向量中的位被设置，如果在位向量502中设置了对应位中的一个位。以下是用于说明这一点的示例。因为在位向量502中位0和位16未被设置，所以位向量504中的位0未被设置。然而，因为在位向量502中位2和位18中的至少一个被设置(即位18被设置)，所以在位向量504中位2被设置。在位向量506中位3被设置，因为位向量502中的位3、11、19和27中的至少一个被设置(即，位3被设置)。位向量508中的位2被设置，因为位向量502中的位2、6、10、14、18、22、26和30中的至少一个被设置(即，位18和26被设置)。

如本文所使用的，如果位向量具有每位2ⁿ个文档，则短行位向量可以被称为“秩n”(rank-n)位向量。例如，位向量502可以被称为秩0位向量(因为它每位包含2⁰＝1个文档)，位向量504可以被称为秩1位向量(因为它包含每位2¹＝2个文档)，可以将位向量506称为秩2位向量(因为它每位包含2²＝4个文档)，并且位向量508可以被称为作为秩3位向量(因为它每位包含2³＝8个文档)。

现在转到图6，提供了图示出用于使用位向量来生成搜索索引的方法600的流程图。方法600可以至少部分地例如使用图44的索引器4418被执行。如在块602处所示，将项目指派给位向量。如上所讨论的，可以将每个项目指派给多个位向量。附加地，将多个项目指派给位向量中的至少一些位向量；尽管一些位向量可能只有一个被指派的项目。将位向量中的一些位向量建立为长行位向量，其中每个位对应于单个文档，并且将位向量中的一些位向量建立为短行位向量，其中每个位对应于多个文档。

如在块604处所示，将文档指派给位向量中的位位置。在长行位向量中，每个文档对应于位向量中的单个位位置。在短行位向量中，多个文档对应于每个位位置。将文档指派给与长行位向量中指派给该文档的位位置对应的短行位向量中的位位置。应该理解的是，可以使用各种不同方式中的任何方式来定义秩之间的位对应关系。在一些配置中，秩之间的位对应关系基于以下等式：

等式1：秩r的一行中的四字j的位i映射到秩r+1的一行中的四字

的位i。

等式2：秩r的一行中的四字j的位i对应于秩r-1的一行中的四字2j和2j+1中的第i位。

如在块606处所示，基于文档中的项目的存在，在位向量中设置位。对于每个文档，标识包含在文档中的项目，标识对应于每个项目的位向量，并标识和设置指派给那些位向量的每个位向量中的文档的位。在一些情况中，在处理不同的项目和/或文档时可能已经设置了位。

图7图示出了使用位向量的非常简单的搜索索引700的示例。搜索索引700存储16个位向量，每个位向量包括位阵列。位向量包括四个长行位向量702，其中每个位对应于单个文档。正如从图7中可以看出的那样，每个长行位向量702包括32位，从而使得搜索索引700索引针对32个文档的信息。搜索索引700还存储多个短行位向量。特别地，搜索索引700存储四个秩1位向量704(即，每位两个文档)、四个秩2位向量706(即每位四个文档)和四个秩3位向量708(即，每位八个文档)。

每个位向量可以对应于多个项目。附加地，每个项目可以被包括在至少一个长行位向量和至少一个短行位向量中。因此，长行位向量中的每个位表示特定文档是否包含来自对应于位向量的项目集合的至少一个项目。短行位向量中的每个位表示文档集合中的至少一个是否包含来自对应于位向量的项目集合的至少一个项目。正如从图7和上面的讨论中可以理解的那样，每个位向量包括在存储装置中连续的位，以表示哪些文档包含由位向量表示的一个或多个项目。相比之下，指示文档包含哪些项目的针对文档的位被分散在位向量之中，并且因此在存储装置中是不连续的。这种方式支持服务搜索查询，因为与来自查询的项目对应的针对位向量的位在存储装置中是连续的，并且因此可以被快速地取回。

搜索索引中的项目分布

基于搜索索引的期望的设计优化(包括存储需求(例如，可以被存储在每个机器上的文档的数目)和处理速度(例如，每秒可以执行的查询数目))，使用位向量在搜索索引中的项目的分布是可配置的。一般来说，降低存储需求和提高处理速度是所期望的。然而，如下面进一步详细讨论的，对于各种项目分布方面，在存储需求和处理速度中存在折衷。

一个项目分布方面涉及包括在每个位向量中的项目的数目。每位向量更多项目允许每台机器存储更多的文档，由此减少整体存储需求。然而，每位向量更多项目通常增加噪声，从而降低处理速度，因为在执行搜索查询时需要附加处理来移除噪声。

另一项目分布方面是在搜索索引中包括每个项目的副本的数目(即，多少位向量包含关于具体项目的信息)。如果项目被存储在多个位向量中，那么可以稍后移除通过在位向量中包含多个项目而被产生的噪声。然而，增加包括特定项目的位向量的数目会增加存储需求。另外，增加包括特定项目的位向量的数目会降低处理速度，因为必须执行更多的相交。

另一项目分布设计方面是长行位向量(即，每位一个文档)与短行位向量(即，每位多个文档)的混合。较短的位向量提高了处理速度，因为在执行行相交时要扫描的存储器较少。然而，较短的位向量增加了噪声，因为对于给定的设置的位，不知道哪个文档实际上包含项目。长行位向量和短行位向量的混合不影响存储需求。

以下提供根据一个实现方式的针对项目分布的示例性经验法则。根据本示例，如果期望10％的位密度和10:1的信噪比，则相交的数目等于针对项目的逆文档频率(IDF)(除了具有IDF为1的项目，其中信噪比为1.0)。一个项目的IDF可以通过将文档总数除以包含该项目的文档的数目取对数被确定。例如，在每10,000个文档中出现一次的项目的IDF为4。当具有10％的位被设置的位向量相交在一起时，这些位相对靠近在一起——通常/经常在相同的字节中。然而，当这些行中有四行已经相交在一起时，这些位分开得足够远以至于它们分开得比处理器/CPU高速缓存线更远(即，64字节＝512位；尽管这在不同的CPU中可能不同)。作为结果，对于一定数目的相交(例如，在这个示例中是4)，扫描整个位向量并且访问每个位以便执行相交。然而，在完成足够的相交之后，这些位分开得足够远，以至于探测可以被进行到在感兴趣的剩余位向量中的随机位置中(即，不需要扫描所有的高速缓存线，尽管在高速缓存线中探测单个位仍然将会导致从存储器读取整个高速缓存线。某个最小数目的位向量必须全部相交，但是在将该某个数目的位向量相交之后，附加的相交的成本会急剧下降(至每个设置的位一个高速缓存未命中-对比-需要读取整行的高速缓存未命中)。从此中拿走的一个是任意长的相交序列与简单的查询具有大约相同的处理成本。这是因为针对每个查询的成本都是由前N个相交来支配，其中来自位向量的所有位都被访问。在那N个相交之后，相交的附加位向量的数目不会增加太多成本，因为在那些行中几乎不读取高速缓存线。由于需要整体读取位向量和项目的前N个相交可以被存储在长位向量和短位向量的组合中，所以可能针对那前N个相交可能期望使用最短的位向量，因为扫描一个较短的位向量花费较少。因此，搜索索引的设计可以将其中包括项目的短位向量的数目最大化。然而，可以使用至少一个长位向量(即，秩0)位向量来降低单个文档的分辨率。

举例来说明，假设项目“snoqualmie”具有4的IDF(意味着在大约每10,000个文档中出现一次)。IDF为4的1000个项目，如项目“snoqualmie”，可以被组合成单个位向量以获得10％的位密度。为了将误判率提高到10％的信号，将需要5位向量的4次相交来将噪声降低到1/100,000。因此，项目“snoqualmie”可以被存储在5行中。由于短行扫描较快，但至少需要一个长行，因此该项目可能被映射到4个短位向量和一个长位向量。

匹配器算法

当使用基于位向量的搜索索引的搜索引擎接收到搜索查询时，匹配器可以使用位向量来标识包含来自搜索查询的项目的文档的集合。在常见场景中，与被包含在搜索查询中和/或从搜索查询得出的项目对应的位向量被相交以标识匹配文档(联合(union)和否定(negation)也是可能的，但可能不那么常见)。基于搜索查询来开发匹配器计划或查询计划(在本文中被可互换地使用)，以便确定如何标识用于相交的位向量和/或确定执行位向量相交的顺序，如在下面将更详细地描述的那样。随后可以在对匹配文档进行排名的一个或多个后续过程中分析从匹配过程标识的匹配文档。

转到图8，提供了图示出用于匹配器以标识与来自搜索查询的项目匹配的文档的方法800的流程图。方法800可以至少部分地例如使用图44的匹配器4404被执行。最初，如在块802处所示，接收搜索查询。如在块804处所示，从搜索查询标识一个或多个项目。应当理解，在整个说明书中，当从搜索查询标识项目时，项目可以包括被包含在所接收的搜索查询中的确切项目。备选地或附加地，这些项目可以包括从查询扩充标识的其他项目。其他项目可以包括例如针对拼写错误的项目的正确拼写、项目的备选形式和同义词。

如在块806处所示，标识与来自搜索查询的一个或多个项目对应的位向量。可以将每个项目包括在多个位向量中，并且可以标识包含每个项目的每个位向量或者位向量的一部分。如在块808处所示，将位向量相交以标识匹配文档。将与单个项目相关联的位向量相交以标识与该项目匹配的文档。使用如由查询所指定相交、联合和否定的组合来对与不同项目相关联的位向量进行组合。

在一些情况中，可以通过将所有标识的位向量相交来标识匹配文档。在其他情况中，可以通过将标识的位向量的不同子集相交来标识匹配文档。这取决于查询如何由匹配器制定。例如，如果查询只包含“和”运算符，则将所有的位向量相交。作为一个具体示例，假设执行查询来标识包含“大”(large)和“集”(collection)的文档。在这种情况中，包含项目“大”的位向量将与包含项目“集”的位向量相交。与在这些位向量中的每个位向量中被设置的位对应的文档被确定为匹配文档。如果执行包含“或”运算符的查询，则可以通过将不同的位向量子集相交来标识匹配文档。例如，假设执行查询以标识与“集”相关的包含“大”或“更大”(larger)的文档。可以从包含项目“大”的位向量与包含项目“集”的位向量的相交以及从包含项目“更大”的位向量与包含项目“集”的位向量的相交二者标识匹配文档。

在一些配置中，在图8的块808处，针对搜索查询而被标识的位向量可以按照任何顺序被相交。然而，在其他配置中，可以配置位向量相交的顺序以提供更高效的处理。如先前所讨论的，针对每个项目的位向量可以包括短行位向量和长行位向量二者。另外，如以上所讨论的，对于初始相交，处理相交的位向量中的每个位。然而，在一定数目的相交之后，当执行附加的相交时，不需要扫描整个位向量。作为替代，例如可以通过探测位向量中的随机位置来执行那些附加的相交。因此，一些配置可以通过最初将短行进行相交来提高相交过程的效率。图9提供了示出用于首先使用短位向量来将位向量进行相交的方法900的流程图。方法900可以至少部分地例如使用图44的匹配器4404被执行。如在块902处所示，从要被相交的位向量集合标识短行位向量。如在块904处所示，在将任何长行位向量相交之前将短行位向量的至少一部分相交。在一些配置中，在将长行位向量相交之前将所有短行位向量相交。在其他配置中，可以在一些短行位向量之前处理一些长行位向量。当随后执行需要处理每个位的相交时，短行位向量和长行位向量可以按照任何顺序被相交。预期任何和所有这样的变型都在本文所描述的技术的各方面的范围内。

举例来说明首先将短行位向量相交的处理，假设针对项目“大”、“强子”和“对撞机”执行查询。如图10中所示，项目“大”具有1.16的IDF并且被包括在两个短行位向量1002、1004和一个长行位向量1006中。项目“强子”具有3.71的IDF并且被包括在四个短行位向量1008、1010、1012、1014和一个长行位向量1016中。项目“对撞机”具有3.57的IDF并且被包括在四个短行位向量1018、1020、1022、1024和一个长行位向量1026中。

如图11中所示，匹配器可以在逻辑上布置位向量以用于首先与短位向量相交，然后再是长位向量。在图11的示例中，来自三个项目的短行位向量已经被交替。然而，应该理解，短行位向量可以按照任何方式被排序。例如，可以首先布置针对项目“大”的短行位向量，接着是针对项目“强子”的短行位向量，随后是针对项目“对撞机”的短行位向量。

在图11中所示的示例中，匹配器将短行位向量中的每个短行位向量相交，然后将结果与长行位向量相交。当将相同长度的位向量相交时，来自第一位向量的位与第二位向量中的对应位相交(例如，第一位被相交，第二位被相交，第三位被相交等)。例如，这些相交可以由CPU一次执行64位。然而，当将不同长度的位向量相交时，来自较短位向量的位对应于较长位向量中的多个位。例如，当将每位具有四个文档的短行位向量与每位具有一个文档的长行位向量相交时，来自短行位向量的位与长行位向量中的四个对应位中的每个位分离地相交。

如之前所指出的，可以处理要求将不同的位向量子集相交的一些查询。例如，假设搜索查询“大强子对撞机”被扩充以形成查询“(大或更大)和强子和(对撞机或对撞)”。这个查询将涉及位向量相交的以下组合：(1)大和强子和对撞机；(2)大和强子和对撞；(3)更大和强子和对撞机；(4)更大和强子和对撞。当执行这样的查询时，可以对位向量相交进行排序，从而使得首先执行对多个位向量相交组合公共的相交，并且这些公共相交的结果被保存，因此可以对它们进行重用。

图12图示出了对位向量相交进行排序的概念，从而使得首先执行对于多个位向量组合共同的相交，并且对结果进行重用。如图12中所示，对搜索查询“大强子对撞机”1202进行处理以形成查询“(大或更大)和强子和(对撞机或者对撞)”1204。在本示例中，每个项目包括两个短行和一个长行。如此，扩充查询1204可以用表达式1206中所示的针对每个项目的位向量表示，其中：“A”和“a”对应于项目“大”；“B”和“b”对应于项目“更大”；“C”和“c”对应于项目“强子”；“D”和“d”对应于项目“对撞机”；霸气“E”“e”对应于项目“对撞”。短行位向量由小写表示，并且长行位向量由大写表示。例如，a₁和a₂对应于针对项目“大”的两个短行位向量，并且A₁对应于针对项目“大”的长行位向量。

表达式1206可以通过将短行位向量和对组合而言共同的项目的位向量拉到左边来形成表达式1208。例如，项目“强子”(由表达式1208中的“c”表示)被包括在所有组合中，而项目“大”和“跟大”(由表达式1208中的“a”和“b”表示)各自被包含在两个组合中。注意，项目“对撞机”和“对撞”(由表达式1208中的“d”和“e”表示)各自也被包括在两个组合中，从而使得在备选公式中，表达式1208中的“a”和“b”的位置可以被与“c”和“d”交换，反之亦然。

表达式1208可以使用树1210被表示，树1210也可以如图13中的树1300所示，其中每个块对应于一个位向量。如树1300中那样表示表达式1208图示出了执行相交的顺序。如图14中所示，最初将针对项目“强子”(c₁和c₂)的两个短行位向量相交，并且可以保存结果。这允许来自该相交的结果被重用，正如将在下面被讨论的。结果被进一步与针对项目“大”(a₁和a₂)的两个短行位向量相交，并且可以保存结果。这允许来自这四个位向量的相交的结果被重用，正如将在下面被讨论的。这些结果进一步与针对项目“对撞机”(d₁和d₂)的短行位向量以及这三个项目(A₃、C₃和D₃)中的每个项目的长行位向量相交。从这些相交发现与“大”、“强子”和“对撞机”匹配的文档的集合。

如图15中所示，如以上参考图14所讨论的那样生成的针对项目“强子”和“大”(c₁、c₂、a₁和a₂)的短行位向量的相交的结果可以被重用并与针对项目“对撞”(e₁和e₂)的短行位向量以及针对三个项目(A₃、C₃和E₃)的长行位向量相交。从这些相交发现与“大”、“强子”和“对撞机”匹配的文档的集合。

如图16中所示，如以上参考图14所讨论的那样生成的针对项目“强子”(c₁和c₂)的短行位向量的相交的结果可以被重用并且与针对项目“更大”(b₁和b₂)的短行位向量相交，并且可以保存结果，从而使得可以对它们进行重用，正如将在下面讨论的。这些结果可以进一步与针对项目“对撞机”(d₁和d₂)的短行位向量和针对三个项目(B₃、C₃和D₃)的长行位向量相交。从这些相交发现与“更大”、“强子”和“对撞机”匹配的文档的集合。

如图17中所示，如以上参考图16所讨论的那样生成的针对项目“强子”和“更大”(c₁、c₂、b₁和b₂)的短行位向量的相交的结果可以被重用，并与针对项目“对撞”(e₁和e₂)的短行位向量以及针对三个项目(B₃、C₃和E₃)的长行位向量相交。从这些相交发现与项目“更大”，“强子”和“对撞”匹配的文档的集合。

图18提供了图示出用于诸如图44的匹配器4404之类的匹配器生成匹配器计划的方法1800的流程图，匹配器计划提供用于对位向量进行相交的高效顺序。最初，如在块1802处所示，接收搜索查询。如在块1804处所示，从搜索查询标识项目。

如在块1806处所示，标识与来自搜索查询的一个或多个项目对应的可用位向量。可以将每个项目包括在多个位向量中，并且可以标识每个位向量或者包含每个项目的位向量的子集。例如，这可能涉及标识针对每个项目有多少个短位向量可用、每个短位向量的长度以及针对每个项目有多少个长位向量可用。

在块1808处生成匹配器计划，以提供用于将针对项目中的每个项目的位向量进行相交的顺序。如上所述，可以生成匹配器计划的顺序以提供高效的匹配。例如，短位向量可以在长位向量之前被相交。作为另一示例，可以对位向量相交进行排序，首先执行对多个位向量相交组合共同的相交，并保存相交的结果，因此它们可以被重用。在块1810处将位向量相交以标识匹配文档。

将查询计划编译为机器代码

针对给定的搜索查询被生成的匹配器计划(或查询计划)可以提供具有诸如“和”、“或”以及“非”运算的各种运算的节点树，并标识要相交的位向量。运行这样的匹配器计划可能涉及将所有那些运算应用于被标识的位向量。处理匹配器计划的一种方式可以是对树进行解释，意味着树将被遍历并且每个节点都被评估。然而，对树进行遍历并评估每个节点会有显著的开销。考虑一个对树进行解释的假设示例。在这样的示例中，将存在着与当每个节点被访问时确定每个节点的类型相关联的一些成本，这是理解如何评估节点所必须的步骤。还将存在着与存储和枚举与每个节点相关联的子代集合相关联的一些成本。那些动作中的每个动作都要花时间来处理并且产生开销。

为了对位向量进行相交而在节点处进行的实际工作的成本相对较小。例如，该工作可以只包括两个指令——将值“加”到累加器中并分支以在累加器为零时终止评估。确定节点类型以及确定针对节点而存在的子代节点的数目的成本实际上高于位向量相交的成本。因此，这呈现出了解释的开销大于实际工作(即，将位向量进行相交)的情况。此外，为了处理匹配器计划，可以多次(例如，数千次甚至数百万次)对树进行评估，从而使得在处理期间可以重复分析每个节点，从而产生附加的开销。

为了解决这个问题，可以将匹配器计划编译成机器语言。特别地，可以使用JIT(即时)编译器来处理匹配器计划以生成机器代码。例如，在使用基于x64的处理器(例如，XEON处理器)的搜索系统中，JIT编译器可以将匹配器计划编译为x64代码。JIT编译器在从用户接收到搜索查询的时刻完成。在这样的配置中执行查询的过程可以包括接收搜索查询、基于搜索查询来生成匹配器计划、以及将匹配器计划转换成机器代码。

当对匹配器计划进行JIT编译时，这个过程可以包括与解释器的方式相类似地在匹配器计划上走过。尽管根本的区别在于：JIT编译器只检查每个节点一次，因为它输出了在它在树上走过时过程将输出的代码。然后可以重复运行该代码(例如，数千次甚至数百万次)并且运行代码没有由解释器使用的评估方法的开销。

处理器具有对其可用的各种资源(例如，处理器和存储器之间的总线、在处理器内的保持从存储器带入的数据的固定尺寸的高速缓存、可以完成一定工作量的具有一定数目晶体管的一定数目的处理器核心，等等)。通常，对于任何给定程序，速度被其中一个资源的限制。它被其中一个资源限制的原因是：一旦它被该资源限制，它就没有足够快到被下一个最宝贵的资源的限制。不同的程序被不同的东西所限制。大索引搜索的基本限制是访问大量数据。通常情况下，当今存在的处理器的基本限制是数据可以通过存储器总线移动通过处理器的速度有多快。对于发布列表，算法的复杂性导致CPU在存储器总线之前变得饱和。本文所描述的技术的一些方面的价值在于代码足够简单，从而使得CPU能够处理数据的速度比存储器总线能够提供数据的速度快，并且因此，存储器总线可以是饱和的。

因此，在本文所描述的技术的一些方面中，一个设计目标可以是使存储器总线饱和，这意味着存在一定量的信息以带入到算法中，并且目标是使系统被信息量以及存储器总线将信息带入处理器的能力限制。这个设计目标将避免受到处理器指令开销的限制。换言之，目标是让处理器在存储器中等待，而不是相反。尽管处理器的内核越来越多，但是由于存储器总线变得越来越快越来越宽，所以存储器总线仍然很难保持饱和。结果，每个存储器总线访问之间的指令数目可以被限制为少至两条或三条指令，以便使存储器总线饱和。对匹配器计划进行JIT编译提供了限制指令的数目以帮助实现这个目标的机器代码。

应该指出，使用JIT编译来帮助实现使存储器总线饱和的设计目标在使用某些现有处理器(诸如XEON x64处理器)的系统中可能是有用的。然而，可以使用其他硬件设计，诸如现场可编程门阵列。由于其他硬件设计的成本结构可能不同，所以JIT编译可能对这些设计没有那么有用。

查询IDF提升

如前所讨论的，搜索系统通常使用标识包含查询项目的文档(即，“匹配文档”)的匹配器，其后跟着的是对匹配文档中的至少一些匹配文档进行排名的排名器。影响由这种搜索系统执行搜索的运行时间的变量之一是由匹配器返回的匹配文档的数目。如果返回大量匹配文档，则可能花费不可接受的时间量来对这些文档进行排名。

因此，针对给定查询的搜索系统的性能可以被视为针对查询可以被匹配器返回的匹配文档的数目的函数。对此进行查看的一种方法是通过参考查询的IDF。查询的IDF可以通过将被索引的文档的总数除以针对查询的匹配文档的数目取对数被确定。例如，具有IDF为4的查询将从语料库中的每10,000个文档中返回一个匹配文档。对于给定的搜索查询，查询的IDF表示来自文档的语料库的可能匹配文档的数目。

根据本文所描述的技术的各方面而使用具有位向量的搜索索引的搜索系统可以良好地执行导致可接受数目或百分比的匹配文档的搜索查询。基于搜索系统的设计优化，可以配置被认为是可接受数目或百分比的匹配文档。在一些配置中，这对应于具有大约4或更大的IDF的查询(即，10,000个或更少文档中的1个匹配查询)。对于这样的搜索查询，进行排名可能是足够便宜的以至于匹配器可以在无需对匹配过程进行任何修改的情况下处理搜索查询并返回匹配文档。

对于将返回不可接受数目或百分比的匹配文档的搜索查询(例如，具有小于4的IDF的查询)，一些配置使用各种技术来减少匹配文档的数目。这些技术在本文中被称为“查询IDF提升”，因为针对搜索查询的匹配文档的减少导致针对查询的更高IDF。可以被一些配置使用以减少针对搜索查询的匹配文档的数目的一般技术是在针对搜索查询的匹配过程期间将一个或多个附加位向量相交。这些附加位向量在本文中被称为“加强行”位向量，因为附加位向量通过减少匹配文档的数目(即，提升查询的IDF)来加强匹配过程。

在本文所描述的技术的一些方面中，加强行位向量可以基于文档的静态排名。如本领域中所知的，静态排名是指与搜索查询无关的文档排名特征。例如，经常由搜索引擎使用的一个静态排名特征是基于包含去往文档的超链接的其他文档的数目来对文档排名。去往该文档的链接越多，则可以被视为指示更高的重要性，并且因此指示更高的排名。由于文档的静态排名与查询无关，因此它们可以在添加关于文档的信息时在索引生成的时刻被确定。

为了支持查询IDF提升，可以向搜索索引添加位向量以标识文档语料库中具有最高静态排名的文档。这一静态排名位向量可以通过确定语料库中的文档的静态排名被生成。基于静态排名，可以标识具有最高静态排名的特定数目或百分比的文档。例如，可以标识前10％的静态排名文档或具有高于所选择的静态排名分数阈值的静态排名分数的文档。生成位向量，其中为最高静态排名文档中的每个最高静态排名文档(例如，前10％的静态排名文档)设置位，而对于其他文档(例如剩余的90％的文档)，让位被清除。如此，当执行搜索查询时，如果匹配器确定将返回不可接受数目的匹配文档，则匹配器也可以与静态排名位向量相交。由于仅针对静态排名位向量中的最高静态排名文档设置位，所以与该位向量相交将导致只有来自最高静态排名文档中的与搜索查询中的项目匹配的文档作为匹配文档而被返回。实质上，使用静态排名位向量将可能的文档的池限制为最高静态排名文档。

另一查询IDF提升方法是使用针对非主体信息的加强行。一般而言，针对文档的项目可以在各种不同的位置中被标识。可以从文档的主体标识项目，但也可以从其他非主体位置标识项目。例如，针对文档的非主体位置可以包含锚文本(即，链接到文档的另一文档内的超链接的文本)、文档的URL、文档的标题(即，在浏览器的标题栏中被呈现的字)以及搜索信息，诸如导致用户从搜索结果选择文档的搜索查询的项目以及被包括在文档的摘录(即摘要/概要)中的项目。

非主体信息通常被视为提供比主体信息更好的相关性的指示器。因此，将匹配器仅限于非主体信息减少了结果集合，同时产生的文档更可能更相关。根据本文所描述的技术的一些方面，可以在位向量中对非主体信息进行索引。这可以通过标识出现在非主体位置中的项目以及用将项目标识为非主体项目(即，出现在非主体位置的项目)的信息来对那些项目进行索引而被完成。作为结果，位向量索引信息不仅标识通常的项目(即，来自主体和非主体位置的项目)，而且也标识非主体项目(即，仅仅在非主体位置中的项目)。一般项目和非主体项目可以分布遍及整个搜索索引。例如，特定位向量可以包括一般项目和非主体项目。

根据本文所描述的技术的一些方面，当执行搜索查询时，匹配器最初相交针对与来自查询的项目对应的一般项目(即，来自主体位置和非主体位置的项目)的位向量，以估计将被返回的匹配文档。如果匹配器估计将返回不可接受数目的匹配文档，则匹配器标识并相交针对与来自查询的项目对应的非主体项目的位向量。实质上，这将匹配文档限制为包含非主体位置中的查询项目的文档。

参见图19，提供了图示出用于使用加强行来对文档进行匹配的方法1900的流程图。方法1900可以至少部分地例如使用图44的匹配器4404被执行。如在块1902处所示，接收搜索查询。如在块1904处所示，基于搜索查询来确定一个或多个项目。一个或多个项目可以包括在搜索查询中被明确阐述的项目和/或基于搜索查询中的项目被确定的项目(例如，拼写错误、备选形式、同义词等)。

在块1906处做出关于匹配器针对搜索查询是否很可能返回不可接受数目的匹配文档的确定。该确定可以基于根据本文所描述的技术的不同方面的方法的任何组合。在一些配置中，确定基于来自搜索查询的项目的IDF。在一些配置中，确定基于采样。举例来说明，可以通过标识在块1904处被标识的针对项目的位向量并且对那些位向量进行相交来开始匹配过程从而做出确定。此时，标识和相交的位向量可以包括具有与在块1904处标识的项目对应的一般项目(即，来自主体位置和非主体位置的项目)的位向量。在匹配过程期间，可以基于作为匹配而被返回的文档的百分比来估计可能返回的匹配文档的数目。这可能涉及在索引的一部分上运行整个计划，并且然后使用观察到的匹配比率来预测如果在整个索引上运行的情况下将会返回的匹配总数。

如果在块1908处确定很可能返回可接受数目的匹配文档，则可以在不使用任何加强行位向量来减少匹配文档的数目的情况中执行匹配过程，如在块1910处所示的。备选地，如果在块1908处确定可能返回不可接受数目的匹配文档，则可以在块1912处选择一个或多个加强行位向量，并且如在块1914处所示对其进行相交以减少匹配文档的数目。

可以选择任何数目和类型的加强行位向量以及对其进行相交。例如，可以选择静态排名位向量并对其进行相交，以将可能的匹配文档限制为最高静态排名文档。作为另一示例，具有与在块1904处标识的项目对应的非主体项目的位向量可以被相交，以将可能的匹配文档限制为包含非主体位置中的项目的文档。这可以针对在块1904处标识的所有项目或仅仅针对项目的子集被完成。应该理解，在匹配过程期间可以选择其他类型的加强行位向量并对其相交，以减少匹配文档的数目。

在本文所描述的技术的一些方面中，可以基于估计的匹配文档的数目来选择要相交的加强行位向量的数目和/或类型。而且，与搜索查询中的其他项目相比，不同的项目可以具有更多或更少的加强行。不同的加强行方式可以在匹配文档中提供不同的减少。对于将很可能导致较高数目的匹配文档的查询，可以选择提供匹配文档的较大减少的加强行。例如，基于估计的匹配文档的数目，可以选择静态排名位向量、具有非主体项目的一个或多个位向量、或者静态排名位向量和具有非主体项目的一个或多个位向量二者，并对其进行相交。

尽管图19的方法1900仅示出了关于匹配文档的数目是否很可能是不可接受的单个确定，但是随着匹配过程继续，可以重复地做出确定。例如，初始确定可以指示很可能返回可接受数目。然而，在进一步匹配之后，可能确定现在很可能是不可接受的，并且可以基于该重新确定来选择加强行。

一些搜索查询可能具有如此低的IDF(即，返回特别大量的匹配文档)，以至于加强行方法可能不足以限制匹配文档的数目。对于这样的搜索查询，搜索引擎可以高速缓存针对这些搜索查询的搜索结果。因此，当接收到被高速缓存的搜索查询时，高速缓存的搜索结果将被简单地取回。

因此，在匹配过程期间可以使用各种不同的技术来控制返回的匹配文档的数目。可以基于针对给定搜索查询而被确定的匹配文档的估计数目来选择技术。仅作为示例而非限制，一个特定配置针对基于不同范围的IDF的搜索查询而使用不同的技术。在这一示例配置中，对于IDF小于2的搜索查询，使用高速缓存的结果。对于IDF在2和3之间的搜索查询，对静态行位向量和具有非主体项目的一个或多个位向量进行相交。对于IDF在3到4之间的搜索查询，对具有非主体项目的位向量进行相交。最后，对于IDF大于4的搜索查询，在不添加任何加强行位向量以减少匹配文档的数目的情况下执行匹配过程。

搜索索引中的短语

一些搜索查询包括具体短语。短语是用于搜索引擎的重要概念，因为在文档的不同位置具有项目集的文档可能与包含该短语的文档不相关。例如，考虑短语：“The The”(一支乐队)和“是生存还是死亡”(to be or not to be)。虽然这些短语中包括的项目是常见的，但短语本身相当罕见。

一般来说，如果允许标识文档中的短语的信息未被索引，那么匹配器可以标识不是包含短语而是包含短语的项目的文档。如果排名器也不考虑短语，那么没有短语的文档可能会比包含该短语的其他文档排名更高，尽管从用户的角度看，包含该短语的文档可能被认为是更好的结果。另外，如果对最大数目没有限制，那么由匹配器发送给排名器的文档的数目可能会很大，从而导致对所有文档进行排名的时间量不可接受。备选地，如果对发送给排名器的文档数目设置限制，则匹配器可以选择包含位于不同位置的项目的文档，同时排除包含短语的文档。

发布列表系统具有用来使用位置发布列表的选项，所述位置发布列表存储不仅关于文档中的项目的存在而且关于该项目在文档中的位置的信息。因此，可以通过使用位置信息来标识短语以确定字是相邻的并因此形成了短语。然而，需要大量的存储装置来存储位置信息，并且整理项目的位置以便发现短语是CPU密集型的。

由本文所描述的技术的各方面使用的位向量方法不在索引中存储位置信息，并且因此不能使用与位置发布列表系统中相同的方法来标识短语。作为结果，本文所描述的技术的各个方面可以作为替代将短语存储在位向量中，以允许标识包含搜索查询中所阐述的短语的文档。如在本文中所使用的，短语是指两个或更多个字的任何组合，诸如n元语法(n-gram)、n元组、k附近n元组等等。n元语法是n个连续或几乎连续的项目的序列。如果一个n元语法对应于一连串的连续项目，则它就被称为是“紧密的”，并且如果它以项目在文档中出现的顺序包含了项目(但这些项目不一定是连续的)，则它就被称为是“松散的”。松散n元语法通常被用来代表一类等同短语，这类等同短语由于不重要的字而有所不同(例如，“如果下雨，我会淋湿”(if it rains I'll get wet)和“如果下雨，那么我会淋湿”(if it rainsthenI'll get wet))。如在本文中所使用的，n元组是在文档中共同出现(顺序无关)的“n”个项目的集合。此外，如在本文中所使用的，k附近n元组是指在文档中的“k”个项目的窗口内共同出现的“n”个项目的集合。

可以与上面针对项目的讨论类似地将短语存储在位向量中。作为结果，索引中的每个位向量可以存储项目和短语的任何组合。短语和项目之间的区别在于：短语不需要被存储在像针对项目那样多的位向量中。作为替代，例如可以将短语存储在单个短行位向量中。由于短语包含与短语中的项目显著重叠的信息，因此将针对项目的位向量与针对短语的位向量相交可以允许标识包含该短语的文档。这基于上面参考查询IDF提升所讨论的加强行位向量的概念。对于短语来说，较弱的查询将简单地对针对个体项目的位向量进行相交。然而，查询可以通过也对针对短语的一个或多个位向量进行相交被加强。这使得使用位向量将短语存储在搜索索引中是便宜的，并且提供优于诸如位置发布列表之类的其他方式的优点，这些其他方式需要显著大量的存储装置以用于短语。

图20A提供了用于图示出使用包含短语的位向量作为加强行位向量的概念的示例。本示例图示出了对短语“简单街道”(easy street)的查询。项目“简单”和“街道”都很常见，IDF分别为1.27和1.14。由于项目是常见的，所以它们不需要许多位向量来对针对项目的信息编码。在本示例中，其中针对项目的位向量的数目被IDF四舍五入的这样一个经验法则已被使用，从而使得项目“容易”和“街道”各自被包括在两个位向量中。另外，将每个项目包括在一个短行位向量和一个长行位向量中。

短语“简单街道”较不常见，IDF为4.07。如果使用相同的经验法则，则该短语将被包括在由四个短行位向量和一个长行位向量组成的五个位向量中。如果针对短语使用该多个位向量，则针对短语将需要相当大量的存储装置。然而，针对“简单街道”的位向量与针对“简单”的位向量和针对“街道”的位向量有很多共性。

如图20B中所示，如果针对“简单街道”执行查询，则使用针对“简单”和“街道”的位向量，因为至少与查询匹配的文档必须包含那些项目。正如从图20B中可以看出的那样，来自那些项目的位向量提供了四个位向量的相交，这足以移除噪声。作为结果，不需要针对“简单街道”的五个位向量来标识匹配文档。作为替代，只使用两个位向量来标识包含短语“简单街道”的匹配文档。因此，搜索索引不需要存储针对短语“简单街道”的三个位向量2006、2008、2010。作为替代，搜索索引只存储两个短行位向量2002、2004。

搜索索引中的分片

由搜索引擎索引的文档通常在长度上差异很大，其中文档的长度通过文档中的独特字的数目被测量。在一个范畴的一端上，一个文档可以只包含一个字；而在该范畴的另一端上，文档(例如，字典)几乎可以包含所有的字。在使用位向量来对文档进行索引的上下文中，短文档具有跨位向量被设置的小百分比位，而长文档具有设置的大百分比位。针对位向量产生的一个问题是在处理充分变化长度的文档时失去效率。只能针对一个长度达到所期望的位密度。文档长度中太大的方差导致位密度在某些地方过高而在其他地方过低。

举例来说，图21图示出了搜索索引的一部分，其仅示出了长行位向量(即，每位一个文档)。突出显示的列2102对应于长文档。正如图21中可以看出的那样，几乎所有位都是基于在文档中出现的加下划线的项目的存在被设置的。虽然大多数位是针对长文档被设置的，但是有许多项目(即图21中的非下划线的项目)在文档中不存在。作为结果，包括不在文档中的项目(即，图21中的非下划线的项目)但是与文档中的项目共享位向量的搜索查询将与长文档匹配，即使该长文档不是针对该项目的真正匹配。正如可以被理解的，误判的可能性随着产生大于目标位密度的文档而增加。

一些配置通过将索引打断/划分成搜索索引的不同部分或“分片”来解决这个变化文档长度的问题。每个分片对具有与不同文档长度范围对应的长度的文档进行索引。例如，可以将具有0-100个项目的文档指派给第一分片，将具有101-200个项目的文档指派给第二分片，将具有201-300个项目的文档指派给第三分片等等。

通过提供不同的分片，每个分片内的文档都在一个文档长度范围内，从而防止由文档长度中的大的差异所产生的效率低下。每个分片可以具有到位向量的不同项目指派，以控制每列中的位密度(即，在每列中被设置位的百分比)。在具有较长文档的分片上，可以在位向量中共享较少的项目以控制列位密度。换言之，较长的分片可以每位向量具有较少的项目。相反，对于具有较短文档的分片，可以在位向量中共享较多的项目(即，每位向量具有较高的项目)。

图22图示出了用于使用位向量来生成针对搜索索引的分片的方法2200。方法2200可以至少部分地例如使用图44的索引器4418被执行。如在块2202处所示，确定要使用的分片的数目。另外，如在块2204处所示，为每个分片确定文档长度的范围。尽管在图22中将分片的数目和针对每个分片的文档长度的范围的确定示出为分离的块，但是应该理解，这些设计参数可以在一个单一过程中被确定。如在块2206处所示，基于文档长度范围，根据文档的长度将文档指派给每个分片。如在块2208处所示，通过在计算机存储介质上存储针对每个分片的位向量来生成搜索索引。每个分片存储位向量，这些位向量对具有针对每个分片的文档长度范围内的文档长度的文档的项目进行索引。

在一些配置中，对要使用的分片的数目和每个分片的文档长度范围的确定可以基于两个考虑。第一个考虑是每个分片都有固定的开销，因为每个查询需要在每个分片上被执行。因此，不希望有太多的分片。

第二个考虑是由于具有变化长度的文档而被浪费的与存储量相关联的成本。特别地，给定所期望的列位密度(例如，10％)，如果分片中的最长文档产生期望的列位密度(即，10％)，则较短的文档将具有较低的列位密度。列位密度低于期望的列位密度的任何文档代表被浪费的存储装置。分片中文档长度的变化越大，浪费的存储量就越大。

成本函数可以作为上述两个考虑的函数被生成。特别地，将成本函数计算为将分片的数目乘以一些加权因子加上基于每个分片中的变化文档长度所引起的浪费的存储装置的成本。基于针对附加分片所需的处理成本(即，速度成本)相对于从分片中的文档长度中具有较大变化而来的浪费的存储装置的成本(即，存储装置成本)的相对重要性，应用于分片数目的加权可以可配置。例如，作为基于所消耗的总存储器(最长长度·文档数目)或者更特别地使用以下等式的近似值，可以计算出被浪费的存储装置的成本：

等式3：最长长度·文档数目-Σ文档长度

可以将求解成本函数视为优化问题。因此，可以使用各种不同的算法来求解成本函数，以优化分片数目和针对每个分片的文档长度的范围。在一些配置中，将成本函数作为所有配对最短路径问题来求解。

当接收到搜索时，可以在分片中的每个分片上执行查询。每个分片上的查询返回文档集合，将这些文档进行组合以提供匹配文档集合。

在一些配置中，可以共享对针对每个分片的查询进行准备的一些工作。通常，对于分片中的每个分片，将针对相同项目的位向量进行相交。分片之间的主要区别是项目到位向量的映射。例如，一个分片中的项目可以被包括在三个位向量中。对于另一个分片，该项目可以被包括在与第一分片中的位向量完全不同的七个位向量中。由于用于查询不同分片的主要区别是项目到位向量的映射，所以在将项目转换为实际位向量之前，可以在分片上重用查询的结构和查询处理。

图23图示出了用于使用多个分片来执行搜索的方法2300。方法2300可以至少部分地例如使用图44的匹配器4404被执行。如在块2302处所示，接收搜索查询。如在块2304处所示，针对搜索查询标识一个或多个项目。一个或多个项目可以包括在搜索查询中被明确阐述的项目和/或基于搜索查询中的项目被确定的项目(例如，拼写错误、备选形式、同义词等)。

如在块2306处所示，基于所标识的项目生成一般查询计划。一般查询计划可以一般性地阐述用于对包含来自搜索查询的项目的位向量进行相交的过程。如在块2308处所示，将一般查询计划转换为针对每个分片的分片特定的查询计划。如在块2310处所示，然后在每个对应的分片上执行每个分片特定的查询计划以标识针对搜索查询的匹配文档。

将一般查询计划转换为每个分片特定的查询计划在每个分片上的大部分阶段都是相似的。通常，在对查询进行解析之后，标识项目集合，并且将这些项目映射到针对每个分片的位向量集合。分片之间的主要差别在于从项目到位向量的映射是不同的。例如，一个分片中的项目可以在三个位向量(例如，第7、10和15行)中。在另一分片中，该项目可以出现在10个位向量中，其可能是与第一个分片完全不同的行。将项目转换为行之前的所有内容可以在所有分片上被重用。即使从项目到行的映射在分片之间是不同的，查询的结构也可能保持相同。换言之，对于每个项目来说，都存在短行和长行的集合，并且将短行拉到左边以及将长行拉到右边的方式在分片上是相同的尽管行的数目和行的标识符不同。

在一些配置中，一般查询计划可以包括针对每个项目的最大数目的短行和针对每个项目的最大数目的长行。计划器最初可以在项目和行之间没有特定映射的情况下运行(行本质上是虚拟行，没有映射到索引中的物理行)。针对特定分片的计划可以通过将每个虚拟行替换为特定于该分片的物理行被生成。在每个不同的分片上，将使用不同的物理行集合。当一般查询计划具有最大数目的短行和长行时，并非所有分片都可以使用所有这些虚拟行(即，计划行)。为了解决这个问题，由于将虚拟行替换为物理行，所以将未使用的虚拟行替换为可以被用作填充行且不影响查询的布尔表达式的语义的物理行。例如，具有已经被包括的一个或多个物理行的全部或者复制品的物理行可以用于那些额外的行。

所以可以很快地为每个分片定制一般查询计划。在一些配置中，匹配引擎得到两个输入：运行的已经被编译的代码和指向它应该针对给定分片使用的所有行的指针的表格。因此，为每个分片“定制”一般计划可以简单地涉及为每个分片提供不同的行表(即，针对每个分片使用相同的代码)。通过这种方式，对于分片而言，一直到匹配器的整个查询流水线可以是通用的，其中分片之间的区别被表达为具有指向行的指针的表格。因此，许多计划工作被重用。

对针对分片的查询计划进行重用的上述方式的一个成本是：一般查询计划可能参考比一些分片实际所需要的更多的行，因为一般查询计划旨在容纳分片可能需要的最大行数，这意味着对于一些分片来说，存在一些浪费工作来对都是1或者是以前使用的行的复制品的占位符或填充行进行相交。然而，这可能出于多种原因而是可接受的。匹配器的成本主要是扫描前几个(例如，四个)行，从而使得附加的行扫描/相交不增加显著的成本。附加地，如果该方式简单地重用上次使用的行，则对该行进行相交的成本很小，因为该行已经处在处理器高速缓存中。

条带表

每个项目在文档语料库中出现的频率可能差别很大。有些项目是非常普遍的，而其他项目是非常罕见的，甚至于在文档语料库中出现过一次。如前所讨论，给定项目将噪声减少到可接受水平所需的位向量相交的数目随着项目频率而变化。通常，常见项目(即，文档语料库中具有高频率的项目)需要较少的位向量相交，而罕见项目(即，文档语料库中具有低频率的项目)需要更多的位向量相交。

当构建位向量搜索索引时，根据本文所描述的技术的各个方面，可以采取多种不同的方法以用于确定针对项目的位向量配置。如本文所使用的，针对项目的“位向量配置”阐述了用于该项目的位向量的数目和长度。位向量配置还可以标识在该配置中在其上存储每个位向量的存储装置的类别(例如，RAM、SSD和/或HDD)。

可以被使用的一种方式是“一刀切”的方法，其中所有的项目具有相同的位向量配置。然而，这种方式有一些缺点。特别地，如果“一刀切”位向量配置指定较高数目的位向量以虑及低频项目，则由于对于较高频率项目而言不需要较高数目的位向量，所以浪费了存储装置。例如，假设索引中最罕见的项目需要10位向量来充分降低针对该项目的噪声，并且因此针对索引中的每个项目使用10位向量。如果针对更常见项目所需的位向量的数目要小得多，那么对这些常见项目中的每个项目使用10位向量浪费了存储装置。

备选地，如果“一刀切”位向量配置指定较少数目的位向量，则较低频率项目可能不具有足够数目的位向量以充分降低噪声。例如，假设最常见的项目只需要两位向量。对于较不常见的项目，只使用两个位向量将不足以降低噪声，并且针对这些项目将存在不可接受的误判数目。

另一方式是针对每个项目使用自定义位向量配置。换言之，在向每个项目指派位向量配置时各个地对待每个项目。虽然这是可能的并且可以在本文所描述的技术的一些方面中被使用，特别是当用较少的相区分项目对小文档语料库进行索引时，但是对于具有大量相区分项目的非常大量的文档集来说可能是不实际的。例如，当处理非常大量的项目时，将每个项目映射到自定义位向量配置所需的数据结构将是巨大的。

又一方式是基于项目特性来将位向量配置指派到被聚类到不同条带(即，等同类别)中的项目组，并将特定位向量配置指派给每个条带。换言之，“条带”是项目组，所述项目组具有足够类似的项目特性以被指派相同的位向量配置。例如，针对一个条带的位向量配置可以指定两个秩6位向量、一个秩3位向量和一个秩0位向量。具有与该条带特性匹配的每个项目将使用该位向量配置。如本文所使用的，可以使用“条带表”来存储项目特性到由搜索索引使用的针对每个条带的位向量配置的映射。搜索索引可以使用任何数目的条带表。附加地，可以使用任何数据结构来存储针对条带表的映射。

影响位向量的数目和/或长度和/或被用于存储针对每个项目的位向量的存储装置类别的任何项目特性都可以被用于定义条带。在本文所描述的技术的一些方面中，也可以在执行查询时在运行时使用项目特性，并且因此可以将项目特性限制为可以被快速确定的那些特性。

仅作为示例而非限制，条带可以由以下项目特性定义：分类、语法(gram)尺寸、IDF、IDF总和以及层提示。分类是指项目在文档中的位置(有时被称为“流”)。这些例如可以包括主体、非主体和元字(未被显示但被添加到/利用文档进行索引以提供关于文档的元数据的字，比如文档的语言)。语法尺寸是指针对项目的字数目(例如，针对单个字项目为一个，针对短语为两个或更多个)。IDF是指项目的频率。由于每个分片索引不同的文档集，因此特定项目的频率可能在分片之间是不同的。在一些配置中，确定准确的项目频率是唯一可行的或者仅仅针对最常见的项目确定项目频率的良好近似。对于其他项目，假定项目频率低于某个阈值项目频率，并且该阈值项目频率被用作针对项目频率的代理。IDF总和为短语所用以近似短语的频率。确定所有短语的实际频率可能是不切实际的。相反，一些配置可以组合短语中的个体项目的频率，以提供针对短语的IDF总和。这是服务来帮助将短语分成组的近似。层提示用来表示搜索查询中项目出现得多频繁。这可以帮助确定要使用的存储装置的类别。例如，一些项目在文档中是常见的，但在搜索查询中很少使用。可以将针对这些项目的行存储在较慢的存储装置上。还应该注意，在使用分片的配置中，每个分片可以具有不同的项目分布，因此给定的项目可以在分片中的每个分片中具有不同的位向量配置。

指派给每个条带的位向量配置可以基于针对搜索索引的各种设计目标而是可配置的。在一些配置中，设计目标可以包括平衡索引存储消耗与相关性。通常，增加条带中的位向量的数目通过允许更多位向量相交来降低噪声从而提高了相关性，但是提高了针对搜索索引的存储需求。相反，减少针对条带的位向量的数目减少了存储，但也降低了相关性。

给定了存储装置和相关性之间的这些折衷，将位向量配置指派给条带的一种方式是尝试将总存储消耗最小化，同时确保相关性不低于某个阈值。这可以被看作是成本/利益优化问题，其中成本是消耗的存储量，利益是所提供的相关性。虽然存储额外的位向量的成本是相当线性的，但是附加的利益在一个点之后提供快速递减的回报。

对于向条带的给定位向量配置指派，对于语料库而言，消耗的存储量相对容易计算。可以基于与条带相关联的项目的频率来对条带中的项目的数目进行近似。另外，可以基于项目的频率(例如，IDF)来确定项目所贡献的发布数目。给定向条带的特定位向量配置指派，可以基于每个条带中的发布数目和每个条带中的位向量配置来确定存储量。

相关性度量可以在本文所描述的技术的各个方面中以多种不同的方式被确定。可以将相关性确定为在统计上显著的语料库和在统计上显著的查询日志的上下文下观察到的总值，诸如平均值。然而，相关性也可以考虑最小值、方差、第n百分位值、甚至是完整的分布。

在本文所描述的技术的一些方面中，相关性度量可以基于针对向条带的给定位向量配置指派所期望的误判率。误判率反映了预期由匹配器返回的、实际上与查询并不匹配的匹配文档的数目或百分比，因为文档并不包含来自查询的一个或多个项目。例如，如果针对查询的位向量相交产生100个匹配文档(即，来自相交的100个1位)并且那些匹配文档中的20个不是实际匹配，则误判率为0.2或20％。真实匹配的匹配文档在本文中被称为有效匹配文档，而不匹配文档在本文中被称为无效匹配文档。

虽然在某些配置中可以使用误判率作为相关性度量，但是误判率具有一些缺陷。通常，误判率仅适用于匹配器，并且可能不足以预测端到端流水线相关性。例如，误判率并未虑及对为每个查询返回的匹配文档的数目进行了限制的匹配器设计。在针对一个查询在语料库中可用的匹配文档数目低于由匹配器返回的最大文档数目的情况下，尽管匹配文档结果合适，但误判率将为高。例如，假设一个匹配器被设计为针对每个查询返回不超过五个匹配文档。在查询包括一个或多个罕见项目的情况下，整个语料库中可能只有一个匹配文档。然而，因为匹配器被设计为返回五个匹配文档，所以那些文档中的四个必然是无效匹配。作为结果，误判率将为80％，但是匹配器却不能返回一组更好的匹配文档。

误判率也未虑及被无效匹配文档替换的有效匹配文档。例如，再次假设一个匹配器被设计为针对每个查询返回五个匹配文档。在一个情况中，假设一个语料库对于第一个查询具有五个匹配文档，并且匹配器为第一个查询返回四个有效匹配文档和一个无效匹配文档。在另一个情况中，假设语料库对于第二个查询具有四个匹配文档，并且匹配器为第二个查询返回四个有效匹配文档和一个无效匹配文档。在这两种情况下，误判率是相同的(20％)。然而，对于第一个查询，一个有效的匹配文档被一个无效的匹配文档替换；而对于第二个查询，则没有有效匹配文档被替换。尽管误判率相同，但是来自第二查询的匹配文档集合比针对第一个查询的匹配文档集合呈现出更好的相关性。

因此，一些配置使用基于可能已经由匹配器返回但被无效匹配文档替换的有效匹配文档的一部分的差错率。这个差错率可以用作比误判率更好的、用于预测总体流水线相关性的代理。例如，在上面的示例中，在语料库中只有一个有效匹配文档，并且匹配器必须返回五个匹配文档，误判率为80％。然而，基于被替换的有效匹配文档的差错率将为零，这更准确地反映了相关性。在上面的示例中，第一个查询有一个有效匹配文档被替换，而第二个查询没有有效匹配文档被替换，对于两个查询而言误判率都是20％。然而，基于被替换的有效匹配文档的差错率将针对第一个查询为20％并且针对第二个查询为零，这更准确地反映了相关性。

在本文所描述的技术的一些方面中，搜索系统可以被配置为使得执行附加的验证步骤，其中保留有效匹配文档并移除无效匹配文档。这将移除由匹配器返回的误判。例如，匹配器可以被配置为允许将更大数目的匹配文档提供给附加的验证步骤。如果验证步骤不消耗太多附加的存储装置和/或需要太多附加的处理时间，则这可能是可接受的。在这样的配置中，相关性度量可以基于“修复成本”，其是标识和移除无效匹配文档所需的附加的存储装置和/或处理时间中的成本。

为了优化向条带的位向量配置指派，可以使用作为相关性度量(例如，误判率、差错率、修复成本或其他度量)和存储需求的加权和的成本函数。基于相关性和存储装置对搜索系统的设计的相对重要性，所应用的加权是可配置的。可以使用各种优化算法，其使用成本函数来优化指派给每个条带的位向量配置。例如，在一些配置中，可以使用梯度下降算法来快速收敛到向条带的合理/局部最优的位向量配置指派集合。

图24提供了示出用于生成诸如条带表之类的数据结构的方法2400的流程图，其将项目特性映射到位向量配置。如在块2402处所示，将项目特性指派给多个条带中的每个条带。附加地，如在块2404处所示，将位向量配置指派给每个条带。可以将项目特性和/或位向量配置指派给每个条带，如上所述。例如，可以使用成本函数来以针对平衡存储装置消耗与相关性度量的设计目标被优化的方式将位向量配置指派给每个条带。在块2406处生成数据结构，其针对每个条带将项目特性映射到位向量配置。数据结构可以为了多个目的而用于标识针对项目的位向量配置，所述多个目的诸如例如生成基于位向量的搜索索引、索引关于搜索索引中的文档的信息以及在针对搜索查询的匹配过程期间访问针对项目的位向量。

项目表

除了将位向量配置指派给项目之外，根据本文所描述的技术的各方面，将存储装置中的位向量位置映射到项目以允许对文档进行索引和执行查询二者。当对文档进行索引时，在文档中标识项目，并且需要标识针对这些项目的位向量位置以设置针对文档的列中的位。当执行搜索查询时，从查询标识项目，并且需要标识针对这些项目的位向量位置以取回位向量从而执行位向量相交。因此，在任一情况中，给定一个项目，需要标识针对该项目的位向量的存储位置。

尽管针对项目的位向量配置标识了针对项目的位向量的数目和长度(以及可能要使用的存储装置的类别)，也可以使用标识针对这些位向量的实际/特定存储位置的映射。例如，针对项目的位向量配置可以指示使用三个秩6位向量、1个秩3位向量和1个秩0位向量。该映射将项目(或其散列)与针对那五个位向量的每一个的存储位置相关联。针对项目的存储位置的映射在本文中被称为“项目表”。任意数目的项目表可以被搜索索引使用。另外，可以使用任何数据结构来存储针对项目表的映射。

一种用于映射针对项目的存储位置的方式是提供明确映射，其标识存储装置中的针对每个索引项目的特定位向量位置。对于给定项目，明确映射将项目(或其散列)与位向量标识符相关联，位向量标识符可以是指向存储装置中的针对该项目的位向量的位置的指针。如果针对一个项目使用明确映射，那么在对文档进行索引或执行查询时标识针对项目的位向量位置涉及查找针对项目的映射并取回由该映射所标识的特定位向量位置。

尽管可以为所有项目提供明确映射(特别是对于具有较少项目数目的较小文档集合的搜索索引)，在包含大量项目的较大搜索索引中包括针对所有项目的明确映射也可能是不切实际的。因此，在一些配置中的另一种方式是针对至少一些项目不包括明确映射，而是改为使用“自组织”方法，其中使用算法来得出针对项目的位向量位置。根据本文所描述的技术的一些方面，为每个条带提供了用于基于项目散列的导数来确定位向量位置的算法。例如，如果针对条带的位向量配置指定了三个位向量，则可以提供三种算法，每种算法都是一个项目的散列函数。因此，为了使用对于项目的自组织方式来发现位向量位置，基于项目的特性来确定项目的条带，并且可以使用为该条带指定的算法来确定针对该项目的位向量位置。可以将针对每个条带的算法存储在条带表、项目表或其他一些数据结构中。针对条带的算法可以简单地是不同的散列函数，该不同的散列函数在下面的意义上来说是不相关的：如果将各种散列函数应用于相同的输入值(即，相同的项目)，则存在着很大的可能性将针对每个散列函数返回不同的结果。

一些配置针对搜索索引中的不同项目使用明确映射和自组织方法。特别地，明确映射可以用于搜索索引中最常见的项目，而自组织方法可以用于剩余的项目。

转到图25，提供了图示出用于使用明确映射和自组织信息来确定位向量存储位置的方法2500的流程图。最初，如在块2502处所示，接收搜索查询。方法2500可以至少部分地例如使用图44的匹配器4404被执行。如在块2504处所示，从搜索查询标识一个或多个项目。

在块2506处访问一个或多个数据结构以确定在块2504处标识的针对项目的位向量的存储位置。数据结构可以包括上面讨论的条带表和/或项目表。特别地，数据结构为某些项目提供了明确映射，其中为这些项目明确标识位向量的存储位置。数据结构还存储自组织信息，用于得出针对未被提供明确映射的其他项目的位向量的存储位置。自组织信息可以提供用于确定位向量的存储位置的映射算法。可以针对不同的条带提供不同的映射算法。如此，自组织信息可以将项目特性映射到映射算法。换言之，可以将不同的项目特性集合映射到不同的映射算法。

在块2508处做出关于将使用明确映射信息还是自组织信息来标识针对在块2504处标识的项目的位向量的存储位置的确定。例如，项目表可以存储明确映射。可以检查项目表以查看它是否包括该项目。如果是，则标识明确提供的位向量存储位置，如在块2510处所示。如果明确映射信息不可用，则使用自组织信息来得出针对该项目的位向量存储位置，如在块2512处所示。这可能涉及确定针对该项目的项目特性以及查询针对那些项目特性的映射算法。例如，映射算法可以由其中针对不同的条带阐述不同的映射算法的条带表来存储。可以基于为该条带标识的项目特性和映射算法来确定针对该项目的条带。然后使用映射算法来得出位向量存储位置。

如在块2514处所示，访问针对该项目的位向量。如果在块2504处标识了多个项目，则对每个项目执行在块2506、2508、2510、2512和2514处的访问位向量的过程。然后将所访问的位向量相交以标识用于搜索查询的匹配文档，如在块2516处所示。

可以根据本文所描述的技术的各个方面以多种方式来用数据填充项目表。例如，给定正被索引的文档的静态语料库，可以通过对那些文档进行扫描并将这些项目总计起来从而确定那些文档中的项目频率的统计数据，并基于该信息来为该文档集合建立项目表。然而，网络上的文档的特性总体上是相当稳定的，因此可以选择随机数目的文档(例如，一千万个文档)，可以为该文档集合计算项目频率，可以构建相当优化地存储来自那些文档的发布的项目表，并且然后你可以针对其他文档使用该项目表。

当生成针对项目表的明确映射时，一些配置涉及将位向量密度(即，在每个位向量中设置的位的百分比)维持在某个期望位密度周围。例如，可以使用算法来生成明确映射，该明确映射为项目选择位向量以基于文档中的项目的频率来实现期望的位密度。位向量的位密度不需要精确地等于期望的位密度；相反，该方法试图保持接近期望的位密度(例如，一些位向量可以具有稍高的位密度，并且一些位向量可以具有稍低的位密度)。

行修剪/扩充

当使用位向量来设计和构建搜索系统时，存储搜索索引的信息量可以基于最坏情况查询。存在一些查询，其只用少量的索引信息就能被处理。在该范畴的另一端上，存在一些查询，其需要存储大量的信息来良好地处理查询。

有趣的是，从信息存储的角度来看最难处理的查询是由单个字组成的查询，其中对于查询可用的唯一位向量信息是针对该单个字的位向量。相反，作为多个字的联合的查询(例如，非常典型的3或4个字)，每个附加的字需要较少的信息来处理查询。如果查询具有大量字并且系统取回针对每个字的所有位向量，则执行查询可能需要引入大量的信息，并且查询可能变得低效。然而，并非所有这些信息都是良好地执行查询所需要的。

本文所描述的技术的一些方面使用在本文中被称为行修剪和行扩充的处理，其涉及在执行针对查询的匹配时针对查询的每个项目使用更少(修剪)或更多(扩充)的可用位向量。例如，假设一个查询包括三个字，每个字的IDF为四，因此每个字被存储在五个位向量中(基于针对一个字的行相交的数目对应于其IDF的示例经验法则)。因此，针对这个查询有15个可用于相交的位向量。然而，15个位向量的14个位向量相交比所需要的要多。

可以使用可用位向量的一部分，而不是使用可用于三个字的所有位向量。通常，查询的IDF可以用于确定要相交的位向量的数目。例如，在具有三个字的查询的先前示例中，10,000之1的目标误判率只需要五个位向量的四个相交。可以从可用于三个字的15个位向量选择五个位向量(例如，来自第一个字的两个位向量；来自第二个字的两个位向量；以及来自第三个字的一个位向量)。

用于项目的位向量可以被散布在不同类型的存储介质(例如，DDR RAM、SSD和HDD)上。对于具有多个项目的更典型的查询而言，行修剪仅允许取回在较快的存储介质(例如，DDR RAM和/或SSD)中的位向量。对于针对项目需要更多信息的查询(例如，单个项目查询)，除了较快的存储介质中的行之外，行扩充还从较慢的存储介质(例如，SSD或HDD)取回位向量。由于需要更多信息的查询通常较罕见，因此将附加的位向量存储在较慢的存储介质中是可以接受的。例如，假设一个项目有七个位向量，在DDR RAM中存储五个位向量，在HDD中存储两个位向量。一些查询可能只需要位于DDR RAM中的两个或三个位向量。更典型的查询可能需要位于DDR RAM中的四个或五个位向量。一些罕见的查询可能需要全部七个位向量。

在构造项目到行的映射(例如，在项目表中)时的一个考虑是：确定针对每个项目使用多少个位向量以及针对每个项目在哪个存储介质上存储位向量。关于项目的位向量的数目的确定可以基于项目在语料库中的频率。罕见项目需要更多的位向量。关于哪个存储介质存储针对项目的位向量的确定可以基于项目在查询中的频率。在查询中较不常出现的项目可以驻留在较慢的介质上。这权衡了在处理查询时存储针对项目的位向量与使用该项目的位向量的可能性/频率的成本。通常，可以将各种存储介质上的位向量的数目及其位置编码在条带表中。

接收查询时的一个考虑是：确定在匹配器计划中针对每个项目要包括多少位向量。该确定可被视为优化问题，其权衡了来自附加位向量的降低噪声的益处与从较慢的存储介质取回那些位向量的成本。附加位向量的益处可以通过相关性度量(例如，误判率、差错率、修复成本或其他度量)被量化。

转到图26，提供了图示出用于搜索查询的行修剪/扩充的方法2600的流程图。方法2600可以至少部分地使用例如图4的匹配器4404被执行。最初，如在块2602处所示，接收搜索查询。如在块2604处所示，从搜索查询标识一个或多个项目。

如在块2606处所示，为每个项目确定要使用的位向量的数目。如上所述，这可以基于诸如来自附加位向量的噪声降低的益处和取回附加位向量的成本之类的因素(其可以考虑存储位向量的存储介质的类型)。所述确定可以使用试探法和/或可以基于对初始数目的位向量进行相交来估计匹配文档的数目或百分比，并且然后使用基于该估计的不同数目的位向量来重新运行相交。在一些情况中，可以向可用位向量设置优先级，并且可以根据该优先级来选择位向量。在块2608处对位向量进行相交以标识匹配文档。

另一种方式将是基于在执行位向量相交时观察到的位密度来动态地调整位向量的数目(尽管这种方法可能不提供查询稳定性)。这样的方式不同于确定位向量的初始数目并且然后使用新数目的位向量重新运行，因为不重新运行匹配过程。相反，当匹配过程继续时，添加或移除位向量。该方式在图27中被示出，其提供了图示出用于针对搜索查询的行修剪/扩充的另一方法2700的流程图。方法2700可以至少部分地使用例如图44的匹配器4404被执行。最初，如在块2702处所示，接收搜索查询。如在块2704处所示，从搜索查询标识一个或多个项目。

如在块2706处所示，为每个项目确定位向量的初始数目。例如，可以使用试探法来确定该初始数目。所述确定可以考虑预期将返回多少匹配文档、相关性度量、和/或从存储装置取回位向量的成本。

如在块2708处所示，通过对位向量进行相交来使用初始数目的位向量来开始匹配过程。在执行匹配过程的同时，调整正被使用的位向量的数目，如在块2710处所示。这可以包括添加附加的位向量和/或移除位向量。位向量的数目可以在匹配过程期间被调整任意次数。该调整可以基于不同的考虑，诸如返回的匹配文档的数目或百分比和/或从存储装置取回更多/更少位向量的成本/成本节省。在一些情况中，可以向可用位向量指派优先级，并且可以根据该优先级来添加或移除位向量。

更新搜索索引

当新文档变得可用以及先前索引的文档被修改或变得陈旧(因此可以被移除)时需要更新搜索索引。对使用发布列表构建的搜索索引进行更新传统上是有问题的。通常对发布列表进行排序(例如，通过文档ID或静态排名)，这使得难以添加和移除文档。将文档添加到发布列表涉及确定发布列表中的位置以添加文档ID，然后移动其他文档ID以允许该文档ID的添加。如果需要从发布列表移除文档，则文档标识被移除，并且然后需要基于该移除来移动其他文档ID。基于添加和移除来移动文档ID会影响被搜索系统所使用的跳过列表和/或其他机制，并且需要基于文档ID的移动来更新跳过列表和/或其他机制。因此，更新基于发布列表的搜索索引可能需要使服务器脱机、重建搜索索引并且然后使服务器重新联机。如果服务器对大型文档集进行索引，则重建搜索索引的过程可能是非常耗时的，导致服务器长时间处于脱机状态。如果时间长度足够长，那么可能会不太经常更新搜索索引，导致搜索索引变得陈旧。

使用基于位向量的搜索索引诸如图44的位向量搜索索引4410的优点在于，可以递增地更新搜索索引，而不需要在任何时间段内关闭服务器——这是一些搜索系统中的情况。因为在表示相同数目的文档的上下文中位向量可以全部是恒定的宽度，从使得针对新文档的空间被预先分配，所以可以通过简单地设置和清除位来执行添加和移除文档，如将讨论的下面进一步详细讨论的那样。

与发布列表对照而言，位向量不会遇到与按照排序的顺序对文档进行维护相关联的问题。不需要偏移文档ID或更新指针，这在更新发布列表时可能是需要的。即使在系统正在运行时也可以执行添加或移除文档。如果在执行更新时接收到搜索查询，则取决于更新的进度，可能会是两个结果中的一个。第一个可能的结果是在更新之前已经标识的匹配集合。也就是说，在以将影响结果的方式改变位之前执行搜索查询。第二个可能的结果是在更新之后已经标识的结果。也就是说，在位被充分改变以影响结果之后执行搜索查询。不存在可能提供任何其他结果集合的时间点。由于更新位向量可以在停机时间最短或者没有停机时间的情况中快速完成，因此简化了数据中心设计，因为它不需要考虑实质性的停机时间，也不用担心搜索索引由于不经常更新而变得陈旧。

转到图28，提供了图示出用于将文档添加到基于位向量的搜索索引的方法2800的流程图。例如，可以由索引器4418执行方法2800以更新图44中所示的搜索系统4400中的位向量搜索索引4410。如在块2802处所示，标识文档中的项目。还可以标识每个项目的位置(例如，主体、非主体、元)。如在块2804处所示，选择要添加文档的列。

作为举例说明列的标识，图29图示出了具有长度不一的位向量集的简化搜索索引2900。突出显示部分2902是被分配用于索引特定文档的列，包括与该文档对应的每个位向量中的位。正如可以理解的那样，短行位向量中的列的位与其他文档被共享。

在一些配置中，搜索索引中的位向量可以包括多个“空”列以允许文档的添加。在这些列的位被设置为零的意义上来说这些列是空的。注意，空列可能会基于对位进行共享的其他文档的存在而在某些短行位向量中设置那些位。

如在块2806处所示，标识与文档中发现的项目对应的位向量。如在块2808处所示，标识与为该文档选择的列对应的被标识的位向量中的每个被标识的位向量中的位，并且如在块2810处所示(即，通过将每个位设置为“1”)，设置被标识的位。

现在参考图30，提供了图示出用于移除文档的方法3000的流程图。方法3000可以至少部分地使用例如图44的索引器4418被执行。如在块3002处所示，标识与要被移除的文档对应的列。如以上所指出的，列是指与特定文档对应的每个位向量中的位。举例来说，图31A图示出了具有长度不一的位向量集合的简化搜索索引3100(将较短位向量展开以示出对应位)。由区域3102突出显示与将被移除的文档对应的列(即，位集合)。

如在块3004处所示，被标识的列中的每个位被设置为零。在图31B中体现了将该列中的所有位设置为零。由于较短位向量中的位被其他文档共享，其中一些将保留在索引中，所以可能需要为那些文档恢复较短位向量中的位。因此，标识对较短位向量中的位进行共享的文档集，如在块3006处所示。这些文档是对应于图31C中所示的列3104、3106、3108、3110、3112、3114、3166的文档。如在块3008处所示，重置与包含在那些被标识文档中的项目对应的较短位向量中的位。这可以例如通过标识与包含在文档中的项目对应的位向量、标识与文档对应的那些位向量中的位、并设置这些位被完成(类似于上面参照图28讨论的用于添加文档的方式)。图31D图示出了基于对应于列3104、3106、3108、3110、3112、3114、3116的文档已经在搜索索引3100中被重置的位。

用于移除特定文档的上述方式可能是昂贵的操作，因为它需要与被移除文档共享位的文档被重新索引。因此，可以在有限的情形中使用这种方式，例如，当出于法律原因需要将文档从搜索索引移除时。

用于从搜索索引移除文档的另一方式将移除不得不对与被移除文档共享位的文档进行重新索引的复杂事项，其批量移除文档。以那样的方式，通过将所有位设置为零，同时移除共享位的所有文档，并且不需要重新索引文档。例如，可以使用到期方式，其中策略规定时常地(例如，每24小时、每周、每月等)移除文档。根据该策略，所有比设定时间阈值还旧的文档将通过将针对这些文档的位设置为零而被移除。时间阈值可以与文档被索引的频率相一致。举例来说明，文档可以每24小时被索引。因此，将从搜索索引移除24小时前进行索引的文档(即，通过在针对文档的列中将这些位设置为零)同时再次爬取文档并对其进行重新索引。当再次爬取文档时，可以使用先前使用的同一列对文档进行索引。然而，更简单的方式可以简单地将先前的列中的位清零并将文档索引在搜索索引中的新列中。这有助于在基于当文档被爬取时将文档添加到搜索索引中的连续位置时批量地移除文档。

从搜索索引移除文档的另一方式是：不是真正地移除索引信息，而是改为防止响应于搜索查询返回某些文档。特别地，可以将长位向量存储在搜索索引中，并在对所有搜索查询进行匹配期间相交。长位向量中的位可以被最初设置为1，并且如果文档要被移除，则针对该文档的位被设置为零。因此，当接收到搜索查询并且将长位向量相交时，有效地移除位被设置为零的任何文档。虽然这种方法提供了一种相对简单的方式来“移除”文档，但是由于“移除”的文档在搜索索引中占据了空间，所以它具有成本。然而，这对于随机访问删除可能是可接受的(例如，出于法律原因需要移除文档)，因为随机访问删除的情况可能相对罕见。

当将索引完全存储在RAM中时，对索引的更新是相对直截了当的。例如，如果使用过期策略，则RAM中的搜索索引在概念上可以就被认为是位的2D阵列，其中将文档添加到右手边，而在左手边上移除文档。然而，较大的搜索索引可能实际上不完全被容纳在RAM中，并且可以使用诸如SSD和/或HDD之类的其他存储设备来存储搜索索引的一些部分。特别地，SSD和HDD具有较大的存储容量并且成本相对较小。然而，SSD和HDD通常比RAM慢，无论是每秒每一个可以处理的请求数目(即IOPS-每秒输入/输出操作)的限制还是可以传送数据的速率(即，测量到的吞吐量，例如，每秒字节数或每秒MB数)。

针对递增索引更新的性能考虑包括但不限于：将列添加到二维阵列中的成本以及由于数据存储设备(如RAM、SSD和HDD)的面向块的性质导致的效率低下。举例来说明这样的考虑，图32A示出了按照行优先的顺序布置的4×4阵列。当以行-主要(row-major)顺序排列阵列时，一行内的连续列位置驻留在连续的存储位置中。例如，列A至列D驻留在第1行中的位置0-3和第2行中的位置4-7。根据本文所描述的配置，以行-主顺序对发布进行布置，其中列对应于文档集合，并且行对应于项目集合。这种布置用来优化在查询处理期间行扫描的速度。

在文档摄取的进程期间，可能有必要将另一列添加到阵列中。图32B示出了在添加第五列之后来自原始阵列的数据的布局。为了保持行-主要布局，有必要移动原来在存储位置4-15中的数据。例如，考虑位置B2。在图32A中的原始4×4阵列中，位置B2对应于存储位置5。在图32B中的新的4×5阵列中，位置B2对应于存储位置6。

因为这些数据移动，所以添加单个列的工作量与复制整个阵列的工作量在同一量级上。一种避免与添加列相关联的成本的方式是从为附加列保留了空间的更大的阵列开始。图33A示出了这样一个阵列的示例。在这个特定示例中，阵列具有用于6列的空间，但只有两个在使用中。图33B示出了添加第三列涉及仅写入与该列相关联的存储位置。其他存储位置保持不被触动。在添加另外三列之后，该阵列将变满，如图33C中所示。

此时，可以将阵列复制到更大的缓冲器，如图34A中所示。备选地，可以开始新的缓冲器，如图34B中所示。如图34A中所示，对阵列进行复制是昂贵的，但是具有这样的优点：每行映射到可以有效地被扫描的连续存储块。如图34B中所示，开始一个新的缓冲器是便宜的，但是具有这样的缺点：每行现在映射到一对块。每个块内的存储是连续的，但块本身不在相邻的存储位置。诸如SSD和HDD的一些设备对于被访问的每个连续存储块招致巨大的设立成本。对于这些设备，图34B中的布置将招致两倍于图34A中的布置的设立成本。

为了在读取行时提供可接受的性能，需要限制索引中存储块的数目。同时，为了在摄取文档时提供可接受的性能，需要限制块复制的次数。本文所描述的配置使用阵列层级结构来在对组成一行的块的数目施加限制的同时将块复制操作的次数最小化。例如，一些配置可以使用用于两个小阵列、两个中等阵列和两个大阵列的空间，如图35A中所示。在这个示例中，小阵列持有与中等阵列的一半一样多的列。大阵列持有与小阵列的五倍一样多的列。

最初，系统是空的，如图35A中所示。当文档到达时，将它们索引到新创建的小阵列中，如图35B中所示。如图33A中所示，小阵列由包含已经被索引的文档的列集合和为未来将被索引的文档所保留的列集合组成。此时，可以利用单个块读取来对行进行访问。

在某一点处，第一小阵列变满并且创建一个新的小阵列来接受附加文档，如图35C中所示。此时，对行进行访问需要两个块读取操作。最终第二个小阵列变满，如图35D中所示。此时，创建一个中等尺寸的阵列并用两个小阵列的内容的副本进行初始化，如图35E中所示。然后清除两个较小的阵列并在第一个小阵列中继续文档摄取。在这种配置中，行访问需要两个块读取操作。最终，小阵列将再次填满并且将创建第二个中等块，如图35F中所示。此时，行访问需要三个块读取操作。在某一点处，两个小阵列将再次变满，但是这次两个中等阵列也将是满的，如图35G中所示。在这种情形下，没有媒体阵列可用于保持小阵列的内容。行访问现在需要四个块读取操作。此时，将创建一个新的大阵列，并用两个小阵列和两个中等阵列的内容进行初始化。然后清除小阵列和中等阵列并在第一个小阵列中继续摄取，如图35H中所示。行访问现在需要两个块读取操作。

数据存储设备通常以大于单个位的粒度来提供对数据的读取/写入访问。这些设备上的位被分组成块，所述块代表可以在单个操作中被读取或写入的最小数据量。例如，DDR3存储器协议将数据布置为512位的块。从DDR3存储器读取单个位需要读取包含该位的块中的所有512位。同样，写入单个位需要在该块中写入全部512位。SSD和HDD具有甚至更大的块尺寸。例如，典型的SSD可以将数据布置成4,096字节或32,768位的块。在这样的SSD上读取或写入单个位将涉及读取或写入32,768位。典型的HDD块甚至更大。

如以上所指出的，本文所描述的配置将发布数据布置为二维位阵列，其中行对应于项目的集合，列对应于文档的集合。2D位阵列按照行主要顺序来排列。也就是说，单行内的位占据连续的存储位置，并且组成该阵列的行占据连续的存储位置。这种布局的后果是单行上的操作涉及访问一系列连续的存储位置，而列上的操作要求访问不连续的一系列存储位置。添加、更新或移除文档的动作涉及写入单列内的位，并且因此要求访问不连续的存储位置。

这种操作是低效的，因为读取或写入单个位涉及读取或写入完整的位块。在更新DDR存储器的情况中，读取或写入单个位涉及512位的操作。因此，与读取或写入512个连续位的操作相比，浪费了511/512的存储设备吞吐量。这种低效率对于存储在DDR存储器中的发布而言是可以接受的，因为相对于DDR存储器的高吞吐率，文档摄取率相当低。

然而，当发布被放置在SSD或HDD上时，由于块访问而导致的低效率由于两个原因而变得不可接受。第一个原因是SSD和HDD通常具有更大的块尺寸。例如，SSD可以使用4Kb(32k位)的块，并且HDD可以使用16Kb(132k位)的块。这些块分别比典型的DDR3块大64和256倍。其后果是：读取或写入存储在SSD或HDD中的单个位比读取或写入存储在DDR3存储器中的单个位低64至256倍。第二个原因是在SSD或HDD上读取或写入块的时间远远大于读取或写入DDR3存储器块的时间。例如，典型的SSD操作可能花费20ms，而典型的DDR3操作可能花费10ns。换言之，读取或写入SSD块可能比访问DDR3存储器中的数据块慢200万倍。HDD甚至更慢。

如图35A至图35H中所示，利用被布置成阵列层级结构的索引，通过将小阵列放置在DDR存储装置中以及将中等阵列和大阵列放置在SSD和HDD上，可以减轻与离线存储设备相关联的低效率，如图36中所示。这样起作用的原因是个体列写操作只发生在最小阵列中。由于最小阵列被存储在DDR中，针对列写入的成本很低。较大的阵列只通过复制较小阵列集合的全部内容来被初始化。这些大的复制操作对离线存储设备是有效率的。在一些配置中(诸如在图35A至图35H的示例中)，可以将数据从阵列集写入到更大尺寸的阵列(例如，从小到中等或从中等到大)，从而使得写入到更大尺寸阵列的数据填充该阵列，限制写入到更大尺寸的阵列的数目。

阵列中的每个阵列在本文中可以被称为累积缓冲器，因为每个阵列用于累积文档直到达到某个点，并且然后将内容写入到更大的阵列。现在转到图37，提供了图示出用于使用累积缓冲器来在位向量搜索索引中对文档进行索引的方法3700的流程图。方法3700可以至少部分地使用例如图44的索引器4418被执行。如在块3702处所示，最初，在累积缓冲器存储设备中对文档进行索引。累积缓冲器存储设备将文档信息存储为位向量，其中每个位向量包括位阵列，每个位指示是否一个或多个文档中的至少一个文档包含与位向量对应的一个或多个项目中的至少一个项目。在累积缓冲器存储设备是初始存储设备的情况中，通过为每个文档设置位，可以一次一个地在累积缓冲器存储设备中对每个文档进行索引。例如，可以在爬取文档之后在累积缓冲器存储设备中设置针对文档的位。在其他情况中，在块3702处文档被索引的累积缓冲器存储设备之前可以有一个或多个先前的累积缓冲器。在这样的情况中，可以基于在先前的累积缓冲器中设置的位来在累积缓冲器存储设备中对文档进行集中索引。

在块3704处做出关于是否已经满足阈值的确定。如果为否，则通过返回到块3702表示继续在累积缓冲器存储设备中对文档进行索引的过程。备选地，如果已经满足了阈值，则在后续存储设备中集中地索引来自累积缓冲器存储设备的被索引的文档信息，如在块3706处所示。正如可以理解的那样，当后续存储设备大于累积缓冲器存储设备时，数据可以从累积缓冲器存储设备中的连续位移动到后续存储设备中的非连续位。

在不同的配置中可以使用不同的阈值。在一些情况中，阈值是某一数目的文档，从而使得当在累积缓冲器存储设备中已经索引了所述某一数目的文档时，阈值被满足并且将信息从累积缓冲器存储设备索引到最终存储设备。在其他情况中，阈值是某一时间段(例如，一小时、一天等)，使得当该时间段已经过去时，将信息从累积缓冲器存储设备索引到最终存储设备。在另外的情况中，阈值可以是某个存储量(例如，为累积缓冲器存储设备或者累积缓冲器存储设备集所设置的存储容量)，使得当存储量已被满足时，将信息从累积缓冲器存储设备索引到最终存储设备。

如在块3708处所示，做出关于后续存储设备是否已满的确定。如果为否，则可以重复在累积缓冲器存储设备中对文档进行索引(例如，通过清洗累积缓冲器存储设备并索引新文档)直到满足阈值并且将信息从累积缓冲器存储设备索引到后续存储设备的过程。这个过程可以继续，直到后续存储设备已满为止，在此刻，过程结束，如在块3710处所示。除了最终存储设备是否为满之外，在确定是否重复该过程时还可以使用其他阈值。例如，可以作为替代使用基于时间的阈值(例如，最终存储设备可以被配置为保持一天的文档价值)或文档阈值(例如，最终存储设备可以被配置为保持阈值数目的文档)。

应该理解的是，累积缓冲器的数目和尺寸可以基于设计目标而是可配置的。一般来说，对于其他成本使得具有附加累积缓冲器不是那么期望的某个点而言，更多的累积缓冲器是可期望的。特别地，累积缓冲器可以用于服务于搜索查询(即，将不仅基于在最终存储设备(即，大存储设备)中索引的文档而且基于还没有被提供给最终存储设备的当前存储在累积缓冲器中的文档来服务于搜索查询)。如此，当每个累积缓冲器被访问以服务于搜索查询时，更多累积缓冲器可以减慢查询处理速度。取决于设计目标，可以选择最佳数目的累积缓冲器。例如，如果搜索索引将经历高容量查询但是数据不经常更新，那么最佳设计可以是较少的累积缓冲器。作为另一示例，如果搜索索引将经历不频繁的搜索查询但数据经常更新，则最优设计可以是较多的累积缓冲器。另外，在某一数目的写入之后，SSD容易烧毁。因此SSD上的累积缓冲器的数目将影响烧毁，当在设计中选择SSD累积缓冲器的数目时可能要考虑SSD的烧毁率。

初级排名器算法

如本文所讨论的，搜索系统可以使用匹配器，诸如图44的匹配器4404，以最初标识用于搜索查询的一组匹配文档。由于这组文档在大多数情况下太大而不能作为搜索结果集合被返回，所以可以利用一个或多个排名器来进一步缩小文档组，从而使得响应于搜索查询，仅返回最相关的文档。在一个配置中，使用至少两个排名器，包括初级排名器，诸如图44的初级排名器4422。虽然初级排名器能够根据对文档进行评分和排名来很接近地对诸如图44的最终排名器4426之类的后续排名器将要做什么进行近似，但是初级排名器操作起来并不昂贵。例如，在本文所描述的技术的一个方面中，初级排名器为后续排名器消除了后续排名器也将消除的所有文档。如此，由初级排名器使用的算法被设计成消除(例如，将低分数指派给)也将被后续排名器(诸如图44的最终排名器4426)所使用的算法所消除的所有文档。这允许显著地减少了在初级排名器处的候选文档集合，而不必删除与查询特别相关并且在最终排名器或其他后续排名器处应该被包含在候选文档集合中的文档。

现在参照图38，图示出了用于执行本文所描述的技术的各方面的示例性系统3800。匹配器3802(其可以对应于图44的匹配器4404)、分数表服务器3804和初级排名器3610(其可以对应于图44的初级排名器4422)被提供，并且可以通过网络3608的方式进行通信。先前已经在本文中描述了匹配器3802，因此将不关于系统3800描述之。被匹配器3802发现是相关的文档的标识被返回给初级排名器3810。对于被指示为可能与特定搜索查询相关的每个文档，分数表服务器3804访问与每个文档相关联的分数表。在一个配置中，将分数表存储在诸如数据存储3806的分数表数据存储库中。

初级排名器3810具有许多功能，如在本文中更详细描述的。例如，初级排名器3810除了图38中未示出的其他组件外还包括分数表构建组件3812、分数表查找组件3814、评分组件3816、键(key)比较组件3818和点击表查找组件3820。下面将更详细地描述这些组件中的每一个的功能性。

尽管传统的排名器可以利用与发布列表中的每个项目相关联的数据的有效载荷来对文档进行评分和排名，但是本文中所描述的技术的各方面使用具有预先计算的数据的表格。发布列表可以利用可代表整个文档语料库的反向索引。例如，发布列表可以首先按文档、然后按文档中的每个项目的出现被布置。该列表还可以包括指针，该指针可以用于从项目的第一次出现移动到该同一项目的后续出现。尽管发布列表可能有助于减少候选文档的数目，但是它们也消耗大量的存储器，并且比使用本文所描述的分数表更慢。

如上所述，代替使用发布列表，一些配置利用散列表，也被称为分数表。在一个方面中，每个文档具有其自己的分数表，其包括诸如频率数据之类的预先计算的数据。如所提及的，这些分数表可以被存储在数据存储库3806中。分数表还可以包括已经预先计算的其他数据。关于频率，频率可以被预先计算，但是可以不是作为文档中的项目的实际频率而是作为例如IDF被存储在分数表中。IDF与文档中项目出现的次数成比例地增加，但被语料库中的字的频率所抵消。换言之，被存储在表格中的值可以反映与特定项目在语料库中的相对不频繁相关的、在文档中的该项目的频率。还设想了表示分数表中的项目的预先计算的频率的其他方式。如此，被存储在分数表中的与项目的频率相关的数据可以指示文档中的项目的频率，但是可以按照这样的方式被存储以至于需要某种类型的计算来确定实际频率。由初级排名器使用的算法可以使用指示针对每个文档的其分数计算中的频率的数据，并且因此可能不需要计算项目的实际频率。更进一步，出于效率的目的，比如为了减少所需的存储器，可以针对分数表中的项目以最大频率裁剪频率数据，从而使得可以在分数表中用较少的位来表示频率数据。

如所提及的，每个文档可以具有相关联的分数表，该分数表存储用于由初级排名器使用来对文档进行评分和排名的预先计算的分量的数据。为了产生有效的排名器，分数表构建组件3812可以不在分数表中包括文档中的所有项目。例如，只有在特定文档的主体中出现一次以上的那些项目的数据才可以被存储在该文档的分数表中。文档中大约85％的项目可能只在文档的主体中被发现一次，因此，消除与这些项目相关联的各种组件的预先计算可以节省存储器，并使初步排名器操作比其他方式快得多。因此，在文档的主体中仅出现一次的项目和在文档中根本未出现的项目可以被视为是相同的，并且因此可以被赋予相同的分数，因为初级排名器可能不能在这些项目之间进行区分。由于系统知道在文档的主体中仅出现一次的项目不被包括在针对每个文档的分数表中，所以在一个配置中，系统将在特定分数表中没有发现的所有项目视为在主体中出现一次。这意味着文档中未包含的项目将被视为在主体中出现一次。这是可以接受的，因为它不会显著影响排名。来自其他位置(例如，非主体和元字)的项目可以被评分更高并存储信息，即使这些项目在这些其他位置中仅出现一次。

举例来说明，如果特定搜索查询包括项目“猫”和“狗”二者，则可以返回发现具有项目“猫”的文档。初级排名器可以访问针对该特定文档的分数表，以发现“狗”没有在分数表中被列出，并且可以假设“狗”在文档的主体中仅被提及一次。在这种场景下，初级排名器可以给该文档一个“1”而不是“0”的分数，这个分数通常将被赋予在其中根本未出现这个项目的一个文档。如此，在一个配置中，对于在分数表中没有发现的特定项目，没有文档被赋予“0”的分数。

虽然已经讨论了文档中的每个项目的频率，但是其他预先计算的数据也可以被存储在分数表中。例如，文档中的每个项目出现在哪里的指示可以被编码在分数表中。例如，在一种类型的文档中，项目可以位于标题流、主体流、锚流、URL流等中。位于文档标题中的项目例如可以指示文档具有与该项目相关的良好机会，并且因此与用户的与搜索查询相关联的意图相关。此外，在文档的单个段落中或特定章节中多次出现的特定项目可以指示该文档与搜索查询的特定相关性。

除了上面讨论的诸如文档中的项目的频率以及项目位于文档的哪个部分中之类的预先计算的分量之外，当与搜索查询相关地计算针对文档的最终分数时，也可以考虑一个或多个实时分量，诸如通过评分组件3616。实时分量是一旦被输入和接收到搜索查询就计算出的那些分量，因为它们通常不能被预先计算。例如，搜索查询中特定项目的位置在运行时之前不能被计算，因为在那个时候之前查询是未知的。此外，文档的地理本地性与查询起源的地理本地的匹配程度如何在运行时之前不能被确定，并且因此被实时计算。另一示例是文档的语言与查询的语言的匹配程度如何。这在输入搜索查询之前也不会被计算，并且初级排名器运行一个算法来确定文档集合对搜索查询有多相关。

如由评分组件3816所计算的，与搜索查询相关的文档的最终分数可以取决于一个或多个预先计算的分量和一个或多个实时分量二者。例如，每个分量，无论是否被预先计算，都可以通过初级排名器所使用的算法而被指派个体分数。诸如评分组件3816之类的算法然后考虑个体分数以计算与特定搜索查询相关的针对每个文档的最终分数。最终分数可以用来对文档进行排名，或者以其他方式用来将文档从一些随后排名器的考虑中消除。在一个配置中，最终分数是指示特定文档与搜索查询的对应程度的数字。

在确定针对每个文档的分数中，初级排名器也可以使用点击表。点击表的功能可能与如上所述的分数表相同。将数据存储在针对文档的每个项目的点击表的空隙中。在一个配置中，在文档中发现的所有项目都被包括在点击表中，但在另一配置中，只有出现了一次以上的项目才被包括在点击表中。对于每个项目，点击表存储数据，该数据指示文档被提交相同或相似搜索查询的用户选择的频率。特定文档被提交相同或相似搜索查询的其他用户选择的频率会是一个关于该文档是否应该被认为与当前搜索查询相关的有价值的指示器。如此，例如可以通过点击表查找组件3820来访问点击表，所述点击表查找组件3820是作为可以对针对特定搜索查询的文档的最终分数做贡献的组件。

图39图示出了例如使用图38的初步排名器3810以基于与搜索查询的相关性来对多个文档进行评分的方法3900的流程图。首先在块3902处，访问与被发现可能与所接收的搜索查询的至少一部分相关的文档相关联的表格。该表格可以存储用于得出文档中的项目子集的每个项目的频率的数据。在一个配置中，项目子集中的每个项目在文档中多次出现。在一个情况中，文档中的所有项目的不到一半都被包括在该项目子集中。文档可以是例如由图44的匹配器4404发现的基于关键字匹配而具有与搜索查询相关的可能性的多个文档中的一个。在块3904处，确定与搜索查询对应的至少一个项目的频率。在一个配置中，频率的确定可以简单地指来自表格的频率数据被访问和取回。如何处理数据取决于算法。例如，算法可能需要将表格中的数据转换成频率的不同表示，诸如从IDF到就是文档中的项目的频率。备选地，算法可以在针对文档的分数的计算中使用IDF。如前所述，可以预先计算指示频率的数据，并且可以将其存储在表格中，并且因此在块3904处，表格中的数据被用来通过由初级排名器所使用的算法来确定频率。被存储在表格中的这个频率数据不仅可以提供文档中的项目的频率的指示，而且可以提供与文档语料库中的项目的相对不频繁相关的、在文档中的该项目的频率。

在块3906处，计算与搜索查询相关的文档的分数。这至少基于文档中的至少一个项目的频率以及与文档和搜索查询的项目相关联的其他数据。频率是预先计算的分量。其他预先计算的分量包括文档中的项目的位置，诸如在标题、主体、摘要、锚、URL等中是否发现该项目。分数的至少一部分可以基于诸如运行时之类的一个或多个实时计算的实时分量。这些可以包括例如搜索查询中的至少一个项目的位置、彼此相关的每个项目的位置、文档的语言与搜索查询的语言的比较、以及与文档相关联的地理本地和与搜索查询相关联的地理本地的比较。在本文所描述的技术的一个方面中，可以使用预先计算的分量和在接收到搜索查询之后计算出的实时分量两者的许多个体分量分数来计算最终分数。

现在参照图40，提供了图示出了例如使用图38的初级排名器3810来基于与搜索查询的相关性对多个文档进行评分的另一方法4000的流程图。在块4002处，访问存储对应于文档的数据的表格。虽然所存储的数据可能不是实际频率，而是作为替代可以是例如IDF，但是数据被预先计算以指示文档中的项目的频率。该频率数据对与搜索查询有关的文档的分数做出了贡献。仅出于示例性目的，预先计算的分量可以包括文档中的项目的频率、项目所位于的文档的一部分诸如标题、主体、锚、URL、摘要等、以及项目出现在文档的那些部分中的频率。在块4004处，计算针对每个预先计算的分量的分数，并且在块4006处，实时地或在运行时计算针对每个实时分量的分数。在块4008处，基于预先计算的分量和实时分量的分数，计算针对与搜索查询相关的文档的最终分数。如所提及的，最终得分也可以考虑点击表中的点击数据。这种点击数据指示：针对与搜索查询相关联的项目，文档被其他用户选择的频率。

除了仅针对在文档中发现的一部分项目诸如在文档中出现两次或更多次的项目将数据存储在分数表中之外，初级排名器还适于通过当分数表被构建和访问时允许发生冲突而使用比典型排名器更少的存储器。例如，当针对在文档中发现的一个项目的数据被写在针对另一项目的数据上时，可能发生冲突。如此，根据本文所描述的技术的各方面使用的分数表以多种方式与其他分数表非常不同地进行操作。最初，分数表通常具有空隙，每个空隙具有与其相关联的键。在一个配置中，来自文档的每个项目都有其自己的键，当针对其他项目的数据正被添加到表格中时该键被使用。通常，当一个空隙已经在其中存储有数据时，该空隙不用于存储针对另一项目的数据，而是改为利用另一空隙，例如，空空隙。然而，本文的配置中所使用的分数表允许发生这些冲突。当诸如通过分数表构建组件3812正在构建分数表时以及当发生查找时(诸如当分数表查找组件3814访问分数表以针对文档中的特定项目确定频率和其他预先计算的信息时)，可能发生冲突。

虽然通常一个键可以被存储为64位，但是本文所描述的技术的各方面提供了要被存储的少得多的位量。例如，在一个配置中，可以针对分数表的空隙存储64位键中的仅仅五个位。当较大键的五个位被存储并且诸如由键比较组件3818来与另一五位键进行比较时，键将匹配的机会比存储较大位量时以及与其他键相比时更高。尽管在上面的示例中使用了5个位，但是应该注意的是，可以使用比总位数目更小的任何位数目。例如，即使使用65位中的60位键也将允许发生冲突，因为两个不同的键将有可能具有相同的60位部分，并且因此在这种情况中将发生冲突。

当发生冲突时，如上所述，采取预防措施以确保从初级排名器发送到最终排名器的文档集合中排除与搜索查询不相关的文档，诸如最终排名器将丢弃的文档。例如，当针对特定文档构建分数表时，以及当已经确定要将在文档中发现的针对第二项目的数据添加到已经与不同于第二项目的第一项目相关联的空隙中时(例如，空隙已经存储了与不同项目相关联的数据)，可以确定文档中的第二项目的频率是否大于文档中的第一项目的频率。如果第二项目的频率更大，则将那个更大的频率存储在该空隙中，但是这两个项目都将保持与相同的空隙相关联。这里，第一项目的频率正在被第二项目的频率重写。

然而，如果被添加到空隙的第二项目的频率小于已经与该空隙相关联的第一项目的频率，则第一项目的较高频率将保持存储在该空隙中，尽管可以将第二项目添加到该空隙。在这里，虽然第二项目将与该空隙相关联，但它的频率将不被存储在分数表中，因为它低于已存储的频率。如果较低的频率被存储在较高的频率上，则针对特定搜索查询，可能错误地排除与该分数表相关联的文档，即使它可能是针对该搜索查询的相关文档。通过针对两个项目仅存储较高的频率，针对其中一个项目返回或计算的频率可能高于其应该的频率(例如，如果返回的频率是针对不同的项目)，但是当在发送给后续排名器以进行进一步处理的相关文档集合中应该返回文档时文档将不被排除。相反，文档可能被排名得比它应该的排名更高，并且如此，即使该文档不像其他文档那样相关，也可以在相关文档集合中被返回。如此，所有被发现是相关的文档，诸如那些分数高于特定阈值的文档，将被返回，但也可能包括一些可能不那么相关的文档。

转到图41，提供了图示出使用图38的初步排名器3810用于将针对项目的数据添加到分数表的空隙的方法4100的流程图。首先在块4102处，访问具有空隙的表格，其中该表格存储与文档相关联的数据。在块4104处，对于表格的第一空隙，将与第一项目相关联的第一散列键的部分和与要被添加到第一空隙的第二项目相关联的第二散列键的部分进行比较。如本文所提及的，本文所描述的技术的各方面允许多于一个的项目与相同空隙相关联，但是只有指示其中一个项目的频率的数据被存储在其中。在块4106处，确定第一散列键的部分是否匹配第二散列键的部分。如果散列键的部分不匹配，则与第二项目对应的数据(例如，指示频率的数据)不被存储在分数表的第一空隙中，在块4112处被示出。然而，如果散列键的部分匹配，则在块4108处确定文档中的第二项目的频率大于文档中的第一项目的频率。在块4110处，与表格的第一空隙相关联地存储与第二项目的频率相关联的数据。在一个配置中，该频率数据重写现有数据，现有数据对应于也与第一空隙相关联的第一项目的频率数据。

根据本文所描述的技术的各方面，如果第一散列键的部分不匹配第二散列键的部分，则考虑第二空隙，并且因此将第二散列键的部分和与第三项目相关联的第三散列键进行比较，所述第三项目的对应数据被存储在表格的第二空隙中。如果这些散列键部分匹配，则确定文档中的第三项目的频率是否大于第二项目的频率。如果第二项目的频率较大，则将与第二项目相关联的频率数据存储在表格的第二空隙中，重写与第三项目相关联的频率数据。然而，如果第二散列键的部分不匹配第三散列键的部分，则对应于第二项目的数据不被存储在表格的第二空隙中。该过程可以继续，直到定位到散列键的部分匹配到那儿的空隙为止。

尽管只有与在文档中发现的项目子集相关联的数据被存储在分数表中，并且即使允许发生冲突，但是初级排名器的结果毫无意外地比传统排名系统更好，从而提供了更相关的文档集合。例如，当初级排名器与诸如本文关于图44所述的搜索系统之类的搜索系统结合被使用时，被初步排名器发现是相关的文档毫无意外地比被其他排名系统发现是相关的文档更为相关，而且发现速度更快。在一些配置中，初级排名器以比其他排名系统快两倍、五倍、七倍或甚至十倍的速度起作用，从而使得本文所描述的整个搜索系统能够以比传统搜索系统快很多的速率进行操作。

在本文所描述的技术的各方面中，可以由机器学习算法教导初级排名器以标识针对特定搜索查询的最相关文档。通常而言，向初级排名器提供输入，其可以包括搜索查询、文档，并且人类发现哪些文档与每个搜索查询最相关。从这个输入，对初步排名器进行训练以产出与人将产出的一样的相关文档。在一个配置中，机器学习算法使用奇异值分解，但也可以使用其他的。

匹配修复

在诸如图44的搜索系统4400的搜索系统中，可以使用诸如匹配器4404之类的匹配器作为搜索流水线中的早期步骤，以基于来自搜索查询的项目来标识匹配文档。正如在前面所解释的那样，由匹配器标识的文档集合常常太大而不能作为搜索结果进行返回或者发送到诸如图44的最终排名器4426之类的昂贵排名器(即，从对每个文档进行排名所需的处理量的角度来看是昂贵的)，因为排名器处理大量的文档将花费很长的时间。此外，如果匹配器使用概率方法，诸如使用如上所述的基于位向量的搜索索引，则匹配文档集合实际上可能包括一个或多个无效匹配文档，这些文档不是针对搜索查询的真实匹配。换言之，无效匹配文档可能是误判，因为这些文档不包含来自搜索查询的一个或多个项目。将无效匹配文档发送到诸如图44的最终排名器4426之类的昂贵排名器，将会由于这样的排名器处理每个文档所需要的费用而浪费资源。

为了移除无效匹配文档并由此减少发送到下游排名器的匹配文档的数目，本文所描述的技术的一些方面使用在本文中被称为匹配修复阶段的阶段。通常，诸如匹配修复组件4424之类的匹配修复组件可以从诸如图44的匹配器4404之类的匹配器接收匹配文档集合的至少一部分，其包括无效匹配文档并且基于存储的标识每个文档中包含的项目的信息来评估每个文档，以移除至少一些无效匹配文档。所存储的信息例如可以是正向索引。

根据本文所描述的技术的各方面，可以在匹配器和最终排名器之间的各种不同位置中使用匹配修复组件。例如，图44图示出了其中匹配器4404提供匹配文档集合4420的流水线，匹配文档集合4420被使用初级排名器4422来评估以移除一些不相关文档，使用匹配修复组件4424来评估以移除无效匹配文档的至少一部分，然后使用最终排名器4426来评估以提供搜索结果集合。然而，搜索系统可以使用任何数目的排名器在其他位置处使用匹配修复。例如，可以将来自匹配器4404的匹配文档直接提供给匹配修复组件4424，而没有任何初级排名器首先移除文档。另外，可以将来自匹配修复组件4424的文档提供给在最终排名器4426之前的一个或多个初步排名器。任何和所有这样的变型都被认为是在本文所描述的技术的范围内。

在搜索中使用的资源(例如，成本、处理时间、存储装置等)可以与以有效的方式提供准确和相关的搜索结果的需求进行平衡。匹配修复组件的使用可以进一步优化搜索结果过程而不增加对附加资源的需要，并且最终可以减少当前使用的资源。简而言之，匹配修复组件旨在成为对潜在搜索结果进行进一步提炼的组件。匹配修复组件可以在过滤潜在搜索结果方面提供更好的性能；但是匹配修复组件可能需要附加存储装置，并且可能比初步排名器稍慢。然而，可以被匹配修复组件使用的任何附加资源(例如，更昂贵的)可以抵消或小于被诸如图44的最终排名器4426之类的后续的昂贵排名器节省的资源。例如，通过在匹配修复组件处花费稍多一点时间来提炼文档集合，后续排名器将需要更少的时间。此外，如果后续排名器接收和提炼的文档比没有进行匹配修复的文档更窄，则后续排名器可以使用更少的存储器。

在应用中，诸如图44的匹配修复组件4426之类的匹配修复组件可以从诸如匹配器4404的匹配器下游地接收文档集合(在匹配器和匹配修复组件之间没有或没有使用诸如初级排名器4420的初级排名器进行任何过滤)。如所提及的，文档集合可能包括无效匹配文档。在这一点处包含无效匹配文档在系统中是适当的，因为在适当时，即使结果稍微偏离，目标也是快速地移动，并且在适当时花费更多的时间来纠正结果，并且从而优化系统和结果。通过添加匹配修复组件，可以减少发送到后续排名器上的文档集合，并且初级排名器可以能够稍微更快地执行其任务，但是稍微不完美，因为匹配修复组件可以进一步提炼潜在搜索结果。如果潜在搜索结果是从初步排名器直接去往最终排名器而不使用匹配修复，则将需要花费附加的资源以确保发送给最终排名器的潜在搜索结果是非常准确的(例如，在10％的准确度内)。添加匹配修复组件允许初级排名器不那么准确，并且执行速度更快。

如以上所指出的，当前一阶段(例如，匹配器)是以基于信息论的压缩为基础时，匹配修复组件特别有用。在没有基于信息论的压缩引擎的系统例如发布列表中，匹配修复组件可能不是有价值的，因为使用发布列表的匹配器可以是确定性的，因此不存在无效匹配文档；意味着花费资源来获得完美的结果，所以没有机会给匹配修复。

匹配修复组件可以执行无损修复或有损修复。如本文所使用的，无损修复通常是指可以从压缩数据完美重建原始数据的情形。另一方面，有损修复在本文中是指使用不精确的近似来表示内容的情形。因此，匹配修复组件可以完全修复或不那么完美地修复。任何一种选择都可以在另一区域得到补偿。例如，如果匹配修复组件不那么完美地被执行(例如，将更高数目的无效匹配文档发送到后续排名器上)，那么可以在匹配器阶段中添加附加的位向量以减少在第一位置被发送到匹配修复组件上的误判的数目(无效匹配文档)。备选地，一个完美修复将允许系统在匹配器阶段使用较少的位向量，同时也意识到不向匹配修复组件发送太多的文档，这会在该阶段导致太多的成本。因此，在这种情形下，最大成本可以与文档的阈值数目相关联，从而使得匹配器阶段可以具有将允许发送最大数目的文档的尽可能少的位向量，直到发送到匹配修复组件上的文档的阈值数目。这将允许在匹配修理组件处的成本低于所指定的成本，并且由于可以发送的最大数目的文档被发送，所以在匹配器阶段还允许最少量的时间和成本。

一旦接收到文档集合，匹配修复组件就可以访问文档集合内的每个文档的表示。该表示可以是数据结构。该表示可以包括针对文档的正向索引。正向索引存储呈现每个文档/与每个文档相关联的一个或多个项目的列表。匹配修复组件然后可以将正向索引与搜索查询进行比较以确定文档是有效匹配文档还是无效匹配文档。有效匹配文档是与搜索查询的真实匹配，而无效匹配文档不是真实匹配。因此，匹配修复组件可以检查正向索引以确定针对文档的正向索引是否指示文档匹配搜索查询(例如，针对文档的正向索引是包含第一项目还是第二项目，等等)。在确定与搜索查询相关联的一个或多个项目不存在于文档中时，匹配修复组件可以将文档标识为无效匹配文档。无效匹配文档可以被匹配修复组件丢弃，而不会发送到后续排名器上。类似地，当在正向索引中存在与搜索查询相关联的一个或多个项目时，可以将与正向索引相关联的文档标识为有效匹配文档并将其发送到后续排名器上。

通常，评估针对每个文档的数据结构以确定它是有效的还是无效的匹配是不合理的。然而，在本申请中使用匹配器和初级排名器将可能的文档数目减少到各个地进行评估是可接受的数目。例如，假设在匹配修复组件上发送100个文档，并且50个是好的，50个是坏的。匹配修复组件可以访问例如文档表示的存储位置(例如，SSD)并评估针对每个文档的表示。整个文档可以被存储在SSD中，或者作为选择，每n个字可以被存储在SSD中(其中n是任何数字)。存储的文档量例如可以基于设计目标、匹配器和匹配修复组件之间的折衷等而是可配置的。

匹配修复组件的引入通过允许在匹配修复之前的阶段(例如，匹配器和初级排名器)执行比没有匹配修复的情况中更差的性能而为系统提供了成为更有效的机会。此外还存在优化系统的机会，诸如评估差错率的成本与存储器的成本。例如，如果对于特定的系统，标识出10％差错率的成本是1gb，并且20％差错率的成本是2gb，那么可以对系统进行优化以在这样一个的差错率下执行：所述差错率仍然有效但是利用了最佳存储器使得存储器/资源使用总量低于未压缩值。

现在转到图42，提供了图示出用于使用匹配修复以从概率匹配器下游移除无效匹配文档的方法4200的流程图。方法4200可以至少部分地使用例如图44的匹配修复组件4424被执行。最初，在块4202处，接收被发现与搜索查询的至少一部分相关的多个文档。多个文档可以包括一个或多个无效匹配文档。在块4204处，访问针对每个文档的表示。针对文档的表示包括文档内存在的项目。在块4206处，将每个文档内存在的项目和与搜索查询相关联的一个或多个项目进行比较。在块4208处，确定一个或多个无效匹配文档不包含与查询相关联的一个或多个项目。在块4210处，在确定一个或多个无效匹配文档不包含与该查询相关联的一个或多个项目时，从被发现与搜索查询的至少一部分相关的多个文档移除该一个或多个无效匹配文档。

现在转到图43，提供了图示出用于使用匹配修复以从概率匹配器下游移除无效匹配文档的另一方法4300的流程图。可以至少部分地使用例如图44的匹配修复组件4424来执行方法4300。最初，在块4302处，接收被发现与搜索查询的至少一部分相关的第一多个文档。第一多个文档可以包括一个或多个无效匹配文档。在块4304处，访问针对第一多个文档中的每个文档的正向索引。正向索引可以存储包含在每个文档中的一个或多个项目的列表。在块4306处，使用针对第一多个文档中的每个文档的正向索引，标识包含与搜索查询相关联的一个或多个项目的一个或多个有效匹配文档，并且在块4308处，使用针对第一多个文档中的每个文档的正向索引，标识不包含与搜索查询相关联的一个或多个项目的一个或多个无效匹配文档。在块4310处，从第一多个文档移除一个或多个无效匹配文档，以创建被发现与搜索查询的至少一部分相关的一个或多个文档的经过滤的集合。在块4312处，传送被发现与搜索查询的至少一部分相关的一个或多个文档的经过滤的集合，以用于为搜索查询对一个或多个文档的经过滤的集合的每个文档进行排名。

位向量搜索系统配置

上文讨论的基于位向量的搜索索引、初级排名器和匹配修复的使用允许取决于设计目标的各种配置。为了降低用于后续考虑的文档数目，需要每个阶段使用的数据，所以由匹配器使用的位向量数据被优化，以便廉价地减少所有可能文档的集合。然而基于信息值填充这些位向量，所以对位向量存储器的尺寸的压缩简单地增加了误判率。通过将缓冲器增加一个固定尺寸，误判率减半(对数线性)。误判结果最终在匹配修理阶段被移除，并且对于每个误判被移除存在一个固定的成本。初步排名是每项目评分的固定成本(例如，如果由初步排名器所使用的分数数据驻留在存储器中，则每个线程每个文档大约150ns)。

以下是基于不同设计目标的五种不同配置的示例，以说明基于位向量的搜索系统的弹性。如前所讨论，“D”是指存储消耗(例如，可以被每台机器索引的文档的数目)，“Q”是指处理速度(例如，每秒查询-QPS)。表1提供了配置的概要。

表1-配置

1.高DQ–有效web搜索

高DQ配置将总效率最大化。这种配置受到DDR总线吞吐率的限制。这种方法以180KDQ运行，在V13机器上以18K QPS每台机器1000万个文档。SSD的版本仍然受到DDR总线的限制，但是使用SSD来移除对于DDR容量的压力，从而以五分之一的速度允许五倍的文档数目。管道中有众多性能改进，这些改进涉及查询计划的更严格的控制和更积极的提前终止。这些变化每一个都可以使性能提高25％。提前终止以一种将对结果集合的相关性的损害减至最少的方式用于限制查询的成本。

2.深度DQ–尾部web搜索

深度DQ可以在高DQ的相同的盒子上操作，而不会对头部搜索能力产生显著影响，但是当速度更快的SSD可用时，这个参数会更强。深度DQ主要使用HDD，但是它确实在SSD中使用非常窄的位向量来发现要扫描的HDD区域。它使用元组和短语来避免低IDF项目(等同于长发布列表)。对于每个结果发生HDD搜查。对于IT网络索引，1000台机器可以掌控因特网。此方法适用于不太可能发现许多结果的查询，或者需要许多深度DQ位向量。

3.高Q-SubSQL

高Q配置类似于高DQ配置——除了它不使用SSD之外。没有SSD，则引擎被配置为一直具有较低的延迟。甚至像“列出麦当娜的所有朋友”这样的困难图表查询将在10毫秒内完成，并且大部分将在500微秒内完成。

这种配置可以被设计成在对象存储库内在本地工作，从而使得组合的实体具有NoSQL的许多性能(特别是像MongoDB这样的文档存储库——最流行的NoSQL软件)。

与到数据的通用接口相反，SubSQL通过提供低级别高性能原语来进一步远离典型的SQL。例如，Join操作不由SubSQ执行；然而，可以将复杂的类似join的性能构建到索引中，以提供低延迟和高性能的云操作。在SubSQL中主要使用更细粒度的排名和排序操作作为以低成本发现大型结果集合内的项目的方式。

4.高D-数字生活和数字工作。

个人文档和个人电子邮件的世界将与图表相交，这些图表将不仅允许沿着图表共享更多的内容，而且还帮助我们每个人发现我们需要的东西而不需要询问它。这种配置可以将(由SubSQL供给的)图表与由高D搜索引擎供给的文档集成在一起。每台机器持有大量的文档，但不能很快地供给它们。这对非共享个人文档而言运行非常良好，因为单个机器可以持有所有单个个人的文档，并且查询只需要访问该单个机器。每个人每天执行很少的查询，并且可以100,000个用户共享在单个机器上的租用。

当人们彼此共享文档时，就会发生重大突破。当一个人查询文档时，搜索通常将需要查看可能与我共享文档的任何人的文档。人们被亲密地分区到他们的图表中，并且非常广泛地共享文档的人们被复制到许多分区上。

一般操作环境

已经简要描述了本文所描述的技术的各方面的概述，下面描述在其中可以实现本文所描述的技术的各方面的示例性操作环境，以便为本文所描述的技术的各个方面提供一般上下文。首先参考图45，特别地，示出了用于实现本文所描述的技术的各方面的示例性操作环境，并且将其一般性地指定为计算设备4300。计算设备4300仅仅是合适的计算环境的一个示例，并且不旨在对本文所描述的技术的各方面的功能性或使用的范围建议任何限制。计算设备100也不应该被解释为具有与所图示的组件的任何一个或组合相关的任何依赖性或要求。

可以在包括诸如程序模块的计算机可执行指令的计算机代码或机器可用指令的一般上下文中描述本文所提供的技术的各方面述计算机代码或机器可用指令由计算机或诸如个人数据助理或其他手持设备的其他机器执行。通常，包括例程、程序、对象、组件、数据结构等的程序模块是指执行特定任务或实现特定抽象数据类型的代码。本文所描述的技术的各方面可以在包括手持设备、消费者电子设备、通用计算机、更专业的计算设备等的各种系统配置中被实践。本文所描述的技术的各方面也可以在分布式计算环境中被实践，其中由通过通信网络被链接的远程处理设备执行任务。

参照图45，计算设备4500包括直接或间接耦合以下设备的总线4510：存储器4512、一个或多个处理器4514、一个或多个呈现组件4516、输入/输出(IO)端口4518、输入/输出组件4520和说明性电源4522。总线4510表示可以是一个或多个总线(诸如地址总线、数据总线或它们的组合)的总线。虽然图45的各个块为了清楚起见用线条被示出，但实际上，勾画各种组件并不如此清楚，比喻来讲，线条更准确地是灰色和模糊的。例如，人们可以将诸如显示设备之类的呈现组件看作是I/O组件。同时，处理器具有存储器。发明人认识到这是本领域的性质，并且重申，图45的图示仅仅图示了可以结合本文所描述的技术的一个或多个方面而被使用的示例性计算设备。在诸如“工作站”、“服务器”、“膝上型计算机”、“手持设备”等这样的类别之间没有进行区分，因为所有这些都被预期在图45的范围内并且是对“计算设备”的引用。

计算设备4500通常包括各种计算机可读介质。计算机可读介质可以是可由计算设备4500访问的任何可用介质，并且包括易失性和非易失性介质、可移除和不可移除介质。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据之类的信息的任何方法或技术被实现的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存存储器或其他存储器技术、CD-ROM、数字多功能光盘(DVD)或其他光盘存储装置、磁盒、磁带、磁盘存储装置或其他磁存储设备或可用于存储所期望的信息并可由计算设备4500访问的任何其他介质。计算机存储介质本身不包含信号。通信介质通常以诸如载波或其他传送机制的已调制数据信号来体现计算机可读指令、数据结构、程序模块或其他数据，并且包括任何信息递送介质。术语“已调制数据信号”意指具有一个或多个其特性被设置或改变以便对信号中的信息进行编码的信号。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接之类的有线介质以及诸如声学、RF、红外线和其他无线介质之类的无线介质。上述任何介质的组合也应被包括在计算机可读介质的范围内。

存储器4512包括易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可移除的、不可移除的或它们的组合。示例性硬件设备包括固态存储器、硬盘驱动、光盘驱动等。计算设备4500包括从诸如存储器4512或I/O组件4520的各种实体读取数据的一个或多个处理器。呈现组件4516将数据指示呈现给用户或其他设备。示例性的呈现组件包括显示设备、扬声器、打印组件、振动组件等

I/O端口4518允许计算设备4500被逻辑地耦合到包括I/O组件4520的其他设备，其中一些可以被内置在其中。说明性组件包括麦克风、操纵杆、游戏摇杆、卫星天线、扫描仪、打印机、无线设备等。I/O组件4520可以提供处理由用户生成的空中手势、语音或其他生理输入的自然用户界面(NUI)。在一些情况中，可以将输入发射到适当的网络元件以供进一步处理。NUI可以实现以下任意组合：屏幕上和屏幕附近的语音识别、触摸和触笔识别、面部识别、生物识别、手势识别、与计算设备4500上的显示相关联的空中手势、头和眼睛跟踪以及触摸识别。计算设备4500可以配备有深度相机，诸如立体相机系统、红外相机系统、RGB相机系统以及这些相机的组合，以用于手势检测和标识。另外，计算设备4500可以配备有能够检测运动的加速度计或陀螺仪。可以将加速度计或陀螺仪的输出提供给计算设备4500的显示器以渲染沉浸式增强现实或虚拟现实。

已经与特定方面相关地描述了该技术，这些方面在所有方面都旨在是说明性的而不是限制性的。在不脱离本发明范围的情况下，备选配置对于本文所描述的技术的所属领域的普通技术人员而言将变得显而易见。

从上文将可以看出，本文所描述的技术非常适合于获得上述的所有目标和目的、以及对所述系统和方法而言明显且固有的其他优点。将理解的是，某些特征和子组合是实用的并且可以在不参考其他特征和子组合的情况下被使用。这被权利要求的范围所预期并且在权利要求的范围内。

Claims (19)

1.一种由具有一个或多个处理器的至少一个服务器执行的计算机实现的方法，所述方法包括：

运用匹配器以通过利用一个或多个项目查询存储关于多个文档的信息的搜索索引来从所述搜索索引标识匹配文档的集合，其中由所述匹配器标识的匹配文档的所述集合包括一个或多个有效匹配文档和一个或多个无效匹配文档，所述一个或多个有效匹配文档具有所述一个或多个项目中的至少一个项目，所述一个或多个无效匹配文档不具有所述一个或多个项目中的任何项目；

在基于所述一个或多个项目标识匹配文档的所述集合之后，访问针对匹配文档的所述集合中的每个匹配文档的表示，其中针对每个匹配文档的所述表示包括存在于该匹配文档内的多个项目；

将存在于每个匹配文档内的所述项目和所述一个或多个项目进行比较；

通过确定至少一个无效匹配文档不包括所述一个或多个项目中的任何项目来从所述一个或多个无效匹配文档标识所述至少一个无效匹配文档；以及

在标识所述至少一个无效匹配文档时，从被匹配文档的所述集合移除所述至少一个无效匹配文档。

2.根据权利要求1所述的方法，其中针对每个匹配文档的所述表示根据正向索引被访问。

3.根据权利要求1所述的方法，其中针对来自匹配文档的所述集合的第一匹配文档的所述表示包括被包括在所述第一匹配文档内的每个项目。

4.根据权利要求1所述的方法，其中针对来自匹配文档的所述集合的第一匹配文档的所述表示包括被包括在所述第一匹配文档内的项目的一部分。

5.根据权利要求1所述的方法，其中所述方法还包括：

基于所述一个或多个项目从所述搜索索引标识其他匹配文档；

生成针对来自匹配文档的所述集合的所述匹配文档中的每个匹配文档以及所述其他匹配文档中的每个匹配文档的初级排名；以及

在访问针对匹配文档的所述集合中的每个匹配文档的所述表示之前，基于所述初级排名移除所述其他匹配文档以免进一步的处理。

6.根据权利要求1所述的方法，其中所述方法还包括：在从匹配文档的所述集合移除所述至少一个无效匹配文档之后，返回标识保留在匹配文档的所述集合中的所述匹配文档的至少一部分的搜索结果的集合。

7.根据权利要求1所述的方法，其中所述方法还包括：在从匹配文档的所述集合移除所述至少一个无效匹配文档之后，生成针对保留在匹配文档的所述集合中的所述匹配文档的至少一部分中的每个匹配文档的排名。

8.根据权利要求7所述的方法，其中所述方法还包括：基于所述排名来提供搜索结果的集合。

9.存储计算机可用指令的一个或多个计算机存储介质，所述计算机可用指令在由一个或多个计算设备使用时，使得所述一个或多个计算设备执行方法，所述方法包括：

利用一个或多个项目查询位向量搜索索引以标识匹配文档的集合，所述位向量搜索索引包括多个位向量，每个位向量包括位阵列，所述位阵列存储针对被包含在文档中的项目的对应集合的信息，其中来自所述多个位向量中的给定位向量中的每个位指示与所述位对应的一个或多个文档是否包括来自针对所述给定位向量的项目的所述对应集合的至少一个项目，其中匹配文档的所述集合包括一个或多个有效匹配文档和一个或多个无效匹配文档，所述一个或多个有效匹配文档具有所述一个或多个项目中的至少一个项目，所述一个或多个无效匹配文档不具有所述一个或多个项目中的任何项目；

接收针对匹配文档的所述集合中的每个匹配文档的正向索引，其中所述正向索引包括被包括在每个匹配文档中的一个或多个项目；

使用针对匹配文档的所述集合中的每个匹配文档的所述正向索引，标识不包括所述一个或多个项目中的任何项目的至少一个无效匹配文档；以及

从匹配文档的所述集合移除所述至少一个无效匹配文档以创建一个或多个匹配文档的经过滤的集合。

10.根据权利要求9所述的介质，其中匹配文档的所述集合中的每个匹配文档使用初级排名器而被排名。

11.根据权利要求9所述的介质，其中针对来自匹配文档的所述集合的第一匹配文档的所述正向索引包括被包括在所述第一匹配文档中的每个项目。

12.根据权利要求9所述的介质，其中针对来自匹配文档的所述集合的第一匹配文档的所述正向索引包括被包括在所述第一匹配文档中的项目的一部分。

13.根据权利要求10所述的介质，其中所述初级排名器从匹配文档的所述集合移除一个或多个匹配文档。

14.根据权利要求9所述的介质，其中所述方法还包括：基于一个或多个匹配文档的所述经过滤的集合来返回搜索结果的集合。

15.根据权利要求9所述的介质，其中所述方法还包括：生成针对来自一个或多个匹配文档的所述经过滤的集合的所述一个或多个匹配文档的至少一部分中的每个匹配文档的排名。

16.根据权利要求15所述的介质，其中所述方法还包括：基于所述排名来提供搜索结果的集合。

17.一种计算机化系统，所述系统包括：

一个或多个处理器；以及

一个或多个计算机存储介质，所述一个或多个计算机存储介质存储计算机可用指令，所述计算机可用指令在由所述一个或多个处理器使用时，使得所述系统：

通过利用一个或多个项目查询搜索索引来从所述搜索索引标识匹配文档的集合，匹配文档的所述集合包括一个或多个有效匹配文档和一个或多个无效匹配文档，所述一个或多个有效匹配文档具有所述一个或多个项目中的至少一个项目，所述一个或多个无效匹配文档不具有所述一个或多个项目中的任何项目；

生成针对来自匹配文档的所述集合的每个匹配文档的初级排名；

基于所述初级排名从匹配文档的所述集合移除至少一个匹配文档以提供匹配文档的子集；

利用针对匹配文档的所述子集中的每个匹配文档的正向索引来标识匹配文档的所述子集中的至少一个无效匹配文档，并且移除所述至少一个无效匹配文档，以提供匹配文档的经过滤的集合；

生成针对匹配文档的所述经过滤的集合中的所述匹配文档的至少一部分的最终排名；以及

基于所述最终排名来提供搜索结果的集合。

18.根据权利要求17所述的系统，其中针对第一匹配文档的所述正向索引包括所述第一匹配文档内的每个项目。

19.根据权利要求17所述的系统，其中针对第一匹配文档的所述正向索引包括所述第一匹配文档内的项目的一部分。

Images