Chapter 14- RAG Fundamentals

Chapter Goal

Chapter 13 answered the question:

Why do LLMs need retrieval?

We learned that internal model knowledge can be:

outdated
incomplete
missing
private-data-blind
weak for long-tail information

Retrieval gives the system access to external information at inference time.

Now we need to understand exactly how that becomes a working architecture.

The core system is:

User Query
↓
Retriever
↓
Relevant Documents / Passages
↓
LLM Context
↓
Generator
↓
Answer

This is the basic architecture of Retrieval-Augmented Generation, or RAG.

The important architectural shift is that the LLM does not have to answer only from its internal parameters.

Instead:

Question
↓
Find Relevant External Information
↓
Place That Information in Context
↓
Generate an Answer Using It

So a RAG system contains two major capabilities:

Retrieval
+
Generation

The retriever is responsible for finding useful external information.

The generator is responsible for producing the answer.

Between them sits an extremely important object:

Retrieved Context

The retrieved information must become part of the input available to the LLM.

That process is often called:

Context Injection

If the generator then produces an answer that stays supported by the supplied evidence, the answer is grounded.

By the end of this chapter, you should understand:

what RAG is;
what the Retriever does;
what the Generator does;
why retrieval and generation are separate stages;
the basic RAG architecture;
what documents and passages mean inside a RAG pipeline;
what Retrieved Context is;
what External Context is;
what Context Injection means;
what Evidence Context means;
how retrieved information reaches the LLM;
why retrieved information does not modify model parameters;
what Grounding means;
what Grounded Generation means;
what a Grounded Answer is;
how retrieval quality can affect generation;
and how RAG connects Information Retrieval to LLM inference.

The central pipeline of this chapter is:

User Query
↓
Retriever
↓
Relevant Documents / Passages
↓
Retrieved Context
↓
Context Injection
↓
LLM / Generator
↓
Grounded Generation
↓
Answer

14.1 Retrieval-Augmented Generation

1. What Is Retrieval-Augmented Generation?

Retrieval-Augmented Generation is an architecture in which an AI system retrieves relevant external information and provides that information to a language model before or during answer generation.

Query
↓
Retrieval
↓
Relevant Information
↓
Generation
↓
Answer

The name itself describes the architecture:

Retrieval
+
Augmented
+
Generation

Retrieval finds useful external information.

Augmented means that information becomes available to the model during inference.

Generation produces the final natural-language answer.

RAG
=
Generation augmented by retrieved information

2. Why “Augmented” Matters

Without retrieval:

User Question
↓
LLM Parameters + Prompt
↓
Answer

With RAG:

User Question
↓
External Retrieval
↓
Relevant Information
↓
LLM Parameters + Retrieved Information
↓
Answer

The model has gained an additional information source.

Augmentation
≠
Retraining

The model is not necessarily learning new parameters.

Instead:

Retrieved Information
→ becomes available during the current inference

3. RAG Is a System Architecture, Not Just an LLM Feature

It is more useful to think of RAG as:

an LLM connected to an information retrieval system

rather than:

an LLM that simply knows more

        External Information
               ↓
            Retriever
               ↓
User Query → Retrieved Evidence
               ↓
              LLM
               ↓
             Answer

RAG combines two systems we have already studied:

Information Retrieval
+
Language Generation

4. The Two Main Components

At the highest level, RAG contains:

Retriever
+
Generator

The Retriever answers:

What external information should the model see?

The Generator answers:

Given the question and the supplied information, what answer should be produced?

These are different jobs.

5. What Is the Retriever?

The Retriever is the component responsible for finding information relevant to the user's query.

Its search space might contain:

web pages
internal documents
support articles
PDFs
database records
knowledge-base articles
document passages

User Query
↓
Retriever
↓
Relevant Candidates

The retriever may use techniques we already studied:

lexical retrieval
dense retrieval
hybrid retrieval
ranking
reranking

RAG does not replace those techniques.

It uses them.

6. The Retriever Does Not Generate the Final Answer

The retriever's primary job is:

find useful information

not:

write a polished final response

