Turning a Retrieval Curve Into a Go/No-Go Release Rule

Before any threshold makes sense, pin down what you are measuring and on what. Three choices drive the rest:

The metric. Recall@k answers "of all the relevant chunks that exist, how many did we retrieve?" Precision@k answers "of the k chunks returned, how many were relevant?" (RAG Evaluation Simplified). For knowledge assistants where a missed chunk means an unanswerable question, recall@k is usually the gate metric and precision@k is the guardrail. Pick one primary metric per gate; two primary metrics invite the argument about which one wins.

The query set. You need a fixed golden set with expected evidence per query. Twenty to thirty hand-written pairs is enough to start catching regressions, and the value is that it never changes between runs (Welcome, Developer). If you want statistical confidence later, plan for a larger held-out split, because interval width scales with sample size.

The k. Recall@k is meaningless without a fixed k, and k interacts with everything downstream. Raising top-k from four to 10 pushed time to first token from 3.6 to 7.9 seconds in NVIDIA's enterprise retrieval sizing tests, while moving chunk size from 256 to 1,024 tokens took it from about 2.0 to 7.1 seconds (Splunk). If you gate on recall@10, you have committed to returning ten chunks, so the latency gate has to be written against the same k.

One useful insight the first search result rarely gives you: the optimal chunk size is not a constant across corpora, so do not carry a threshold across from a blog post. A multi-dataset sweep found 64 to 128 token chunks optimal for fact-based answer datasets, while 512 to 1,024 token chunks won on datasets needing broader context (Rethinking Chunk Size for Long-Document Retrieval). NVIDIA's experiments found page-level chunking best on average across its datasets but 1,024 tokens best on FinanceBench and 512 on earnings documents (NVIDIA). Your threshold has to be expressed relative to your own baseline, not an absolute score copied from someone else's corpus.

The threshold is the smallest improvement that counts as a win. It should be derived from how much your metric moves when nothing changes.

The practical procedure:

1. Re-run the current configuration against the golden set several times with resampling (bootstrap over queries, or repeated splits) and record the spread of recall@k.
2. Note the standard deviation of that spread. That is your noise floor.
3. Set the threshold at roughly two noise floors, then sanity-check it against business cost. If a chunker change costs half a day of engineering and doubles your vector count, a lift smaller than the noise floor is not worth the risk.

A worked example. Suppose your golden set has 200 queries and your baseline recall@10 is 0.74. Bootstrapping gives a 95% interval of roughly plus or minus 0.05, that is, 0.69 to 0.79. A candidate chunker scores 0.76. That candidate is inside the noise band of the baseline, so the correct verdict is "no decision": you cannot distinguish it from no change. Now suppose a different candidate scores 0.81 with its own interval of 0.77 to 0.85 and a bootstrap distribution of the paired difference whose 95% interval is 0.02 to 0.13, excluding zero. That candidate clears a 0.03 threshold on the point estimate and clears the confidence test. Verdict: go, subject to sign-off.

Use paired resampling (resample queries, compute both configurations on the same resampled set, take the difference) rather than comparing two independent intervals. Paired differences are much tighter because the same hard queries are hard for both systems, and a gate built on unpaired intervals will reject real improvements or accept noise depending on which way you get the arithmetic wrong.

The published gate design that most closely matches this is the stratified beta-binomial gate, which computes a probabilistic regression risk, the probability that the new version's underlying quality is worse than the old by more than a margin, instead of comparing single numbers (AGO AI Quality Gate). You do not need that machinery to start; percentile bootstrap intervals over a fixed query set give you the same discipline with far less code. But whichever you pick, the gate rule must reference the interval, not the point estimate, or the threshold is decorative.

The table below is a starting policy, not a universal benchmark. Calibrate the numbers to your own noise measurement and risk tolerance; the gate study cited above explicitly treats its thresholds as illustrative starting points (RAG QA Testing Guide).

The last row is the one most teams get wrong. When evidence is missing, the honest gate outcome is "not evaluable", not "pass by default". The AGO work calls this a four-state decision model, where missing data and judge errors are explicit outcomes rather than being averaged away as zeros (AGO AI Quality Gate).

If any part of the curve is scored by an LLM judge, the gate is only as good as the judge. This is where a lot of release rules quietly fail.

The numbers are sobering. On identical stratified samples of 1,200 RAG traces, a low-cost judge detected non-adherent answers barely above chance, with an AUROC of 0.603, while a stronger judge reached 0.783 and still ranged from 0.62 to 0.88 depending on the domain (AGO AI Quality Gate). A judge that outputs perfect protocol-shaped JSON can still be close to useless as a measuring instrument.

Three habits keep the judge honest:

• Keep the judge prompt narrow and ask for a small ordinal scale (0, 1, 2) rather than 0 to 10, because wide scales produce noisy, inconsistent scores that look precise and are not (Welcome, Developer).
• Ask for a one-sentence reason alongside the score, so a dropped number can be diagnosed without a manual re-run.
• Meta-evaluate the judge on a labeled sample before it influences your release decision, and record the agreement figure in the gate policy.

