为何通配符搜索得分不计算TF/IDF，低boost部分匹配反超精准匹配？

你观察到的现象本质是Lucene（以及基于它的Elasticsearch等工具）对两类查询的得分逻辑设计不同：

1. 通配符查询的得分逻辑 #

通配符、前缀、模糊这类动态匹配的非精准查询，默认会被包装成ConstantScoreQuery执行。这类查询的核心特点是：

• 无法提前统计匹配词的词频（TF）、文档频率（IDF）等统计信息（因为匹配的词是查询时动态生成的）；
• 直接将设置的boost值作为最终得分，不参与任何统计类的得分计算。

你的调试信息也验证了这一点：

45.0 = max of:
    45.0 = name_text_de:*damen*^45.0

这里的45就是你设置的boost值，直接作为该查询的得分。

2. 精准匹配的得分逻辑 #

精准term查询属于精确词项查询，会采用标准的相似度算法（比如默认的BM25）计算得分，boost值只是作为乘数，参与整个统计得分的计算：
最终得分 = boost × IDF × TF（加上长度归一化等修正因子）

你的调试信息里，boost设为50，但经过IDF（该词在3838个文档中出现，IDF值仅1.538）、TF（文档中仅出现1次，TF值0.529）的稀释后，最终得分变成了50 × 1.538 × 0.529 ≈ 40.7，反而低于通配符查询的45。

3. 为什么要这样设计？ #

• 通配符查询召回的结果精度低，且动态匹配的计算成本高，用固定得分可以简化逻辑、提升性能，同时让boost直接作用于得分，方便快速调整结果优先级；
• 精准匹配的核心是精确召回+精细排序，基于统计的相似度算法能更合理地衡量文档与查询的相关性，boost作为权重因子来放大这种相关性得分。

解决思路：让精准匹配获得固定得分 #

如果希望精准匹配的得分不被统计因子稀释，直接用boost值作为得分，可以把term查询包装在constant_score中：

{
  "constant_score": {
    "filter": { "term": { "name_text_de": "dam" } },
    "boost": 50
  }
}

这样精准匹配的得分就会是50，超过通配符查询的45。

内容的提问来源于stack exchange，提问作者rustyfinger