Mental model
Module 10: Build the evidence package the model actually sees- Select, order, deduplicate and budget retrieved evidence so the model receives useful context rather than a dump of search results.
RAG & Knowledge Systems Engineering · Module 10 of 18
Engineer
Context Construction
Select, order, deduplicate and budget retrieved evidence so the model receives useful context rather than a dump of search results.
Engineering focus: Build the evidence package the model actually sees
In plain English
What problem are we solving?
Select, order, deduplicate and budget retrieved evidence so the model receives useful context rather than a dump of search results.
You are not expected to know the engineering vocabulary before using the idea. Formal terminology comes after the mental model.
Running case · Evidence Desk
Improve the same system, module by module.
Carry one evidence-grounded knowledge assistant through all 18 modules. Preserve source IDs, retrieval evidence, evaluation cases, authority decisions and security assumptions so every improvement is measurable.
Mental model
Understand it before you optimize it.
The context window is a suitcase with a size limit. Pack the strongest, non-duplicate evidence first and keep labels so every claim can be traced back.
01Ranked chunks
02Deduplicate
03Authority / recency
04Token budget
05Context packet + IDs
Remember
More context is not automatically better context.
Learning objectives
By the end of this module, you should be able to:
- Create an explicit context budget.
- Deduplicate overlapping chunks.
- Order evidence using relevance and authority.
Context is a scarce resource
Every token used for irrelevant evidence competes with instructions, user input and useful sources.
Deduplicate overlapping chunks
Chunk overlap and multi-retriever fusion can return near-duplicates. Repetition wastes context and may bias generation.
Order matters
High-quality authoritative evidence should be easy for the model to use. Consider relevance, recency and source authority.
Preserve citation mapping
The context builder should maintain stable source/chunk identifiers so generated claims can be mapped back to evidence.
Engineering depth
Engineering deep dive
- Allocate a context budget across instructions, conversation and retrieved evidence.
- Prefer evidence diversity over repeated overlapping chunks.
- Keep stable source labels adjacent to their text.
- Measure context precision/noise sensitivity when increasing top-k or token budget.
Worked examples
Context budget
Budget: 2,000 tokens
Instructions 300
User question 80
Evidence A 500
Evidence B 420
Evidence C 350
Citation labels 80
Reserve 270
Duplicate evidence: rejected- A budget makes trade-offs explicit.
- A reserve prevents the prompt from overflowing after formatting.
Diagnostic lens
If this goes wrong, where do you look first?
Symptom
The model receives good evidence but still misses the key fact.
Likely causes
- Context is overcrowded
- Duplicates dominate
- Authority/order is poor
First checks
- Count context tokens
- Inspect duplicate chunks
- Check source order and identifiers
Engineering principle
Context construction is its own engineering stage.
Try it · core lab · account-free
Lab 10 — Context Construction
Goal: Assemble a bounded context packet from ranked chunks with deduplication and source IDs.
Before you start
- Core lab requires only Python 3 and local files unless otherwise stated.
- Running case: build the same evidence-grounded knowledge assistant across the course.
- Keep source IDs and intermediate evidence so each result is inspectable.
- Reflection: Write one sentence describing what this step proves and one sentence describing what it does not prove.
Run the baseline
python3 - <<'PY2'
chunks=[('A','vpn reset requires MFA'),('A2','vpn reset requires MFA'),('B','contact support if token lost')]
seen=set(); out=[]
for cid,text in chunks:
key=text.lower().strip()
if key in seen: continue
seen.add(key); out.append({'chunk_id':cid,'text':text})
print(out)
PY2Inspect the evidence
Record the intermediate source IDs, ranks, metadata or state produced by the baseline. Explain which pipeline layer this evidence belongs to.
Overflow the context
Add duplicate and low-value chunks until your notional token budget is exceeded. Remove duplicates and rebuild the bounded context packet.
Diagnose and restore
Context construction is its own engineering stage. State the failing layer, change only that layer, then repeat the verification checks.
Write the engineering note
Record: hypothesis → evidence → change → observed result → remaining limitation. Keep this note with the running Evidence Desk project.
Verify
- Duplicate text is removed.
- Every included chunk retains a citation identifier.
- The baseline and the deliberately broken case produce different, explainable evidence.
- You can name the pipeline layer that owns the failure and the control that repairs it.
Expected outcome
- A reproducible local result plus a short evidence note.
- A short before/after record showing the failure, diagnosis and repaired state.
Break / fix · diagnose
- Inspect the intermediate evidence before changing the model or prompt.
- If a command fails, preserve the error and classify which pipeline layer failed.
- Change one pipeline variable at a time and rerun the same test case.
- Do not accept a plausible answer as proof; verify the intermediate evidence and source identity.
Production view
Production RAG improves when every change can be traced to evidence at a specific pipeline layer. In production, retain the before/after evidence so the same failure can become a regression test.
Production checklist
What would an engineer verify before shipping this layer?
Context token budget explicit
Duplicates controlled
Source labels preserved next to evidence
Avoid these traps
Common beginner and engineering mistakes
- Appending every retrieved chunk.
- Dropping source IDs during context assembly.
- Mixing trusted instructions and retrieved evidence in the same authority channel.
Knowledge check
Can you explain the idea and diagnose the system?
1Why is more context not always better?
Irrelevant context raises cost and can distract the model.
2Why deduplicate?
To reduce wasted tokens and repeated evidence bias.
3What identifiers should context retain?
Stable source and chunk IDs.
4What should influence evidence ordering?
Relevance plus factors such as authority, freshness and diversity.
My Learning
Record your progress for this module.
Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.
Attempt the core lab and knowledge checks before marking the module complete.