问题
问卷中有如下这样的文档，开发者想通过 match query 搜索这些文档来使用分数。
POST sample-index-test/_doc/1
{"first_name": "James","last_name" : "Osaka"
}以下是对上述文档的示例查询：
GET sample-index-test/_explain/1
{"query": {"match": {"first_name": "James"}}
}上述命令给出来的结果是：
{"_index": "sample-index-test","_id": "1","matched": true,"explanation": {"value": 0.2876821,"description": "weight(first_name:james in 0) [PerFieldSimilarity], result of:","details": [{"value": 0.2876821,"description": "score(freq=1.0), computed as boost * idf * tf from:","details": [{"value": 2.2,"description": "boost","details": []},{"value": 0.2876821,"description": "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:","details": [{"value": 1,"description": "n, number of documents containing term","details": []},{"value": 1,"description": "N, total number of documents with field","details": []}]},{"value": 0.45454544,"description": "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:","details": [{"value": 1,"description": "freq, occurrences of term within document","details": []},{"value": 1.2,"description": "k1, term saturation parameter","details": []},{"value": 0.75,"description": "b, length normalization parameter","details": []},{"value": 1,"description": "dl, length of field","details": []},{"value": 1,"description": "avgdl, average length of field","details": []}]}]}]}
}如你所知，Elasticsearch 根据相关性对文档进行评分。 在为该文档建立索引后，让我们现在搜索索引。我们目前只有一份关于该索引的文档。
GET sample-index-test/_search
{"query": {"match": {"first_name": "James"}}
}搜索后，你将看到以下结果：
{"took": 0,"timed_out": false,"_shards": {"total": 1,"successful": 1,"skipped": 0,"failed": 0},"hits": {"total": {"value": 1,"relation": "eq"},"max_score": 0.2876821,"hits": [{"_index": "sample-index-test","_id": "1","_score": 0.2876821,"_source": {"first_name": "James","last_name": "Osaka"}}]}
}我想提请你注意结果的 _score 字段。 如你所见，我们文档的 _score 值为 0.2876821 。 例如，当你多次更新文档时，假设我们使用以下请求更新了记录 10 次：
POST sample-index-test/_update/1
{"script" : "ctx._source.first_name = 'James'; ctx._source.last_name = 'Cena';"
}或者 POST sample-index-test/_doc/1
{"first_name": "James","last_name" : "Cena"
}不会有任何添加到索引中。 我们又有了一份文件，没有了。 我们刚刚更新了文档的 last_name 字段。 让我们再次进行精确搜索并尝试查看结果：
GET sample-index-test/_search
{"query": {"match": {"first_name": "James"}}
}上面的命令显示的结果是：
{"took": 0,"timed_out": false,"_shards": {"total": 1,"successful": 1,"skipped": 0,"failed": 0},"hits": {"total": {"value": 1,"relation": "eq"},"max_score": 0.046520013,"hits": [{"_index": "sample-index-test","_id": "1","_score": 0.046520013,"_source": {"first_name": "James","last_name": "Cena"}}]}
}正如你在此处看到的，分数发生了变化。 该文档的分数现在为 0.046520013 。 但根据 TF/IDF 计算，我们需要看到与我们的第一个搜索响应相同的分数。 因为当我们将它与文档的第一个状态进行比较时，没有任何变化。 即使我没有更改 first name 字段，我也只是更改了 last_name 字段并继续搜索 first_name 。 让我们对 _explain 端点进行更多挖掘。
GET sample-index-test/_explain/1
{"query": {"match": {"first_name": "James"}}
}Explain API 端点将为查询和特定文档计算得分解释。 上述请求的结果如下所示：
{"_index": "sample-index-test","_id": "1","matched": true,"explanation": {"value": 0.046520013,"description": "weight(first_name:james in 0) [PerFieldSimilarity], result of:","details": [{"value": 0.046520013,"description": "score(freq=1.0), computed as boost * idf * tf from:","details": [{"value": 2.2,"description": "boost","details": []},{"value": 0.046520017,"description": "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:","details": [{"value": 10,"description": "n, number of documents containing term","details": []},{"value": 10,"description": "N, total number of documents with field","details": []}]},{"value": 0.45454544,"description": "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:","details": [{"value": 1,"description": "freq, occurrences of term within document","details": []},{"value": 1.2,"description": "k1, term saturation parameter","details": []},{"value": 0.75,"description": "b, length normalization parameter","details": []},{"value": 1,"description": "dl, length of field","details": []},{"value": 1,"description": "avgdl, average length of field","details": []}]}]}]}
}去掉一些对我们来说是可选的部分。 现在让我们关注 IDF 计算。 如你所知，反向文档频率（Inverse Document Frequency）查看一个词在语料库中的常见（或不常见）程度。 这意味着我们将使用索引中的文档数来计算 IDF。有关 IDF 的更多知识，请阅读文章 “Elasticsearch：分布式计分”。
idf, computed as log(1 + (N - n + 0.5) / (n + 0.5))正如你在上面看到的，我们使用的是文档总数，但问题是我们在索引中有一个文档，但它显示的是 10。
{"value": 10,"description": "n, number of documents containing term","details": []},{"value": 10,"description": "N, total number of documents with field","details": []}因此，如果你使用此分数来计算其他服务的内容，这就是问题所在。
为什么会这样？
Elasticsearch 使用 Lucene 并将所有文档存储在段中。 段（segment）是不可变的，文档更新操作有两步过程。 更新文档时，将创建一个新文档，并将旧文档标记为已删除。 所以，当你在 Elasticsearch 索引中创建第一个文档时，Elasticsearch 会将它保存在一个段中，并且只有一个文档。 然后你更新同一个文档 10 次； 在任何更新操作中，Elasticsearch 都会在一个段中创建另一个文档，并将最旧的文档标记为已删除。 但是当你搜索索引时，你会从段中找到最新的文档状态。 暂时删除的文档数量为10。你会再次搜索到文档的最新状态，但 Elasticsearch 会继续在内部统计它们以进行IDF 计算。 因此，每次更新后，“the number of documents with field” 和 “number of documents containing term” 都会发生变化。
解决方案
如你所知，如果你知道什么是段，这个问题会在一段时间后自行解决。 所以，如果你想自己做这件事而不等待，你需要使用 _forcemerge。 我需要在这里放一个来自 Elasticsearch 文档的解释。在我们稍微等一段时间后，我们再去搜索，我们将会看到最终的分数和我们刚开始搜索的结果是一样的。
合并通过将其中的一些合并在一起来减少每个分片中的段数，并且还释放已删除文档所使用的空间。 合并通常会自动发生，但有时手动触发合并很有用。
我们建议只强制合并只读索引（意味着索引不再接收写入）。
为了对我们的索引执行 _forcemerge，我们使用了以下请求：
POST sample-index-test/_forcemerge根据你的索引大小，此请求可能需要一些时间，你可以通过在 Kibana 上执行以下请求来完成任务：
GET _tasks?actions=*forcemerge*&detailed另一种方法就是等待。 Elasticsearch 还有一个调度程序和合并策略来自动合并段。 在使用强制合并之前，我建议仔细阅读相关的官方文档。
最后，还有一个索引生命周期操作，用于使用策略执行强制合并操作。 根据你的逻辑，你可以使用不同的解决方案来获得更好的搜索评分结果。
