Framing RAG as a search system with a language model on the end is the clearest mental model of it. Most bad answers really are retrieval misses upstream, and walking the failure modes per stage is more useful than another architecture diagram.
Exactly. That was the main idea I wanted to get across. A bad answer does not automatically mean the model needs to be better. Sometimes the document was parsed incorrectly, the chunk lost important context, or retrieval never surfaced the right passage in the first place.
That is why I think separating retrieval quality from generation quality matters so much. Once you can identify whether the right chunk was retrieved, ranked correctly, and actually passed into the prompt, debugging becomes much more systematic. Otherwise, it is easy to spend time changing models when the real problem is somewhere earlier in the pipeline.