lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4845) Add AnalyzingInfixSuggester
Date Tue, 19 Mar 2013 15:29:18 GMT


Robert Muir commented on LUCENE-4845:

This seems to not blow up for title-like fields:
I did a quick test of geonames (8.3M place names, just using ID as the weight)

AnalyzingSuggester: 117444563 bytes, 74887ms build time
InfixingSuggester: 302127665 bytes, 125895ms build time

I think realistically an N limit can work well here. After such a limit, the infixing is
pretty crazy anyway, and really infixing should "punish" the weight in some way since its
a very scary "edit" operation to do to the user.

Plus you get optional fuzziness and real "phrasing" works too :)
> Add AnalyzingInfixSuggester
> ---------------------------
>                 Key: LUCENE-4845
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/spellchecker
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 5.0, 4.3
>         Attachments: infixSuggest.png, LUCENE-4845.patch, LUCENE-4845.patch, LUCENE-4845.patch
> Our current suggester impls do prefix matching of the incoming text
> against all compiled suggestions, but in some cases it's useful to
> allow infix matching.  E.g, Netflix does infix suggestions in their
> search box.
> I did a straightforward impl, just using a normal Lucene index, and
> using PostingsHighlighter to highlight matching tokens in the
> suggestions.
> I think this likely only works well when your suggestions have a
> strong prior ranking (weight input to build), eg Netflix knows
> the popularity of movies.

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