For example:

Question:
How can I cancel my annual subscription?

Retriever Output:
Passage A
Passage B
Passage C

Those passages then become input to the next stage.

Retriever
→ Information Selection

Generator
→ Answer Production

7. What Is the Generator?

The Generator is the language model that produces the final response using the available input.

Its input may include:

system instructions
user question
retrieved context
other application instructions

User Question
+
Retrieved Information
↓
Generator
↓
Answer

The generator is usually an LLM or another generative language model.

8. Generator Does Not Mean “Source of All Knowledge”

The generator may have internal parametric knowledge.

But in a RAG system, important factual information may come from:

retrieved context

So:

Generator
≠
sole information source

Instead, the generator can:

interpret information
summarize information
organize information
explain information
produce language

while the retriever supplies external information.

9. Retriever vs. Generator

The simplest distinction is:

Retriever
→ finds

Generator
→ writes

A more precise version is:

Retriever
→ selects external information relevant to the query

Generator
→ produces the answer using the query,
  instructions, and available context

10. Retrieval Failure vs. Generation Failure

Suppose the correct answer is contained in Passage C.

Retrieval Failure

The retriever returns:

A
B
D
E

Passage C never reaches the LLM.

The generator cannot use it.

Generation Failure

The retriever correctly returns:

A
C
D

But the generator:

misreads C
ignores C
contradicts C
adds unsupported details

Here retrieval succeeded.

Generation failed.

Wrong Answer
does not automatically mean
Retrieval Failed

14.2 Basic Architecture

11. The Basic RAG Architecture

The basic RAG pipeline is:

User Query
↓
Retriever
↓
Relevant Documents / Passages
↓
LLM Context
↓
Generator
↓
Answer

Each stage performs a different function.

We can expand it slightly:

User Query
↓
Search External Collection
↓
Retrieve Relevant Documents / Passages
↓
Provide Retrieved Content to LLM
↓
LLM Processes Query + Retrieved Content
↓
Generate Answer

12. Step 1 — User Query

Everything begins with a request.

For example:

What is our refund policy for annual Enterprise plans?

At this point, the system has:

information need
expressed as
user query

13. Step 2 — Retrieval

The query is sent to a Retriever.

Query
↓
Retriever

The retriever searches its available collection.

For example:

Internal Knowledge Base

It may find:

Enterprise Billing Policy
Annual Subscription Terms
Refund Procedure

These become candidate sources.

14. Step 3 — Relevant Documents or Passages

The system does not necessarily send every retrieved document to the LLM.

It may identify:

relevant documents

or more specifically:

relevant passages

For example:

Document:
Enterprise Billing Policy

Relevant Passage:
Annual Enterprise plans may be refunded within...

A useful distinction is:

Document
→ larger information unit

Passage
→ smaller relevant section

15. Why RAG Often Uses Passages Instead of Entire Documents

Imagine a 70-page document.

Only one paragraph answers the query.

Sending the entire document may introduce:

irrelevant information
extra token usage
context competition
noise

Instead:

Large Document
↓
Relevant Passage
↓
LLM Context

We will study document preparation and chunking in Chapter 15.

16. Step 4 — LLM Context

The retrieved information must now become visible to the language model.

Suppose retrieval returns:

Passage A
Passage B
Passage C

The system may construct input approximately like:

Instructions

User Question

Retrieved Passage A
Retrieved Passage B
Retrieved Passage C

All of this becomes part of the model's current input context.

17. Step 5 — Generation

The Generator receives:

User Query
+
Retrieved Context

and produces an answer.

For example:

Question:
Can Enterprise annual subscriptions be refunded?

Retrieved Passage:
Annual Enterprise subscriptions may be refunded
within 14 days of purchase...

Generated Answer:
Yes. According to the policy, annual Enterprise
subscriptions may be refunded within 14 days...

The answer is now using retrieved external information.

18. The Full Basic Architecture

External Information Collection
          ↑
          │
User Query
↓
Retriever
↓
Relevant Documents
↓
Relevant Passages
↓
Retrieved Context
↓
LLM / Generator
↓
Answer

