Why RAG?
RAG becomes useful when a model needs access to information that is private, changing, domain-specific or too large to reliably encode in model weights. The key is not to add retrieval because it is fashionable, but because external knowledge is part of the problem.
The basic architecture
A production flow commonly includes ingestion, parsing, chunking, embedding or indexing, retrieval, optional reranking, prompt construction and generation. Each stage introduces quality and latency trade-offs.
Retrieval patterns
Dense vector retrieval is only one option. Keyword search, metadata filtering, hybrid retrieval and reranking can be combined depending on the vocabulary, precision requirements and structure of the source material.
Production considerations
Measure retrieval quality separately from generation quality. Track latency, source coverage, stale documents, failed retrievals and user feedback. Keep citations and observability close to the response path so the system can be improved continuously.
When not to use RAG
If the answer already exists in a reliable transactional database, a direct query may be safer. If the problem is deterministic computation, use the appropriate system of record or computation engine. RAG should solve a knowledge-access problem, not become a default architecture.
Talk through your specific problem with a verified expert.