What threshold combinations for uncertainty and rarity signals maximize RAG performance?

This explores how to tune two retrieval triggers — when the model is unsure (uncertainty) and when a query touches rarely-seen knowledge (rarity) — to get the best RAG results. The honest answer from this corpus: it doesn't hand you a magic threshold pair, and a few notes actively push back on the idea that fixed thresholds are the right knob at all. What the corpus does establish is *why combining both signals matters* and *why hard-coded cutoffs tend to be the wrong design* — which is probably the more useful thing to walk away knowing.

The strongest support for the question's premise is that uncertainty and rarity catch genuinely different failures. Model confidence misses hallucinations about rare entities (the model is confidently wrong), while rarity misses uncertain reasoning over common knowledge — so a hybrid trigger beats either alone Should RAG systems use model confidence or data rarity to trigger retrieval?. That orthogonality is the real reason to use two signals: they cover each other's blind spots, not because some sweet-spot ratio exists.

But on the uncertainty side specifically, the corpus suggests the threshold matters less than you'd think — what matters is *calibration*. Calibrated token-probability uncertainty beats more elaborate multi-call adaptive retrieval at a fraction of the cost Can simple uncertainty estimates beat complex adaptive retrieval?, and low token probability is itself a reliable signal that the model has hit a genuine knowledge gap, letting you retrieve only when it counts When should retrieval happen during model generation?. The lever is a well-calibrated confidence estimate, not a finely-tuned numeric cutoff.

Here's the lateral turn worth noticing: a chunk of this corpus argues that *anything* fixed — thresholds, intervals, top-k — is the wrong frame, and that these decisions should be *learned per query*. Fixed retrieval triggering is named as a structural failure mode, not a tuning problem Where do retrieval systems fail and why?. DynamicRAG trains an RL agent to set document count and order per query from generator feedback, replacing a fixed top-k entirely Can document count be learned instead of fixed in RAG?. StructRAG routes each query to a task-appropriate knowledge structure rather than applying one uniform strategy Can routing queries to task-matched structures improve RAG reasoning?. And process-level supervision — rewarding good intermediate retrieval steps rather than only final answers — outperforms outcome-only training for these adaptive decisions Does supervising retrieval steps outperform final answer rewards?. The drift across these notes is unmistakable: from "pick the right threshold" toward "learn the policy."

So the reframe the corpus offers is this — the question asks for a static answer (which two numbers?), but the research keeps answering with a dynamic one (let the model's calibrated uncertainty plus rarity decide *whether* to retrieve, then let a learned policy decide *how much*). If you want the one place that directly defends combining both signals, start there Should RAG systems use model confidence or data rarity to trigger retrieval?; if you want to see why the threshold framing dissolves into a learning problem, follow the per-query adaptation thread.