Or in one line:

User Query
→ Retriever
→ Relevant Documents / Passages
→ LLM Context
→ Generator
→ Answer

19. Retrieval Happens Before Generation in the Basic Model

In the basic RAG architecture:

Retrieve
↓
Generate

The system first gathers external information.

Then the generator uses it.

Information Acquisition
↓
Language Generation

20. One Query Can Retrieve Multiple Pieces of Information

The Retriever does not need to return one source.

It may return:

Passage A
Passage B
Passage C
Passage D

Query
↓
Retriever
├── Passage A
├── Passage B
└── Passage C
↓
LLM Context
↓
Generator

This can be useful when the answer requires information from multiple passages.

21. The Retrieved Result Is Not Automatically the Final Context

The retrieval system might initially retrieve:

20 candidates

but only some may eventually be provided to the LLM.

20 Retrieved Candidates
↓
Ranking / Reranking
↓
Top 5 Passages
↓
LLM Context

Retrieved Candidate Set
≠
Final LLM Context

14.3 Retrieval Context

22. What Is Retrieved Context?

Retrieved Context is the external information retrieved by the system and made available to the LLM for the current task.

For example:

User Query:
What is the refund window?

Retrieved Context:
Customers may request a refund within 14 days
of the initial annual subscription purchase.

The model can now use that information while answering.

23. Retrieved Context Is Part of the Current Input

Model Parameters
≠
Current Context

Retrieved context belongs to:

Current Context

not:

Permanent Model Parameters

Model Parameters
→ existing learned knowledge

Retrieved Context
→ temporary external information

During inference:

Parameters
+
Context
↓
Generation

24. External Context

External Context refers to information that comes from outside the model's internal parametric knowledge and is supplied during inference.

Examples:

retrieved documents
web pages
knowledge-base passages
database results
private company information

External Source
↓
External Information
↓
LLM Context
↓
LLM

25. Retrieved Context vs. External Context

External Context
→ information supplied from outside the model

Retrieved Context
→ external information specifically obtained through retrieval

For example, manually pasting a document into a prompt is external context.

If a retrieval system automatically finds that document, it becomes retrieved context.

26. What Is Context Injection?

Context Injection is the process of inserting external retrieved information into the input available to the LLM.

Retrieved Passage
↓
Insert into Model Input
↓
LLM Context

A simplified input might look like:

Instructions:
Answer using the supplied information.

Context:
Annual subscriptions may be refunded within 14 days.

Question:
What is the refund window?

The retrieved passage has been injected into the model's context.

27. Context Injection Is Not Parameter Injection

Context injection does not normally mean:

modify the neural network weights

Instead:

Retrieved Text
↓
Input Tokens
↓
Context Window
↓
Transformer Processing

Context Injection
→ changes current input

Fine-Tuning / Training
→ changes model parameters

28. Retrieved Text Becomes Tokens Like Other Input

From the model's perspective, retrieved context eventually becomes part of the input text.

Retrieved Passage
↓
Tokenization
↓
Tokens
↓
Model Context
↓
Transformer

The model does not receive a magical object called:

knowledge

It receives information represented inside its input context.

29. The Context Window Still Applies

Retrieved information enters the model's context window.

Instructions
+
Conversation
+
User Query
+
Retrieved Context
+
Generated Output

all compete for available context capacity.

Therefore:

Retrieved Information
must fit into
usable LLM context

Context budget and selection will be studied in Chapter 17.

30. Evidence Context

Evidence Context is retrieved context that is intended to support the answer.

Suppose the question is:

When can a customer request a refund?

Retrieved Passage A says:

Refund requests are accepted within 14 days.

That passage can function as evidence context because it directly supports the answer.

Retrieved Context
→ information made available

Evidence Context
→ information that can support claims

31. Not Every Retrieved Passage Is Good Evidence

A passage can be retrieved because it appears relevant.

But it may still be:

incomplete
outdated
weakly related
ambiguous
incorrect
contradictory

Retrieved
≠
Automatically Good Evidence

