Stopping Policy in Agentic Search

The stopping decision of an iterative search agent is a policy to design and evaluate apart from the retriever and the generator. The number of saved search calls does not show unsafe early stops.

The stopping decision of an iterative search agent sets both accuracy and cost. One study evaluated the first stop of the policy to be deployed, question by question. It reports a 3.70% cut in search calls, while 27 of the 69 actual early stops were unsafe. Before you use early stopping to cut cost, decide which metrics to report next to the reduction rate.

An agent that answers multi-hop questions repeats search and answer generation several times, as in the loop covered in ReAct. Practical systems often set a fixed iteration limit k, but the number of searches a question needs differs from question to question. Recent research sets the stopping point with a reinforcement learning reward, a training-free statistical threshold, or a value function. Each paper compares against a different baseline.

Where the Stopping Decision Sits

An iterative search loop contains three decisions. The retriever decides what to fetch, the generator decides what to answer, and the stopping policy decides whether to search again. A fixed k replaces the third decision with one constant.

flowchart LR
    Q[Question] --> S["Current state<br/>question, evidence, interim answer"]
    S --> P{Stopping policy}
    P -->|Continue| R[Retriever]
    R --> G[Generator]
    G --> S
    P -->|Stop| A[Final answer]

SAAS (arXiv:2605.29796, 2026-05) splits errors in this decision into two ratios. The question-level over-search ratio (QOR) is the rate of search on questions that the model can answer from its internal knowledge. The step-level over-search ratio (SOR) is the rate of search that continues after the agent has collected sufficient evidence.

On Qwen2.5-7B-Instruct, the QOR averaged over seven QA benchmarks is 100.0% for HiPRAG and 99.9% for StepSearch. It is 82.8% for Search-R1 and 52.5% for RFT. HiPRAG and StepSearch started a search almost every time, even on questions that internal knowledge could answer. An agent can learn to search, but its stopping behavior stays invisible unless you measure it separately.

Stopping Learned from a Reward

SAAS sets a search boundary by comparing rollouts with search disabled and rollouts with search enabled on the same question. A question is NoSearch when the number of correct search-disabled rollouts reaches a threshold δ, which is 2 by default. It is NeedSearch when all search-disabled rollouts fail and at least one search-enabled rollout is correct. All other questions are Undetermined.

The reward adds a search penalty to the accuracy reward, which is F1. The penalty applies only when F1 equals 1. On NoSearch questions, the penalty grows with the number of searches. On NeedSearch questions, it applies only to searches above the minimum count among correct rollouts. Both penalties use a coefficient α of 0.05.

The training schedule also treats stopping separately. Stage 1 trains with the outcome reward only. Stage 2 turns on the boundary reward when validation performance stops improving. The paper explains that turning on the boundary reward too early can cause reward hacking, where the agent avoids even necessary searches.

On Qwen2.5-7B-Instruct, averaged over the seven benchmarks, SAAS reached 48.7% accuracy with 0.97 searches on average. HiPRAG reached 49.8% with 2.19 searches. Calculated from these figures, SAAS cuts search by about 56%, and its accuracy is 1.1 percentage points lower. Accuracy here is answer accuracy judged by GPT-4, which is different from Exact Match (EM).

The QOR of SAAS is 45.9%, and the SOR is 6.3% for SAAS and 19.5% for HiPRAG. However, the paper reports only over-search metrics and does not measure the rate of skipped necessary searches. Whether the removed searches included necessary ones is visible only indirectly, through average accuracy.

A Training-Free Threshold

TASR (arXiv:2606.13814, 2026-06) stops without training when two conditions are true at the same time. The normalized answer must match the answer from the previous round. The logit margin after isotonic calibration must be above 0.25.

The rule cannot stop at round 1, and it runs for at most 5 rounds. The retriever ranks the passages only once, and each round shows one more passage from that fixed ranked list. Thus TASR reduces LLM rounds, which are LLM calls, not search calls.

The 0.25 threshold stays the same across 32 model, retriever, and corpus configurations. The calibrator is fit once per model on a 100-question HotpotQA distractor tune split and then frozen. The open-domain BM25 cells and the dense-retriever cells reuse this calibrator without change.

For the scale test with Nemotron-3-Ultra-550B, the calibrator was fit again on the tune split of that model. The calibrator was not fit again when the retriever or corpus changed, but a new generator model gets a new calibrator.

The evaluation grid has 6 cells: 3 models and 2 distractor datasets (HotpotQA and 2WikiMultiHopQA), with 300 questions per cell. The primary baseline is fixed k=3, with an F1 of 53.98 and 3.00 LLM calls on average. TASR is 3.42 F1 higher at 57.40 and uses 0.13 more calls, at 3.13. Against fixed k=5 (F1 60.52, 5.00 calls), TASR keeps 94.8% of the F1 with 62.6% of the calls.

