几个月前，我在这里问了一个类似的问题。但是我无法让它正常工作：
我尝试构建一个简单的文件名搜索。我希望用户可以搜索文件名的任何部分。
假设以下文件名已编入索引：
[1] My_file_2012.01.12.txt
[2] My_file_2012.01.05.txt
[3] My_file_2012.05.01.txt
[4] My_file_2012.08.27.txt
[5] My_file_2012.12.12.txt
[6] My_file_2011.12.12.txt
[7] file_01_2012.09.09.txt
然后用户可能会搜索：
"ile_20" (finds the first six documents)
"12.txt" (finds 1, 5, 6)
"12" followed by "01" (finds 1, 2, 3 - NOT 7)
"2012" followed by "01" (finds 1, 2, 3 - NOT 7)
（注意：是的，用户可能真的会搜索像“ile_20”这样的字符串......例如因为复制和粘贴错误）
因此，我使用 nGram-tokenizer 来索引文件名的每个部分。到目前为止，这工作正常。为了支持上面提到的“跟随”搜索，我需要一个尊重术语顺序的查询，无论这两个术语之间有多少文本（好吧，假设最多 100 个字符）。
由于带有“slop”的“text_phrase”查询不正确地尊重术语的顺序，我决定使用“span_near”查询。这在大多数情况下都可以正常工作。
在这里查看我的完整示例索引，包括。错误描述：点击
如上例所述，查询“'2012' 后跟 '01'”不起作用，因为 nGram 标记器为每个标记生成一个位置值，但这些值在用于“span_near”查询时不是很有用。在索引时，术语“2012”被分配给位置值（50），该位置值大于术语“01”的位置值（例如10）。由于 50 和 10 不按顺序排列，因此查询将没有结果。有序事物仅适用于具有相同长度的术语（例如“'12' 后跟 '01'”）或如果术语按长度排序（例如“'20' 后跟 '.12'” ）。
那么我怎样才能实现正确的搜索行为呢？我只希望能够在尊重术语顺序的同时搜索文件名的任何部分。
也许有一种方法可以告诉“span_near”不要使用该位置，而是使用“start_offset”？或者我可以使用另一个查询吗？