Chapter 17- Building the Context for the LLM

Chapter Goal

In Chapter 16, we prepared the query for retrieval:

User Query
↓
Query Understanding
↓
Rewriting / Expansion / Decomposition
↓
Retrieval Queries
↓
Retriever

The Retriever may now return several relevant passages.

For example:

Passage A
Passage B
Passage C
Passage D
Passage E
Passage F

But this creates a new problem:

Which of these passages should actually be given to the LLM?

The answer cannot simply be:

give everything to the model

because the LLM has a limited context window, and not every retrieved passage is equally useful.

So after retrieval, the system may need to:

select the best passages
↓
remove weak or irrelevant passages
↓
fit useful information into the context budget
↓
compress information when necessary
↓
identify the parts that can support the answer
↓
construct the final context

The central pipeline is:

User Query
↓
Retrieval
↓
Candidate Passages
↓
Context Selection
↓
Relevance Filtering
↓
Context Budget
↓
Context Compression
↓
Supporting Evidence
↓
Final LLM Context
↓
Generation

The main idea is:

Retrieval finds possible information. Context construction decides what information the LLM will actually see.

By the end of this chapter, you should understand:

what Context Selection is;
what Passage Selection means;
how Relevance Filtering works;
why the Context Window creates a budget;
what Context Allocation means;
what Context Competition is;
why too much context can become harmful;
what Context Compression is;
what Summarized Context means;
what Relevant Passage Extraction does;
what Evidence Retrieval means;
what Supporting Passage Retrieval is;
what Evidence Candidate Selection means;
and how retrieved information becomes usable LLM context.

17.1 Context Selection

1. What Is Context Selection?

Context Selection is the process of deciding which retrieved information should actually be included in the LLM's context.

Suppose retrieval returns:

10 passages

The system may decide that only:

Passage 2
Passage 4
Passage 7

are useful enough to include.

Retrieved Candidates
↓
Context Selection
↓
Selected Context

The important distinction is:

Retrieved
≠
Automatically Included in Context

Retrieval creates candidates.

Context Selection decides what survives.

2. Why Context Selection Is Necessary

Imagine the Retriever returns:

Passage A
→ directly answers the question

Passage B
→ somewhat related

Passage C
→ outdated

Passage D
→ directly relevant

Passage E
→ mostly irrelevant

Putting all five into the prompt may create unnecessary noise.

Instead:

A
D

may be enough.

Context Selection tries to answer:

Which pieces of retrieved information are most useful for this specific generation task?

3. Retrieval Candidates vs. Final Context

Retrieval Candidates

Everything returned by the retrieval system.

Candidate A
Candidate B
Candidate C
Candidate D
Candidate E

Final Context

The information eventually given to the LLM.

Candidate A
Candidate D

Retrieval Output
↓
Selection
↓
LLM Input

The final context is usually a subset of the available candidate information.

4. What Is Passage Selection?

Passage Selection means choosing specific passages from the retrieved candidate set for inclusion in the LLM context.

Suppose a query asks:

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

Retrieval returns:

Passage A:
Annual plans renew automatically.

Passage B:
Enterprise refunds are available within 14 days.

Passage C:
Users can update payment methods from Settings.

Passage D:
Cancellation after 14 days does not automatically
create refund eligibility.

Useful passages are:

B
D

because they directly support the information need.

5. Passage Selection Is Query-Dependent

A passage can be useful for one query and useless for another.

For example:

Passage:
Annual subscriptions renew automatically every year.

For:

When does my subscription renew?

this passage is highly useful.

For:

Can I receive a refund?

it may not answer the question.

Useful Passage
depends on
User Query

6. What Is Relevance Filtering?

Relevance Filtering removes passages that are not sufficiently relevant to the current query or task.

Retrieved Candidates
↓
Relevance Filtering
↓
Remove Weak Candidates
↓
Keep Relevant Candidates

Example:

Query:
Enterprise refund eligibility

Retrieved passages:

A → Enterprise refund policy
B → Enterprise login instructions
C → Refund exceptions
D → Password reset

After relevance filtering:

A
C

remain.

7. Retrieval Ranking vs. Relevance Filtering

Ranking

1. Passage A
2. Passage C
3. Passage B
4. Passage D

Ranking orders candidates.

Filtering

Keep:
A
C

Remove:
B
D

Filtering removes candidates that are not useful enough.

Ranking
→ Which is better?

Filtering
→ Is this useful enough to keep?

8. Why Retrieved Results May Still Need Filtering

