Java 短语查询和使用木瓦过滤器有什么区别？

我目前正在使用lucene为网页编制索引。其目的是能够快速提取包含特定表达式（通常为1、2或3个单词）的页面，以及页面中还有哪些其他单词（或1到3个单词的组合）。 这将用于构建/丰富/修改同义词表（固定词汇表）

从我找到的文章来看，问题似乎是找不到（或用木瓦）

Lucene有a、a和a，它们似乎与此任务相关

从中，我了解到Lucene还可以搜索由固定数量的单词分隔的术语（称为slop）。给出了一个例子

然而，我不清楚这些方法之间的区别？它们是根本不同的，还是您必须做出性能/索引大小的选择

ShingleMatrixFilter和ShingleFilter之间有什么区别

---

希望Lucene大师能找到这个问题，并回答；-）

使用短语与使用木瓦之间的差异主要涉及性能和评分

在索引中有单个单词的典型情况下使用短语查询（如“foo-bar”）时，短语查询必须遍历“foo”和“bar”的倒排索引，找到包含这两个术语的文档，然后遍历它们在这些文档中的位置列表，以查找“foo”出现在“bar”之前的位置.

这对性能和评分都有一定的影响：

位置（.prx）必须索引和搜索，这就像反向索引的附加“维度”，这将增加索引和搜索时间

由于反向索引中只显示单个术语，因此没有计算实际的“短语IDF”（这可能不会影响您）。因此，这是基于项IDF的和来近似的

另一方面，如果你使用木瓦，你也在索引单词n-grams，换句话说，如果你的木瓦大小达到2，你也会在索引中有“foo-bar”这样的术语。这意味着对于这个短语查询，它将被解析为一个简单的TermQuery，而不使用任何位置列表。由于它现在是一个“真正的术语”，IDF一词将是准确的，因为我们确切地知道这个“术语”存在多少文档

但使用木瓦也有一些成本：

增加术语词典、术语索引和帖子列表的大小，尽管这可能是一个公平的折衷，尤其是如果您完全使用Field.setIndexOptions禁用位置

索引分析阶段的一些额外成本：虽然ShingleFilter优化得很好，速度也很快

没有明显的方法来计算“草率短语查询”或不精确短语匹配，尽管这可以近似，例如，对于大小为2的“foo bar baz”短语，您将有两个标记：foo_bar、bar_baz，您可以通过lucene的一些其他查询（如BooleanQuery）实现搜索，以获得不精确的近似值

一般来说，使用木瓦或公共图等索引单词ngram只是一种折衷（相当专业），以降低位置查询的成本或提高短语评分

但这种东西有真实的使用案例，这里有一个很好的例子：

---

感谢您的详细回答（已接受）。你能评论一下ShingleFilter和ShingleMatrixFilter的区别吗？解释得很好。这篇文章通过一些实际例子帮助我理解了带状疱疹：