Solr:分数百分比

ale*_*exf 5 lucene search solr

首先,我已经看到了lucene 文档,它告诉我们不要以百分比形式生成分数:

人们经常希望根据 Lucene 分数计算“百分比”,以确定什么是“100% 完美”匹配与“50%”匹配。这也称为“标准化分数”

不要这样做。

严重地。不要再试图以这种方式思考你的问题,它不会有好结果。

由于这些建议,我使用了另一种方法来解决我的问题。

然而,lucene的论证有几点我不太明白为什么它们在某些情况下会出现问题。

对于这篇文章的情况,我可以很容易地理解为什么它不好:如果用户进行搜索并看到以下结果:

  • 产品A:5星
  • 产品B:2星
  • 产品C:1星

如果 ProductA 在第一次搜索后被删除,那么用户下次再来时,如果看到以下结果,他会感到惊讶:

  • 产品B:5星
  • 产品C:3星

所以,这个问题正是Lucene的文档所指出的


现在,我们再举一个例子。

想象一下,我们有一个电子商务网站,它使用“经典搜索”语音搜索相结合。此处的拼音搜索是为了避免由于拼写错误而导致最大数量的空结果。相对于经典搜索的分数,拼音结果的分数非常低。

在这种情况下,第一个想法是只返回至少具有最高分数 10% 的结果。即使使用经典搜索,低于此阈值的结果也不会被视为与我们相关。

如果我这样做,我就不会遇到上述帖子的问题,因为如果删除文档,如果旧的第二个产品成为第一个产品,那么似乎合乎逻辑,并且用户不会感到非常惊讶(这与以下行为相同)如果我将分数保留为浮点值)。

此外,如果语音搜索的分数非常低,正如我们预期的那样,我们将保持相同的行为,仅返回相关分数。


所以我的问题是:像 Lucene 建议的那样标准化分数总是不好吗?我的例子是一个例外还是即使对于我的例子来说这样做也是一个坏主意?

fra*_*ces 5

正如您所讨论的,Lucene 得分值仅与表达一匹配中每个匹配的相对强度相关。在一组特定搜索结果的上下文中,特定记录的分数没有绝对意义

因此,唯一合适的分数标准化是标准化结果集中文档的相关性之间的关系,即使这样,您也需要非常小心地使用此信息。

考虑这个结果集,我们在其中检查每个记录的分数与前一个结果的比较:

