RAGEngineering Hub
Chapter 10 · concept 2 of 6 · show all
  1. 1What RAG is, and why
    1. 1.1Why models need outside knowledge, and what hallucination means
    2. 1.2What RAG is: anatomy of a request
    3. 1.3RAG vs fine tuning vs long context and prompt caching
    4. 1.4Use cases and the quality, latency and cost triangle
    5. Chapter overview
  2. 2Tokens, cost and your first RAG
    1. 2.1Tokens and context windows for RAG
    2. 2.2The RAG lifecycle and your first RAG in miniature
    3. Chapter overview
  3. 3Getting documents in
    1. 3.1Content sources and file formats
    2. 3.2Parsing, layout and OCR
    3. 3.3Tables, images and mixed content
    4. 3.4Cleaning, normalization and quality gates
    5. 3.5Metadata, document identity and versioning
    6. 3.6Updates, deletes, reindexing and ingestion pipelines
    7. Chapter overview
  4. 4Chunking
    1. 4.1Why we chunk, and the main chunking strategies
    2. 4.2Structure aware chunking and tables
    3. 4.3Chunk size, overlap and token based sizing
    4. 4.4Contextual chunking and late chunking
    5. 4.5Parent child and multi representation indexing
    6. 4.6Chunk metadata, provenance and the chunking debugging playbook
    7. Chapter overview
  5. 5Embeddings
    1. 5.1Embeddings and similarity from first principles
    2. 5.2What embeddings cannot do
    3. 5.3Choosing an embedding model: size, cost, language
    4. 5.4Embedding model migration and index rebuilds
    5. Chapter overview
  6. 6Vector stores and scores
    1. 6.1Vector databases, ANN indexes and choosing a store
    2. 6.2Score calibration and thresholds
    3. 6.3Late interaction and multivector retrieval
    4. Chapter overview
  7. 7Finding the right chunks
    1. 7.1Query understanding, rewriting and expansion
    2. 7.2Dense retrieval and keyword search with BM25
    3. 7.3Hybrid retrieval and rank fusion
    4. 7.4topK, no good match, and metadata filtering
    5. 7.5Routing, diversity, deduplication and caching
    6. 7.6Reranking: two stage, cross encoder and LLM rerankers
    7. Chapter overview
  8. 8When retrieval fails
    1. 8.1Retrieval failure analysis playbook
    2. Chapter overview
  9. 9Building the answer
    1. 9.1Context selection, packing and citations
    2. 9.2Grounding prompts and abstention
    3. 9.3Lost in the middle and context management
    4. 9.4Conflicts, staleness and freshness rules
    5. 9.5Hallucination checks and answer verification
    6. 9.6Conversational RAG, answer UX and RAG APIs
    7. Chapter overview
  10. 10Measuring
    1. 10.1Why measure, and what to measure
    2. 10.2Building a golden dataset
    3. 10.3Retrieval metrics: precision, recall, MRR, nDCG
    4. 10.4Faithfulness and answer correctness
    5. 10.5LLM as judge, and judging the judge
    6. 10.6Offline and online evals, regression tests and slices
    7. Chapter overview
  11. 11Safety and operations
    1. 11.1Prompt injection and poisoned documents
    2. 11.2Access control, privacy and governance
    3. 11.3Index lifecycle operations
    4. 11.4Observability and tracing
    5. 11.5Latency, cost, caching and model routing
    6. 11.6Reliability, degraded modes and launch readiness
    7. Chapter overview
  12. 12Scale and advanced RAG
    1. 12.1Scaling, multi tenancy and enterprise architecture
    2. 12.2Choosing an architecture: naive, advanced, agentic, graph
    3. 12.3Agentic RAG and RAG as an MCP tool
    4. 12.4GraphRAG, structured data and multimodal RAG
    5. Chapter overview

Building a golden dataset

How we built 52 test questions for this course: real needs, an exact evidence sentence for each, deliberate hard cases, and a script that checks every quote is really in the corpus.

A real question

Where do good test questions come from?

From the questions your users really need answered, written down with the exact sentence that answers them. Add the hard cases on purpose, check every quote with a script, and keep the set small enough to review by hand.

The problem

Why this matters

Have a model generate a thousand test questions from the documents.
The belief

Have a model generate a thousand test questions from the documents.

Our set has 52 questions, each with an evidence sentence checked against the corpus. It covers 11 kinds of case, from tables and old versions to injected instructions and questions with no answer. Generated questions can help, but only after a person checks them.
What really happens

Our set has 52 questions, each with an evidence sentence checked against the corpus. It covers 11 kinds of case, from tables and old versions to injected instructions and questions with no answer. Generated questions can help, but only after a person checks them.

Why not the simpler way