Later chapters will distinguish more carefully between:

source
passage
evidence
claim

32. Retrieved Context Can Change the Answer Without Changing the Model

Consider the same LLM asked:

What is the company's refund window?

With Context A:

Refund window: 14 days

the model may answer:

14 days

With Context B:

Refund window: 30 days

the same model may answer:

30 days

Same Model
+
Different Retrieved Context
↓
Different Answer

33. Context Makes External Knowledge Usable

Retrieval alone finds information.

The LLM can use it only after it becomes accessible during inference.

Retrieval
↓
Retrieved Context
↓
Context Injection
↓
LLM Processing

Without this connection:

Retriever finds information
but
Generator never sees it

the RAG system would not work.

14.4 Grounded Generation

34. What Is Grounding?

Grounding means keeping the generated answer tied to the evidence available to the model.

In a basic RAG system:

Retrieved Evidence
↓
LLM Context
↓
Generation
↓
Answer Supported by Evidence

Suppose the retrieved evidence says:

The annual plan can be cancelled from
Settings → Billing → Cancel Subscription.

The generator answers:

You can cancel the annual plan from
Settings → Billing → Cancel Subscription.

This answer is grounded because the statement is supported by the evidence supplied to the model.

Evidence
↓
Supported Answer

=
Grounding

35. Grounding Is Not a Separate Checking Stage

It is important not to imagine Grounding as necessarily being another component that comes after generation and compares the answer with the retrieved evidence.

The basic RAG pipeline is:

Retrieve Evidence
↓
Place Evidence in Context
↓
Generator Uses Evidence
↓
Grounded Answer

The grounding is the relationship between:

Generated Claims
and
Retrieved Evidence

If a separate system later checks whether those claims are actually supported, that is better described as:

Groundedness Evaluation
or
Grounding Verification

So:

Grounding
→ answer stays supported by evidence

Groundedness Evaluation
→ check whether that actually happened

36. Grounded Generation

Grounded Generation is generation that stays supported by the supplied evidence.

Question
+
Evidence Context
↓
Generator
↓
Evidence-Supported Answer

Ideally, the generator should answer based on:

what the evidence supports

rather than adding unsupported details.

37. What Is a Grounded Answer?

A Grounded Answer is an answer whose relevant factual claims are supported by the evidence available to the model.

Evidence:

The service is available Monday through Friday,
from 09:00 to 17:00.

Grounded answer:

The service is available Monday through Friday
between 09:00 and 17:00.

Unsupported answer:

The service is available seven days a week.

The first stays within the evidence.

The second does not.

38. Grounded Does Not Automatically Mean Factually True

Imagine the retrieved source itself is wrong:

Source says:
Company founded in 2018.

The model faithfully answers:

The company was founded in 2018.

The answer is grounded in that source.

But if the true year was:

the answer is factually wrong.

Grounded
≠
Necessarily True

Grounding asks:

Does the evidence support the answer?

Factuality asks:

Is the answer actually true?

We will study this distinction deeply in Chapter 20.

39. Good RAG Requires Both Good Retrieval and Good Generation

RAG Quality
depends on
Retrieval Quality
+
Generation Quality

If retrieval is poor:

Wrong Evidence
↓
Generator
↓
Potentially Wrong Answer

If retrieval is excellent but generation is poor:

Correct Evidence
↓
Generator Misinterprets It
↓
Wrong Answer

The ideal case is:

Relevant Evidence
↓
Accurate Use of Evidence
↓
Grounded Answer

40. RAG Does Not Automatically Force the LLM to Use Context Correctly

Simply adding context does not guarantee perfect behavior.

The model may:

ignore relevant passage
focus on irrelevant passage
combine evidence incorrectly
use internal knowledge instead
add unsupported information
misread wording

Context Available
≠
Context Correctly Used

41. Internal Knowledge Can Conflict with Retrieved Context

Suppose the model internally associates:

Refund Window = 30 days

but the current retrieved policy says:

Refund Window = 14 days

Now two information sources exist:

Parametric Knowledge
vs.
Retrieved Context