Even a good Retriever can return imperfect candidates.

Early retrieval stages may prefer to retrieve some extra candidates rather than risk missing the correct information entirely.

Broad Retrieval
↓
Candidate Pool
↓
Ranking / Reranking
↓
Filtering
↓
Precise Selection

9. Context Selection Is Not the Same as Retrieval

Retrieval searches the collection.

Context Selection works on what retrieval already found.

Search Index
↓
Retrieval
↓
Candidate Passages
↓
Context Selection
↓
LLM Context

Retrieval
→ find possible information

Context Selection
→ choose what the LLM should see

17.2 Context Budget

10. What Is a Context Budget?

An LLM cannot receive unlimited information.

Its input must fit within a finite Context Window.

The system therefore effectively has a:

Context Budget

The budget must accommodate:

system instructions
conversation history
user query
retrieved passages
other application context
generated output

Context Window
=
Limited Capacity

11. Context Window Review

Recall from Chapter 1 that the Context Window is the amount of information the model can process within the current interaction.

Context Window
├── Instructions
├── Conversation
├── User Query
├── Retrieved Context
└── Output Space

Retrieved passages must fit inside this larger space.

Retrieval Capacity
≠
Context Capacity

A Retriever may find hundreds of relevant passages while the final LLM context uses only a small subset.

12. Why Not Put Everything Into the Context?

Even if the model can technically hold all retrieved information, including everything may still be undesirable.

Too much context can introduce:

irrelevant information
duplicate information
conflicting information
context competition
higher token usage
more difficult evidence selection

The goal is not:

Maximum Context

The goal is:

Useful Context

13. What Is Context Allocation?

Context Allocation means deciding how much of the available context window should be assigned to different kinds of information.

Imagine a hypothetical context budget of:

100 units

An application might allocate:

10 → system instructions
15 → conversation history
5  → user query
50 → retrieved evidence
20 → output

The numbers are only illustrative.

The important concept is:

Finite Context
↓
Different Information Types
↓
Allocation Decisions

14. Retrieval Competes With Other Context

Retrieved passages are not the only information inside the context window.

System Prompt
+
Conversation History
+
User Query
+
Retrieved Evidence
+
Tool Results

all consume space.

Therefore:

More Retrieved Context
↓
Less Remaining Context Capacity

Context construction is therefore partly a resource-allocation problem.

15. What Is Context Competition?

Context Competition occurs when multiple pieces of information compete for limited context capacity and the model's ability to use that information effectively.

Suppose the context contains:

Passage A → highly relevant
Passage B → highly relevant
Passage C → weakly relevant
Passage D → irrelevant
Passage E → duplicate

All consume context.

But only A and B may be necessary.

Limited Context
+
Many Candidate Passages
↓
Competition

16. Context Competition Is Not Only About Token Limits

A model may technically have enough capacity to hold all passages.

But the information can still compete conceptually.

Correct Passage
+
10 Weak Passages
+
3 Conflicting Passages

may be harder to use reliably than:

Correct Passage
+
1 Supporting Passage

So Context Competition concerns both:

capacity
+
information quality

17. Duplicate Information Also Uses Budget

Suppose retrieval returns five passages that all say:

Refund period = 14 days

Including all five may add little new information.

Same Evidence
Repeated 5 Times
↓
More Context Usage
↓
Little Additional Information

The system may prefer one or two strong passages instead.

18. Context Budget Creates a Selection Problem

Imagine retrieval produces:

50 passages

but the usable context can reasonably support:

5 passages

The system must choose.

Many Candidate Passages
↓
Limited Context Budget
↓
Select Most Useful Information

This is why Context Selection and Context Budget are tightly connected.

17.3 Context Compression

19. What Is Context Compression?

Context Compression means reducing the amount of retrieved information while preserving the parts most useful for the current task.

Large Retrieved Context
↓
Compression
↓
Smaller Useful Context

The goal is:

Less Text
+
Preserve Important Information

20. Why Context Compression Is Useful

Suppose retrieval returns a 2,000-word section.

Only three sentences are relevant.

Instead of sending all 2,000 words:

Large Passage
↓
LLM

the system may produce:

Relevant Information Only
↓
LLM

This can reduce:

token usage
noise
context competition
irrelevant information

21. Compression Is Different From Dropping Everything

Context Compression does not simply mean deleting information randomly.

A useful compression process tries to preserve:

facts needed for the query
important conditions
exceptions
relationships
supporting evidence

while removing:

unrelated details
repetition
boilerplate
irrelevant sections

