elasticsearch ElasticSearch fieldNorm始终为1

我最近开始使用elasticsearch，如果这是一个“基本”问题，我深表歉意。我也在将我们的资料从ES版本1.3迁移到2.4（！）的过程中，因此在这个过程中有些东西已经坏掉了，过去有用的查询/等不再有用（或给出“坏”结果）。我已经解决了其中一些问题，但这是个难题

我读过关于相关性评分是如何完成的。我的索引是用模式标记器处理的（只需拆分成单词），然后用小写过滤器和ngram过滤器（最小长度1，最大长度3）

现在如果我搜索字母“a”，那么我应该先得到相对较短的文档，对吗？因此，例如“asian”（其中包含两个所需代币实例）的得分应该高于“Astasia abasia”（其中有六个），因为其代币的比例大于“a”。比例性由术语频率和场范数来解释。伟大的这就是我想要的。但是

事实上，“亚洲人”甚至没有出现在前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正常工作？

答案与我预期的有所不同；我希望这个答案能帮助其他人节省我的时间。我在我读过的文档中没有看到这一点，但通过实验发现了这一点。我非常具体的问题可以通过使用ngram标记器而不是ngram过滤器来解决，但让我解释一下原因

问题在于何时计算fieldNorm，这也是ngram过滤器和令牌化器不同的原因之一

fieldNorm

基于文档中的令牌数量，使用文档

1/sqrt（#令牌）

中给出的公式；分母中可能有+1，也可能没有+1，这取决于你问的人，但这对这个问题并不重要。重要的是，

#tokens

图是在标记化之后但在过滤之前计算的

据我所知，这只对ngram和edge ngram过滤器很重要，因为它们是唯一改变文档中令牌数量的过滤器，所以这可能就是为什么文档中没有重点解释的原因。但这里有几个用例来解释为什么这很重要：

假设您的文档包含很长的短语-可能是描述你可以用一个标准的标记器或其他什么东西来标记。那么你的字段规范基本上是基于单词的数量。这可能是你想要的；这取决于您的用例。这样，搜索在字数方面倾向于较短的文档（但使用较长的字数不会影响搜索）。如果改用ngram标记器，则fieldNorm与字符数成比例；所以如果你用很多小词，我用更少但更大的词，我们的分数可能是一样的。通常不是你想要的

现在假设您的文档由单个单词或非常短的短语组成（如我的）。如果使用标准标记器进行标记，大多数文档都将具有fieldNorm 1，因为它们是单个单词。然而，我希望我的搜索优先考虑较短的单词（作为“常用词”的近似值），所以这没有帮助。相反，我将使用ngram标记器，这样较长的单词会被推到底部，较短的单词会被推到顶部

---

你能分享你的疑问吗？你解释的结果是什么？您还可以检查其中一个字段中存在多少术语吗？您可以在字段上进行术语聚合，并检查“sum\u other\u doc\u count”的值@jay感谢您的回复，但不幸的是，我直到下班回家后才收到它，周六无法获得确切的查询和结果。也就是说，我相信相关信息在上述问题中。该查询是一个带有单个术语“a”的匹配查询，因此我要求术语数量的原因是——fieldNorm计算为1/平方根（术语数量）。这意味着术语的数量越大，fieldNorm越小。所有字段都使用ngrams，这意味着术语的数量将非常多。你看到的值1——根据我所读到的，该值是默认的索引时间提升1+字段范数。该值存储在单个字节中，因此会丢失精度。