Evidence Object
Reproducible RAG evaluation study
When a retrieval system should answer, and when it should stay quiet
I wanted the system to answer only when lexical search and dense search agreed on the same current document, and to stay quiet otherwise. I froze that rule, and three conditions for success, before I opened the holdout. On the synthetic support corpus the rule met all three. It was right on 17 of the 20 questions it answered, and it covered 17 of the 22 questions that had an answer in the corpus. It still answered 3 of 14 questions it should have refused. Across all 36 questions the decision was right 28 times. That last figure is context: it was not one of the three conditions. The study does not write the answer. The Explorer is a different demo.
Direct entry: this page stands alone. It does not imply a Decision Room journey from Home.
Form, Provenance and Status are separate dimensions, not one badge.
- Form
- Research
- Provenance
- SyntheticPublic
- Status
- Holdout consumed
- What it is
- Research / methodology evidence: versioned synthetic benchmark with a frozen evaluation protocol and SHA-256 evidence package.
- Question / context
- When should a RAG system answer versus defer under conflicting or weak retrieval evidence?
- What was done
- Compared lexical/dense/hybrid retrieval with a pre-registered top-1 consensus gate and a one-time unblinded holdout.
- What was learned
- Stricter answer/defer rules can be evaluated reproducibly on a synthetic holdout; the holdout is then consumed.
- What it supports here
- Methodology credibility for the retrieval study. Distinct from Explorer, which is a separate demo on another corpus and is not hosted here.
- What it does not prove
- Production RAG performance, commercial readiness, client outcomes, or Explorer metric equivalence. Holdout is consumed; not unseen validation.
I ran this on a synthetic benchmark with a frozen 36-question holdout, and that holdout is now open. The numbers belong to this benchmark. They are not a production result.
Why this study exists
I built this study to look at retrieval failures and at the decision to answer or step back. It compares lexical and dense retrieval, a hybrid of the two, and a reranking that prefers current documents over obsolete ones. The protocol, and the split between development and holdout, stayed fixed.
The question I was testing
A document that looks relevant is not always a reason to answer. I wanted a stricter rule for the awkward cases: lexical and dense search disagree, a current document and an obsolete one compete, the question needs clarification, or the evidence is too thin to answer safely.
What the study included
- A BM25 lexical retrieval baseline.
- A dense MiniLM retrieval baseline.
- Equal-weight reciprocal-rank fusion (RRF).
- Status-aware current-first reranking.
- Consensus, selective-risk and signal-separability analysis.
- A versioned synthetic benchmark with a frozen development/holdout split.
- A top-1 consensus gate and three success criteria registered before the holdout.
- A one-time unblinded holdout evaluation.
- Deterministic reports and a SHA-256 artifact registry.
What I kept fixed
- I used only a synthetic benchmark: no production traffic and no real enterprise corpus.
- The holdout stayed fixed at 36 queries with a fixed answer, clarify and abstain composition.
- I froze the gate rules and three success criteria before any holdout evaluation.
- I kept development and holdout separated until the one-time evaluation.
- The holdout is unblinded, so it cannot be reused as unseen evidence.
- I do not retune the gate on this benchmark after observing the holdout.
- Integrity regeneration checks reproducibility only; it does not create new evaluation evidence.
- These results do not support population-level claims or production deployment claims.
How the answer/defer gate works
- 01
Lexical retrieval
BM25 provides exact-term and token-overlap evidence.
- 02
Dense retrieval
Pinned MiniLM embeddings provide semantic retrieval evidence.
- 03
Hybrid fusion
Reciprocal-rank fusion combines lexical and dense rankings with equal weights.
- 04
Status-aware reranking
Current documents are prioritised over obsolete evidence.
- 05
Top-1 consensus gate
The system answers only when BM25, dense retrieval and the final current-first ranking agree on the same top document; otherwise it defers.
How I ran the study
- 01
Establish baselines
I started with lexical BM25 and dense MiniLM retrieval baselines on the synthetic corpora.
- 02
Add fusion and document status
I combined lexical and dense rankings with equal-weight reciprocal-rank fusion and applied status-aware current-first reranking.
- 03
Analyse failure signals
I examined consensus failures, selective risk and signal separability to see when retrieval evidence was strong enough to answer.
- 04
Freeze the benchmark
I built a versioned synthetic benchmark with a frozen development/holdout split before the final evaluation.
- 05
Pre-register the gate and criteria
I registered the top-1 consensus gate and three success criteria before any holdout access.
- 06
Evaluate once
I ran a one-time unblinded holdout evaluation without changing the gate or thresholds afterwards.
- 07
Prepare the evidence package
I assembled deterministic JSON reports and a versioned study package. Generation is not part of this study.
What I produced
- Versioned synthetic corpora.
- A typed retrieval and evaluation implementation.
- Deterministic JSON reports.
- A pre-registration artefact.
- A one-time holdout report.
- A final study report.
- A versioned study package. Generation is not implemented.
- Automated integrity and reproducibility checks.
- A versioned study package with SHA-256 verification.
Technologies
- Python
- uv
- pytest
- BM25
- sentence-transformers
- all-MiniLM-L6-v2
- reciprocal-rank fusion
- SHA-256 artifact verification
What the benchmark showed
Pre-registered synthetic holdout result
Frozen success criteria
PASS 3/3
PASS 3/3 means the three pre-registered criteria were met on the 36-query holdout: 17/20, 17/22 and 3/14. Those three criteria are the only frozen success criteria. I froze the gate and thresholds before seeing the holdout and did not change them afterwards.
Synthetic holdout metric
Answered-query precision
17/20 = 0.850
The frozen threshold required at least 0.75.
Synthetic holdout metric
Answerable-query coverage
17/22 = 0.773
The frozen threshold required at least 0.70.
Synthetic holdout metric
False-answer rate
3/14 = 0.214
The frozen threshold allowed at most 0.50 for queries expected to defer.
Descriptive synthetic holdout metric
Decision accuracy
28/36 = 0.778
28/36 = 0.778 is descriptive context reported alongside precision, coverage and deferral errors. It was not one of the three frozen success criteria.
Reproducibility evidence
Evidence package
Generation is not implemented
Synthetic benchmark. Holdout is unblinded and cannot be reused as unseen. These are not Explorer metrics and not a client result.
What the results do not show
- This is a single synthetic benchmark with a small fixed 36-query holdout.
- The answer, clarify and abstain composition was fixed.
- I did not evaluate a real enterprise corpus or real support traffic.
- The system does not produce a calibrated probability or confidence score.
- I did not evaluate answer generation.
- Three abstain queries were answered incorrectly.
- Five answerable queries were deferred.
- There is no evidence of generalisation to other corpora, domains or languages.
- The holdout is unblinded and cannot be reused as unseen evidence.
- These results do not show production performance or guaranteed answer correctness.
What I would need before using this with real data
- Before using this approach with real data, I would create a new representative holdout.
- I would estimate prevalence and the cost of false answers and unnecessary deferrals.
- I would define document lifecycle ownership and status responsibility.
- I would measure retrieval quality, deferral behaviour, latency and cost.
- I would define access controls for sensitive material.
- I would include human escalation for deferred or uncertain cases.
- I would evaluate answer generation separately from retrieval consensus.
- If the gate changed, I would require new confirmatory data before relying on it.
Where this method can help
- Retrieval answer-or-defer design, within the public study ceiling. Not packaged assurance.
- Answerability and abstention policy design.
- False-answer and evidence-conflict analysis.
- Synthetic and representative evaluation design.
- Status-aware knowledge retrieval.
- Evaluation protocol design.
- Technical evidence and decision reporting.
Project evidence
- View the public repository
Source code, synthetic corpora, tests, reports and reproducibility controls for the study.
Study, demo and next steps
View Retrieval systems and evaluation
Interactive companion demo
RAG Explorer is a separate interactive demo using its own synthetic corpus. It does not use the study holdout or reproduce the study results or metrics.
A separate demo uses a different corpus and does not reproduce this study’s results. It is not currently publicly available.
A citation can be stale
A retrieved passage can be a real citation and still be the wrong one to use. If a newer document replaced it, an answer that stays faithful to the old passage is grounded and still out of date. The study is about that decision. It does not write the answer.
Answering or staying quiet is one of three separate questions. The other two are whether a setup clears a bar fixed in advance, and whether a later change makes the output worse. Judging the wording of a generated answer would be a separate piece of work. These pieces are not one system today.
| Gate decision | Answered | Deferred |
|---|---|---|
| Expected answer | 17 | 5 |
| Expected defer | 3 | 11 |
36 holdout queries. Top-1 gate, version 1.0.0, scored once. Rows are the expected behavior. Columns are the gate decision.
17 is an expected answer that was given. 5 is an expected answer that was deferred: undue deferrals. 3 is an expected defer that was answered: undue answers. 11 is an expected defer that was deferred. 17 + 5 + 3 + 11 = 36.
Answers where a deferral was expected
Each panel is a different split and a different rule. They are not three readings of the same set.
12 / 14
36 development queries. Consensus rule at depth 3. Of the 14 queries where a deferral was expected, it answered 12. This rule was not scored on the holdout.
7 / 14
The same 36 development queries, with a different rule: the top-1 gate. Of the 14 expected deferrals, it answered 7. This split was used to choose the rule. It is not the holdout.
3 / 14
Another 36 queries, the holdout. Top-1 gate, version 1.0.0. Of the 14 expected deferrals, it answered 3.
- BM25
- Dense MiniLM
- Hybrid RRF
- Status-aware RRF
| Share of 22 queries where an answer was expected | @1 | @3 | @5 |
|---|---|---|---|
| BM25 | 0.000 | 0.636 | 0.773 |
| Dense MiniLM | 0.045 | 0.545 | 0.682 |
| Hybrid RRF | 0.000 | 0.455 | 0.636 |
| Status-aware RRF | 0.000 | 0.000 | 0.000 |
Development split, only the 22 queries where an answer was expected. The figure is the share of those queries in which an obsolete document appears inside that rank cutoff. @5 means inside the top five, not the fifth rank on its own.
Status-aware RRF is the rerank that prefers the current document. On this split it stays at 0.000 inside @1, @3, and @5. This is not the gate’s precision, and it is not a holdout result.