22. What Is Summarized Context?

Summarized Context is a shorter representation of retrieved information created through summarization.

Original:

Enterprise customers who purchase an annual plan
are eligible to request a refund within fourteen
calendar days of the initial purchase date.

After this period, cancellation prevents future
renewal but does not automatically create refund
eligibility for the current subscription period.

Summarized:

Enterprise annual plans are refundable within
14 days of purchase. Cancelling after that period
stops renewal but does not automatically create
refund eligibility.

The important information remains while the context becomes smaller.

23. Summarization Can Lose Important Details

Compression creates a risk.

Suppose the original passage says:

Refunds are available within 14 days,
except for accounts that have used
more than 80% of their annual service credits.

A poor summary says:

Refunds are available within 14 days.

The exception disappeared.

Compression
↓
Potential Information Loss

Good Context Compression must preserve details that matter to the query.

24. What Is Relevant Passage Extraction?

Instead of summarizing a long document, the system can extract only the specific passage that matters.

This is Relevant Passage Extraction.

Suppose the retrieved document contains:

Section 1 — Account Creation
Section 2 — Billing
Section 3 — Refunds
Section 4 — Security
Section 5 — Data Export

The user asks:

What is the refund period?

The system can extract:

Section 3 — Refunds

or even:

Enterprise annual plans are refundable
within 14 days of purchase.

Large Retrieved Document
↓
Relevant Passage Extraction
↓
Small Relevant Context

25. Summarization vs. Relevant Passage Extraction

Summarization

Long Passage
↓
Shorter Rewritten Version

Relevant Passage Extraction

Long Document
↓
Relevant Original Passage

Summarization
→ rewrite more compactly

Extraction
→ select smaller original content

Both can reduce context size.

26. Extraction Can Preserve Original Wording

One advantage of extraction is that the original source wording remains available.

Original:

Refund requests must be submitted within
14 calendar days of purchase.

Relevant Passage Extraction keeps:

Refund requests must be submitted within
14 calendar days of purchase.

A summary might instead say:

Refunds are allowed for 14 days.

The meaning is similar, but the wording has changed.

27. Compression Happens After Retrieval

Query
↓
Retrieval
↓
Retrieved Information
↓
Compression
↓
Compact Context
↓
LLM

Compression does not search the original corpus.

It operates on already retrieved information.

Retrieval
→ find information

Compression
→ reduce retrieved information

17.4 Evidence Retrieval

28. What Is Evidence Retrieval?

Evidence Retrieval means finding retrieved information that can support the answer the system needs to produce.

The emphasis shifts from:

find information related to the topic

toward:

find information that can support the answer

User Question
↓
Retrieved Information
↓
Supporting Information
↓
Evidence Candidates

29. Relevant Information vs. Supporting Evidence

A passage can be relevant without directly supporting the required answer.

Question:

How long is the Enterprise refund period?

Passage A:

Enterprise subscriptions are billed annually.

This is related to the topic.

But it does not support the answer.

Passage B:

Enterprise customers may request a refund
within 14 days of the original purchase.

This directly supports the answer.

Relevant
≠
Necessarily Supporting

A useful mental distinction is:

Relevant Context
→ useful for understanding or answering

Evidence
→ directly supports what the answer says

30. What Is Supporting Passage Retrieval?

Supporting Passage Retrieval focuses on passages capable of supporting a specific answer or claim.

Suppose the question is:

Does cancelling an Enterprise plan automatically
create refund eligibility?

A supporting passage says:

Cancellation after the refund period prevents
future renewal but does not automatically create
refund eligibility.

That passage directly supports:

No.

Question
↓
Supporting Passage
↓
Supported Answer

31. Supporting Passages Can Come From Multiple Sources

Sometimes one passage is enough.

Other times, the answer requires several pieces of information.

For example:

Question:
Which plan is cheaper and which offers refunds?

The system may need:

Passage A
→ pricing information

Passage B
→ refund policy

Answer
↓
may depend on
↓
Multiple Supporting Passages

32. What Is Evidence Candidate Selection?

Among the relevant context, some passages may directly support the factual statements needed in the answer.

These can be treated as:

Evidence Candidates

Conceptually:

Retrieved Passages
↓
Relevant Context
↓
Potential Supporting Passages
↓
Evidence Candidates

Evidence Candidate Selection means identifying which of those passages are useful as direct support.

33. Context Selection vs. Evidence Selection

These concepts often overlap, but they answer slightly different questions.

Context Selection

What information is useful for the LLM to see?

Evidence Selection

