[
https://issues.apache.org/jira/browse/SOLR-18290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091913#comment-18091913
]
ASF subversion and git services commented on SOLR-18290:
--------------------------------------------------------
Commit 4a3bfa598e39a5ece8e03b2154b37356b5228db3 in solr's branch
refs/heads/main from Sonu Sharma
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=4a3bfa598e3 ]
SOLR-18290: combined-query / RRF : support shards.rows (#4546)
Enhance combined-query / RRF to support shards.rows param properly -- thereby
supporting stable paging results
> Support configurable fusion candidate pool in Combined Query
> ------------------------------------------------------------
>
> Key: SOLR-18290
> URL: https://issues.apache.org/jira/browse/SOLR-18290
> Project: Solr
> Issue Type: Improvement
> Components: vector-search
> Reporter: Sonu Sharma
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The Combined Query / RRF flow has no explicit control over the fusion
> candidate pool and its size is implicitly tied to \{{start}} + \{{rows}}. As
> a result, the pool shifts with each page, causing the fused ranking to drift
> across pagination even for the same underlying query (e.g., page 2 with
> \{{rows=10}} only fetches ~10–20 candidates per subquery per shard, a
> different RRF input than page 1).
> The root cause is that the candidate pool depth is not a first-class,
> independently configurable concern.
> It requires a control by introducing a parameter like `combiner.queryDepth`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
