Most retrieval debugging starts in the wrong place. A user reports a bad answer, someone checks whether the right document was in the corpus at all, confirms it was, and closes the ticket confused — the document existed, so what went wrong? Usually: it was retrieved, just not in the top few results the model actually read before generating an answer. Recall was fine. Ranking wasn't.
That distinction matters because the two failures get fixed in completely different ways. A recall problem — the right document genuinely isn't in your candidate set — gets fixed upstream, in chunking, indexing, or corpus coverage. A ranking problem — it's in there, just at position 23 out of 50 — gets fixed downstream, in how you score and order candidates, and no amount of re-chunking or re-embedding touches it, because the document was never the issue. It's easy to conflate the two if your only debugging signal is "was the answer right," because a wrong answer looks the same from the outside regardless of which stage failed.
The practical fix is to actually look at the full candidate list your retriever returns, not just what got passed to the model. If the right passage shows up consistently, just lower in the list than you'd like, that's a scoring problem: consider a second-stage reranker, or a fusion method that combines lexical and semantic signal, before touching your embedding model or your chunk sizes. If the right passage is entirely absent from a wide candidate set, that's a coverage or indexing problem, and reranking won't save you.
The underlying habit worth building is treating "did retrieval work" as a two-part question instead of one. Was the right thing found, and separately, was it found near enough to the top to matter. Most retrieval postmortems only ever ask the first question, which is why so many RAG fixes end up being expensive changes — new embedding models, larger context windows — aimed at a problem that was actually about ranking all along.