What information directly supports what the answer needs to say?

For example:

Passage A:
Enterprise is the company's premium plan.

Passage B:
Enterprise customers may request a refund
within 14 days.

Passage C:
Cancellation after 14 days prevents renewal
but does not automatically create refund eligibility.

All three may be useful context:

Context:
A + B + C

But the direct evidence for the refund answer is:

Evidence:
B + C

So a useful relationship is:

Retrieved Information
↓
Relevant Context
↓
Evidence

Evidence is often a more specific subset of the context.

34. Evidence Selection Is Not Always a Separate Stage

In a simple RAG pipeline, Context Selection, Compression, and Evidence Selection may overlap heavily.

For example:

Retrieved Passage
↓
Select Relevant Passage
↓
Extract Relevant Part
↓
Final Context

If that extracted part directly supports the answer, then the same information is both:

Context
and
Evidence

So the system does not necessarily need a separate physical component called:

Evidence Selector

The conceptual distinction remains useful:

Context
→ what the model sees

Evidence
→ what supports the answer

35. Evidence Retrieval Does Not Guarantee Correct Evidence

The system may still retrieve:

outdated policy
wrong product
wrong country
incomplete passage
conflicting source

Evidence Candidate
≠
Automatically Valid Evidence

At this stage, the system is identifying potential support.

Later chapters will examine:

evidence quality
claim support
grounding
faithfulness

more precisely.

36. The Full Context-Building Pipeline

We can now connect the four parts of Chapter 17.

Retrieved Candidates
↓
Context Selection
↓
Passage Selection
↓
Relevance Filtering
↓
Selected Relevant Context

Then the system must fit that information into the available context:

Selected Context
↓
Context Budget
├── Context Window
├── Context Allocation
└── Context Competition

If the selected information is still too large:

Selected Context
↓
Context Compression
├── Summarized Context
└── Relevant Passage Extraction

The resulting information may then contain passages that directly support the answer:

Compressed / Selected Context
↓
Supporting Passages
↓
Evidence Candidates

Finally:

Final LLM Context
↓
Generation

In some systems, these steps are implemented separately.

In others, several of them happen together.

37. A Complete Example

Suppose the user asks:

Can I cancel my Enterprise annual subscription,
and can I still get a refund?

The Retriever returns:

Passage A:
Enterprise subscriptions renew annually.

Passage B:
Customers can disable renewal from Billing Settings.

Passage C:
Refund requests are allowed within 14 days.

Passage D:
Enterprise plans include priority support.

Passage E:
Cancellation after 14 days prevents future renewal
but does not create automatic refund eligibility.

Passage F:
Standard plans have a 30-day refund period.

Step 1 — Context Selection

The system identifies:

B
C
E

as the most useful passages.

It removes:

A
D
F

for this specific question.

Step 2 — Relevance Filtering

Passage F discusses refunds, but for:

Standard plans

The user asked about:

Enterprise

so it is filtered out.

Step 3 — Context Budget

Suppose B, C, and E all fit inside the available context budget.

They can remain.

Step 4 — Context Compression

If the original passages were much longer, the system could extract only:

B:
Customers can disable renewal from Billing Settings.

C:
Refund requests are allowed within 14 days.

E:
Cancellation after 14 days prevents future renewal
but does not create automatic refund eligibility.

Now the context is compact and focused.

Step 5 — Evidence

For:

Can I cancel?

Passage B provides direct support.

For:

Can I still get a refund?

Passages C and E provide direct support.

In this example, the same selected and compressed passages function as both:

Final Context
and
Evidence

There does not need to be another completely separate selection stage.

Step 6 — Generation

The LLM receives:

User Question
+
Passage B
+
Passage C
+
Passage E

and can generate:

Yes. You can disable renewal from Billing Settings.
Refund requests are available within 14 days of purchase.
After that period, cancellation prevents future renewal
but does not automatically create refund eligibility.

The important point is that the LLM did not receive every retrieved passage.

It received a carefully constructed context containing information that also serves as supporting evidence.

38. Why This Stage Matters for RAG

RAG is often summarized as:

Retrieve
↓
Generate

But a more realistic simplified architecture is:

Retrieve
↓
Select
↓
Filter
↓
Fit to Context Budget
↓
Compress if Necessary
↓
Construct Useful Evidence Context
↓
Generate

The gap between:

retrieved information

and:

information actually shown to the LLM

is extremely important.

39. Why This Matters for AI Visibility

Suppose a website is successfully retrieved.

