adding in the loop Diego and Christine as potentially they are not in the list yet. -------------------------- Alessandro Benedetti Apache Lucene/Solr Committer Director, R&D Software Engineer, Search Consultant
www.sease.io On Fri, 3 Dec 2021 at 15:24, Anna Ruggero <a.rugg...@sease.io> wrote: > Hi Diego, > Thank you for your reply. > From what I've seen the topN variable takes the value from the rerankDocs > parameter passed at query time. > I've tried to pass different values for the rerankDocs and topN seems > always to reflect this. Also in these cases, hits.length was always equal > to topN. > > It's also true that from documentation > https://solr.apache.org/guide/8_11/query-re-ranking.html: > *rerankDocs*: The number of top N documents from the original query that > should be re-ranked. *This number will be treated as a minimum*, and may > be increased internally automatically in order to rank enough documents to > satisfy the query (i.e., start+rows). The default is 200. > > Could be this evidence of the hypothetical case you mentioned? topN = 100 > but hits.length > 100 > Could you give me an example of this? > I would be happy to know if this can happen in some way :) > > Thank you very much. > > Anna > > > > On 2021/12/02 23:28:23 Diego Ceccarelli wrote: > > Hi, I had a quick look and it seems that Anna is right, but there should > be > > a case where you ask to rerank more documents than what you want to see.. > > need to review the code :) > > > > cheers, > > Diego > > > > > > > > > > On Thu, 2 Dec 2021, 16:40 Alessandro Benedetti, <a....@sease.io> > > wrote: > > > > > Adding Christine and Diego to the loop if they missed this. > > > Thanks Anna for raising. > > > > > > Cheers > > > -------------------------- > > > Alessandro Benedetti > > > Apache Lucene/Solr Committer > > > Director, R&D Software Engineer, Search Consultant > > > > > > www.sease.io > > > > > > > > > On Wed, 10 Nov 2021 at 16:41, Anna Ruggero <a....@sease.io> wrote: > > > > > >> Hi all, > > >> > > >> I was looking at the *org.apache.solr.ltr.LTRRescorer#scoreFeatures * > > >> method. > > >> Since we are using reranking applied to some topN documents > (rerankDocs > > >> parameter) I think that this block of code in > *org.apache.solr.ltr.LTRRescorer#scoreSingleHit > > >> *will never be accessed: > > >> > > >> if (hitUpto >= topN) { > > >> // once that heap is ready, if the score of this document is lower > that > > >> // the minimum > > >> // i don't want to log the feature. Otherwise I replace it with the > > >> // minimum and fix the > > >> // heap. > > >> if (hit.score > reranked[0].score) { > > >> reranked[0] = hit; > > >> heapAdjust(reranked, topN, 0); > > >> if (featureLogger != null && indexSearcher instanceof > SolrIndexSearcher) { > > >> featureLogger.log(hit.doc, rerankingQuery, (SolrIndexSearcher) > indexSearcher, > > >> modelWeight.getFeaturesInfo()); > > >> } > > >> } > > >> > > >> Since we are reranking the topN documents. the *hits.length* in the > > >> scoreFeatures method is always *equal* to the *topN* variable. > > >> Therefore, since *hitUpto* is going from *0* to *hits.length -1*, we > > >> will never have *hitUpto >= topN* > > >> > > >> Is there any condition I am missing? > > >> Couldn't this piece of code be removed? > > >> > > >> Thank you, > > >> Anna > > >> > > > > > >