Every number in this course comes from 47 answerable questions out of a set of 52. If those questions were sloppy, every comparison would be too. A golden set is the foundation of evaluation, and the place where shortcuts cost the most later.

The idea

The idea in plain words

A golden dataset is a versioned list of test cases. Each case has a question, the expected answer, the expected documents and the evidence that proves it, plus metadata such as case type and user role. It is small, varied and checked.

An exam with an answer key, where every answer points to the page in the textbook.

How it works

Step by step

  1. Support tickets, search logs, expert interviews. Write the question the way a user would ask it.
    1

    Start from real needs

    Support tickets, search logs, expert interviews. Write the question the way a user would ask it.

  2. 2

    Copy the exact evidence

    For each question, the expected answer, the document id and the exact sentence that proves it.

  3. A script confirms each evidence sentence is in the corpus. A person reviews the answers. Then the set is versioned and only changed on purpose.
    3

    Verify, then freeze

    A script confirms each evidence sentence is in the corpus. A person reviews the answers. Then the set is versioned and only changed on purpose.

In detail

Fields. id, question, case_type, expected_doc_ids, answer, evidence, expected_abstain, and optional user_role or conflict_with.

Case types in ours. answerable 17, table 8, version 8, exact-code 4, multi-clause 3, restricted 3, paraphrase 2, conflict 2, abstain 2, injection 2, multi-doc 1.

Checks. Our check_golden.py loads every document and confirms each evidence string appears verbatim. It also lists documents no question uses: 5 of our 25, a hint of gaps.

Bias. We wrote questions while reading the documents, so they reuse the documents' words. That favours keyword search (RAG-27). Real traffic and paraphrased questions balance it.

Generated questions. A model can draft questions per chunk. Treat drafts as candidates: check the evidence, rewrite in user language, drop trivial ones.

The code

Try it in Python

import json, pathlib

def check(golden_path: str, corpus_dir: str):
    docs = {p.stem: p.read_text() for p in pathlib.Path(corpus_dir).glob("*.md")}
    problems = []
    for line in open(golden_path):
        g = json.loads(line)
        if g.get("expected_abstain"):
            continue
        texts = [t for name, t in docs.items() if any(name.startswith(d) for d in g["expected_doc_ids"])]
        if not any(g["evidence"] in t for t in texts):
            problems.append(g["id"])
    return problems     # must be empty before the set is frozen

See it

What we measured

Measured · our golden set

corpus/golden/golden_v1.jsonl over 25 English Polder documents, checked with corpus/scripts/check_golden.py.

Questions52
With an answer in the corpus47
Expected to abstain5
Case types11
Evidence strings found verbatimall
Documents no question uses5 of 25

Checked 2026-11-04 with npm run check-golden.

Try it on a real example

Two items from our golden set

Item

g-01 · exact-code

Question: What does error E4012 mean on the FiberBox?
Answer: Mesh pairing failed because the mesh extender runs old firmware…
Evidence: | E4012 | Mesh pairing failed | Mesh extender on old firmware |
Document: SYN-TEL-FIBERBOX

A retrieved chunk counts as a hit only if it contains the evidence line exactly.

Choosing

Use it when, avoid it when

Use it when
  • Hand-checked questions with exact evidence
  • Deliberate hard cases and unanswerable questions
  • A script that verifies every quote
Avoid it when
  • Thousands of unchecked generated questions
  • Questions only in the documents' own words

What it costs · A day or two for 50 questions. Grows cheaply from real bug reports.

In production

Grow the set from production: when a user reports a wrong answer, add that question with the right evidence. Keep slices balanced so one type does not dominate the total. Version the set, and when you change it, re-run the baseline so old and new numbers stay comparable.

Watch out

Common mistakes

  • More questions are always better. 50 checked questions beat 1,000 unchecked ones.
  • Only answerable questions matter. Abstain, injection and role cases catch the worst failures.
  • The set is done once written. It grows with every real failure.

Check yourself

Remember this

Remember these

  • Write questions from real needs, in users' words.
  • Store answer, document id and the exact evidence sentence.
  • Cover hard cases on purpose: tables, versions, codes, conflicts, no answer, injection, roles.
  • Check every quote with a script and review by hand before freezing.

Say it in an interview

  1. 01My golden set has 52 questions, each with the exact evidence sentence and document id.
  2. 02It covers 11 case types, including tables, versions, conflicts, injection and roles.
  3. 03A script checks every evidence string is in the corpus before the set is frozen.
  4. 04I know its bias: questions reuse document wording, so I add paraphrases.
  5. 05Real user failures become new golden questions.

Quick quiz

Three questions

Question 1

Q1

Why store the exact evidence sentence, not just the answer?

Question 2

Q2

What is a known weakness of our golden set?

Question 3

Q3 · from RAG-39

What does a golden set let you do?

Saved on this device. No account needed.