The paper also reports why the margin floor is necessary. With the answer-stability condition alone, about 3% of trajectories stopped on a repeated wrong answer before the gold passage arrived. With the margin floor added, about half of those trajectories changed to a correct answer in a later round.

The call distribution has a longer tail. The 95th-percentile (P95) call count of TASR is 4, against 3 for fixed k=3. The paper states that TASR does not suit deployments where worst-case latency matters. A stopping policy decides how much inference compute each question gets, and this allocation problem is covered in Test-Time Compute Scaling.

Stopping Learned with a Value Function

Stop-RAG (arXiv:2510.14337, 2025-10) is a paper from the NeurIPS 2025 MTI-LLM Workshop. It models iterative RAG as a finite-horizon Markov decision process (MDP). It trains a value-based stopping controller with Q(λ) targets from complete trajectories. The controller is a DeBERTa-v3-large Q-network that is separate from the generator, so it also works when the generator is a black-box API.

The setup uses a Llama-3.1-8B-Instruct generator, a Contriever-MSMARCO retriever, and a bge-reranker-v2-m3 reranker, with at most 10 iterations. Each dataset has 1,000 test questions sampled from its dev split. The baselines are the plain pipeline, which runs all 10 iterations without stopping, and LLM-Stop, which asks the generator through a prompt whether to stop.

The result depends on the baseline. Against the fixed 10-iteration run, Stop-RAG cut the average steps to 8.6 on MuSiQue and to 5.1 on 2WikiMultihopQA. In the same comparison, F1 rose from 44.8 to 47.0 and from 73.1 to 75.7.

Against LLM-Stop, the average steps increased from 7.6 to 8.6 and from 5.0 to 5.1. F1 rose from 44.6 to 47.0 and from 73.3 to 75.7. Retrieval recall rose from 64.5 to 66.5 and from 79.1 to 82.6.

The authors explain that Stop-RAG continues when more evidence helps, while LLM-Stop ends early. A separate controller did better than asking the same generator to stop, and this result supports separating the stopping decision. The table below puts the three methods side by side.

The three papers differ in metrics, datasets, iteration budgets, and baselines, so do not compare their numbers directly. The main results of all three papers are average quality and average call count. None of them reports, as a main result, how many of the actual stops were unsafe.

The First Stop Defines the Deployed Policy

Luo's "When Should Multi-Round RAG Stop?" (arXiv:2608.13237, 2026-08) evaluates this gap directly. A judge scores each search state, and the policy stops at the first state whose score crosses the threshold. If no state crosses it, the policy follows the original run (Native). Thus the first stop on each trajectory defines what the deployed policy does.

The experiment freezes the reasoner, retriever, corpus, and search budget. The reasoner is Search-R1 Qwen2.5-7B PPO v0.2, trained with proximal policy optimization (PPO). The retriever is E5 with top-3 results, the corpus is Wiki-2018, and the budget is at most 4 searches.

The judge is Qwen3.5-2B, fine-tuned with low-rank adaptation (LoRA) on 3,009 states from 900 HotpotQA training questions. The threshold of about 7.875 was selected on a 100-question validation set and then frozen. The selection criteria include a STOP precision of at least 0.90.

The confirmatory set has 800 questions from the HotpotQA distractor dev split. EM fell from 0.44875 to 0.44250, which is 0.625 percentage points. The 95% confidence interval of the difference is [−1.25, 0] percentage points. This is within the non-inferiority margin of 2 percentage points that the paper set in advance, so the non-inferiority criterion passed.

The paper defines a safe opportunity as a state where Native proposes another search and a frozen answer probe already gives the official answer. An unsafe early stop is a selected first stop that does not meet this definition. The paper also states that a safe opportunity does not mean the evidence is complete.

The average figures divide by all 800 questions, including the 731 questions where the policy did not act. Because of this, the 39% unsafe rate among the 69 stops is hidden inside a small difference of 0.625 percentage points.

The paper gives two reasons why the 27 unsafe stops did not all become new wrong answers. Native was already wrong on some of those questions. On others, an early state failed the safe-opportunity definition, but the final answer was still correct.

The precision of the threshold also did not transfer. On validation, the precision was 0.9091 from 11 predicted STOP states. On the confirmatory set, it fell to 0.6216, with a recall of 0.0880.

