Why RAG?
Understand the problems RAG solves, when retrieval is better than relying only on an LLM, and how it improves access to private and changing knowledge.
By the end of this lesson, you will be able to:
- Explain why applications use Retrieval-Augmented Generation.
- Identify the limitations of relying only on an LLM's internal knowledge.
- Understand how RAG helps with private and frequently changing information.
- Compare an LLM-only workflow with an LLM + RAG workflow.
- Explain how retrieval can improve relevance and grounding.
- Recognize cases where RAG is useful and where it may not be necessary.
- Understand the main trade-offs: quality, latency, cost, and complexity.
The Core Problem RAG Solves
Large language models can generate fluent answers, but an application often needs information that is private, current, specific, or controlled by the application. That information may not be available inside the model.
An employee asks, βHow many days of parental leave are available?β The application retrieves the current policy instead of expecting the LLM to know an internal rule.
A customer asks how to configure a product. RAG retrieves the relevant documentation and gives it to the model as evidence.
Why Not Just Ask the LLM?
An LLM generates text from patterns learned during training and the information supplied in its current context. Your application may need knowledge that is not present in either place.
- Simple architecture
- No retrieval pipeline required
- May lack private information
- May not know the latest company or product changes
- Can produce confident but unsupported answers
- Retrieves application-specific information
- Can use maintained knowledge sources
- Provides relevant context at query time
- Can support source references and citations
- Adds retrieval complexity and latency
Problem #1: Private Knowledge
Many useful AI applications depend on information that belongs to an organization or product. Examples include HR policies, engineering documentation, support procedures, contracts, product manuals, and internal FAQs.
Missing context
The model may have no reliable access to the private document collection.
Retrieved context
The application searches its approved knowledge source and supplies relevant passages.
Domain relevance
The answer can be based on the information that actually matters to the application.
Access control
Retrieval must respect permissions so users receive only information they are allowed to access.
Problem #2: Frequently Changing Information
Knowledge can change after a model has been trained. Prices, policies, product specifications, schedules, procedures, and documentation can all be updated.
Training snapshot
The model's learned knowledge is not automatically updated whenever your document changes.
Updated documents
The application can update its searchable source and retrieve the latest relevant content.
RAG does not make the model itself permanently learn the new information. It supplies the information when the user asks a question.
Problem #3: Domain-Specific Knowledge
Some questions require terminology and details from a narrow domain. A RAG system can connect a general-purpose model to a specialized knowledge collection.
Retrieve approved clauses, policies, or case material for a controlled workflow.
Find the exact section needed to explain a configuration or troubleshooting step.
Retrieve relevant passages from a selected research collection.
Search internal procedures and documentation before generating an answer.
Use maintained specifications, FAQs, and support documentation.
Retrieve approved troubleshooting content for a customer's issue.
RAG Improves the Information Flow
Think of RAG as adding an information-retrieval step between the user's question and the model's answer.
The important point is that the model does not have to rely only on what it already knows. The application can provide the information needed for this particular question.
RAG Can Improve Grounding
Grounding means connecting a generated response to information supplied by the application. Retrieved context gives the model evidence it can use while answering.
The model answers without application-specific evidence.
The model receives relevant application knowledge before generating the response.
Why Retrieval Quality Matters
RAG is only as useful as the information it retrieves. If the correct chunk is not found, the generator may not have the evidence needed to answer.
This is why chunking, embeddings, vector databases, metadata filtering, hybrid search, Top-K, and reranking all matter to a RAG system.
RAG and Context Windows
An LLM can only process a finite amount of input in a request. Retrieving everything is therefore not a good strategy.
- The answer may miss an important detail
- Relevant evidence may be incomplete
- Increases tokens and cost
- Adds irrelevant information
- Can make the model's job harder
A strong RAG pipeline tries to retrieve enough relevant evidence without sending unnecessary content.
Simple Python Example
This example shows why retrieval can be useful. The answer function receives context that the application found before generation.
knowledge = {
"refund": "Customers can request a refund within 30 days.",
"shipping": "Standard shipping usually takes 3 to 5 business days."
}
question = "How long do I have to request a refund?"
# Retrieval step: choose relevant knowledge.
context = knowledge["refund"]
# Generation step: an LLM would use this context.
answer = f"Based on the policy: {context}"
print(answer)The example is intentionally simple. A production system would usually retrieve from an index or database instead of selecting a dictionary key directly.
RAG vs Fine-Tuning
- You need external or private knowledge
- Documents change frequently
- You want retrieval and source control
- The main problem is access to information
- You need different model behavior
- You want a particular style or output format
- You need task-specific response patterns
- The main problem is model behavior rather than document lookup
RAG and fine-tuning are not interchangeable. RAG primarily changes what information the model receives; fine-tuning primarily changes how the model behaves.
RAG Is Not Always Necessary
Adding retrieval introduces infrastructure, indexing, evaluation, latency, and maintenance. If a task can be solved reliably with a simple prompt and the model already has the needed knowledge, RAG may add unnecessary complexity.
Private documents
The answer depends on knowledge controlled by your application.
Changing content
The knowledge source is updated more often than a model is retrained.
General writing
The task does not depend on a specialized external knowledge base.
Simple transformation
Summarizing or rewriting text already supplied directly in the prompt may not require retrieval.
The Cost of Adding RAG
RAG solves information problems, but it also creates a larger system.
Documents must be loaded, cleaned, chunked, and indexed.
Vectors, metadata, documents, and indexes need to be maintained.
Retrieval and reranking add work before generation.
Embedding, search, reranking, and additional context can increase usage.
You must test both retrieval quality and answer quality.
Source documents and indexes need reliable update processes.
Security Is Another Reason to Use Controlled Retrieval
In enterprise applications, retrieval is not just about relevance. The system should also control which information can be returned to a user.
A RAG implementation should treat access control as a system requirement, not merely a prompt instruction.
How RAG Connects to What You Have Learned
Prepare documents
Break knowledge into useful retrieval units.
Represent meaning
Convert text into vectors for semantic matching.
Search knowledge
Store vectors and metadata for efficient retrieval.
Combine signals
Use keyword and semantic retrieval when both signals help.
Improve ordering
Re-score candidates to move the strongest evidence higher.
Generate from evidence
Give selected context to the LLM and produce the answer.
A Practical RAG Decision Checklist
Common Misconceptions
No. It provides retrieved context for a particular request.
No. Irrelevant context can increase cost and reduce focus.
No. It can improve grounding but cannot guarantee correctness.
No. They address different problems and can be combined.
No. RAG includes ingestion, retrieval, context construction, generation, and evaluation.
No. RAG can use many approved knowledge sources.
How to Evaluate Whether RAG Actually Helps
The goal is not βadd RAG because everyone uses RAG.β The goal is to solve a real information-access problem and measure whether retrieval improves the result.
Practice: Should This Application Use RAG?
Decide whether RAG is useful for each scenario and explain why.
Make the architecture decision
1. A chatbot answers questions about 500 internal company policies. 2. An assistant rewrites a paragraph supplied by the user. 3. A support bot answers questions using product manuals that change every month.
Quick Quiz
1. Why is RAG useful for private company knowledge?
It lets the application retrieve relevant internal information and provide it to the LLM as context.
2. Why can RAG help with changing information?
The searchable knowledge source can be updated without requiring the model itself to be retrained for every document change.
3. Does retrieving more context always improve an answer?
No. Too much irrelevant context can increase cost and reduce the model's focus.
4. Does RAG guarantee factual answers?
No. Source quality, retrieval quality, context construction, and generation can all affect correctness.
30-Second Recap
RAG connects LLMs to application-specific knowledge.
Knowledge sources can be updated independently of model training.
Retrieval supplies evidence for the current question.
The model can generate using retrieved context.
Key Takeaways
- RAG is useful when an application needs external, private, domain-specific, or changing knowledge.
- Without retrieval, an LLM may not have the information required for a specific application question.
- RAG retrieves relevant evidence and supplies it to the model at query time.
- Good retrieval matters because the generator can only use the evidence it receives.
- More context is not automatically better; useful context should be relevant and controlled.
- RAG adds cost, latency, infrastructure, security, and evaluation requirements.
- RAG and fine-tuning solve different problems.
- The right reason to use RAG is to solve a real information-access problem, then measure whether it improves the system.