【ElasticSearch】 QueryString查询中文歧义词异常问题解决

最新推荐文章于 2024-04-15 02:48:35 发布

昕玫

最新推荐文章于 2024-04-15 02:48:35 发布

阅读量3.9k

点赞数

分类专栏：搜索引擎 elasticSearch

本文链接：https://blog.csdn.net/hereiskxm/article/details/50574207

版权

搜索引擎同时被 2 个专栏收录

19 篇文章 0 订阅

订阅专栏

elasticSearch

18 篇文章 1 订阅

订阅专栏

目前文档存储和查询使用的是IKAnalyse分词，IK这种分词算法对于歧义的处理比较完善，比如：”光远大厦“，会分割成”光”，“远“，”远大“，”大厦“。也就是说，它几乎把可能的分词都提供了，这大大提高了用户搜到自己想要的文章的命中率。

但今天发现一个问题，在使用queryString来查询这类歧义词的时候，经常会找不到：

<pre name="code" class="java">"query_string": {
              "query": "content:\"大厦\"",
              "fields": [
                "content"
              ],
              "analyzer": "ik"
            }

后发现是queryString中双引号引起的，修改成这样就可以了：

"query_string": {
              "query": "content:大厦",
              "fields": [
                "content"
              ],
              "analyzer": "ik"
            }

这是lucene已修正的一个BUG，queryString中的查询信息带双引号时用短语查询，而短语查询在中文上往往会出现奇怪的问题。短语查询是有序且词之间不能有分隔，这在专门的短语查询中可以用slop来处理，但是queryString中显然不能自定义这个参数。而且短语查询虽然也会对查询语句先做分词处理，但是对歧义的处理不完善，往往会查不到一些明显的结果。

因此处理方法为去掉引号。并且，用户在查询语句中用空格或者标点的时候，用多个子语句拼接查询。如用户查询“广州天气”，queryString设为“content:广州 AND content:天气”。

参考材料摘要（从百度知道找到的我也是醉了）

Q：如何避免lucene queryparser中文分词的缺陷

A：这个问题简单说来就是，对于一个连续的中文query，queryparser将Analyzer返回的Term序列构成了PhraseQuery（也有可能是MultiPhraseQuery），而PhraseQuery默认的匹配规则是要求Term序列在索引的文档中完全顺序匹配。这对于英文查询来说是可以接受的，因为queryparser在分析query时，首先通过AND、OR、NOT将query进行切分（这可以理解为queryparser 的第一层分析，这样切分后构成的TOP Query就是BooleanQuery），然后将切分后的subquery交由Analyzer分析（当然这要求是满足FieldQuery的情况，否则也可能是RangeQuery、WildcardQuery等），因为英文单词之间以空格分割，相当于OR查询，所以英文中的subquery就可以理解是个短语（比如由多个连字符连接的短语，或者是英文和数字接合的短语，在lucene查询语法中，显示的双引号之间的内容认为是短语）。但对中文来说，如果将subquery分析成PhraseQuery，就很成问题。比如subquery是”诺基亚N97“，如果构成PhraseQuery，则要求索引的文档中必须存在”诺基亚N97“，如果”诺基亚“和”N97“中间有其他词，就不算匹配。对于这个例子，是可以调整PhraseQuery的 slop参数来变相解决，但这种情况，使用AND BooleanQuery更合适，使用BooleanQuery在对文档打分上也要比PhraseQuery好很多。而对于query分词结果，也存在一些TermQuery之间是OR的情况，使用PhraseQuery显然也不合适。
如LUCENE-2458提到，这个bug会在3.1和4中被修复，修复方法是，只有显示通过双引号括起来的subquery才生成 PhraseQuery，否则可以派生子类来自定义处理。就目前使用来说，如果你使用IK做Analyzer，那么它提供的IKQueryParser是很好的替代方案，它构造的就是由AND和OR联合的BooleanQuery。但因为BooleanQuery没有考虑各个Term在文档中的位置关系，一味的根据词频计算得分，检索效果有时也不是很好。不知道大家是怎么处理的？我有想到去扩展它的Query和Scorer，不过看起来有些麻烦，暂且还没精力投入上去。

http://zhidao.baidu.com/link?url=iOH4hcU_VVUu2zPbPYaPq5pI8pT1zXwYOfdFOFbYAtAvYHhV6k-sSR0VOg4UUVTfaUzIboBEqcDE8hNGY6YqxGAk4JcaJXRTZixXRjnXQ0K