A RAG system generally wants the current authoritative evidence to guide the answer.

Older Internal Association
+
Current Retrieved Policy
↓
Use Current Evidence

42. Grounding Depends on Evidence Availability

A model cannot ground a claim in evidence that was never provided.

If the retrieved context contains only:

pricing information

the model should not confidently answer:

opening hours

unless another supported information source is available.

Evidence Coverage
limits
Supported Claims

43. The Generator Should Know the Difference Between Evidence and Instructions

A typical RAG input may contain:

Instructions
+
Retrieved Evidence
+
User Question

Instructions

Tell the model what to do.

Retrieved Evidence

Provides external information about the subject.

User Question

Defines what the user wants answered.

Instructions
→ behavior

Evidence
→ external information

Question
→ task

44. A Complete RAG Example — Private Knowledge Base

Suppose a company has an internal policy document.

The user asks:

Can Enterprise customers receive a refund
after cancelling an annual plan?

Step 1 — Query

Can Enterprise customers receive a refund
after cancelling an annual plan?

Step 2 — Retrieval

The Retriever searches:

Internal Knowledge Base

and finds:

Enterprise Billing Policy

Step 3 — Passage Retrieval

Enterprise annual-plan customers may request
a refund within 14 days of the original purchase.
Cancellation after the 14-day period does not
create automatic refund eligibility.

Step 4 — Retrieved Context

That passage becomes:

Retrieved Context

Step 5 — Context Injection

The system supplies:

Instructions

Retrieved Policy Passage

User Question

to the LLM.

Step 6 — Generation

Enterprise customers may request a refund
within 14 days of the original annual-plan purchase.
Cancelling after that period does not automatically
make the subscription eligible for a refund.

Step 7 — Grounding

The factual statements in the answer stay supported by the retrieved policy.

No separate grounding component is required for this relationship to exist.

Private Document
↓
Retriever
↓
Relevant Passage
↓
Retrieved Context
↓
Context Injection
↓
Generator
↓
Grounded Answer

45. A Complete RAG Example — Current Web Information

Suppose the user asks:

What did Company X announce today?

The model cannot safely depend only on internal parameters.

User Query
↓
Web Retriever / Search
↓
Current Company Announcement
↓
Relevant Passage
↓
LLM Context
↓
Generator
↓
Answer

The architecture is essentially the same as private RAG.

The main difference is the external source:

Private RAG
→ private knowledge base

Web RAG
→ public web

The underlying pattern remains:

Retrieve
→ Contextualize
→ Generate

46. RAG as a Pipeline of Information Transformation

It is useful to see RAG as information moving through several forms.

External Information
↓
Retrieved Candidate
↓
Relevant Passage
↓
Retrieved Context
↓
Model Input
↓
Generated Language
↓
Answer

At every step, information can be:

selected
filtered
lost
misinterpreted

So the final answer depends on the entire pipeline.

Not just the LLM.

47. Where RAG Can Fail

Retrieval Failure

Correct document not found

Ranking Failure

Correct document found
but ranked too low

Passage Failure

Correct document found
but wrong section selected

Context Failure

Useful evidence not supplied effectively

Generation Failure

Evidence available
but answer misuses it

Grounding Failure

Answer includes claims
not supported by supplied evidence

This layered failure model will become useful later in AI Visibility analysis.

48. Why RAG Matters for AI Visibility

A brand or source does not necessarily need to be memorized inside model parameters to influence an answer.

It may influence an answer through retrieval.

Brand / Website / Third-Party Source
↓
Retrieval
↓
Relevant Passage
↓
LLM Context
↓
Generated Answer

A source may therefore need to become:

retrievable
relevant
highly ranked
selected into context
usable as evidence

before it can influence the final answer.

49. RAG Is Not the Same as Search

Search typically focuses on:

Find and Rank Information

RAG adds generation.

Search

Query
↓
Retrieval
↓
Ranked Results

versus:

RAG

Query
↓
Retrieval
↓
Retrieved Context
↓
Generator
↓
Answer

50. RAG Is Not the Same as Fine-Tuning

