In Lucene we have several different suggest implementations, under the
suggestmodule; today I'm describing the new AnalyzingSuggester (to be committed soon; it should be available in 4.1).
To use it, you provide the set of suggest targets, which is the full set of strings and weights that may be suggested. The targets can come from anywhere; typically you'd process your query logs to create the targets, giving a higher weight to those queries that appear more frequently. If you sell movies you might use all movie titles with a weight according to sales popularity.
You also provide an analyzer, which is used to process each target into analyzed form. Under the hood, the analyzed form is indexed into an FST. At lookup time, the incoming query is processed by the same analyzer and the FST is searched for all completions sharing the analyzed form as a prefix.
Even though the matching is performed on the analyzed form, what's suggested is the original target (i.e., the unanalyzed input). Because Lucene has such a rich set of analyzer components, this can be used to create some useful suggesters:
- With an analyzer that folds or normalizes case, accents, etc. (e.g.,
using ICUFoldingFilter), the suggestions will match
irrespective of case and accents. For example, the query
"ame..." would suggest Amélie.
- With an analyzer that removes stopwords and normalizes case, the query
"ghost..." would suggest "The Ghost of Christmas Past".
- Even graph
TokenStreams, such as SynonymFilter, will work: in
such cases we enumerate and index all analyzed paths into the FST.
If the analyzer recognizes "wifi" and "wireless
network" as synonyms, and you have the suggest target "wifi
router" then the user query "wire..." would suggest "wifi
- Japanese suggesters may now be possible, with an analyzer that
copies the reading (ReadingAttribute in
the Kuromoji analyzer) as
While this is a great step forward, there's still plenty to do with Lucene's suggesters. We need to allow for fuzzy matching on the query so we're more robust to typos (there's a rough prototype patch on LUCENE-3846). We need to predict based on only part of the query, instead of insisting on a full prefix match. There are a number of interesting elements to Google's autosuggest that we could draw inspiration from. As always, patches welcome!
Thank you for this article! I've just started using Lucene's suggesters to implement autocomplete feature in my project. So far everything works great.ReplyDelete
Though, I'd be thankful if you could tell me if AnalyzingSuggester and FuzzySuggester are thread-safe when using lookup() method? I couldn't find this information anywhere.
lookup() is thread safe!
Can you please point me to an example?ReplyDelete
I don't know of any examples ... but maybe look at its unit test? https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_1/lucene/suggest/src/test/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggesterTest.java
I've been playing around with this the last days and I think I almost got it working - maybe you know what needs to be changed :)
I have a copyField "asug", which copies from "name" (this has accents in it), it is a custom fieldType with a KeywordTokenizer (since I want the whole term to be returned), lowercase and ascii-folding, for both index and query.
It seems that it always returns the indexed value, rather than the actual field value - so "ame.." gives me back "amelie".
I randomly got the right value back by feeding without index-analyzers and restarting with index-analyzers. Any ideas?
Now that I think about it, it makes sense why that didn't work ... I was quering on a non-stored, indexed (copy)field. So that's obviously the reason I got back the indexed value.Delete
That's very odd ... it should always return the original field value, not the analyzed form. Can you make a small set of names showing the issue?
here's a pastebin: http://pastebin.com/20vSGJ1a
After that I feed the document and do:
I get the "right outcome" for every possible query I tried, e.g. Têst, tést, TÈST,... Only problem is, that this seems to return the stored index value ("test name"), rather than the stored field value ("Têst Námè").
Can you send an email to email@example.com with these details? I'm not sure what's going on. That test case sure looks like it should work (ie return Têst Námè not test name).
So to clarify it, AnalyzerSuggester needs to be used on the field directly (no copyField or something), then it's working :)ReplyDelete
So to query on the field "name" with filters specified in "text_asug" (lowercase, ascii,...) one would use:
Phew, thanks for bringing closure Sebastian!ReplyDelete
http://luceneautosuggester-lucene.rhcloud.com/.. Sample lucene auto suggester demo using analyzing suggester and fuzzy suggester.. Lucene autosuggester is awesome...ReplyDelete
Thanks for the great demo.
I am confuse for the Japanese autocomplete and I see your demo can support the Japanese autocomplete.
Could you please share the configurations?
Thanks a lot.
And, Mike, thanks for this article.
Thanks for very good sample :)Delete
Nice demo! Thanks for sharing.
Any idea if the source is available for this demo?ReplyDelete
I'm also curious about source code. I'm having trouble figuring out how to load an existing index to have the Suggester use (if that's even possible).ReplyDelete
If you have suggestions in your index, as e.g. text and weight etc. as stored fields in your documents, you can use the DocumentDictionary class to enumerate the suggestions from your documents. You pass that to AnalyzingSuggester.build to build the suggester.Delete
How can the AnalyzerSuggester return the original fieldvalue if the lookup is done by the analyzed value? Dependiing on the analyzer this is not a unique operation.ReplyDelete
The surface form is separately stored (as an FST output), even though matching is done based on the analyzed form.Delete
Can you comment on ThreadSafety? Can we just instantiate a Suggester and then build, lookup, etc against a stored instance?ReplyDelete
Could you ask this on Lucene's user list (firstname.lastname@example.org)?