Chapter 3 · concept 5 of 6 · show all
2Tokens, cost and your first RAG
4Chunking
- 4.1Why we chunk, and the main chunking strategies
- 4.2Structure aware chunking and tables
- 4.3Chunk size, overlap and token based sizing
- 4.4Contextual chunking and late chunking
- 4.5Parent child and multi representation indexing
- 4.6Chunk metadata, provenance and the chunking debugging playbook
- Chapter overview
7Finding the right chunks
8When retrieval fails
Metadata, document identity and versioning
How to give every document a stable identity and a version with validity dates, so search returns the version that was true at the right time.
A real question
Why does the assistant quote last year's price?
Both the old and the new tariff sheet are in the index, and they look almost the same to search. Give every version dates, and filter to the one valid today.
The problem
Why this matters
Add the new version to the index, and search will prefer it.
Versions share almost all their text, so search cannot tell them apart. In our test, the wrong version ranked first for 3 of 5 version questions.
Why not the simpler way
The simple index stores text and forgets where it came from. Then a tariff sheet is updated, the new file is added, and both versions sit in the index. A customer asking today's price gets last year's, because the old sheet ranks just as high. Without identity and versions, the index cannot tell "the same document, changed" from "two different documents".
The idea
The idea in plain words
Give every document three things. A document id that never changes (SYN-TEL-TARIFF). A version for each state of it (2025.1, 2025.2, 2026.1). And validity dates: from when, until when, this version was true. Store them on every chunk. At query time, filter to the version valid on the date the question is about, which is usually today.
Train timetables work this way. The line number stays the same; each timetable says from which date it applies.
How it works
Step by step
1Label every document
A document id that never changes, a version for each state, and the dates it is valid.
2Filter before ranking
Keep only the versions valid on the date the question is about, usually today.
3Then rank and answer
Search now chooses among valid text only, so the answer is right for that date.
In detail
Useful metadata falls into four groups:
- Identity: document id, version, source URL or path, content hash.
- Time: effective from, effective to, ingested at.
- Access: allowed roles or groups, confidentiality label.
- Description: title, section path, language, product, sector.
Retrieval then becomes "search within the valid set": apply the metadata filter first, then rank by relevance. The date to filter on comes from the question ("in September 2025") or defaults to today.
The code
Try it in Python
from datetime import date
def valid_on(meta: dict, day: date) -> bool:
start = date.fromisoformat(meta["effective_from"])
end = date.fromisoformat(meta["effective_to"]) if meta.get("effective_to") else None
return start <= day and (end is None or day < end)
def search_valid(chunks, score, day: date, k=3):
"""Filter to the versions valid on `day`, then rank."""
pool = [c for c in chunks if valid_on(c["meta"], day)]
return sorted(pool, key=score, reverse=True)[:k]
See it
What we measured
Measured · right version at rank 1, 5 version questions
Golden questions g-30, g-31, g-32, g-41 and g-42 over SYN-TEL-TARIFF (3 versions) and SYN-POL-OUT (2 versions); recursive 512 chunks, vector search. Filter: keep chunks whose version is valid on the question's date (today, or the date in the question).
Measured 2026-11-03. Without the filter the answer passage was still in the top 3 for all 5, next to a wrong version, so the model had to pick. The filter got one question wrong: g-32 asks whether a replaced plan can still be bought, and the answer lives in the older sheet.
Try it on a real example
A real question: “What does PT-MOB-25GB cost per month today?”
Rank 1: Tariff sheet 2025.2 (valid until 2026-02-01)
The old sheet ranked first. An answer of “EUR 20.00” would be out of date.
Choosing
Use it when, avoid it when
- A stable document id, a version and validity dates on every chunk
- A date filter before ranking for anything that changes over time
- File names as identity
- Deleting old versions when the past still gets asked about
What it costs · A few fields per chunk and a filter per query. The harder cost is getting owners to supply correct dates.
In production
Keep old versions, but mark them, rather than deleting them: questions about the past need them, and audits ask "what did the assistant say last March, and from which version". Validate metadata at ingestion with the quality gates, because a missing date silently drops a document from every filtered search. Put access labels on chunks, not only on documents, and filter before ranking so restricted text never reaches the prompt.
Watch out
Common mistakes
- The newest version is always right. Questions about the past, or about what was replaced, need older versions.
- Search will rank the right version first. Versions share most of their text, so it often does not.
- Metadata is optional polish. It is what makes answers true for a date and a user.
Check yourself
Remember this
Remember these
- Every document needs a stable id, a version and validity dates.
- Store them on every chunk and filter before ranking.
- Right version first: 2 of 5 without the filter, 4 of 5 with it.
- Access labels work the same way: filter before the text reaches the prompt.
Say it in an interview
- 01Every document gets a stable id, a version and validity dates, stored on every chunk.
- 02I filter to the version valid on the question's date before ranking.
- 03On my corpus the right version came first for 2 of 5 version questions; with the filter 4 of 5.
- 04The one filter miss asked about a replaced plan, so old versions must stay findable.
- 05Access labels live on chunks and are filtered before ranking.
Quick quiz