PrerequisiteAI 102 recommended, plus Modules 1 to 3 of this course
0 / 6 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor
Learning objectives
Explain why an agent can still miss the right answer after documents are in the Knowledge Base
Distinguish Fixed-Length, Structural and Semantic Chunking, and split by "which content belongs together as one semantic unit"
Define Metadata fields and Retrieval Filters for a document
Complete a Knowledge Chunk & Metadata Design
The problem and the preparation flow
10 min
The documents are in the knowledge base. Why is the answer still missing?
The last module showed the basic RAG flow: retrieve first, then answer. But putting a document in does not mean it can be found. This module asks: for an agent to find the right small piece of knowledge, what preparation must happen before it is indexed?
Core question
The documents are already in the Knowledge Base. Why does the agent still fail to find the right answer?
Imagine a 40-page leave policy (a simulated scenario). An employee asks: "Does sick leave need a medical certificate?" If the system cuts the document at arbitrary points, retrieval may return the first half of the "sick leave days" rule while the required-certificate rule sits in another piece. The answer looks grounded, but it is incomplete.
Knowledge preparation flow
Document: obtain and load the source document
Structure: identify headings, sections, tables and lists
Chunk: split by meaning into pieces that stand on their own
Metadata: label each piece with source, date, version, access and more
Index: build a searchable index
Retrieve: fetch relevant pieces by question and filters
Info
Much of retrieval quality is decided before retrieval happens. Well-cut, well-labelled knowledge gives the agent a chance to find the right content.
Key takeaway: A missing answer is often a knowledge-preparation problem, not only a model problem.
10 min
Document Loading and Structure: see what the document looks like first
Document Loading reads a document into the system. A document's structure (heading hierarchy, sections, tables, lists, footnotes) carries meaning. If loading flattens everything into one long string of text, that structural information is lost.
Structure preserved
Headings and sections stay recognizable
Table columns stay attached to their values
List items are not scattered
You can split by structure later and cite the section in answers
Flattened to plain text
Headings look like ordinary sentences
Tables become numbers and words that no longer line up
List order and levels disappear
Hard to tell which section a passage belongs to
Warning
Before loading a document, confirm you are allowed to use it and remove unnecessary personal data and secrets. In practice, use only simulated or already-public documents. Do not enter company secrets, client personal data or unauthorized information.
Different document types stress different structure: an SOP has steps and preconditions, a policy has clauses and exceptions, a report has sections and figure notes. Read the structure first to know where the boundaries might be.
Check yourself
A procurement policy containing tables is flattened into one plain-text string during loading. What is the most likely problem?
Key takeaway: Identify and keep the document structure first; it shows where content boundaries lie.
Chunking methods and semantic units
10 min
Three ways to chunk: Fixed-Length, Structural, Semantic
Chunking splits a long document into smaller pieces that can be retrieved independently. There are three common ideas. They do not replace one another; each focuses on a different question.
Comparing three Chunking methods
Method
Basis
Strength
Risk
Fixed-Length
A fixed length (characters or tokens)
Simple, fast, easy at scale
May cut through a sentence or clause
Structural
Headings, sections, paragraphs
Respects how the author organized the document
When sections are too long or too short, meaning can still be incomplete
Semantic
Whether content forms one semantic unit
Pieces stand alone, answers are more complete
Needs judgment, takes more effort and understanding
Chunk Size and Chunk Overlap are tuning parameters: too large a piece mixes in unrelated content; too small loses context. Some overlap lowers the risk of a cut boundary but adds repetition. These are trade-offs to test against your documents and tasks, not numbers with one right answer.
Warning
This course does not teach a fixed rule such as "the best size is N tokens". The more important question is: does this piece of content form a meaningful unit on its own?
Check yourself
Someone says: "Cut every document into 500 tokens with 50 tokens of overlap, and that is semantic chunking." What is wrong with this?
Key takeaway: Split by semantic unit; size and overlap are parameters to test, not the rule.
10 min
Which content belongs together as one semantic unit?
When judging a boundary, ask: if this piece were retrieved on its own, could the reader (or agent) understand and use it correctly? If another piece is needed to make sense of it, the two may belong to one unit.
Simulated SOP: handling a refund complaint
"Scope" and "Preconditions" belong together, otherwise nobody knows when the steps apply. "Steps 1 to 4" are one continuous procedure and should not be split. "Exceptions" (for example, past the refund deadline) form a unit of their own and are often queried on their own.
1Find natural sections Mark headings, steps, tables and exception notes first.
2Ask "does it stand alone?" Read each candidate piece by itself. Is it still understood correctly?
3Keep dependencies together Keep a condition with its conclusion, a term with its definition, a step with its precondition, in the same piece where possible.
4Name each piece State in one sentence what question the piece answers. If you cannot, the boundary may be wrong.
Info
Chunking is judgment, not a formula. Finally, someone who knows the document checks whether the boundaries make sense, because only a person knows which content must be read together in real work.
Check yourself
An SOP's "Preconditions" and "Steps" were cut into two separate pieces, and the agent retrieves only the Steps piece. What could happen?
Key takeaway: Keep content that depends on each other, and must be understood together, in the same piece.
Metadata and practice
10 min
Metadata and retrieval filters, plus practice
Metadata is data that describes a piece: what it is, where it came from, when, and for whom. With Metadata, retrieval does not only match text; it can narrow the scope, for example to "latest version", "HR department" or "public level" pieces only.
Common Metadata fields
Field
Purpose
Question at retrieval time
Source
Which document and section the piece came from
Is this a trusted source?
Author
The owner or unit responsible
Whom should we ask to confirm?
Date
Created or updated date
Is the information out of date?
Topic
Subject category
Is it relevant to this question?
Document Type
SOP, policy, report, FAQ and so on
Do we need a rule or a case?
Access Level
Who may see it
Is the asker allowed to read this?
Version
The document version
Is this the version in force?
Warning
Access Level is only a label on the data; it is not authorization. Real access control must be enforced on the server side, not merely hidden in the front end or left to the agent's own judgment.
1Mark chunk boundaries Take a simulated SOP, policy or report and decide where each Chunk starts and ends.
2Define Metadata List the fields each piece needs and how each is filled.
3Define retrieval filters Write which questions apply which filters, for example "only current-version pieces the asker may access".
4Produce the design Assemble a Knowledge Chunk & Metadata Design. Do not enter secrets or personal data in practice.
Go to the AI 103 practice: In the "Chunks and Metadata" activity, practise defining boundaries and filters.
Check yourself
Two versions of a travel policy are in the knowledge base, and the agent often cites the withdrawn one. Which fix is the most direct?
Key takeaway: Metadata lets retrieval narrow by source, freshness, version and access, but authorization must still be enforced on the server.
Recap
5 min
Recap
Done
Good retrieval comes from good knowledge preparation: read the structure, split by meaning, then label source, freshness and access clearly with Metadata.
Knowledge preparation flow recap
Document
Structure
Chunk
Metadata
Index
Retrieve
Designing boundaries and Metadata is human judgment. The agent retrieves according to that design, but whether the design is sound and the data trustworthy is still checked, and owned, by a person. The next module asks: once an agent has knowledge, does it know how to do the work?
