Lucene.NET 2.9 - MultiFieldQueryParser，提升字段，词干和前缀答案

【问题标题】：Lucene.NET 2.9 - MultiFieldQueryParser, boosted fields, stemming and prefixesLucene.NET 2.9 - MultiFieldQueryParser，提升字段，词干和前缀
【发布时间】：2015-03-10 13:34:44
【问题描述】：

我有一个系统，其中搜索查询具有不同提升值的多个字段。它在 Lucene.NET 2.9.4 上运行，因为它是一个 Umbraco (6.x) 站点，这就是 CMS 使用的 Lucene.NET 版本。

我的客户问我是否可以添加词干提取，所以我编写了一个自定义分析器来执行标准/小写/停止/PorterStemmer。词干过滤器似乎工作正常。

但是现在，当我尝试将我的新分析器与 MultiFieldQueryParser 一起使用时，它什么也没找到。

MultiFieldQueryParser 正在返回一个包含词干的查询 - 例如。如果我搜索“图”，我得到的作为它返回的查询的一部分是：

keywords:figur^4.0 Title:figur^3.0 Collection:figur^2.0

即它正在搜索正确的字段并应用正确的提升，但尝试在包含非词干词的索引上对词干词进行精确搜索。

我认为 MultiFieldQueryParser 真正需要的是返回 PrefixQuery 类型的子句列表。所以它会输出一个类似

的查询

keywords:figur*^4.0 Title:figur*^3.0 Collection:figur*^2.0

如果我尝试在术语末尾添加一个通配符并将其输入解析器，则词干分析器不会启动。即它会构建一个查询来查找“figure*”。

有什么方法可以结合 MultiFieldQueryParser 提升和前缀查询？

【问题讨论】：

标签： lucene lucene.net prefix information-retrieval

【解决方案1】：

您需要使用自定义分析器重新索引。仅在查询时应用词干分析器是没有用的。您可以使用通配符拼凑一些东西，但它仍然是一个丑陋、不可靠的拼贴。

【讨论】：

好电话。虽然 - 关于它是一个丑陋的不可靠的组合只是意见 - 这是有损的，我可以想象我的客户明天会回到我身边，当他们说“当我做这两个时我没有什么可回来的不同的词，匹配的并不总是第一个？你能解决它吗？ - 我们正在处理自然语言。丑陋不可靠的英语。 :)
好吧，我想它的丑陋是我的看法。尽管它显然引入了不可靠性，但除了额外的搜索结果之外，您将无法搜索诸如阴谋或天空之类的词（例如，词干：“conspiraci”、“sky”）。并且尝试将查询解析器生成的查询重新处理为一组通配符后分析往往会变得混乱，尤其是当您引入嵌套布尔查询等时。