Fine-Tuning

Training Data
↓
Parameter Updates
↓
Modified Model

RAG

External Information
↓
Retrieval
↓
Context
↓
Inference

Fine-Tuning
→ changes model parameters

RAG
→ supplies information at inference time

51. RAG Is Not the Same as a Larger Context Window

A model can have a large context window without using retrieval.

For example:

User manually provides
100 pages
↓
LLM Context

That is not necessarily RAG.

RAG specifically introduces:

retrieval

to determine what external information should be supplied.

Large Context
≠
RAG

52. RAG Is Not the Same as Memory

RAG
≠
Model Memory

RAG retrieves information from an external source.

Memory systems may preserve information from previous interactions or user history.

Both can provide context, but they are conceptually different mechanisms.

53. Common Misunderstandings

Misunderstanding 1: RAG is a special kind of LLM

Incorrect. RAG is an architecture that combines retrieval with generation.

Misunderstanding 2: The Retriever and Generator are the same component

Incorrect. The Retriever finds information. The Generator produces language.

Misunderstanding 3: The Retriever must always search the public web

Incorrect. It may search a private knowledge base, internal documents, or another external collection.

Misunderstanding 4: Retrieved documents automatically become permanent model knowledge

Incorrect. They normally become temporary inference context.

Misunderstanding 5: Context Injection modifies model parameters

Incorrect. It modifies the current input.

Misunderstanding 6: Every retrieved passage is evidence

Not necessarily. A retrieved passage may be irrelevant, outdated, incomplete, or otherwise unsuitable.

Misunderstanding 7: If retrieval succeeds, the answer must be correct

Incorrect. Generation can still misuse correct evidence.

Misunderstanding 8: Grounding is a separate post-generation checker

Not necessarily. Grounding describes the relationship between generated claims and the evidence supplied to the model. A separate later check would be Groundedness Evaluation.

Misunderstanding 9: A grounded answer must be factually true

Not necessarily. The source itself can be wrong.

Misunderstanding 10: RAG and fine-tuning solve the same problem

Incorrect. Fine-tuning changes model parameters; RAG supplies external information during inference.

Misunderstanding 11: A large context window automatically means RAG

Incorrect. RAG specifically includes a retrieval step.

Misunderstanding 12: RAG eliminates hallucinations

Incorrect. Retrieval and generation can still fail.

54. How the Concepts Connect

Chapter 13 gave us:

Model Knowledge Limitations
↓
Need External Information
↓
Retrieval

Chapter 14 turns that idea into an architecture:

User Query
↓
Retriever
↓
Relevant Documents / Passages
↓
Retrieved Context
↓
Context Injection
↓
Generator
↓
Grounded Answer

The responsibilities are now clearer:

Retriever
→ find external information

Retrieved Context
→ carry that information into inference

Generator
→ produce the answer

Grounding
→ keep generated claims supported by evidence

This gives us the first complete RAG mental model:

External Information
       ↓
    Retriever
       ↓
Relevant Passage
       ↓
Retrieved Context
       ↓
Context Injection
       ↓
      LLM
       ↓
   Generation
       ↓
Grounded Answer

But one important question remains:

Where do the retrievable passages come from?

A large document does not automatically become an effective retrieval index.

It must first be:

processed
parsed
divided into useful units
represented
indexed

That leads directly into:

Chapter 15 — Preparing Information for Retrieval

Mental Model

Imagine a lawyer working with a large internal archive.

A client asks:

What does our contract say about early termination?

The lawyer first searches the archive.

Question
↓
Search Archive

This is the:

Retriever

The lawyer finds a 50-page contract.

Only one section matters:

Section 8.3 — Early Termination

That is the:

Relevant Passage

The lawyer places that passage on the desk.

That is like:

Retrieved Context

Now the lawyer reads:

the client's question
+
the relevant contract section

and writes the answer.

That is:

Generation

If the answer stays within what the contract supports:

Answer
↕
Contract Evidence

the answer is:

Grounded

The AI equivalent is:

