I would look at the candidates before touching a weight. The system has confused three identities: a search hit, a chunk, and the source document version that the user is allowed to rely on. Lexical search may rank one paragraph from revision 7, vector search another from revision 8, and the fusion layer may treat them as independent evidence. Giving one branch more weight can move those hits around. It cannot decide which revision is current or make five near copies worth five context slots.

Trace the exact query through both candidate lists, fusion, reranking, grouping, and context selection. Record source object ID, source revision, policy or product version, chunk span, index generation, and permission decision. Did the migration deliberately dual read old and new generations? Did the active-source registry point to revision 8 while an old index still returned revision 7? Did a reranker score each chunk independently and let five chunks from one manual crowd out the exception notice in another source? Elastic's RRF documentation describes rank fusion over the child retrievers' result windows. That mechanism does not supply our application rule for source-version authority.

For a question asking about the current policy, establish eligible source revisions before the final evidence selection. Ideally the query pins one complete searchable generation and applies the requested product version and current source state in each retrieval branch. During a dual-read migration, normalize old and new hit IDs to the same source identity, reject superseded versions for the current answer, and deduplicate identical spans. I would group remaining chunks by source and section, then allocate context slots to distinct answer-bearing evidence. Do not collapse the whole manual to one chunk if the question genuinely needs a definition and an exception on separate pages. The unit to diversify is a meaningful evidence group, not merely a filename.

Grouping after the top six is too late when the exception never reaches those six. Overfetch candidates within a measured budget, filter and group before the small reranker or context window, and measure whether the governing exception survives. Compare claim-level citation support and answer correctness, not only the score distribution. Some engines have field collapsing or diversification features, such as Elasticsearch's collapse operation, but its placement in a particular retrieval pipeline and its effect on reranking need testing. Application source identity still has to be right.

Now make the question explicitly ask, “What did revision 7 say in 2024?” Revision 7 is no longer noise. The query plan should select the historical corpus and label the answer's time and citation. A hard global rule that deletes every old version would break that use case. Current and historical queries need different eligibility, while both keep a coherent version boundary.

If the active registry itself is behind the source, I would not let the newest-looking chunk decide authority by timestamp. Either fetch a current source version, use a release manifest with a known freshness bound, or say the answer may be stale. This incident is fixed when the service can explain why these six spans belong together and which revision each claim came from. A weight change alone cannot give that explanation.