RAG changes the evidence available to the model
Retrieval-augmented generation searches an approved source collection for relevant material and gives that material to the model before it answers. It does not make every answer correct. It makes a different kind of system possible: one that can show which source supported the response and can be updated by changing the source collection instead of retraining a model.
Strong signs that RAG is appropriate
The case becomes stronger when several of these conditions are true.
- The answer depends on private or organisation-specific information
- Policies, procedures, or product details change over time
- Users need citations or source passages
- Different people should see different source sets
- The same questions consume expert time repeatedly
Cases where RAG may be unnecessary
A document folder alone is not a reason to build RAG. If the task is occasional summarisation, low-risk drafting, or a question that public knowledge already answers well, a simpler assistant or search interface may be enough.
RAG can also be the wrong first step when the documents are contradictory, badly owned, or out of date. Retrieval will expose that governance problem; it will not repair it automatically.
The minimum credible RAG build
A useful first release needs more than a chat box.
- A defined and permission-safe source collection
- A representative set of real user questions
- Retrieval evaluation before answer-style tuning
- Visible sources and a clear no-answer behaviour
- An update process for changed or removed documents
How to evaluate an outsourced RAG project
Ask to see retrieval results separately from the final prose. A fluent answer can hide weak evidence. The provider should be able to show which content was retrieved, why the system chose it, what happens when sources disagree, and how access boundaries are enforced.