ProductA         (Let's pretend the score is 10)
ProductB:  97%   (9.7)
ProductC:   8.5% (.82)
ProductD: 100%   (.82)
ProductE: 100%   (.82)
ProductF:  24%   (.2)
Run Code Online (Sandbox Code Playgroud)

在这种情况下,前两个结果具有非常相似的分数,而接下来的三个结果具有相同的分数但显着落后。这些数字显然不会与在线购物者分享,但ProductC 和 ProductF 的相对分数较低,表明下降幅度足够大,您可以使用它们来通知其他显示选项。也许 ProductA 和 ProductB 会以比其他字体更大的字体显示。如果在急剧下跌之前只有一种产品出现,它可能会得到更特别的突出显示。

我警告不要在这种搜索中完全抑制相对较低得分的结果。正如您在示例中已经证明的那样,相对分数可能会产生误导,除非您的相关性经过非常精细的调整,否则最相关的文档可能并不总是最合适的。如果由于单个记录碰巧重复搜索词足够多次而赢得了出色的分数,从而导致所需的结果被丢弃,那么这对您没有任何好处,这是一个真正的威胁。

例如,"Hamilton Beach Three-In-One Convection Toaster Oven"将在搜索 时匹配八分之一的单词toaster,而"ToastMaster Toast Toaster Toasting Machine TOASTER"根据您的索引方式,将匹配多达七分之五的单词。(这两个产品名称都是完全虚构的,但我希望第二个名称看起来不太有信誉。)

此外,所有返回的文档都是匹配的,无论它们的分数有多低。有时,排名较低的结果是用户真正想要的黑马发现。除非您告诉他们,否则用户不会明白除了他们所看到的之外还有匹配的文档,因此您可能会将尾随结果隐藏在“第 2 页”或剪切后面,但您可能不想阻止它们。让用户了解结果集的大小还可以帮助他们决定如何微调搜索。使用分数的显着下降作为分页的阈值可能非常有趣,但可能是一个具有挑战性的实现。


fem*_*gon 3

问题是,你如何确定你的截止点,它意味着什么?

看一个例子可能会更容易。假设我正在尝试按姓氏查找人。我要寻找:

  • “史密斯菲尔德”

我有以下文件,我认为它们都非常匹配:

  • 史密斯菲尔德 - 完全匹配
  • smithfielde - 非常接近,听起来很相似,只有一个(无声)字母缺失
  • smythfield - 非常接近,发音相似,一个元音改变了
  • smithfelt - 几个字母关闭,但仍然很接近并且听起来很相似
  • snithfield - 听起来不太像,但只有一个字母差。也许是一个错字。
  • smittfield - 再说一遍,听起来不太相似,可能是拼写错误或拼写错误
  • smythfelt - 拼写有点错误,但可能是误听
  • smithfieldings - 相同的前缀

所以,我有四件事需要匹配。应确保精确匹配以获得最高分,并且我们需要前缀匹配、模糊匹配和声音相似匹配。那么我们来搜索一下:

smithfield smithfield* smithfield~2 metaphone:sm0flt
Run Code Online (Sandbox Code Playgroud)

结果

  • 史密斯菲尔德 ::: 2.3430576
  • 史密斯菲尔德 ::: 0.97367656
  • 史密斯菲尔德 ::: 0.5657166
  • 史密斯费尔特 ::: 0.50767094

< 10% - 不显示

  • 斯尼菲尔德 ::: 0.2137136
  • 斯米特菲尔德 ::: 0.2137136
  • 史密斯费尔特 ::: 0.0691447
  • 史密斯菲尔德 ::: 0.041700535

我认为史密斯菲尔德是一场相当不错的比赛,但距离晋级还差得很远!不到最大值的2% ,更不用说 10%!好的,让我们尝试一下增强

smithfield^4 smithfield*^2 smithfield~2 metaphone:sm0flt
Run Code Online (Sandbox Code Playgroud)

结果

  • 史密斯菲尔德 ::: 2.8812196
  • 史密斯菲尔德 ::: 0.5907072
  • 史密斯菲尔德 ::: 0.30413133

< 10% - 不显示

  • 史密斯费尔特::0.2729258
  • 斯尼斯菲尔德 ::: 0.11489322
  • 斯米特菲尔德 ::: 0.11489322
  • 史密斯菲尔德 ::: 0.044836726
  • 史密斯费尔特 ::: 0.037172448

那就更糟了!

在生产中,问题会更加严重。在现实世界中,您可能正在处理长而复杂的查询和全文文档。字段长度、匹配重复次数、协调因素、提升和大量查询术语,所有这些都会影响分数。

尽管第二个结果仍然是一个有意义、有趣的结果,但看到第一个结果的分数比第二个结果高一个数量级确实并不奇怪。无法保证分数的均匀分布,因此我们不知道 10% 的数字意味着什么。lucene 的评分算法往往会在使差异变得更大和更好方面犯错误。


总是不好吗?我会说是的。在我看来,总是有两个更好的选择。

1 - 使用良好的查询控制结果集。如果你很好地构建了你的查询,那么将提供结果的截止值,不是因为分数中的某些任意截止值,而是因为它根本不会被评分。

2 - 如果您不想这样做,那么通过在任意点切断结果真的能获得任何好处吗?用户非常善于识别搜索结果何时超出了极限。用户无法找到他们想要的东西是一个严重的烦恼。只要排序良好,显示太多结果通常不是问题。