These two numbers are measuring different events. Recall@20 asks whether a labeled relevant item appears somewhere in twenty candidates. Citation correctness asks whether the answer's particular claim is supported by the particular span it cites. One can improve while the other degrades. Before diagnosing, I would pin the denominator: relevant what? A document containing the topic, an answer-bearing passage, or the exact span supporting a claim? Also check whether the reported twenty are before or after permission and version filters.

One way this happens is simple competition under a fixed downstream budget. We raised vector top-k from, say, 40 to 100 in a hypothetical pipeline. The exact span now appears at rank 18, so recall@20 improves. But the reranker sees many near-duplicate passages, chooses a broad overview at rank 2, and the context selector sends only the first six to the model. The reranker code is unchanged, but its candidate distribution changed. Record every stage's candidate IDs and positions, including the chosen context. An oracle experiment that inserts the exact supporting span into context tells us whether candidate selection is the loss point. Increasing top-k again won't help if the extra evidence is discarded.

A second way is that the metric labels are too coarse. The newly retrieved document discusses the requested feature, so document recall goes up. Its cited paragraph does not contain the requested threshold, exception, or version. The answer may be factually right from another source but attach this easier-looking citation. Annotate claim-level supporting spans and distinguish “about this topic,” “contains the answer,” and “supports this exact claim.” Sample failures and read the passage next to the output sentence. A citation marker on a relevant page is not evidence.

Third, a larger candidate pool can add stale or conflicting material. The reranker may prefer a semantically vivid older release note over a dull current table, especially if version metadata is absent from its input. Even when the correct span remains in context, the model can blend a current condition with an older number and cite the current page. Slice the failures by version, authority, age, source type, and position in context. Re-run the same question with only the validated spans, then add the distractors back one group at a time. If the answer fails only after adding stale passages, the problem is evidence arbitration or generation, not first-stage recall.

“The reranker did not change” is a useful push, but it doesn't freeze the system. Its inputs, ties, score distribution, candidate cap, truncation, and timeout behavior can change when top-k changes. Check whether it actually processed all candidates, whether a fallback path fired, and whether the context packer still has the same token budget. Don't attribute causality to the model just because the model binary stayed the same.

I would run a small factorial comparison on the same queries and corpus snapshot: old and new top-k, current reranking, and an oracle context made from reviewed evidence. Keep authorization and source version fixed. Look at first-stage exact-span recall, reranked rank, selected-context recall, claim support, unsupported assertion rate, and abstention. That tells us which boundary lost the evidence. It also catches a fourth possibility: the apparent recall gain was calculated on a different or leaked evaluation slice. The rollout gate is the supported answer on the user's permitted, current evidence, not recall@20 by itself.