[
https://issues.apache.org/jira/browse/SOLR-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474466#comment-17474466
]
Alessandro Benedetti commented on SOLR-15873:
---------------------------------------------
Hi Christine, sorry for the delay, I am leaving my opinion on this now:
First of all, thank you very much for all your effort and ideas drafted in the
attached pull request.
I reviewed it and the code per se is fine.
My feeling on the other hand is that we are over-complicating the current
problem.
I'll try to explain my point of view:
*Current Technical Problem*
We observed there is a piece of code in the the
org.apache.solr.ltr.LTRRescorer#scoreSingleHit that is never run.
*Practical Consequences*
The readability of the org.apache.solr.ltr.LTRRescorer#scoreSingleHit method is
damaged due to that block of dead code.
A maintainer/contributor/reader may spend a significant amount of time trying
to understand why that block code is there and when is invoked.
This may cause further difficulties in understanding the method and Learning To
Rank rescoring as a whole.
*Proposed Solution*
Remove the code block, making sure no regression happens in official Solr tests.
*Benefits*
The solution is simple and quick, the readability of the method gets a huge
boost, there is less ambiguity and future maintainer/contributor/reader can
focus only on valuable code.
*Unlikely Side Effects of the simple solution*
The Lucene Rescorer API however describes topN as the number of hits to return
i.e. it is possible for firstPassTopDocs to contain more than topN documents:
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.1/lucene/core/src/java/org/apache/lucene/search/Rescorer.java#L51
Potentially some custom plugin introduces some custom ReRankCollector that does
for some reason not cap the number of documents passed in the way official
ReRankCollector does.
Now let's focus on the "unlikely side effects of the solution" i.e. is the
effort and complexity of approaching the problem with a complex and iterative
solution justified by some evidence right now?
At the moment there is nothing in the Apache Solr repo that points in that
direction, so my feeling is that
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it]
.
If some remote custom and proprietary plugin will not be compatible with our
simplification in the future:
*Worst Case Scenario*
They will not be able to upgrade the plugin out of the box, they'll need to
rethink it and potentially raise the problem with the Solr community explaining
their reasons.
At that point, if their reasoning is compelling and supporting their use case
through the official Apache Solr is a good idea, we can spend the effort and
implement a solution on top of the simplified code.
Everything is tracked with Git source control, so it's not a big deal to find
removed code in the future if necessary (or writing a new one probably is even
a better option, because it will be focused on the problem raised).
This is may opinion and it's not my intention to undervalue any of the current
pull request open.
I just want to make sure we proceed with the simplest and most effective
solution, given the knowledge we have currently.
[~diegoceccarelli], [~4nn4r], [~cpoerschke] what do you think?
> simplify LTR[Interleaving]Rescorer code
> ---------------------------------------
>
> Key: SOLR-15873
> URL: https://issues.apache.org/jira/browse/SOLR-15873
> Project: Solr
> Issue Type: Task
> Components: contrib - LTR
> Reporter: Christine Poerschke
> Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> On the dev mailing list
> [https://lists.apache.org/thread/113d1yzty5ryvyt2o9msfytldv41qpgq] thread
> [~4nn4r] shared about the discovery of the
> {{org.apache.solr.ltr.LTRRescorer#scoreSingleHit}} code block and how
> {{hitUpto >= topN}} never arises and so if the piece of code be removed.
> This ticket is about removing (or maybe not) of the code block.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
