Elasticsearch搜索词组，如何更准？

更好的阅读体验，打开【阅读原文】，在PC上浏览

Lucene用了很久，其版本更新也很快。在ES出来之后，直接使用Lucene的时候就比较少了，更多的就在ES框架下一站式完成，ES目前在项目中几乎占据了半壁江山。

ES的功能很强大，使用过程中，有一个问题是绕不过的：就是中文分词。这是至关重要的一个问题，直接影响搜索结果的准确和召回。

一般来讲，分词的问题本身目前解决的已经相当不错了，大家用的比较多的是jieba分词，还有清华、斯坦福、复旦等开源的中文分词。如果要在ES中使用jieba分词，就需要定制一个ES的分词插件，将jieba分词load到ES中。

几年之前，因为项目需要，我撸过一个简单的ES插件，在github上开源: jieba分词ES插件，也有一些用户在使用，期间也在断断续续的更新。

其中的关键，通过阅读代码就会发现，在处理token的过程中，有以下属性需要处理：

• CharTermAttribute

• OffsetAttribute

• TypeAttribute

• PositionIncrementAttribute

分别代表了分词的结果的最小单元：term，分词的offset：startOffset和endOffset，以及词性，例如word、或者数字、字母等等。

最后一个属性PositionIncrementAttribute比较难以理解，在特定的场合下才需要特殊的处理，大部分情况下默认的结果就可以，但在特定的场合下，会丢掉部分的文档。下文我们就详细解释这个属性，通过例子来说明这个是如何产生影响的，以及该如何解决。

我们先解释一下分词的结果，使用到的ES，以及插件版本如下：

• elasticsearch-6.4.0

• elasticsearch-jieba-plugin-6.4.0

安装好插件，启动ES：

有如下输出，则说明插件加载成功：

准备好示例文档：

jieba包括两种分词模式：

• index模式，适用于索引的分词，可以分词更多的term，照顾召回。

• search模式，适用于查询的分词，分词结果没有交叉，更多考虑的是准确率的方面。

我们验证一下分词插件，以及两种模式的影响，通过如下命令，我们先看看search模式的分词效果：

查看输出：

分词结果中，token对应的就是term属性，start_offset和end_offset对应的就是Offset属性，type类似于词性。这几个都是比较好理解的，那么position是什么含义呢？通过观察：

position是分词之后term/token的先对位置，代表了顺序和距离。

这个例子中产品和副经理是紧挨着的，中间没有间隔。也就意味着如下的查询

能够搜到我们的示例文档。这里要注意，slop默认是0，可以不写。当slop要求为0的时候，就要求搜索词组产品经理在文档中连起来的，这个时候命中的是产品经理，而不是产品|群|经理，|表示token分割。如果设置slop为1，则产品|群|经理也会命中。slop的大小，就是position的大小差异。

看下index模式，要更加复杂，PositionIncrement的作用也是在这里体现。同样是上面的文本：

结果如下，需要仔细对比和search的差异。

因为index模式的原因，产品副经理分为了产品|副经理|经理。这个时候，合理的position就十分重要了。通过我最新的插件的实现，这里的position分别是14,15,16。这是正确的，因为要正确处理下面的结果。

当我们执行如下搜索：

命中我们的示例文本，无间隔的产品经理可以命中，并且可以高亮，但是产品副经理没有命中，也没有高亮。

再看这个例子：

则，无间隔的产品经理可以命中，并且可以高亮；同时，产品副经理有命中，产品和经理分别高亮。这两个例子的差别，大家要细细体会。

那么如何正确的处理position呢，关键就在于PositionIncrementAttribute属性的处理，通常我们使用search模式类似的分词是不会遇到问题的，即使使用默认的PositionIncrementAttribute的实现：根据分词得到的token，每次+1，从而得到position。

但默认的实现，遇到如下的情况，就会出现问题：

示例文本：

如果采用默认的实现，则输出：

根据这样的position，我们如下的查询，就找不到这个示例文档，从而产生丢数据的现象。

本来中国人民在示例中是无间隔紧邻的，但是由于position解析的问题，直接导致slop已经变成了4，所以必须制定查询中的slop比较大，才能够返回正确的文档，但这里Rank也会受到影响。

看一下正确position的结果。

其中，中国是0，人民是1，就可以命中了。

基本上，在处理token的时候，要判断``是1，还是0。这里的Lucene实现机制不好，对于分词的实现约束比较多，并且只考虑了英文。现在的实现，优先考虑了召回。极个别情况，还是会有些准确率的问题。

另外一个层面，要从词的切分的角度处理，分词的结果应该提供一个最细粒度的、无交叉的切分，这个方式用来做索引，会比较好一些。那这样，默认的PositionIncrement也是能够满足需求的。接下来看看，jieba是否可以改造一下，支持第三种分词的模式：最细粒度的、无交叉的切分。