A separate exploratory set of 200 questions used a binary LoRA judge. The judge raised the average precision (AP) of STOP decisions from 0.732 to 0.828. It also cut average searches from 2.635 to 1.430. In the same run, EM fell from 36.5% to 31.5%. Thus better ranking and a higher reduction rate do not show answer quality.

This exploratory run used a different policy, threshold, and question set. Its labels had also been used in earlier analyses, so read it as an exploratory result only.

Cost is also more than search calls. The paper states that the judge also uses inference compute, and that its compute, memory, and latency were not converted into search-call units. Thus 3.70% is the reduction in search calls, not in total cost.

Conditions Where the Claim Does Not Hold

The evidence for the unsafe-stop rate comes from one paper and one configuration. The conditions are Search-R1 7B, E5, Wiki-2018, top-3, at most 4 searches, and HotpotQA. The paper limits the scope of its results to this configuration. Do not use 39% as an expected rate for other configurations.

The paper is a single-author arXiv v1 preprint. The author disclosed a procedure violation: a script computed a SHA-256 hash of the answer file before the blind evaluation. The paper reports that the hash was not used for selection. Its effect has not been independently checked.

A separate stopping policy is still not fully independent of the generator. When Stop-RAG was added to the CoRAG pipeline, it scored slightly below the plain run and LLM-Stop on HotpotQA. The authors consider a likely cause to be the CoRAG generator, which was trained for a fixed number of iterations.

Separation also has a cost. TASR needs top-5 logprobs, a short-answer format, and temperature 0. Thus it is hard to use with APIs that hide logprobs or with long-form answers. A method with a judge adds the inference cost of the judge.

When the stopping behavior is trained into the agent model, as in SAAS, no component is added. However, a change of base model probably means that the stopping behavior must be trained again. This is an estimate.

The three papers also use different baselines. SAAS compares with other trained methods such as HiPRAG, and TASR compares with fixed k=3 and k=5. Stop-RAG compares with the fixed 10-iteration run and LLM-Stop. Thus there is no basis to sort the three results into methods that reduce search and methods that increase it.

Some questions stay open in these sources. No study sets an acceptable unsafe-stop rate. The question-level unsafe-stop rates of the SAAS, TASR, and Stop-RAG policies are also not reported.

Evaluation Criteria for Adopting a Stopping Policy

Luo's paper proposes that stopping research report four views together, because any one view alone is incomplete. The views are candidate reachability and oracle headroom, state ranking, question-level first-stop results with safe and unsafe selections, and quality with its costs. The costs include search, tokens, latency, and judge compute. The list below turns these views into adoption criteria, and the list is a judgment.

• Freeze the retriever, generator, corpus, prompt, and search budget, and change only the stopping policy. This keeps the effect of stopping apart from the effect of search quality.
• State the baseline. As Stop-RAG shows, the same policy can look like it reduces search or increases search, depending on the baseline.
• Next to the reduction rate, record the number of actual early stops and the unsafe rate among them. The denominator of the unsafe rate is the number of actual early stops, not the number of all questions.
• Count the questions that changed from correct to wrong and from wrong to correct, together with the average accuracy difference.
• Measure STOP precision again on a question set different from the one used to select the threshold.
• Include the compute and latency of the judge and the calibrator in the cost, and check the P95 call count together with the average.
• If multi-hop questions are a large share, check recall loss from early stopping before over-search.

The search-quality design that a stopping experiment keeps fixed is covered in RAG Moves From Retriever to Compiler and Reranker Objective Shift.

References

• SAAS: Self-Aware Reinforcement Learning for Over-Search Mitigation in Agentic Search, arXiv:2605.29796 (2026-05)
• TASR: Training-Free Adaptive Stopping for Iterative Retrieval, arXiv:2606.13814 (2026-06)
• Stop-RAG: Value-Based Retrieval Control for Iterative RAG, arXiv:2510.14337 (2025-10)
• When Should Multi-Round RAG Stop? Structured Stopping Judgments and Retrieval Reduction in Search-R1, arXiv:2608.13237 (2026-08)

Every figure was checked against each original source as of 2026-10.

Summary

The stopping point of an iterative search agent is a policy with its own signals and objectives, apart from the retriever and the generator. SAAS uses a reward term and a training stage, TASR uses a training-free threshold, and Stop-RAG uses a separate value controller. The three papers compare against different baselines, and the main results of all three are average quality and average call count.

One study evaluated first stops per question. It found a 3.70% cut in search calls and an EM drop of 0.625 percentage points, with an unsafe early-stop rate of 39.13%. When you adopt an early-stopping policy, state the baseline. Record the reduction rate, the unsafe rate among actual early stops, the answer flips, and the judge cost together. This rate comes from one configuration, so run the same evaluation again on your own system.