That still does not guarantee that its content will influence the final answer.

The source might be:

retrieved

but its passage might fail Context Selection.

Or another passage may provide stronger support for the answer.

Source Retrieved
↓
Passage Candidate
↓
Context Selection
↓
Supporting Evidence
↓
LLM Context
↓
Possible Answer Influence

Retrieval Presence
≠
Guaranteed Context Presence

and:

Context Presence
≠
Guaranteed Final Answer Presence

40. Common Misunderstandings

Misunderstanding 1: Everything retrieved should be given to the LLM

Incorrect. Retrieved passages are candidates. Context Selection decides what should enter the final context.

Misunderstanding 2: Passage Selection and Retrieval are the same thing

Incorrect. Retrieval finds candidates. Passage Selection chooses among them for context.

Misunderstanding 3: Ranking automatically means every top-ranked passage should enter the prompt

Not necessarily. Context budget and relevance filtering can still change the final selection.

Misunderstanding 4: A larger context window makes Context Selection unnecessary

Incorrect. Noise, duplication, conflicts, and context competition still matter.

Misunderstanding 5: Context Budget means only the retrieved passages

Incorrect. Instructions, conversation history, user input, and output space also consume context.

Misunderstanding 6: Context Competition happens only when the token limit is exceeded

Incorrect. Irrelevant, duplicate, or conflicting information can compete even when everything technically fits.

Misunderstanding 7: Context Compression simply means deleting text

Incorrect. Its goal is to reduce size while preserving useful information.

Misunderstanding 8: Summarized Context and Relevant Passage Extraction are the same

Incorrect. Summarization rewrites information compactly. Extraction keeps the relevant original content.

Misunderstanding 9: Compression cannot change meaning

Incorrect. Poor compression can remove important conditions or exceptions.

Misunderstanding 10: Every relevant passage is automatically evidence

Incorrect. A passage may provide useful background without directly supporting the answer.

Misunderstanding 11: Evidence Selection must always be a separate technical stage

Incorrect. In simple RAG systems, the same selected and compressed passage may function as both Context and Evidence.

Misunderstanding 12: Evidence is completely different information from the selected context

Incorrect. Evidence usually comes from the relevant context. The distinction is mainly about its role: evidence directly supports what the answer says.

Misunderstanding 13: Evidence Retrieval guarantees correct evidence

Incorrect. Evidence candidates can still be outdated, incomplete, conflicting, or incorrect.

Misunderstanding 14: If a source is retrieved, it must influence the final answer

Incorrect. Its passage may never enter the final context.

41. How the Concepts Connect

Chapter 15 prepared the source side:

Document
↓
Parsing
↓
Chunking
↓
Embedding
↓
Indexing

Chapter 16 prepared the query side:

User Query
↓
Interpretation
↓
Rewriting
↓
Expansion
↓
Fan-Out

Retrieval connects both:

Prepared Query
+
Searchable Index
↓
Retriever
↓
Candidate Passages

Chapter 17 handles what happens next:

Candidate Passages
↓
Context Selection
↓
Relevance Filtering
↓
Context Budget
↓
Context Compression
↓
Supporting Evidence
↓
Final LLM Context

The larger RAG pipeline is now:

DOCUMENT SIDE

Documents
↓
Parsing
↓
Chunking
↓
Indexing


QUERY SIDE

User Query
↓
Query Understanding
↓
Query Variants


RETRIEVAL

↓
Candidate Passages


CONTEXT BUILDING

↓
Selection
↓
Filtering
↓
Budgeting
↓
Compression
↓
Supporting Evidence
↓
Final Context


GENERATION

↓
LLM
↓
Answer

We now understand:

Chapter 13
→ Why retrieval is needed

Chapter 14
→ How RAG works

Chapter 15
→ How documents are prepared

Chapter 16
→ How queries are prepared

Chapter 17
→ How retrieved information becomes LLM context

The next major question is:

When does a source or passage actually become evidence for an answer?

That takes us into:

Chapter 18 — From Source to Evidence

Mental Model

Imagine a lawyer preparing for a court hearing.

The lawyer searches the case archive and finds:

30 potentially relevant documents

That is:

Retrieval

The lawyer does not place all 30 documents in front of the judge.

First, they choose the most useful ones.

Context Selection

Then they remove sections that do not relate to the issue.

Relevance Filtering

The lawyer has limited time and limited space in the argument.

Context Budget

Several documents compete for that limited space.

Context Competition

A 100-page report may contain only two paragraphs that matter.

The lawyer extracts those paragraphs.

