[
https://issues.apache.org/jira/browse/LUCENE-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798504#comment-13798504
]
Michael McCandless commented on LUCENE-5288:
--------------------------------------------
bq. I think for this one we should pull the boolean-ness out of this and make a
pure proximity scorer (so there is no double-scoring and all the other issues
here).
I guess there are two very different use cases here:
* Prox-aware query that runs across the entire index; we already
have things like sloppy PhraseQuery, Span*Query, and this
ProxBooleanTermQuery would just be another in that same category.
* Resort top results from first pass query
I was hoping we could share code for these two use cases, by having
QueryRescorer that takes a Query to do the 2nd pass scoring. This way
you can rescore based on any costly query (e.g., I liked the rescoring
by PhraseQuery).
But I agree that's sort of awkward, and it sounds you are strongly
against that ... so solving both cases with shared code is too
optimistic now / for starters.
I'd like to focus this issue on just adding another prox-aware query, and I
guess
just remove QueryRescorer for now. We can explore it in a
separate/future issue.
> Add ProxBooleanTermQuery, like BooleanQuery but boosting when term occur
> "close" together (in proximity) in each document
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-5288
> URL: https://issues.apache.org/jira/browse/LUCENE-5288
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5288.patch, LUCENE-5288.patch
>
>
> This is very much a work in progress, tons of nocommits... It adds two
> classes:
> * ProxBooleanTermQuery: like BooleanQuery (currently, all clauses
> must be TermQuery, and only Occur.SHOULD is supported), which is
> essentially a BooleanQuery (same matching/scoring) except for each
> matching docs the positions are merge-sorted and scored to "boost"
> the document's score
> * QueryRescorer: simple API to re-score top hits using a different
> query. Because ProxBooleanTermQuery is so costly, apps would
> normally run an "ordinary" BooleanQuery across the full index, to
> get the top few hundred hits, and then rescore using the more
> costly ProxBooleanTermQuery (or other costly queries).
> I'm not sure how to actually compute the appropriate prox boost (this
> is the hard part!!) and I've completely punted on that in the current
> patch (it's just a hack now), but the patch does all the "mechanics"
> to merge/visit all the positions in order per hit.
> Maybe we could do the similar scoring that SpanNearQuery or sloppy
> PhraseQuery would do, or maybe this paper:
> http://plg.uwaterloo.ca/~claclark/sigir2006_term_proximity.pdf
> which Rob also used in LUCENE-4909 to add proximity scoring to
> PostingsHighlighter. Maybe we need to make it (how the prox boost is
> computed/folded in) somehow pluggable ...
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
