lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4481) AnalyzingSuggester may fail to return correct topN suggestions
Date Sat, 20 Oct 2012 10:38:12 GMT


Michael McCandless commented on LUCENE-4481:

The core problem is that the TopNSearcher assumes that every partial
path will lead to at least one final path, but with the AnalyzingSuggester
this is in general false because of token stream graphs.

So as a first step I've turned off all queue pruning ... this fixes
the bugs.

But note that for WFSTCompletionLookup (why is this not WFSTSuggester?
:) ) it's still true, so the solution is simple there: keep pruning
the queue like before.

For AnalyzingSuggsester my current solution is to bound the queue
using topN * M where M is the max number of analyzed forms we ever saw
for any surface form.  So this means if you never make graphs we keep
doing the same aggressive pruning as before.

> AnalyzingSuggester may fail to return correct topN suggestions
> --------------------------------------------------------------
>                 Key: LUCENE-4481
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.1, 5.0
>         Attachments: LUCENE-4481.patch, LUCENE-4481.patch, LUCENE-4481.patch, LUCENE-4481.patch
> I hit this when working on LUCENE-4480.
> Because AnalyzingSuggester may prune some of the topN paths found by FST's Util.TopNSearcher,
this means the queue size limit of topN makes the overall search inadmissible, ie it may incorrectly
prune paths that would have lead to a competitive path.
> However, such pruning is rare: it happens only for graph token streams, and even then
only when competitive analyzed forms share the same surface forms.
> The simplest way to fix this is to make the queue unbounded but this is likely a sizable
performance hit ... I haven't tested yet.  It's even possible the way the dups happen (always
at the "end" of the suggestion, because we tack on 0 byte followed by ord dedup byte) prevent
this bug from even occurring and so this could all be a false alarm!  I have to try to make
a test case showing it ...
> A cop-out solution would be to expose a separate queueSize or queueMultiplier (over the
topN) so that if users are affected by this they could crank up the queue size or multiplier.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message