新一代搜索引擎项目 ZeroSearch 设计探索( 七 ) 本文作者：kaelhua

1 求交基准总数由于(A--tt-darkmode-color: #8F9BAB;">2 语法树节点个数很明显，笛卡尔积语法树的语法节点数会大于原语法树的节点个数， (A--tt-darkmode-color: #8F9BAB;">3 求交基准选取损耗对于求交基准的选取损耗很明显是跟语法树节点个数强相关的，由于笛卡尔积语法树的语法树节点远超原语法树，因此笛卡尔积语法树每次的求交基准选取损耗都会大于原语法树。
4 语法树节点操作个数笛卡尔积语法树层数降低为了 2 层，并且消除了第 3 层的 and 逻辑，整颗语法树只剩下最顶层的 and 逻辑。这一点有什么优势呢？我们在对 and 节点下的子节点进行求交的时候，往往都是一个节点一个节点的操作，因此如果只剩下最顶层的 and 节点的时候，一旦发现有节点经过跳跃查找后，跟求交基准的值不一致，可以很方便的提前就结束掉对于该求交基准 N 的查找，即可以很方便的提前排除掉求交基准 N 。
这一点对于笛卡尔积语法树来说是一个优势，可以减少排除一个基准的需要操作的节点个数。但是其只是降低了提前结束求交基准 N 的查找的代码实现的复杂度，对逻辑后验求交算法进行改进后同样可以实现。
改进的逻辑后验求交算法当我们得出一个求交基准时，各条倒排链都需要进行跳跃查找第一个大于等于求交基准 N 的值，我们可以通过在查找过程中就更新求交基准 N 的值，从而减少后续每条倒排链的查找次数
经过对比后可以发现，语法树打平之后其实并没有什么优势，并且会导致语法节点数指数型增长，因此我们目前认为使用原语法树配合逻辑后验求交算法就是内存检索引擎最佳的求交方式。这种想法当然有点坐井观天了，如果有读者有更好的方式，欢迎指点一二。
在了解完同义词，以及 3 层结构语法树的逻辑后验求交算法后，可以再简单了解一下其余的查询语法。
1 丢弃词可设置 and 节点下的 term 节点为丢弃词，这样的话，它不会参与求交。为什么不在 query 处理环节就把它丢弃掉呢？这里存在一些差别，一个 term 节点即便被设置丢弃词，我们依然会为它设置文档的命中信息，这对于相关性库（文档打分库）来说是有必要的。其实现方式为不参与逻辑后验以及求交基准的计算，但是会参与对于求交基准的倒排链跳跃查找。
2 动态非必留与必留词动态非必留是一种动态求交方式，例如一个 and 节点下挂了 3 个 term 节点 A,B,C（均不是丢弃词），动态非必留设置为 2 个 term 命中即可召回，那么一个文档只要 A,B 或者 A,C,或者 B,C 命中即可。
必留词是指在进行动态非必留求交时，该词必须是求交元素，一般我们会设置在一些核心词上面。例如 A 设置为了必留词的话，那么一个文档只要 A,B 或者 A,C 命中即可召回。动态非必留适用于一些召回不足的场景。其实现方式为对 and 节点下的 term 进行快速选择排序，在选取求交基准时，不再对所有 term 节点取 max ，而是取倒数第[必留个数]大的 term 的 pageid 弹出去。
3 位置约束可对一个 and 节点下的 term 设置位置约束。例如一个 and 节点下挂了 3 个 term 节点 A,B,C(均不是丢弃词) ，我们可以设置 B 存在 Pos=OneOfPos（A）+1 ，设置 C 存在 Pos=OneOfPos(B) + 2 。在我们的引擎里，如果是相邻 term 也设置了位置约束，那么它们会作为一个整体来进行位置约束判断，有点类似于多槽位的模板匹配。其实现方式为取出相关 term 的 pos 列表做二分查找。
and-or语法，配合丢弃词的求交方式，特别依赖于Query处理能力，丢弃词设置的好与坏会决定求交结果准确与否。例如对于Query：[深圳有哪些景点] ，如果深圳或者景点被设置了丢弃词，那么召回结果可能会完全偏移，这种属于在召回侧结果集就已经偏移，在相关性上面进行排序调整也十分吃力。 WeakAnd求交方式是我们目前处于计划中，但还未实现的一个功能，主要原因在于其标准实现方式与新引擎当前的任务模型有冲突，我们还未能找到方法将其良好的融合进去。对于WeakAnd的实现方式网上的资料很多，这里不想赘述。我们对它的认识在于这种求交方式可以缓解对于Query处理能力的依赖。查找算法设计正如上面提过的一样，求交损耗的本质为各条倒排链的跳跃查找次数，跳跃查找次数越少的，性能也就越好。语法树求交设计解决的问题是尽可能减少跳跃查找次数，而查找算法设计解决的问题是尽可能减少每次跳跃查找的消耗。