A model that doesn't know your policies, your contracts, or your product will confidently make them up. Retrieval is how you fix that, and almost every failure in a RAG system is a retrieval problem, not a model problem.
Teams tend to spend their effort on the prompt at the end. The quality was decided several steps earlier, by what the system managed to find.
Pulling from the places your knowledge actually lives (a document store, a wiki, a ticketing system) and keeping it current as those sources change.
How documents get split decides what can ever be retrieved. Contracts, manuals, and chat logs each want different treatment, and defaults suit none of them.
Vector similarity misses exact terms: part numbers, policy codes, names. Combining it with keyword search fixes the failure people notice first.
Retrieving twenty candidates and re-scoring them properly beats retrieving five and hoping. It's usually the single biggest quality gain available.
Retrieval that respects who's asking. Permissions have to be enforced at query time, or the assistant becomes a way around your access rules.
Every answer traceable to the passage it came from. That's the difference between a system people trust and a demo they stop opening.
A RAG assistant doesn't fail loudly. People try it, get a wrong answer twice, and go back to searching the drive themselves.
Retrieval gives the model facts; it doesn't change how the model behaves. For tone, format, and domain judgment see LLM fine-tuning. If it also needs to take action, that's AI agents.
Tell us where the knowledge lives and what people keep asking. We'll come back with a retrieval design and the questions we'd use to test whether it's working.