0

也许这是一个简单的问题，但我不知道如何处理这种情况。

我想在 Lucene 索引中搜索文档，其中我的文档有一个名为的存储字段content，其文本以这种方式标记：

DELIMITER_TOKEN
TOKEN_1                |
TOKEN_2                |  <- this is the first "block"
...                    |     (bounded by some delimiter tokens)
TOKEN_N                |
DELIMITER_TOKEN
TOKEN_1                |
TOKEN_2                |  <- another block...
...                    |
DELIMITER_TOKEN
...                    |  <- and so on...

我想搜索包含例如TOKEN_1,TOKEN_3和TOKEN_8, 但在同一DELIMITER_TOKEN对之间的文档。

我的第一个想法是，我可以SpanNearQuery为搜索词创建一个带有大斜率的词，然后我可以创建一个SpanNotQuery我可以用来从上一个查询的匹配项中排除重叠的 DELIMITER_TOKENs，这样我就不会得到像这样的匹配项

DELIMITER_TOKEN
TOKEN_1
TOKEN_3
DELIMITER_TOKEN
TOKEN_8

我想这个解决方案应该有效。

但有时我必须处理更复杂的情况，例如搜索

TOKEN_1 TOKEN_2 TOKEN_8 DELIMITER_TOKEN TOKEN_3 DELIMITER_TOKEN

...这意味着我想在包含（除其他外）TOKEN_1、TOKEN_2 和 TOKEN_8 令牌的文档中找到一个“块”，并且它旁边有一个包含 TOKEN_3（除其他外）的块。

我的想法是在简单的情况下使用 SpanNotQueries，并像这样创建一个 SpanNearQuery：

new SpanNearQuery(new SpanQuery[] {
        queryForFirstBlock,
        queryForDelimiter,
        queryForSecondBlock}
        0,
        true);

但我认为这行不通，因为对第一个块的查询不一定跨越整个块。我想我将不得不在最后一个 Near Query 中引入一些 slop 来处理这些情况。但是如果我选择引入大于 0 的 slop，那么它将允许这样的匹配：

DELIMITER_TOKEN    
TOKEN_1            |                     |
TOKEN_2            | first near query    |        
TOKEN_8            |                     |
DELIMITER_TOKEN                          |   the top query
TOKEN_X                                  |
DELIMITER_TOKEN    | delitimer           |
TOKEN_3            | second near query   |
4

1 回答 1

0

最后发现这不是一个好主意。如果有人想在 Lucene 中做这样的事情，我认为这是错误搜索设计的标志。

但是我找到了解决方案......（如果有人感兴趣）

这个想法是，您不仅要存储一个分隔符标记，而且要存储其中的两个。（每个块有两个不同的分隔符：例如DELIMITER1和DELIMITER2）

然后你必须在你的 SpanNearQuery 中包含第一个分隔符（这会有很大的倾斜），但你必须DELIMITER2从这些结果中排除（使用 SpanNotQuery）。

现在您只需要构造一个带有 slop 0 的 SpanNearQuery，即可将其“粘合”DELIMITER1到前一个查询。就这样。:)

但我认为如果有人不得不破解这样的东西，那么是时候重新审视实际的搜索逻辑了（我最终得出结论，也许 Lucene 不是最好的选择）。

于 2013-04-25T07:49:32.897 回答