ElasticSearch fieldNorm 始终为 1

Question

我最近开始使用 elasticsearch，所以如果这是一个“基本”问题，我深表歉意。我也一直在将我们的 Material 从 ES 版本 1.3 迁移到 2.4(!)，所以在这个过程中有些东西已经坏了，并且查询等曾经工作不再工作(或给出“坏”结果) .我已经解决了其中的一些问题，但这是一个难题。

我读过 docs关于相关性评分是如何完成的。我的索引是用模式分词器处理的(只是分成单词)，然后用小写过滤器和 ngram 过滤器(最小长度 1，最大长度 3)命中。

现在如果我搜索字母“a”，那么我应该首先得到相对较短的文档，对吧？因此，例如“asian”(包含所需标记的两个实例)应该比“Astasia-abasia”(有六个)得分更高，因为按比例更多的标记等于“a”。比例性由词频和场范数来解释。伟大的!这就是我要的。但是……

事实上，“asian”甚至没有出现在前 5000 次点击中!当我查看 ?explain 时，我看到虽然存在 fieldNorm，但始终等于 1。这是为什么？我该如何解决？

我使用的索引代码在这里:

{
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 0,
        "analysis": {
            "analyzer": {
                "ngram_analyzer": {
                    "tokenizer": "pattern_tokenizer",
                    "filter": [ "lowercase", "ngram_filter" ]
                }
            },
            "tokenizer": {
                "pattern_tokenizer": {
                    "type": "pattern",
                    "pattern": "[\\]\\[{}()/ ,:;\"&]+"
                }
            },
            "filter": {
                "ngram_filter": {
                    "type": "ngram",
                    "min_gram": "1",
                    "max_gram": "3"
                }
            }
        }
    },
    "mappings": {
        "terms": {
            "properties": {
                "code": {
                    "analyzer": "ngram_analyzer",
                    "search_analyzer": "keyword",
                    "type": "string",
                    "norms": {
                        "enabled": true,
                        "loading": "eager"
                    }
                },
                "codeAbbr": {
                    "analyzer": "ngram_analyzer",
                    "search_analyzer": "keyword",
                    "type": "string",
                    "norms": {
                        "enabled": true,
                        "loading": "eager"
                    }
                },
                "term": {
                    "analyzer": "ngram_analyzer",
                    "search_analyzer": "keyword",
                    "type": "string",
                    "norms": {
                        "enabled": true,
                        "loading": "eager"
                    }
                }
            }
        }
    }
}

我觉得我什至不必指定 norms 属性(我觉得上面应该是默认属性)但这没关系。如果我把它们拿出来或放进去，答案是一样的。如何使 fieldNorm 正常工作？

Answer 1

结果结果和我预想的有些不同；我希望这个答案可以帮助其他人节省我花费的时间。我没有在我读过的文档中的任何地方看到这个，但是通过实验发现了它。我非常具体的问题可以通过使用 ngram 分词器而不是 ngram 过滤器来解决，但让我解释一下这是为什么。

问题是何时计算 fieldNorm，这也是 ngram 过滤器和分词器不同的原因之一。

fieldNorm是基于文档中的token数量，使用文档中给出的公式1/sqrt(#tokens)；分母中可能有也可能没有 +1，这取决于你问的是谁，但这对这个问题来说并不重要。重要的是 #tokens 图是在标记化之后但在过滤之前计算的。

据我所知，这仅对 ngram 和边缘 ngram 过滤器很重要，因为它们是唯一会更改文档中标记数量的过滤器，所以也许这就是文档中没有突出说明的原因。但这里有几个用例来解释为什么这很重要:

1. 假设您的文档包含长短语 - 也许是描述？ - 然后您使用标准分词器或其他任何东西进行分词。那么你的领域规范基本上是基于单词的数量。这可能就是你想要的；这取决于您的用例。这样，就字数而言，搜索有利于较短的文档(但使用长字不会影响您的搜索)。如果您改用 ngram 分词器，则 fieldNorm 与字符数成正比；所以如果你使用很多小词，而我使用更少但更大的词，我们的分数可能是一样的。通常不是你想要的。

2. 现在假设您的文档由单个单词或非常短的短语组成(比如我的)。如果您使用标准分词器进行分词，大多数文档的 fieldNorm 值为 1，因为它们是单个单词。但是，我希望我的搜索优先考虑较短的词(作为“常用词”的近似值)，所以这无济于事。相反，我将使用 ngram 分词器，这样较长的词会被推到底部，而较短的词会浮到顶部。