Elasticsearch中任意查询的“实际命中”（不仅仅是匹配的文档）计数

Question

这个问题真的让我很沮丧。我很长一段时间都想找到一个解决方案，但无论我在哪里试图找到人们提出的相同问题，他们要么想要一些不同的东西（比如这里或这里），要么得不到解决问题的答案（比如这里）。

我需要什么

我想知道我的搜索总共有多少命中，与所使用的查询类型无关。我说的不是您总是从ES得到的命中数，也就是为该查询找到的文档数，而是匹配我的查询的文档特征的出现次数。< br >例如，我可以有两个带有文本和文本字段“description”的文档，两个文档都包含单词< code>hero，但其中一个包含两次。< br >就像这个最小的例子:

索引映射:

PUT /sample
{
    "settings": {
        "index" : {
            "number_of_shards" : 1,
            "number_of_replicas" : 0
        }
    },
    "mappings": {
        "doc": {
            "properties": {
                "name": { "type": "keyword" },
                "description": { "type": "text" }
            }
        }
    }
}

两个html" target="_blank">示例文档：

POST /sample/doc
{
    "name": "Jack Beauregard",
    "description": "An aging hero"
}


POST /sample/doc
{
    "name": "Master Splinter",
    "description": "This rat is a hero, a real hero!"
}

...和查询:

POST /sample/_search
{
    "query": {
        "match": { "description": "hero" }
    },
    "_source": false
}

...这给了我:

{
    "took": 2,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": 2,
        "max_score": 0.22396864,
        "hits": [
            {
                "_index": "sample",
                "_type": "doc",
                "_id": "hoDsm2oB22SyyA49oDe_",
                "_score": 0.22396864
            },
            {
                "_index": "sample",
                "_type": "doc",
                "_id": "h4Dsm2oB22SyyA49xDf8",
                "_score": 0.22227617
            }
        ]
    }
}

因此有两个命中（“total”：2），这是正确的，因为查询匹配两个文档。但是我想知道我的查询在每个文档中匹配了多少次（或其总和），在本例中是3次，因为第二个文档包含了两次搜索词
重要信息：这只是一个简单的例子。但我希望它适用于任何类型的查询和映射，也适用于具有＜code＞inner_hits＜/code＞的嵌套文档
我没想到这会如此困难，因为无论如何，这一定是ES在搜索过程中遇到的信息，对吧？我的意思是，它将文档中点击次数较多的文档排序得更高，所以为什么我不能得到这些点击次数的计数
我想把它们称为“内部命中”，但这是另一个ES功能的名称（见下文）。

我尝试过/可以尝试的（但它很丑陋）

• 我可以使用突出显示（无论如何我都会这样做），并尝试使荧光笔为每个“内部匹配”生成一个突出显示（并且不要将它们组合在一起），然后对完整的搜索结果集进行后处理并计算所有突出显示 -

对于任意查询，有没有一种通用的方法来实现这一点？我将非常感谢任何建议。我甚至打算通过修改排名或使用脚本字段等方式来解决这个问题。

多谢了！

Answer 1

由于糟糕的性能，我绝对不建议将其用于任何实际用途，但在解释API的结果中，该数据在术语频率计算中是技术上可用的。参见什么是相关性？概念解释和使用解释API。