Evaluation work in practice also separates retrieval metrics from generation metrics, so a bad answer can be traced to the retriever or to the generator rather than to a single fuzzy score (Confident AI). Your gate should name which half of the pipeline a regression lives in, or the signer will be asked to approve a fix they cannot scope.

A gate with no named owner is a suggestion. Write the rule with three roles:

The release owner. One named engineer accountable for the RAG surface. They can approve a clear win and must block a regression. The name goes in the policy file, not in someone's memory.

The reviewer who can waive. A second named person, usually the tech lead or the product owner for that surface, who can waive a gate when the schedule justifies it. Two signatures for a waiver, one for a clean pass.

The policy owner. Whoever maintains the threshold and the query set, reviewed on a schedule, because a golden set that never changes quietly stops representing production traffic.

When a waiver happens, the log entry needs enough detail that a reader six months later can judge whether the decision was sound. At minimum:

• the gate name and the metric with its value, baseline value and threshold
• the size of the shortfall as a number
• the confidence evidence (interval, sample size, judge agreement figure)
• the reason in free text, written for a stranger
• the waiver owner and the approving signer
• the expiry date and the remediation ticket that closes it
• the commit and the index or chunker configuration hashes that were deployed

Make the log machine-readable so it can be queried later. A minimal entry, as JSON:

{
  "gate": "retrieval.recall_at_10",
  "baseline": {"value": 0.74, "ci": [0.69, 0.79]},
  "candidate": {"value": 0.72, "ci": [0.67, 0.77]},
  "delta_ci": [-0.04, 0.01],
  "threshold": 0.03,
  "verdict": "waived",
  "reason": "Tightens chunk overlap; recall dip concentrated in 11 legal PDFs. Fix tracked in RAG-114.",
  "waiver": {"owner": "ana", "approver": "marcus", "expires": "2026-06-30"},
  "config": {"chunker": "recursive", "size": 512, "overlap": 100, "commit": "a91f2c3"}
}

Two rules make waivers safe rather than corrosive. First, waivers expire; an open waiver past its date is an incident, not a status quo. Second, a waiver that repeats more than twice for the same gate means the threshold or the system is wrong, and the policy owner must revisit it. The measured cost of weak gating is real: under simulated regression, a decision-grade gate profile cut unsafe promotion to between 22.2 and 35.1 percent, against 29.3 to 41.8 percent for a naive gate (AGO AI Quality Gate). Even a good gate lets some regressions through; the log is what lets you find them afterwards.

The rule only works if it runs automatically on every candidate change. Put it in CI as a job that builds the candidate index, runs the fixed query set, computes the paired interval and writes a verdict artifact.

import random
from statistics import mean

def paired_bootstrap_ci(baseline, candidate, iters=2000, alpha=0.05, seed=7):
    random.seed(seed)
    diffs = []
    n = len(baseline)
    for _ in range(iters):
        idx = [random.randrange(n) for _ in range(n)]
        b = mean(baseline[i] for i in idx)
        c = mean(candidate[i] for i in idx)
        diffs.append(c - b)
    diffs.sort()
    lo = diffs[int(alpha / 2 * iters)]
    hi = diffs[int((1 - alpha / 2) * iters)]
    return lo, hi

# per-query recall@10, aligned by query id
lo, hi = paired_bootstrap_ci(baseline_recall, candidate_recall)
verdict = "go" if lo > 0.03 else "block"

Keep the ingest side deterministic so the comparison is fair. Chunk sizes set in characters behave differently from token counts, because a 512-character window is anywhere from 100 to 400 tokens depending on the tokenizer, so a size tuned for one model silently truncates or wastes context on another (ChunkRank). Pin overlap too, since repeats from overlap cost extra vectors; the common guidance holds overlap to 10 to 20 percent of the chunk (The AI Engineer).

One more check for chunker updates specifically: when you change chunk boundaries, the context your generator sees changes, so gate both halves. Chunking sets a ceiling on answer quality that no later stage can recover (The AI Engineer), and the context window utilization a chunk occupies trades against irrelevant text in the prompt (Context Window Utilization). A chunker that raises recall@10 but fills the window with redundant overlap can still hurt end-to-end answers, so run a small faithfulness check as a secondary gate.

If you are optimizing the retrieval path itself, budget latency as a first-class gate: define the retrieval allowance in milliseconds, allocate it by stage, and review p95 rather than the median, because tail latency defines the user experience (Latency Budgets for Memory Retrieval). Trace requests end to end rather than adding per-stage percentiles together, since slow stages may land on different requests (MLflow). When your gate logic needs to call several models for judging and for the candidate pipeline, one OpenAI-compatible endpoint for text, embedding and image models keeps the CI bill predictable; Quanta Inference is one option for that (Quanta Inference).