User Query
↓
Retriever
↓
Relevant Document / Passage
↓
Retrieved Context
↓
Context Injection
↓
Generator
↓
Grounded Answer

The simplest mental model is:

Retriever
→ finds what the model should read

Context
→ gives it to the model

Generator
→ writes the answer

Grounding
→ means the answer stays tied to that evidence

And the simplest reliable definition is:

Retrieval-Augmented Generation is an architecture in which a Retriever finds relevant external information, that information is injected into the LLM's current context, and a Generator produces an answer using both the user's query and the retrieved evidence. Grounding describes the relationship in which the generated claims remain supported by that evidence.

Chapter 14 Recap

Retrieval-Augmented Generation — RAG

An architecture combining:

Retrieval
+
Generation

User Query
↓
Retriever
↓
Relevant Information
↓
Generator
↓
Answer

Retriever

The component responsible for finding external information relevant to the query.

Query
↓
Retriever
↓
Relevant Documents / Passages

Generator

The generative model that produces the answer.

Question
+
Retrieved Context
↓
Generator
↓
Answer

Retriever vs. Generator

Retriever
→ selects information

Generator
→ produces language

Basic RAG Architecture

User Query
↓
Retriever
↓
Relevant Documents / Passages
↓
LLM Context
↓
Generator
↓
Answer

Document

A larger information unit.

article
PDF
manual
policy
web page

Passage

A smaller section of a document that may be directly relevant to a query.

Document
↓
Relevant Passage

Retrieved Context

External information retrieved and made available to the LLM for the current task.

Retriever
↓
Retrieved Context
↓
LLM

External Context

Information supplied from outside the model's internal parameters.

web content
private documents
knowledge-base information
database results

Context Injection

The process of placing retrieved external information into the LLM's current input.

Retrieved Information
↓
Model Input
↓
Context Window

Context Injection vs. Training

Context Injection
→ changes current input

Training
→ changes model parameters

Evidence Context

Retrieved information that can support the generated answer.

Evidence
↓
Context
↓
Generation

Grounding

The relationship in which generated claims stay supported by the supplied evidence.

Retrieved Evidence
↓
Generator Uses Evidence
↓
Supported Answer

Grounding is not necessarily a separate post-generation checking stage.

Groundedness Evaluation

A later check that asks whether the generated answer was actually supported by the evidence.

Generated Answer
+
Evidence
↓
Evaluate Support

Grounded Generation

Question
+
Evidence
↓
Generator
↓
Evidence-Supported Answer

Grounded Answer

An answer whose relevant factual claims are supported by the supplied evidence.

Answer Claim
↕
Supporting Evidence

Grounding vs. Factuality

Grounding
→ Is the answer supported by the evidence?

Factuality
→ Is the answer actually true?

Retrieval Failure

Needed Evidence
not retrieved
↓
Generator cannot use it

Generation Failure

Correct Evidence
retrieved
↓
Generator misuses it

RAG and Model Parameters

Retrieved Information
→ current context

not necessarily

Retrieved Information
→ permanent parameter update

RAG vs. Fine-Tuning

Fine-Tuning
→ parameter updates

RAG
→ inference-time external information

RAG vs. Search

Search
→ retrieves ranked information

RAG
→ retrieves information
   and generates an answer from it

The complete Chapter 14 architecture is:

External Information Source
↓
Retriever
↓
Relevant Documents / Passages
↓
Retrieved Context
↓
Context Injection
↓
LLM / Generator
↓
Grounded Generation
↓
Grounded Answer

We now understand:

why LLMs need retrieval

from Chapter 13, and:

how retrieval connects to generation

from Chapter 14.

The next question is:

How should documents be processed so that the Retriever can reliably find the right information?

That leads into:

Chapter 15 — Preparing Information for Retrieval

The Single Most Important Idea from Chapter 14

RAG is not simply an LLM that “knows more.” It is a multi-component architecture: a Retriever finds relevant external information, that information becomes Retrieved Context inside the model's current input, and a Generator uses it to produce an answer. Grounding means that the generated claims stay supported by that retrieved evidence; checking whether this happened is a separate evaluation problem.