Relevant Passage Extraction

Or the lawyer may summarize a long section.

Summarized Context

Now suppose those two extracted paragraphs directly support the argument the lawyer wants to make.

Those same paragraphs are now also:

Evidence

No second set of completely different information is required.

The difference is their role:

Context
→ useful information available for reasoning

Evidence
→ information that directly supports the claim

The AI equivalent is:

Retrieved Passages
↓
Select Useful Passages
↓
Remove Weak Passages
↓
Fit Within Context Budget
↓
Compress if Needed
↓
Identify Direct Supporting Information
↓
Give Final Context to LLM

The simplest mental model is:

Retrieve
→ find possibilities

Select
→ choose useful information

Budget
→ decide what can fit

Compress
→ keep the useful parts

Evidence
→ the parts that directly support the answer

And the simplest reliable definition is:

Building the context for an LLM means transforming a broad set of retrieved candidates into a smaller, relevant, information-dense set of passages that fits within the model's context budget. Some or all of those selected passages may also function as evidence when they directly support the claims the model needs to make.

Chapter 17 Recap

Context Selection

Choosing which retrieved information should enter the LLM context.

Retrieved Candidates
↓
Context Selection
↓
Selected Context

Passage Selection

Choosing specific retrieved passages useful for the query.

Candidate Passages
↓
Selected Passages

Relevance Filtering

Removing passages that are not sufficiently useful for the current information need.

Retrieved Candidates
↓
Filter
↓
Relevant Candidates

Ranking vs. Filtering

Ranking
→ order candidates

Filtering
→ remove weak candidates

Context Window

The limited amount of information available to the model during the current interaction.

Instructions
+
Conversation
+
User Query
+
Retrieved Context
+
Output

Context Budget

The usable context capacity that must be distributed among different information types.

Finite Context
↓
Allocation Decisions

Context Allocation

Deciding how context capacity is distributed among instructions, conversation, query, evidence, and output.

Context Competition

Competition among useful, irrelevant, duplicate, or conflicting information inside the available context.

Useful Evidence
+
Noise
+
Duplicates
+
Conflicts
↓
Competition

Context Compression

Reducing retrieved information while preserving what matters.

Large Context
↓
Compression
↓
Smaller Useful Context

Summarized Context

A shorter rewritten representation of retrieved information.

Long Retrieved Text
↓
Summary
↓
Compact Context

Relevant Passage Extraction

Selecting the useful original portion of a larger retrieved source.

Large Document
↓
Extract Relevant Passage
↓
LLM Context

Summarization vs. Extraction

Summarization
→ rewrite more compactly

Extraction
→ retain smaller original passage

Evidence Retrieval

Finding retrieved information that can support the answer.

Question
↓
Supporting Information
↓
Evidence Candidates

Supporting Passage Retrieval

Finding passages that directly support the information the answer needs to state.

Question
↓
Supporting Passage
↓
Supported Answer

Evidence Candidate Selection

Identifying which parts of the relevant context can directly support the answer.

Relevant Context vs. Evidence

Relevant Context
→ useful for understanding or answering

Evidence
→ directly supports the answer

Evidence is often a subset of the relevant context.

Context and Evidence Can Be the Same Passage

In a simple RAG system, the same selected and compressed passage may function as both Context and Evidence.

Selected Passage
↓
Useful for Generation
+
Directly Supports Answer

=
Context + Evidence

Retrieval Presence vs. Context Presence

Retrieved
≠
Automatically Included in Context

A source can be retrieved and still never reach the LLM.

The complete Chapter 17 pipeline is:

User Query
↓
Retrieval
↓
Candidate Passages
↓
Context Selection
↓
Passage Selection
↓
Relevance Filtering
↓
Context Budget
├── Context Window
├── Context Allocation
└── Context Competition
↓
Context Compression
├── Summarized Context
└── Relevant Passage Extraction
↓
Supporting Evidence
↓
Final LLM Context
↓
Generation

The RAG pipeline we have built across Chapters 13–17 is now:

Why Retrieval?
↓
Prepare Documents
↓
Understand Query
↓
Retrieve Candidates
↓
Build Context
↓
LLM Generation

The next chapter begins a new layer:

Chapter 18 — From Source to Evidence

The Single Most Important Idea from Chapter 17

Retrieval produces candidate information, not the final LLM context. The system still has to select useful passages, filter weak information, manage limited context capacity, and compress material when necessary. Evidence is not necessarily a separate set of information: it is usually the part of the selected context that directly supports what the final answer says.