A new feature for using the first phase scores in the second phase in the Ltr query

[rifatozcan]

Hi all,

I think it would be a good feature to be able to use first phase query scores as a feature in the Ltr query. Solr Ltr integration has this feature, called OriginalScoreFeature, specially designed for this purpose. It seems that they have achieved this by customizing the QueryRescorer in Solr and passing this info as DocInfo. However, in elasticsearch, it does not seem to be able to customize QueryRescorer.

regards
Rifat

[ebernhardson]

I looked into this as well previously, and the limitations of elasticsearch of only being able to specify a Query implementation in the rescorer makes this difficult. One method might be to upstream something into elasticsearch such as a TopHitsAwareRescoreQuery interface or some such, if the query provided to the rescorer implements this the TopHits implementation could be passed in?

[softwaredoug]

@nomoa I wonder if your depth in ES plugins if you've had any thoughts about this?

[nomoa]

This will have to wait elastic 6.1, they added the possibility to implement our own rescorer. Without this it's impossible to access the first pass query score.
A workaround is still possible: you can duplicate you retrieval query as a feature in the model.

[n1rna]

Hi all,
Now that the ltr has integrated to the elastic 6+ versions, Is this feature now implemented on the esltr plugin? Or are there any on going actions taken about this feature?

[nomoa]

I haven't had time to work on this, I'd be happy to help and review some code if someone is willing to send a PR implementing this feature.

[n1rna]

I would love to get started on implementing this feature. I will inform you about it in the future. 👍

[nted92]

Hi all,
I'd be super interested to have this feature available for a project I'm currently working on.
Did someone get a chance to work on it? In any case, I'd be happy to help!

[nomoa]

I worked on the first steps (see #204) which add a custom rescore context to the plugin. The next steps would be to build another feature type that'd be controlled by this new rescore context so that initial score can be made available to the ltr logic.
Sadly we haven't had much time to work on #204 to make sure it fits our needs...
If someone is willing to test #204 with in mind:

• usability: make sure the normalization options and the doc make sense
• perf: make sure the perf is not degraded when compared to upstream rescore context

I think this would help to move this forward.
Thank you!