【问题标题】:How and why do Solr 'explain' values differ from the Solr score?Solr“解释”值如何以及为什么与 Solr 分数不同?
【发布时间】:2016-03-10 15:46:30
【问题描述】:

在使用“debugQuery=on”调试从 Solr 返回的分数时,我发现“解释”部分中的顶级值不一定与我看到的 Solr 生成的分数匹配。

例如,这里是两个文档的顶级调试信息:

114628: Object
  description: "sum of:"
  details: Array[2]
  match: true
  value: 20.542768

357547: Object
  description: "sum of:"
  details: Array[2]
  match: true
  value: 26.517654

但他们有分数:

114628: 20.542767
357547: 13.258826

我希望第二个文档与我的查询最相关,并且调试值似乎一致。但是,在我收到的最终分数中,该文档的分数已经被调低了。

调试值为何/如何与我看到的最终分数不同?有没有办法获得我期望的行为?

【问题讨论】:

  • 357547中的两个子节点是什么?
  • @MatsLindh 在每个文档的分数中都有很多提升和组合因素。

标签: search solr search-engine recommendation-engine


【解决方案1】:

这似乎在优化我收藏的核心后得到解决。

所有差异的调试分数似乎都减半了。我猜这是因为我的 Solr Cloud 集合存在跨两个节点复制的两个分片的问题。

未减半的分数可能是使用仅使用其中一个节点或分片中的文档计算的 IDF 因子。奇怪的是,调试结果中出现了正确的值,而不是最终的分数。

编辑这似乎只解决了一个案例的问题。我偶尔会在备用查询中看到同样的问题。现在所有受影响的分数正好是其调试分数的 1/4。

EDIT 2 这已被确定为 Lucene 中的错误。问题可以在这里找到:https://issues.apache.org/jira/browse/LUCENE-7132

解决此问题之前的解决方法是在 schema.xml 中使用 BM25 Similarity。

<similarity class="solr.BM25SimilarityFactory"/> 

【讨论】:

    猜你喜欢
    • 2011-10-09
    • 1970-01-01
    • 2013-01-23
    • 1970-01-01
    • 2022-06-20
    • 2014-07-22
    • 2013-06-26
    • 1970-01-01
    • 2012-04-06
    相关资源
    最近更新 更多