2602.03485

# Self-Verification Dilemma: Experience-Driven Suppression of Overused Checking in LLM Reasoning **Authors**: Quanyu Long, Kai Jie Jiang, Jianda Chen, Xu Guo, Leilei Gan, Wenya Wang ## Abstract Large Reasoning Models (LRMs) achieve strong performance by generating long reasoning traces with reflection. Through a large-scale empirical analysis, we find that a substantial fraction of reflective steps consist of self-verification (recheck) that repeatedly confirm intermediate results. These rechecks occur frequently across models and benchmarks, yet the vast majority are confirmatory rather than corrective, rarely identifying errors and altering reasoning outcomes. This reveals a mismatch between how often self-verification is activated and how often it is actually useful. Motivated by this, we propose a novel, experience-driven test-time framework that reduces the overused verification. Our method detects the activation of recheck behavior, consults an offline experience pool of past verification outcomes, and estimates whether a recheck is likely unnecessary via efficient retrieval. When historical experience suggests unnecessary, a suppression signal redirects the model to proceed. Across multiple model and benchmarks, our approach reduces token usage up to 20.3 % while maintaining the accuracy, and in some datasets even yields accuracy improvements. Machine Learning, ICML ## 1 Introduction <details> <summary>Figs/intro.png Details</summary>  ### Visual Description ## Screenshot: Math Problem-Solving Process ### Overview The image depicts a chat interface where a user is solving a math problem step-by-step. The conversation includes color-coded annotations (green, orange, red) to indicate verification steps, error checks, and rethinking phases. ### Components/Axes - **Header**: Blue text instructing the user to "think step by step." - **Chat Bubbles**: - **Green Dashed Bubble**: Contains initial computations, retractions, and verification steps. - **Orange Dashed Bubble**: Focuses on verifying optimality and identifying errors. - **Red Dashed Bubble**: Highlights rethinking assumptions and alternative approaches. - **Annotations**: - Green: "Recheck not identifying any errors" - Orange: "Recheck identifying an error" - Red: "Rethink" ### Detailed Analysis 1. **Initial Computations (Green Bubble)**: - The user begins by taking derivatives and verifying calculations. - Annotation: "Recheck not identifying any errors" (green). - Conclusion: "m + n is 116." 2. **Mid-Results Verification (Green Bubble)**: - The user rechecks probability calculations (P(B)) and confirms "m + n = 116." - Annotation: "Recheck not identifying any errors" (green). 3. **Optimality Proof (Orange Bubble)**: - The user attempts to verify if the minimum is proven but concludes the earlier result was wrong. - Annotation: "Recheck identifying an error" (orange). 4. **Rethinking Assumptions (Red Bubble)**: - The user questions the orientation of "DC" (horizontal vs. alternative) and proposes a new approach. - Annotation: "Rethink" (red). ### Key Observations - The user iteratively revises their approach, starting with confidence in "m + n = 116" but later doubting it due to potential errors in probability calculations. - The shift from green to orange to red annotations reflects increasing uncertainty and the need for deeper re-evaluation. - The final red bubble indicates a fundamental reassessment of initial assumptions. ### Interpretation The conversation illustrates a dynamic problem-solving process where the user: 1. **Validates computations** (green) but remains open to errors. 2. **Identifies contradictions** (orange) when optimality is challenged. 3. **Reevaluates foundational assumptions** (red) to propose an alternative method. This reflects a Peircean investigative approach: hypothesizing, testing, and refining ideas through iterative doubt and verification. The color-coded annotations serve as a visual metaphor for the scientific method, emphasizing the importance of skepticism and adaptability in technical reasoning. </details> Figure 1: Reflective behaviors commonly observed in step-by-step mathematical reasoning. We illustrate three categories: rethink, where the model revises its strategy and explores an alternative line of reasoning; and recheck, where the model verifies already-derived intermediate results through re-computation, arithmetic checking, or optimality validation. Recheck behaviors can be further divided into confirmatory cases, which only confirm previous results, and corrective cases, which identify errors and alter the reasoning outcome. Our empirical analysis shows that recheck behaviors overwhelmingly fall into the confirmatory category. Large language models (LLMs) have recently demonstrated substantial progress on complex reasoning tasks. Large Reasoning Models (LRMs) such as OpenAI o1 (OpenAI et al., 2024) and DeepSeek-R1 (DeepSeek-AI et al., 2025) further extend these capabilities through reinforcement learning (RL), producing long reasoning traces that exhibit reflection and self-correction in an increasingly anthropomorphic manner (Yang et al., 2025b). A useful lens is that RL does not introduce reflection from scratch but scales it up: pretrained LLMs only sporadically exhibit reflective behaviors, and these are often shallow and unlikely to improve solutions (Liu et al., 2025b), whereas RL markedly increases both the frequency and apparent effectiveness of reflection by optimizing task-level rewards. This makes reflection a key mechanism for improving reliability in LRMs. However, the same mechanism can also lead to inefficient computation, where models continue to deliberate and repeatedly verify, despite already having sufficient evidence, a phenomenon often described as overthinking (Sui et al., 2025). Together, these observations position reflection as a central but double-edged component of LRMs. While overthinking in reasoning models has been increasingly studied (Zhang et al., 2025a; Fang et al., 2025; Jiang et al., 2025; Zhang et al., 2026), we observe that a large fraction of reflective steps in practice consist of repeated and often trivial rechecks (Figure 1). Through large-scale analysis of reasoning traces, we find that reflective behaviors can be broadly categorized into two types: 1) rethink, where the model revises its reasoning strategy or reformulates the problem, and 2) recheck (i.e., self-verification), where the model verifies the correctness of already-derived intermediate results through re-computation, arithmetic checking, constraint validation, or optimality testing. Our analysis further shows that recheck occurs frequently during model reflective reasoning across models and datasets (Section 3.2). However, most rechecks are confirmatory: they rarely identify errors or change the reasoning outcome (Section 3.3). These observations are consistent with findings from Kang et al. (2025), who shows that verification steps following a candidate final answer rarely change the final result; in contrast, we study self-verification as a manifestation of the model’s epistemic uncertainty during the reasoning process itself, rather than as post hoc confirmation of a final answer. The prevalence of such redundant rechecking presents a practical challenge: although intended to improve reliability, excessive self-verification consumes substantial reasoning budget and yields diminishing corrective benefit, revealing a mismatch between how often rechecking is performed and how often it is actually useful. This raises a central question: when is self-verification actually worth performing during reasoning? In human problem solving, self-verification is rarely applied uniformly. When encountering a familiar operation, such as taking derivatives of a standard expression or checking a routine constraint, humans often rely on accumulated confidence and proceed without rechecking every step, knowing that similar derivations have rarely failed in the past. Inspired by this, we argue that effective reasoning requires selective self-verification: verifications should be executed aggressively in contexts where errors are likely and conservatively when prior evidence suggests high confidence. Rather than treating self-verification as an unconditional safeguard, it should be guided by experience, allowing the reasoning process to allocate effort where it is most likely to be beneficial. Motivated by this perspective, we propose an experience-driven framework for selective self-verification at test-time. Our approach equips a reasoning model with access to past self-verification experience, allowing it to estimate whether a newly initiated verification step is likely to be useful. Concretely, during inference, we first detect the activation of self-verification behaviors using a lightweight trained identifier. Upon detection, we retrieve similar verification episodes from an experience pool constructed offline. By aggregating historical outcomes, specifically, whether similar rechecks on a certain concrete mathematical manipulations (e.g., taking derivatives) previously corrected errors or merely confirmed correctness, then we can estimate the likelihood that continuing the current verification will be beneficial by a voting strategy. When prior experience indicates that rechecking is unlikely to change the reasoning outcome, we suppress the verification by injecting a brief textual signal and allow the model to proceed to subsequent reasoning steps. Importantly, our method does not modify model parameters, does not truncate necessary reasoning and strategy-level rethinking, and intervenes only on redundant rechecks. Empirically, this selective suppression reduces token usage by up to 20.3% while maintaining comparable accuracy, and in some datasets even yields slight accuracy improvements. ## 2 Related Work #### Self-Evolving LLM with Experience Recent work regarding enabling LLMs to self-evolve from experience focuses on mechanisms for accumulating, abstracting, and reusing interaction histories. ExpeL (Zhao et al., 2024) and Contextual Experience Replay (Liu et al., 2025a) introduce training-free experiential learning by distilling and retrieving past interaction trajectories to improve future performance, while Retrospex (Yufei Xiang & Nguyen, 2024) further integrates experience via an offline RL critic to guide action selection. AgentEvolver (Zhai et al., 2025) extends this paradigm by combining self-questioning, self-navigation, and self-attribution to enable continual autonomous improvement. Complementary studies analyze the limits of test-time learning from experience, showing measurable but slower gains compared to humans (Wang et al., 2025a). Other approaches focus on structuring experience for reuse: HiAgent (Hu et al., 2025) hierarchically manages working memory for long-horizon tasks, while Metacognitive Reuse (Didolkar et al., 2025) compresses recurring reasoning into reusable behaviors. Finally, efficiency-oriented methods optimize experiential reasoning by decomposing or truncating reasoning trajectories, including structured multi-turn decomposition (Zeng et al., 2025), self-braking tuning (Zhao et al., 2025), and early stopping informed by reflection analysis (Kang et al., 2025). #### Efficient Reasoning Recent work on efficient reasoning increasingly focuses on adaptive compute allocation. A line of methods trains models to decide whether to reason, or to switch between fast and slow modes based on input difficulty, including query-level think/no-think decisions and hybrid reasoning strategies (Zhang et al., 2025a; Fang et al., 2025; Jiang et al., 2025; Zhang et al., 2025b). This paradigm has been extended to intrinsic fast–slow switching and multi-format reasoning selection (Zhang et al., 2026; Wu et al., 2025). Finer-grained approaches further adapt computation at the step or process level, for example by leveraging process-level rewards to switch reasoning strategies (Wang et al., 2025b), or by allocating additional computation only to high-value reasoning segments through long–short collaboration (Ning et al., 2025). Complementary analyses observe that reflective reasoning frequently reconfirms the initial answer rather than correcting errors, motivating reflection truncation or early-stopping mechanisms (Kang et al., 2025). In parallel, inference cost has been reduced through adaptive length or budget control and convergence-based stopping criteria (Shen et al., 2025; Liu & Wang, 2025; Mao et al., 2025), while system-oriented model families provide practical reasoning toggles for high-throughput deployment (Bercovich et al., 2025). In contrast to prior work that primarily allocates compute by switching reasoning modes or terminating reasoning early based on difficulty, our approach targets redundant self-verification during inference. We selectively suppress low-utility rechecking behaviors at test time, with reduced reasoning length arising naturally as a consequence rather than an explicit optimization objective. ## 3 Empirical Analysis All analyses are conducted on rollouts generated by four LLMs, Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), gpt-oss-20b (OpenAI, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025). We evaluate models on four mathematical reasoning benchmarks: AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC23 (AMC12, 2023) and MATH500 (Hendrycks et al., 2021). ### 3.1 How frequently do LLMs exhibit reflective behaviour? Recent LLMs generate long Chain-of-Thoughts (CoTs) that frequently include reflective behaviors. These reflections are commonly viewed as a mechanism for improving reasoning reliability, particularly in models trained to deliberate extensively. To better understand the practical role of reflection, we begin by quantifying how frequently such behaviors occur in reasoning traces. <details> <summary>x1.png Details</summary>  ### Visual Description ## Bar Chart: Percentage of Reflections by Model and Dataset ### Overview The chart compares the percentage of reflections across four AI models (QwQ-32B, Qwen3-8B, DeepSeek-R1-Distill-Qwen-7B, gpt-oss-20b) for four datasets (MATH500, AMC, AIME25, AIME24). Each model is represented by a grouped bar cluster, with colors corresponding to datasets as defined in the legend. ### Components/Axes - **X-axis**: "Percentage of Reflections (%)" (0–60% scale) - **Y-axis**: Model names (QwQ-32B at top, gpt-oss-20b at bottom) - **Legend**: - Blue = MATH500 - Red = AMC - Orange = AIME25 - Green = AIME24 - **Bar Colors**: Match legend labels (e.g., QwQ-32B's MATH500 bar is blue). ### Detailed Analysis 1. **QwQ-32B**: - MATH500: 47.9% (blue) - AMC: 40.8% (red) - AIME25: 39.1% (orange) - AIME24: 39.4% (green) 2. **Qwen3-8B**: - MATH500: 42.3% (blue) - AMC: 37.1% (red) - AIME25: 31.8% (orange) - AIME24: 36.4% (green) 3. **DeepSeek-R1-Distill-Qwen-7B**: - MATH500: 34.5% (blue) - AMC: 26.8% (red) - AIME25: 33.8% (orange) - AIME24: 31.4% (green) 4. **gpt-oss-20b**: - MATH500: 20.4% (blue) - AMC: 10.3% (red) - AIME25: 18.8% (orange) - AIME24: 18.9% (green) ### Key Observations - **MATH500** consistently shows the highest reflection percentages across all models, with QwQ-32B achieving the peak at 47.9%. - **AMC** performance declines sharply for smaller models (e.g., gpt-oss-20b at 10.3%). - **AIME25** and **AIME24** exhibit similar trends, with AIME25 slightly outperforming AIME24 in most cases (e.g., Qwen3-8B: 31.8% vs. 36.4%). - **gpt-oss-20b** underperforms across all datasets, with the lowest reflection rates (18.8–20.4%). ### Interpretation The data suggests that **MATH500** is the most effective dataset for reflection tasks, as it consistently yields the highest percentages. Larger models like **QwQ-32B** and **Qwen3-8B** outperform smaller models like **gpt-oss-20b**, indicating a correlation between model size and reflection capability. The near-identical AIME25/AIME24 results for some models (e.g., Qwen3-8B) imply minimal differentiation between these datasets in this context. The steep drop in AMC performance for smaller models highlights potential limitations in handling complex reasoning tasks. These trends align with expectations that larger, more specialized models excel in structured problem-solving benchmarks. </details> Figure 2: Percentage of steps classified as reflections. We begin by analyzing reasoning rollouts at the granularity of individual steps. Each rollout is segmented into a sequence of steps using simple formatting cues “\n\n”. Each segmented step is then annotated as either reflective or non-reflective using GPT-5 (OpenAI et al., 2025). The classifier is prompted to determine whether a step constitutes a reflection based on a strict rule: a step is labeled as reflective only if it explicitly refers to the model’s own reasoning process and engages in monitoring, evaluating, or revising that reasoning. Concretely, reflective steps include explicit self-referential or metacognitive language indicating verification, critique, reconsideration, or switching to new reasoning strategies (e.g., “I should check”, “this approach might be wrong”, “let me reconsider”). In contrast, steps that primarily advance the solution, such as performing calculations, applying formulas, or explaining problem-specific logic, are not considered reflective. The exact instructional prompts are provided in Appendix E. Based on these annotations, we compute the proportion of reflective steps within each rollout and present the results in Figure 2. #### Findings. We observe that across all reasoning-oriented models and benchmarks, reflective steps constitute a substantial portion of model-generated rollouts, often approaching or exceeding one third of all steps. These results indicate that reflection is a systematic and frequent component of LLM reasoning. Interestingly, a common intuition is that reflection should correlate with problem difficulty: harder problems presumably require more exploration, reconsideration, and strategic adjustment, leading to more frequent reflective behavior. However, our results reveal a counterintuitive pattern. For all models, MATH500 exhibits the highest proportion of reflective steps, despite its problems being less difficult than those in AIME. This finding suggests that reflection frequency does not reliably track problem difficulty or the need for deeper reasoning. Instead, reflection appears to be triggered broadly during reasoning, even in settings where extensive deliberation is unlikely to advance the solution. This motivates a closer examination of what kinds of reflection models actually perform. ### 3.2 What Forms of Reflection do LLMs repeatedly exhibit? In practice, reflective steps may serve qualitatively different functional roles. Some reflections support advanced problem solving by revising strategies or restructuring the solution path, while others merely verify previously derived results without introducing new reasoning. Distinguishing between these roles is essential for understanding whether reflection primarily advances reasoning or instead functions as local self-monitoring. #### Rethink vs. Recheck. We introduce a functional taxonomy that separates reflective steps into two categories: rethink and recheck (Examples are provided in Figure 1). Rethinks operate at the level of global reasoning strategy. Rather than evaluating a specific intermediate result, they revise assumptions, introduce alternative solution approaches, abandon earlier plans, or reorganize the structure of the reasoning process. These reflections are inherently exploratory and are often necessary for solving complex problems where the initial approach is flawed or incomplete. Rechecks (i.e., self-verification), in contrast, operate at the level of local correctness. They focus on verifying previously stated intermediate results, computations, or logical steps, with the explicit or implicit goal of assessing whether an earlier conclusion is valid. Rechecks may involve recomputation, constraint checking, case testing, or validation of optimality or minimality. Importantly, rechecks do not introduce new solution strategies; they evaluate existing ones. To operationalize this taxonomy, for each step identified as reflective in Section 3.1, we prompt GPT-5 with surrounding context, including preceding and subsequent steps, enabling it to assess the role that the local reflection plays in the overall reasoning trajectory. Each reflective step is then categorized as either a rethink or a recheck, with ambiguous cases labeled as unable to classify. #### Findings. Figure 3 presents the distribution of reflection types for Qwen3-8B across four benchmarks. Across all datasets, rechecks constitute a substantial fraction of reflective steps, accounting for approximately 40–58% of all reflections. Notably, rechecks make up a larger share of reflections on comparatively simpler datasets, such as AMC and MATH500. This pattern aligns closely with our findings in the previous subsection. There, we show that reflective steps are not more frequent on harder problems, instead, simpler datasets often induce more frequent reflection. The present analysis clarifies that on easier problems, reflection is dominated by local self-verification rather than by meaningful strategy revision. As a result, reflection frequently manifests as repetitive rechecking of intermediate results. This observation motivates a closer examination of whether such rechecks meaningfully contribute to correctness. ### 3.3 Do Rechecks Truly Identify Errors? If rechecks frequently identify and correct errors, their prevalence would justify self-verification as an essential component of reliable multi-step reasoning. However, if most rechecks simply reaffirm already-correct intermediate results, then a substantial portion of reflective behavior is redundant. We therefore examine whether rechecks in practice meaningfully contribute to error correction. #### Corrective vs. Confirmatory Rechecks. We categorize rechecks based on their functional outcome. A corrective recheck identifies an error in a previously stated intermediate result and leads to a correction. In contrast, a confirmatory recheck verifies an earlier step but does not uncover any error and does not alter the mid-result. We prompt GPT-5 to assess whether the recheck reveals an actual mistake and results are also presented in Figure 3. <details> <summary>Figs/reflection_pie_charts_qwen.png Details</summary>  ### Visual Description ## Pie Charts: Distribution of Recheck Types Across Exams ### Overview The image contains four pie charts comparing the distribution of four recheck categories ("Confirmatory Rechecks," "Rethinks," "Corrective Rechecks," "Unable to Classify") across four exams: AIME24, AIME25, AMC, and MATH500. Each chart uses distinct colors for categories, with a legend at the bottom for reference. ### Components/Axes - **Legend**: - Green: Confirmatory Rechecks - Red: Rethinks - Yellow: Corrective Rechecks - Blue: Unable to Classify - **Chart Labels**: - Top-left: AIME24 - Top-right: AIME25 - Bottom-left: AMC - Bottom-right: MATH500 ### Detailed Analysis #### AIME24 - Confirmatory Rechecks (green): 35.5% - Rethinks (red): 49.7% - Corrective Rechecks (yellow): 5.2% - Unable to Classify (blue): 9.7% #### AIME25 - Confirmatory Rechecks (green): 38.7% - Rethinks (red): 39.8% - Corrective Rechecks (yellow): 4.8% - Unable to Classify (blue): 16.8% #### AMC - Confirmatory Rechecks (green): 49.9% - Rethinks (red): 39.8% - Corrective Rechecks (yellow): 4.2% - Unable to Classify (blue): 6.2% #### MATH500 - Confirmatory Rechecks (green): 52.8% - Rethinks (red): 38.6% - Corrective Rechecks (yellow): 3.2% - Unable to Classify (blue): 5.4% ### Key Observations 1. **Dominant Categories**: - Confirmatory Rechecks (green) are largest in AMC (49.9%) and MATH500 (52.8%). - Rethinks (red) dominate AIME24 (49.7%) and are nearly equal to Confirmatory Rechecks in AIME25 (39.8% vs. 38.7%). 2. **Lowest Category**: - Corrective Rechecks (yellow) are consistently the smallest, with MATH500 having the lowest at 3.2%. 3. **Unclassifiable Data**: - AIME25 has the highest "Unable to Classify" (16.8%), suggesting potential issues in data categorization for this exam. ### Interpretation The data reveals significant variability in recheck distributions across exams. AIME25 stands out for its high proportion of "Unable to Classify" (16.8%), which may indicate ambiguities in grading or classification criteria for this exam. MATH500 has the highest Confirmatory Rechecks (52.8%), suggesting stricter initial validation processes. The near-equal split between Confirmatory Rechecks and Rethinks in AIME25 (38.7% vs. 39.8%) implies a balanced reevaluation process. Corrective Rechecks remain consistently rare (<5% in all charts), highlighting their limited role in the workflow. ### Spatial Grounding - **Legend**: Positioned at the bottom center, clearly associating colors with categories. - **Charts**: Arranged in a 2x2 grid, with each exam’s chart occupying equal visual space. - **Text**: All labels and percentages are embedded within the pie slices, with no external annotations. ### Trend Verification - **Confirmatory Rechecks**: Increase from AIME24 (35.5%) to MATH500 (52.8%), showing a trend toward higher initial validation in later exams. - **Rethinks**: Decrease from AIME24 (49.7%) to MATH500 (38.6%), indicating reduced need for reevaluation in later exams. - **Unable to Classify**: Peaks in AIME25 (16.8%) before dropping to 5.4% in MATH500, suggesting improved classification accuracy over time. ### Component Isolation - **Header**: Chart titles (AIME24, AIME25, AMC, MATH500) positioned above each pie chart. - **Main Chart**: Pie slices with embedded percentages and color-coded segments. - **Footer**: Legend explaining color mappings. ### Final Notes All textual content is in English. No non-English elements are present. The data emphasizes the importance of exam-specific recheck strategies, with AIME25’s high "Unable to Classify" rate warranting further investigation into grading consistency. </details> Figure 3: Proportion of reflection types for Qwen3-8B annotated by GPT-5. More results are presented in Appendix B. Human evaluation results are presented in Appendix C. <details> <summary>Figs/method.png Details</summary>  ### Visual Description ## Flowchart: Experience-Driven LLM Reasoning System ### Overview The flowchart illustrates a three-stage system for optimizing large language model (LLM) reasoning through experience-driven verification. It combines experience pool construction, recheck activation detection, and adaptive reasoning with verification suppression. Key elements include an LLM, experience pool, binary classifier, and feedback loops for error correction. ### Components/Axes 1. **Experience Pool Construction** (Blue Box) - **Components**: - LLM (brain icon) - Rollouts on Various Problems (document icon) - Experience Pool (database icon with {e₁, e₂, ..., eₙ}) - **Process Flow**: - LLM generates rollouts → Extract recheck episodes → Annotate outcomes (Necessary/Unnecessary) → Store in Experience Pool 2. **Recheck Activation Detection** (Green Box) - **Components**: - Binary Classifier Training (gear icon) - Necessity Estimation (magnifying glass) - Top-k Vote (search icon) - **Process Flow**: - Experience Pool → Binary Classifier → Necessity Estimation → Top-k Vote 3. **Experience-driven LLM Reasoning** (Orange Box) - **Components**: - LLM (brain icon) - Verification Suppression Signal (red arrow) - Stick figure with laptop (human-in-the-loop element) - **Process Flow**: - LLM reasoning → Recheck Activation Detection → Verification Suppression → Adaptive reasoning ### Detailed Analysis - **Experience Pool Construction**: - Textual examples include: - "I need to check if this is correct..." - "It seems My previous calculation is right..." - Outcomes are annotated as "Necessary" or "Unnecessary" (red text). - **Recheck Activation Detection**: - Binary classifier uses SLM (small language model) for training. - Necessity Estimation employs a "Top-k Vote" mechanism (search icon). - **Experience-driven LLM Reasoning**: - LLM generates reasoning traces (e.g., "Please answer the following math question..."). - Verification suppression signal (red arrow) bypasses rechecks when confidence is high. - Human-like stick figure expresses self-awareness: "Oh, I rarely made mistakes in taking derivatives!" ### Key Observations 1. **Feedback Loops**: - Experience Pool → Recheck Detection → LLM Reasoning creates a closed-loop system for continuous improvement. 2. **Verification Suppression**: - Red arrow indicates dynamic suppression of unnecessary checks based on confidence. 3. **Human-LLM Collaboration**: - Stick figure represents meta-cognitive awareness of error patterns. 4. **Mathematical Context**: - Explicit references to derivatives (Eq. 2) and equation-based reasoning. ### Interpretation This system demonstrates a self-improving LLM framework where: 1. **Experience Pool** acts as a memory bank of past reasoning errors and successes. 2. **Binary Classifier** identifies when rechecks are statistically necessary, reducing computational overhead. 3. **Verification Suppression** optimizes efficiency by avoiding redundant checks when confidence is high. 4. The human-like element suggests the system incorporates meta-cognitive feedback, mimicking human learning from mistakes. The architecture balances rigor (through systematic rechecks) and efficiency (via suppression signals), creating an adaptive reasoning pipeline that improves with accumulated experience. The mathematical focus (derivatives, equations) indicates specialization in STEM domains, while the stick figure metaphorizes the system's growing reliability through iterative learning. </details> Figure 4: Overview of the experience-driven verification control framework. Recheck episodes are collected and annotated offline to form an experience pool, which captures how often rechecks succeed in correcting errors for specific mathematical manipulations or formula-level derivations, e.g. taking derivatives. The experience pool will be consulted at the test-time to suppress redundant self-verification during LLM reasoning. #### Findings. We find that the overwhelming majority of rechecks are confirmatory rather than corrective. Across datasets, approximately 85–95% of rechecks merely confirm prior reasoning and do not change intermediate results or final answers. And this pattern is consistent across both simpler and harder benchmarks. These results indicate that although models frequently engage in self-verification, such behavior seldom leads to error correction. All these findings reveal a clear inefficiency: a large number of tokens are evoked to self-verify but almost never change the outcome, the predominance of confirmatory rechecks suggests that self-verification is often overused in current LLM reasoning. ## 4 Experience-Guided Self-Verification The analysis in the previous section shows that large language models frequently initiate self-verification during reasoning, even in situations where such verification rarely alters intermediate results. As a result, successive self-verification actions often incur additional computational cost while providing limited corrective benefit. This observation motivates a central question: should every verification attempt be carried out, or can some of them be safely avoided? Intuitively, self-verification becomes redundant when similar reasoning patterns have consistently produced correct results on certain math formulas. Human problem solving offers an analogy. When encountering familiar mathematical forms, such as routine re-computations, constraint checks, or optimality and minimality validations, people often rely on prior experience, reasoning that similar derivations have worked correctly many times before. In such cases, explicit rechecking is often unnecessary. Inspired by this perspective, we propose an experience-driven self-verification control framework. The core idea is simple: when a model begins to verify a previously stated intermediate result, we consult historical self-verification outcomes from similar contexts and formulas. If past experience indicates that such verification almost never uncovers errors, we discourage the model from continuing the recheck. Otherwise, verification proceeds as usual. Our approach operates entirely at test time, does not require training or modifying the underlying language model, and introduces minimal inference overhead. While suppressing redundant verification naturally shortens reasoning trajectories and reduces latency, these effects arise as a consequence of avoiding unnecessary verification rather than as an explicit objective. ### 4.1 Experience Memory Construction To enable experience-driven suppression of redundant self-verification, we first construct an experience pool that records historical verification outcomes observed in large language model reasoning. This process is illustrated in the left panel of Figure 4. #### Extracting Recheck Activations. We begin by collecting reasoning rollouts from a target large language model across a diverse set of problem instances. The same model is used both for experience collection and for inference-time reasoning, ensuring that the extracted verification patterns are representative of the target model’s native behavior. Given a reasoning rollout, we aim to collect experiences where the LLM is performing a recheck. To achieve that, we provide the whole rollout to GPT-5 (OpenAI et al., 2025) to identify and extract all sentences that initiate a recheck of a previously stated intermediate result, such as re-computation, constraint verification, candidate testing, or optimality validation. The set of sentences marks the activation of self-verification behavior. We intentionally focus only on recheck activations and exclude rethink behaviors, such as strategy shifts or reformulations, as rethinking plays a crucial role in correcting reasoning trajectories and should not be suppressed. To improve reliability, we apply additional filtering to ensure that extracted set can match and correspond to explicit verification attempts present in the original rollout. We denote the collection of recheck activation sentences as $\mathcal{S}$ . #### Outcome Annotation. For each identified recheck activation, we extract a self-verification episode, which consists of the local reasoning context and the subsequent verification steps, by taking a fixed-size context window surrounding the activation sentence. For each extracted self-verification episode, we prompt GPT-5 (OpenAI et al., 2025) again to annotate whether the recheck is necessary or unnecessary, Specifically, 1) Necessary: if the verification identifies an error, or corrects an intermediate result (corrective); 2) Unnecessary, if the verification confirms correctness and does not change the reasoning outcome (confirmatory). Episodes for which GPT-5 cannot make a clear determination are discarded to ensure annotation reliability. Each annotated self-verification is stored as an experience unit. Formally, we define the experience pool as $$ \mathcal{C}=\{e_{1},e_{2},\dots,e_{n}\}, \tag{1} $$ where each experience unit $e_{i}$ consists of $e_{i}=(c_{i},y_{i})$ . Here, $c_{i}$ denotes a textual representation of the self-verification episode context extracted around a recheck activation, and $y_{i}\in\{0,1\}$ is a binary label indicating whether the recheck is necessary ( $y_{i}=0$ ) or unnecessary ( $y_{i}=1$ ). The resulting experience pool $\mathcal{C}$ serves as a reusable memory of historical self-verification behavior, capturing how often rechecks succeed in correcting errors for specific local reasoning patterns, such as concrete mathematical manipulations or formula-level derivations (e.g., taking derivatives of a quadratic equation in Figure 4). Table 1: Accuracy (Pass@1) and average reasoning length for Base, Full-suppress, and Experience-Driven Suppression (EDS). EDS reduces reasoning length while preserving accuracy relative to the base model. † indicates numbers reported in Kang et al. (2025). Model Dataset Accuracy (%) Length Base Full-supress EDS Base Full-supress EDS Qwen3-8B AIME24 74.58 70.63 (-3.95) 72.92 (-1.66) 14605 12734 (-12.8%) 13296 (-9.0%) AIME25 67.71 66.67 (-1.04) 70.00 (+2.29) 17133 15713 (-8.3%) 16086 (-6.1%) AMC 95.62 96.25 (+0.63) 98.75 (+3.13) 8091 6564 (-18.9%) 6893 (-14.8%) Math500 95.80 95.20 (-0.60) 97.20 (+1.40) 4939 3935 (-20.3%) 4110 (-16.8%) Olympiad Bench 80.42 79.53 (-0.89) 79.82 (-0.60) 10480 9540 (-9.0%) 9739 (-7.1%) Average 80.95 79.56 (-1.39) 81.43 (+0.48) 11361 10071 (-11.4%) 10386 (-8.6%) FTM (Average) † Base Truncate all Selective truncate Base Truncate all Selective truncate (Kang et al., 2025) 84.70 80.90 (-3.80) 81.80 (-2.90) 15,125 10,601 (-29.9%) 11,414 (-24.5%) DeepSeek-7B AIME24 57.50 56.67 (-0.83) 58.75 (+1.25) 11237 10105 (-10.1%) 10478 (-6.8%) AIME25 39.38 35.42 (-3.96) 36.46 (-2.92) 12489 11221 (-10.1%) 11680 (-7.4%) AMC 91.25 90.00 (-1.25) 90.63 (-0.62) 5401 5067 (-6.2%) 5145 (-4.7%) Math500 90.60 87.20 (-3.40) 89.80 (-0.80) 3303 2726 (-17.5%) 2891 (-12.5%) Olympiad Bench 69.00 66.91 (-2.09) 67.95 (-1.05) 7913 7002 (-11.5%) 7183 (-9.2%) Average 66.66 64.21 (-2.45) 65.78 (-0.88) 8386 7467 (-11.0%) 7736 (-7.75%) QWQ-32B AIME2024 79.17 78.75 (-0.42) 83.33 (+4.16) 11237 10105 (-13.4%) 10478 (-9.5%) AIME2025 68.54 64.16 (-4.38) 65.63 (-2.91) 15811 14133 (-10.6%) 14908 (-5.7%) AMC 97.50 93.75 (-3.75) 95.00 (-2.50) 7542 6526 (-13.5%) 6719 (-10.9%) Math500 97.00 95.60 (-1.40) 97.00 (-0.00) 4659 3768 (-19.1%) 3940 (-15.4%) Olympiad Bench 81.90 81.45 (-0.45) 83.53 (+1.63) 9602 8454 (-12.0%) 8710 (-9.3%) Average 82.91 81.21 (-1.70) 83.48 (+0.57) 10293 8988 (-12.7%) 9379 (-8.9%) ### 4.2 Experience-Enhanced Inference #### Detecting Recheck Activation During inference, a key challenge is to identify when the model is about to start a recheck of a previously stated intermediate result. A natural approach is to instruct the model to explicitly mark such behaviors and emit a special operation when it plans to recheck, analogous to pipelines that interleave internal thoughts with tool calls (e.g., Search-o1 (Li et al., 2025)). However, we find that the model often struggles to reliably follow instructions within the thinking part (inside <think> tags). Motivated by Kang et al. (2025), we instead adopt a separate, lightweight identifier that detects whether a generated sentence initiates a recheck and such lightweight components introduce only limited inference latency (Kang et al., 2025). We implement the recheck activation identifier as a binary classifier. Training data is derived from the same reasoning rollouts used for experience pool construction. Specifically, positive examples are given by $\mathcal{S}$ collected in Section 4.1. Positive examples consist of recheck activation sentences confirmed by GPT-5 during the extraction process described. Hard negative examples arise naturally during this filtering stage: sentences that are initially extracted as potential recheck activations but subsequently rejected by GPT-5 as not constituting true rechecks are treated as hard negatives. The trained classifier achieves over 97% accuracy on the constructed validation and test splits. #### Experience Retrieval and Necessity Estimation When the identifier predicts that the current sentence initiates a recheck, we construct a query by extracting a fixed-size context window before the recheck activation. This local context typically contains concrete mathematical manipulations or formula-level derivations that characterize the recheck being attempted. We use this context as a query to retrieve the top- $k$ most similar experience units from the experience pool $\mathcal{C}$ using a sparse retriever (BM25 (Robertson & Zaragoza, 2009)), which is effective for matching symbolic expressions and mathematical operations while introducing minimal inference-time overhead. Let the retrieved set be $\{e_{i_{1}},\dots,e_{i_{k}}\}$ , where each $e_{i_{j}}=(c_{i_{j}},y_{i_{j}})$ . To estimate whether the current recheck is likely to be redundant, we do not forward the retrieved candidate texts to the LLM and ask it to decide whether to proceed with rechecking, as doing so would consume additional token budget and introduce new reasoning steps. Instead, we aggregate the outcome labels of the retrieved experience units. Intuitively, if rechecks on similar local reasoning patterns have rarely corrected errors in the past, continuing the current verification is unlikely to change the outcome. Concretely, we estimate the likelihood that a recheck is unnecessary as $$ \mathcal{P}_{\text{unnec}}=\frac{1}{k}\sum_{j=1}^{k}\mathbb{I}[y_{i_{j}}=1], \tag{2} $$ where $\mathbb{I}[\cdot]$ is the indicator function. If $\mathcal{P}_{\text{unnec}}$ exceeds a predefined threshold $\tau$ , we treat the current recheck as likely unnecessary. #### Experience-Driven Suppression (EDS) If a recheck is estimated to be unnecessary, we inject a short verification suppression signal immediately after the activation sentence (e.g., “This result does not require further checking, let me proceed to the next step.”) We observe that the specific wording of the verification suppression signal affects its effectiveness. Language models exhibit discourse-level attractors for resolving epistemic uncertainty (e.g., phrases such as “wait” or “maybe”), which can cause verification behavior to persist even after an initial interruption. In practice, suppression signals that explicitly assert epistemic closure (e.g., “is correct”) or provide a forward redirection (e.g., “proceed”) are more effective at closing verification-related discourse.. This signal serves as a lightweight directive that discourages the model from continuing the verification process and encourages it to proceed with subsequent reasoning steps. Empirically, we observe that after receiving such a suppression signal, the model typically skips subsequent re-computation or validation steps and proceeds directly to the next stage of reasoning. Importantly, this intervention targets only recheck behaviors; we do not intervene on rethink behaviors, which are often essential for solving hard problems. As shown in Section 5, suppressing redundant rechecks leads to a consistent reduction in reasoning length, which emerges naturally from avoiding unnecessary self-verification. ## 5 Experiments ### 5.1 Experiment Setups We evaluate the effectiveness of Experience-Driven Suppression (EDS) on five mathematical reasoning benchmarks: AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC23 (AMC12, 2023), MATH500 (Hendrycks et al., 2021), and Olympiad Bench (He et al., 2024). Experiments are conducted on three models: Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025). We compare three inference settings. Base: standard model inference without any intervention. Full-suppress: injecting a suppression signal whenever a recheck activation is identified. First Try Matters (FTM) (Kang et al., 2025), a test-time method truncates the thinking immediately after the first candidate final answer is produced. EDS applies selective suppression within the thinking process: mid-rechecks are suppressed only when historical experience indicates that the verification is unlikely to be beneficial. For EDS, we construct the experience pool using reasoning rollouts collected from the Deepscaler dataset (Luo et al., 2025), which consists of AIME and AMC problems prior to 2023. Using GPT-5 We use the model gpt-5-2025-08-07. (OpenAI et al., 2025), we extract recheck activation set $\mathcal{S}$ and annotate whether each recheck is necessary or unnecessary, resulting in an experience pool of 10k units with an unnecessary-to-necessary ratio of approximately 7:3. Recheck activations during inference are detected using a RoBERTa-base (Liu et al., 2019). The classifier is trained on 4,245 instances derived from $\mathcal{S}$ , with a positive-to-negative ratio of 1:3 and a balanced split between hard and easy negatives. Easy negatives are uniformly sampled from non-verification sentences in the original rollouts. We train the classifier for 3 epochs with a learning rate of 2e-5, achieving 97% accuracy on the test split. During EDS inference, we retrieve the top-30 most similar experience units using BM25 (Robertson & Zaragoza, 2009) and suppress a recheck if the proportion of unnecessary experiences exceeds a threshold $\tau=0.8$ . This threshold is set above the base unnecessary rate of the experience pool (0.7). ### 5.2 Main Restuls Table 1 reports accuracy and average length. Across all models and datasets, full-suppress consistently shortens reasoning traces, reducing average length by approximately 11–13%. However, this intervention leads to noticeable accuracy degradation, with average drops ranging from $-1.4$ to $-2.5$ points. FTM achieves substantially larger reductions in reasoning length by truncating all content following the first candidate answer. While effective in reducing token usage, this aggressive truncation incurs a pronounced accuracy drop. In particular, for Qwen3-8B, FTM reduces average reasoning length up to 30% but degrades accuracy by $-3.8$ points. This suggests that their truncation may discard rethink behaviors, which play a crucial role in reasoning and should not be indiscriminately removed. In contrast, EDS targets redundant recheck behaviors while excluding rethink cases from suppression. EDS achieves consistent reductions in reasoning length while maintaining (in many cases improving) accuracy relative to the base model. For Qwen3-8B and QwQ-32B, EDS improves average accuracy by +0.48 and +0.57 points respectively, while shortening reasoning traces by approximately 9% on average and up to 20.3% on MATH500. These results indicate that leveraging historical verification outcomes provides a reliable signal for estimating when a recheck is unlikely to be beneficial, enabling selective suppression without materially affecting correctness. Overall, the results indicate that reflections are neither uniformly harmful nor uniformly necessary. While truncating reflection wholesale (as in FTM) can substantially reduce token, it risks removing rethink and necessary recheck behaviors. By selectively suppressing rechecks based on prior experience, EDS enables models to bypass unnecessary rechecks while preserving self-verification steps that meaningfully contribute to correctness, achieving a more favorable accuracy–efficiency trade-off. ### 5.3 Accuracy–Efficiency Trade-off <details> <summary>Figs/threshold_accuracy.png Details</summary>  ### Visual Description ## Line Graph: Pass@1 Accuracy vs. Threshold ### Overview The image depicts a line graph illustrating the relationship between a "Threshold" (x-axis) and "Pass@1 Accuracy" (y-axis). The blue line shows fluctuations in accuracy across threshold values from 0.0 to 1.0, with an overall upward trend toward higher thresholds. ### Components/Axes - **X-axis (Threshold)**: Labeled "Threshold," scaled from 0.0 to 1.0 in increments of 0.1. - **Y-axis (Pass@1 Accuracy)**: Labeled "Pass@1 Accuracy," scaled from 0.70 to 0.75 in increments of 0.01. - **Legend**: No explicit legend is visible in the image. The blue line is assumed to represent "Pass@1 Accuracy" based on axis labels and color coding. - **Grid**: A light gray grid overlays the plot for reference. ### Detailed Analysis - **Data Points**: - (0.0, ~0.705) - (0.1, ~0.710) - (0.2, ~0.703) - (0.3, ~0.714) - (0.4, ~0.712) - (0.5, ~0.716) - (0.6, ~0.722) - (0.7, ~0.716) - (0.8, ~0.729) - (0.9, ~0.740) - (0.95, ~0.739) - (1.0, ~0.745) - **Line Behavior**: The blue line exhibits a jagged upward trend, with notable dips at thresholds 0.2, 0.4, 0.7, and 0.95. The steepest increase occurs between thresholds 0.8 and 1.0. ### Key Observations 1. **Initial Fluctuations**: The line starts at ~0.705, rises to 0.710 at 0.1, then dips to 0.703 at 0.2, suggesting sensitivity to low thresholds. 2. **Mid-Range Stability**: Between thresholds 0.3 and 0.7, accuracy stabilizes between ~0.712 and 0.722, with minor oscillations. 3. **Final Surge**: A sharp increase from 0.729 (threshold 0.8) to 0.745 (threshold 1.0) dominates the latter half, with a brief dip at 0.95 (~0.739). 4. **Peak Accuracy**: The highest accuracy (~0.745) is achieved at the maximum threshold (1.0). ### Interpretation The data suggests that increasing the threshold generally improves Pass@1 Accuracy, though with notable variability. The peak at threshold 1.0 indicates optimal performance at the highest setting, but the dip at 0.95 raises questions about potential overfitting or noise in the data near the upper threshold range. The fluctuations at lower thresholds may reflect class imbalance or model instability in early decision boundaries. The overall trend implies that higher thresholds prioritize precision over recall, aligning with typical trade-offs in classification models. </details> (a) Pass@1 <details> <summary>Figs/threshold_length_reduction.png Details</summary>  ### Visual Description ## Line Graph: Length Reduction vs. Threshold ### Overview The image depicts a line graph illustrating the relationship between a "Threshold" (x-axis) and "Length Reduction (%)" (y-axis). The blue line shows a gradual decline followed by a sharp drop as the threshold increases from 0.0 to 1.0. ### Components/Axes - **X-axis (Threshold)**: Labeled "Threshold," scaled from 0.0 to 1.0 in increments of 0.2. - **Y-axis (Length Reduction %)**: Labeled "Length Reduction (%)", scaled from 0 to 12 in increments of 2. - **Legend**: No explicit legend is visible in the image. - **Line**: A single blue line represents the data series, with circular markers at each data point. ### Detailed Analysis - **Initial Trend (Threshold 0.0–0.8)**: The line remains relatively flat, hovering between **12.5% and 12.8%** length reduction. - **Sharp Decline (Threshold 0.8–1.0)**: At a threshold of **0.8**, the line drops abruptly to **~5.5%**, then plunges to **~0.5%** at **1.0**. ### Key Observations 1. **Plateau Effect**: The length reduction remains stable until the threshold exceeds **0.8**. 2. **Threshold Sensitivity**: A critical threshold of **0.8–1.0** triggers a near-complete loss of length reduction. 3. **Data Point Precision**: Values are approximate due to the absence of gridlines or exact numerical labels on the line. ### Interpretation The graph suggests a **threshold-dependent mechanism** where increasing the threshold beyond **0.8** causes a dramatic reduction in effectiveness. This could indicate a tipping point in a system (e.g., material stress, biological response, or algorithmic performance) where small changes in input (threshold) lead to disproportionate outcomes. The flat region implies robustness or insensitivity to threshold variations below **0.8**, while the steep decline highlights vulnerability or failure at higher thresholds. The absence of a legend or additional context limits interpretation of the threshold's real-world meaning (e.g., temperature, concentration, etc.). </details> (b) Length reduction (%) Figure 5: Accuracy–efficiency trade-off. <details> <summary>Figs/avg_count.png Details</summary>  ### Visual Description ## Horizontal Bar Chart: Weak vs. Strong Category Performance ### Overview The chart compares two categories ("Weak" and "Strong") across two metrics: "Loop" (pink) and "Successful" (green). The x-axis represents "Average Count" (0–40), while the y-axis lists the categories. The legend is positioned in the top-right corner. ### Components/Axes - **Y-Axis (Categories)**: - "Weak" (top) - "Strong" (bottom) - **X-Axis (Values)**: - Labeled "Average Count" with increments of 5 (0, 5, 10, ..., 40). - **Legend**: - Pink = "Loop" - Green = "Successful" - Positioned in the top-right corner. ### Detailed Analysis - **Weak Category**: - **Loop (Pink)**: Bar length ≈ 4 units (x-axis value ~4). - **Successful (Green)**: Bar length ≈ 25 units (x-axis value ~25). - **Strong Category**: - **Loop (Pink)**: Bar length ≈ 4 units (x-axis value ~4). - **Successful (Green)**: Bar length ≈ 34 units (x-axis value ~34). ### Key Observations 1. **Loop Consistency**: Both "Weak" and "Strong" categories have identical "Loop" values (~4). 2. **Success Disparity**: The "Successful" metric increases from ~25 (Weak) to ~34 (Strong), a ~9-unit difference. 3. **Proportionality**: The "Successful" bar dominates the chart for both categories, occupying ~80–90% of the total bar length. ### Interpretation The data suggests that the "Strong" category correlates with significantly higher success rates compared to "Weak," while the "Loop" metric remains constant across categories. This implies that the "Strength" of the category is a critical factor in determining success, whereas the "Loop" metric may represent a baseline or control variable. The chart emphasizes the importance of category strength in achieving favorable outcomes, with no notable outliers or anomalies observed. </details> Figure 6: Average recheck activation count per rollout. Figure 5 illustrates how the behavior of EDS varies as we adjust the voting threshold $\tau$ , which controls how confidently a recheck must be judged unnecessary before suppression is applied. Increasing $\tau$ makes suppression more conservative, resulting in fewer rechecks being filtered. As shown in Figure 5, accuracy increases steadily with larger $\tau$ and saturates around $\tau\approx 0.95$ , as higher thresholds reduce the likelihood of suppressing rechecks that could be corrective. In contrast, length reduction decreases as $\tau$ increases. In particular, when $\tau$ lies in the range $0.7\leq\tau\leq 0.9$ , length reduction drops rapidly. Together, these trends reveal a clear accuracy–efficiency trade-off: lower thresholds favor stronger suppression and greater reductions in reasoning length, while higher thresholds preserve more verification behavior and yield higher accuracy. This trade-off allows EDS to be flexibly configured according to the desired balance between computational efficiency and reasoning reliability. ### 5.4 Case study <details> <summary>Figs/case.png Details</summary>  ### Visual Description ## Screenshot: Geometry Problem Analysis with Annotations ### Overview The image is a screenshot of a geometry problem analysis divided into three sections: "No Intervention," "Strong Signal," and "Weak Signal." Each section contains textual reasoning about triangle similarity, annotated with color-coded highlights, arrows, and injected signals. The annotations suggest iterative verification or feedback mechanisms in the reasoning process. ### Components/Axes - **Sections**: 1. **No Intervention**: Text discussing triangle similarity without annotations. 2. **Strong Signal**: Text with a red-highlighted note ("This result does not require further checking") and an injected signal. 3. **Weak Signal**: Text with multiple red-highlighted notes and injected signals, ending in a loop. - **Annotations**: - **Red boxes**: Highlight specific text segments (e.g., "Let me check that"). - **Arrows**: Labeled "Activation of recheck" (blue text) pointing to injected signals. - **Injected signals**: Blue text within red boxes (e.g., "Injected signal"). - **Text Colors**: - Primary text: Black. - Highlighted text: Red. - Injected signals: Blue. - Notes: Orange. ### Detailed Analysis #### No Intervention Section - Text discusses triangle similarity (e.g., "triangle ABD ~ triangle ACB" via AA similarity). - No annotations or injected signals. #### Strong Signal Section - Text mirrors the "No Intervention" section but includes: - A red-highlighted note: "This result does not require further checking, let me proceed to the next step." - An injected signal labeled "Injected signal" (blue text) with an arrow labeled "Activation of recheck." - The injected signal suggests a system intervention to confirm correctness. #### Weak Signal Section - Text repeats the similarity reasoning but includes: - Multiple red-highlighted notes (e.g., "No need to check," "Wait, but let me check the similarity"). - Three injected signals labeled "Injected signal" (blue text) with arrows labeled "Activation of recheck." - A loop at the end: "(Loop)." - The annotations imply uncertainty and repeated verification attempts. ### Key Observations 1. **Repetition of Text**: All sections share identical core reasoning about triangle similarity, suggesting a focus on iterative validation. 2. **Signal Strength**: - **Strong Signal**: Confident conclusion with minimal rechecking. - **Weak Signal**: Uncertainty requiring multiple rechecks and a cyclical process. 3. **Annotations**: Arrows and injected signals indicate a feedback loop or automated verification system. ### Interpretation The annotations and injected signals imply a structured reasoning process where: - **No Intervention**: Represents unassisted, linear reasoning. - **Strong Signal**: Indicates a system that confidently validates conclusions, reducing rechecks. - **Weak Signal**: Reflects a system struggling with uncertainty, requiring repeated validation and looping back to earlier steps. The use of "Injected signal" and "Activation of recheck" suggests an external mechanism (e.g., AI or automated tool) intervening to guide or correct the reasoning process. The loop in the "Weak Signal" section highlights inefficiency or ambiguity in the problem-solving approach. This analysis underscores the importance of signal strength in automated reasoning systems, where confidence levels directly impact the need for iterative verification. </details> Figure 7: Success and failure cases. To qualitatively illustrate how verification suppression affects model behavior, Figure 7 presents representative examples under three settings: no intervention, strong suppression, and weak suppression. Without intervention, once a recheck is triggered, the model typically proceeds with explicit verification. Injecting a strong suppression signal that asserts epistemic closure and provides forward redirection reliably terminates the verification process. The model accepts the signal as closing the uncertainty and continues with subsequent reasoning. In contrast, weak suppression signals fail to close the verification discourse and may instead provoke repeated recheck attempts, leading to activation loops in which verification is repeatedly re-initiated. Figure 6 shows that strong signals achieve a higher rate of successful suppression, although looping still occurs. To further stabilize suppression in practice, we introduce a simple cooldown mechanism: after a suppression is applied, recheck detection is temporarily disabled for 3 steps, preventing immediate re-activation of verification. ## 6 Conclusion We revisit reflection in LRMs through the lens of self-verification, and show it is dominated by repeated rechecks that rarely alter downstream reasoning, exposing a mismatch between verification frequency and utility. Without modifying model parameters, we propose an experience-driven test-time controller that detects recheck activations, retrieves similar past verification episodes from an offline pool, and selectively suppresses low-utility checks while preserving strategy-level rethinking. Our method consistently shortens reasoning while maintaining or slightly improving accuracy across models and benchmarks, suggesting that past verification outcomes can guide when verifications are needed. ## Impact Statement This paper presents work whose goal is to advance the field of machine learning by improving the efficiency and controllability of test-time reasoning in LLMs. By reducing redundant self-verification while maintaining solution quality, the proposed approach can lower inference-time compute and latency, enabling more scalable deployment of reliable reasoning models and broader access to such capabilities across resource-constrained settings. We anticipate the primary impacts of this work to be increased energy efficiency and cost-effectiveness of model inference, as well as a clearer methodological foundation for understanding and optimizing reflective behaviors in reasoning. ## References - AIME (2025) AIME. AIME Problems and Solutions, 2025. https://artofproblemsolving.com/wiki/index.php/AIME_Problems_and_Solutions, 2025. Accessed: January 19, 2026. - AMC12 (2023) AMC12. AMC 12 Problems and Solutions. https://artofproblemsolving.com/wiki/index.php/AMC_12_Problems_and_Solutions, 2023. Accessed: January 19, 2026. - Bercovich et al. (2025) Bercovich, A., Levy, I., Golan, I., Dabbah, M., El-Yaniv, R., Puny, O., Galil, I., Moshe, Z., Ronen, T., Nabwani, N., Shahaf, I., Tropp, O., Karpas, E., Zilberstein, R., Zeng, J., Singhal, S., Bukharin, A., Zhang, Y., et al. Llama-nemotron: Efficient reasoning models, 2025. URL https://arxiv.org/abs/2505.00949. - DeepSeek-AI et al. (2025) DeepSeek-AI, Guo, D., Yang, D., Zhang, H., Song, J., Zhang, R., Xu, R., Zhu, Q., Ma, S., Wang, P., et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning, 2025. URL https://arxiv.org/abs/2501.12948. - Didolkar et al. (2025) Didolkar, A., Ballas, N., Arora, S., and Goyal, A. Metacognitive reuse: Turning recurring llm reasoning into concise behaviors, 2025. URL https://arxiv.org/abs/2509.13237. - Fang et al. (2025) Fang, G., Ma, X., and Wang, X. Thinkless: Llm learns when to think. Advances in neural information processing systems, 2025. - He et al. (2024) He, C., Luo, R., Bai, Y., Hu, S., Thai, Z. L., Shen, J., Hu, J., Han, X., Huang, Y., Zhang, Y., et al. Olympiadbench: A challenging benchmark for promoting agi with olympiad-level bilingual multimodal scientific problems. arXiv preprint arXiv:2402.14008, 2024. URL https://aclanthology.org/2024.acl-long.211/. - Hendrycks et al. (2021) Hendrycks, D., Burns, C., Kadavath, S., Arora, A., Basart, S., Tang, E., Song, D., and Steinhardt, J. Measuring mathematical problem solving with the math dataset. arXiv preprint arXiv:2103.03874, 2021. URL https://arxiv.org/abs/2103.03874. - Hu et al. (2025) Hu, M., Chen, T., Chen, Q., Mu, Y., Shao, W., and Luo, P. HiAgent: Hierarchical working memory management for solving long-horizon agent tasks with large language model. In Che, W., Nabende, J., Shutova, E., and Pilehvar, M. T. (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 32779–32798, Vienna, Austria, July 2025. Association for Computational Linguistics. ISBN 979-8-89176-251-0. doi: 10.18653/v1/2025.acl-long.1575. URL https://aclanthology.org/2025.acl-long.1575/. - Jiang et al. (2025) Jiang, L., Wu, X., Huang, S., Dong, Q., Chi, Z., Dong, L., Zhang, X., Lv, T., Cui, L., and Wei, F. Think only when you need with large hybrid-reasoning models. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=fDjDVE4qdj. - Kang et al. (2025) Kang, L., Deng, Y., Xiao, Y., Mo, Z., Lee, W. S., and Bing, L. First try matters: Revisiting the role of reflection in reasoning models, 2025. URL https://arxiv.org/abs/2510.08308. - Langley (2000) Langley, P. Crafting papers on machine learning. In Langley, P. (ed.), Proceedings of the 17th International Conference on Machine Learning (ICML 2000), pp. 1207–1216, Stanford, CA, 2000. Morgan Kaufmann. - Li et al. (2025) Li, X., Dong, G., Jin, J., Zhang, Y., Zhou, Y., Zhu, Y., Zhang, P., and Dou, Z. Search-o1: Agentic search-enhanced large reasoning models, 2025. URL https://arxiv.org/abs/2501.05366. - Liu & Wang (2025) Liu, X. and Wang, L. Answer convergence as a signal for early stopping in reasoning. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 17896–17907, Suzhou, China, November 2025. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.904. URL https://aclanthology.org/2025.emnlp-main.904/. - Liu et al. (2019) Liu, Y., Ott, M., Goyal, N., Du, J., Joshi, M., Chen, D., Levy, O., Lewis, M., Zettlemoyer, L., and Stoyanov, V. Roberta: A robustly optimized BERT pretraining approach. CoRR, abs/1907.11692, 2019. URL http://arxiv.org/abs/1907.11692. - Liu et al. (2025a) Liu, Y., Si, C., Narasimhan, K. R., and Yao, S. Contextual experience replay for self-improvement of language agents. In Che, W., Nabende, J., Shutova, E., and Pilehvar, M. T. (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 14179–14198, Vienna, Austria, July 2025a. Association for Computational Linguistics. ISBN 979-8-89176-251-0. doi: 10.18653/v1/2025.acl-long.694. URL https://aclanthology.org/2025.acl-long.694/. - Liu et al. (2025b) Liu, Z., Chen, C., Li, W., Pang, T., Du, C., and Lin, M. There may not be aha moment in r1-zero-like training — a pilot study. [https://oatllm.notion.site/oat-zero](https://oatllm.notion.site/oat-zero), 2025b. Notion Blog. - Luo et al. (2025) Luo, M., Tan, S., Wong, J., Shi, X., Tang, W., Roongta, M., Cai, C., Luo, J., Zhang, T., Li, E., Popa, R. A., and Stoica, I. Deepscaler: Surpassing o1-preview with a 1.5b model by scaling rl. https://pretty-radio-b75.notion.site/DeepScaleR-Surpassing-O1-Preview-with-a-1-5B-Model-by-Scaling-RL-19681902c1468005bed8ca303013a4e2, 2025. Notion Blog. - MAA (2024) MAA. American Invitational Mathematics Examination (AIME) 2024. https://maa.org/math-competitions/american-invitational-mathematics-examination-aime, February 2024. Accessed: January 19, 2026. - Mao et al. (2025) Mao, M., Yin, B., Zhu, Y., and Fang, X. Early stopping chain-of-thoughts in large language models, 2025. URL https://arxiv.org/abs/2509.14004. - Ning et al. (2025) Ning, Y., Li, W., Fang, J., Tan, N., and Liu, H. Not all thoughts are generated equal: Efficient llm reasoning via multi-turn reinforcement learning, 2025. URL https://arxiv.org/abs/2505.11827. - OpenAI (2025) OpenAI. gpt-oss-120b & gpt-oss-20b model card, 2025. URL https://arxiv.org/abs/2508.10925. - OpenAI et al. (2024) OpenAI, :, Jaech, A., Kalai, A., Lerer, A., Richardson, A., El-Kishky, A., Low, A., Helyar, A., Madry, A., Beutel, A., Carney, A., Iftimie, A., Karpenko, A., Passos, A. T., Neitz, A., Prokofiev, A., Wei, A., Tam, A., Bennett, A., Kumar, A., Saraiva, A., Vallone, A., Duberstein, A., Kondrich, A., Mishchenko, A., et al. Openai o1 system card, 2024. URL https://arxiv.org/abs/2412.16720. - OpenAI et al. (2025) OpenAI, :, Singh, A., Fry, A., Perelman, A., Tart, A., Ganesh, A., El-Kishky, A., McLaughlin, A., Low, A., Ostrow, A., Ananthram, A., Nathan, A., Luo, A., Helyar, A., Madry, A., Efremov, A., Spyra, A., Baker-Whitcomb, A., Beutel, A., Karpenko, A., Makelov, A., Neitz, A., Wei, A., Barr, A., Kirchmeyer, A., Ivanov, A., Christakis, A., Gillespie, A., Tam, A., Bennett, A., Wan, A., Huang, A., Sandjideh, A. M., Yang, A., et al. Openai gpt-5 system card, 2025. URL https://arxiv.org/abs/2601.03267. - Robertson & Zaragoza (2009) Robertson, S. E. and Zaragoza, H. The probabilistic relevance framework: BM25 and beyond. Found. Trends Inf. Retr., pp. 333–389, 2009. - Shen et al. (2025) Shen, Y., Zhang, J., Huang, J., Shi, S., Zhang, W., Yan, J., Wang, N., Wang, K., Liu, Z., and Lian, S. DAST: Difficulty-adaptive slow-thinking for large reasoning models. In Potdar, S., Rojas-Barahona, L., and Montella, S. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track, pp. 2322–2331, Suzhou (China), November 2025. Association for Computational Linguistics. ISBN 979-8-89176-333-3. doi: 10.18653/v1/2025.emnlp-industry.160. URL https://aclanthology.org/2025.emnlp-industry.160/. - Sui et al. (2025) Sui, Y., Chuang, Y.-N., Wang, G., Zhang, J., Zhang, T., Yuan, J., Liu, H., Wen, A., Zhong, S., Chen, H., and Hu, X. Stop overthinking: A survey on efficient reasoning for large language models, 2025. URL https://arxiv.org/abs/2503.16419. - Team (2025) Team, Q. Qwq-32b: Embracing the power of reinforcement learning, March 2025. URL https://qwenlm.github.io/blog/qwq-32b/. - Wang et al. (2025a) Wang, J., Guo, Z., Ma, W., and Zhang, M. How far can LLMs improve from experience? measuring test-time learning ability in LLMs with human comparison. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 25677–25691, Suzhou, China, November 2025a. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.1304. URL https://aclanthology.org/2025.emnlp-main.1304/. - Wang et al. (2025b) Wang, Y., Liu, J., Zhang, S., Chen, J., and Huang, S. Pats: Process-level adaptive thinking mode switching, 2025b. URL https://arxiv.org/abs/2505.19250. - Wu et al. (2025) Wu, S., Xie, J., Zhang, Y., Chen, A., Zhang, K., Su, Y., and Xiao, Y. ARM: Adaptive reasoning model. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=z9oeQrcNh9. - Yang et al. (2025a) Yang, A., Li, A., Yang, B., Zhang, B., Hui, B., Zheng, B., Yu, B., Gao, C., Huang, C., Lv, C., et al. Qwen3 technical report. arXiv preprint arXiv:2505.09388, 2025a. URL https://arxiv.org/abs/2505.09388. - Yang et al. (2025b) Yang, S., Wu, J., Chen, X., Xiao, Y., Yang, X., Wong, D. F., and Wang, D. Understanding aha moments: from external observations to internal mechanisms, 2025b. URL https://arxiv.org/abs/2504.02956. - Yufei Xiang & Nguyen (2024) Yufei Xiang, Yiqun Shen, Y. Z. and Nguyen, C.-T. Retrospex: Language agent meets offline reinforcement learning critic. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, EMNLP, 2024. - Zeng et al. (2025) Zeng, Z., Huang, X., Li, B., Zhang, H., and Deng, Z. Done is better than perfect: Unlocking efficient reasoning by structured multi-turn decomposition, 2025. URL https://arxiv.org/abs/2505.19788. - Zhai et al. (2025) Zhai, Y., Tao, S., Chen, C., Zou, A., Chen, Z., Fu, Q., Mai, S., Yu, L., Deng, J., Cao, Z., Liu, Z., Ding, B., and Zhou, J. Agentevolver: Towards efficient self-evolving agent system, 2025. URL https://arxiv.org/abs/2511.10395. - Zhang et al. (2025a) Zhang, J., Lin, N., Hou, L., Feng, L., and Li, J. AdaptThink: Reasoning models can learn when to think. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 3716–3730, Suzhou, China, November 2025a. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.184. URL https://aclanthology.org/2025.emnlp-main.184/. - Zhang et al. (2026) Zhang, S., Wu, J., Chen, J., Zhang, C., Li, Z., Lou, X., Zhou, W., Zhou, S., Wang, C., and Wang, J. Othink-r1: Intrinsic fast/slow thinking mode switching for over-reasoning mitigation, 2026. URL https://arxiv.org/abs/2506.02397. - Zhang et al. (2025b) Zhang, X., Ruan, J., Ma, X., Zhu, Y., Zhao, H., Li, H., Chen, J., Zeng, K., and Cai, X. When to continue thinking: Adaptive thinking mode switching for efficient reasoning. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Findings of the Association for Computational Linguistics: EMNLP 2025, pp. 5808–5828, Suzhou, China, November 2025b. Association for Computational Linguistics. ISBN 979-8-89176-335-7. doi: 10.18653/v1/2025.findings-emnlp.310. URL https://aclanthology.org/2025.findings-emnlp.310/. - Zhao et al. (2024) Zhao, A., Huang, D., Xu, Q., Lin, M., Liu, Y.-J., and Huang, G. Expel: Llm agents are experiential learners. In Wooldridge, M. J., Dy, J. G., and Natarajan, S. (eds.), Thirty-Eighth AAAI Conference on Artificial Intelligence, AAAI 2024, Thirty-Sixth Conference on Innovative Applications of Artificial Intelligence, IAAI 2024, Fourteenth Symposium on Educational Advances in Artificial Intelligence, EAAI 2024, February 20-27, 2024, Vancouver, Canada, pp. 19632–19642. AAAI Press, 2024. doi: 10.1609/aaai.v38i17.29936. URL https://ojs.aaai.org/index.php/AAAI/article/view/29936. - Zhao et al. (2025) Zhao, H., Yan, Y., Shen, Y., Xu, H., Zhang, W., Song, K., Shao, J., Lu, W., Xiao, J., and Zhuang, Y. Let LRMs break free from overthinking via self-braking tuning. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=u3a2AX0icx. ## Appendix A Benchmark Statistics Table 2: Statistics of Datasets and Rollouts | AIME24 AIME25 AMC23 | 30 30 40 | 16 16 4 | 480 480 160 | | --- | --- | --- | --- | | MATH500 | 500 | 1 | 500 | | Olympiad Bench | 674 | 1 | 674 | | Total | 1317 | - | 2294 | ## Appendix B Reflection Type Statistics <details> <summary>Figs/reflection_pie_charts_all_models.png Details</summary>  ### Visual Description ## Grid of Pie Charts: Model Performance Across Datasets and Categories ### Overview The image displays a 4x4 grid of pie charts comparing model performance across four datasets (AIME24, AIME25, AMC, MATH500) and four categories (gpt-oss-20b, DeepSeek-R1-Distill-Qwen-7B, Qwen3-8B, QwQ-32B). Each pie chart is divided into four colored segments representing: - **Green**: Unnecessary Rechecks - **Yellow**: Necessary Rechecks - **Red**: Rethinks - **Blue**: Unable to Classify ### Components/Axes - **X-axis (Categories)**: - Top row: gpt-oss-20b - Second row: DeepSeek-R1-Distill-Qwen-7B - Third row: Qwen3-8B - Bottom row: QwQ-32B - **Y-axis (Datasets)**: - Left column: AIME24 - Second column: AIME25 - Third column: AMC - Right column: MATH500 - **Legend**: Located at the bottom, with color mappings: - Green = Unnecessary Rechecks - Yellow = Necessary Rechecks - Red = Rethinks - Blue = Unable to Classify ### Detailed Analysis #### Dataset: AIME24 - **gpt-oss-20b**: - Unnecessary Rechecks: 46.5% (green) - Rethinks: 39.1% (red) - Necessary Rechecks: 10.1% (yellow) - Unable to Classify: 4.2% (blue) - **DeepSeek-R1-Distill-Qwen-7B**: - Unnecessary Rechecks: 28.9% (green) - Rethinks: 54.4% (red) - Necessary Rechecks: 7.7% (yellow) - Unable to Classify: 9.0% (blue) - **Qwen3-8B**: - Unnecessary Rechecks: 35.5% (green) - Rethinks: 49.7% (red) - Necessary Rechecks: 5.2% (yellow) - Unable to Classify: 9.7% (blue) - **QwQ-32B**: - Unnecessary Rechecks: 29.5% (green) - Rethinks: 46.6% (red) - Necessary Rechecks: 4.7% (yellow) - Unable to Classify: 19.2% (blue) #### Dataset: AIME25 - **gpt-oss-20b**: - Unnecessary Rechecks: 45.4% (green) - Rethinks: 40.8% (red) - Necessary Rechecks: 9.2% (yellow) - Unable to Classify: 4.6% (blue) - **DeepSeek-R1-Distill-Qwen-7B**: - Unnecessary Rechecks: 31.2% (green) - Rethinks: 50.2% (red) - Necessary Rechecks: 8.2% (yellow) - Unable to Classify: 10.4% (blue) - **Qwen3-8B**: - Unnecessary Rechecks: 38.7% (green) - Rethinks: 39.8% (red) - Necessary Rechecks: 4.8% (yellow) - Unable to Classify: 16.8% (blue) - **QwQ-32B**: - Unnecessary Rechecks: 30.1% (green) - Rethinks: 37.7% (red) - Necessary Rechecks: 4.6% (yellow) - Unable to Classify: 27.6% (blue) #### Dataset: AMC - **gpt-oss-20b**: - Unnecessary Rechecks: 59.5% (green) - Rethinks: 25.2% (red) - Necessary Rechecks: 9.9% (yellow) - Unable to Classify: 5.4% (blue) - **DeepSeek-R1-Distill-Qwen-7B**: - Unnecessary Rechecks: 39.7% (green) - Rethinks: 43.5% (red) - Necessary Rechecks: 8.3% (yellow) - Unable to Classify: 8.4% (blue) - **Qwen3-8B**: - Unnecessary Rechecks: 49.9% (green) - Rethinks: 39.8% (red) - Necessary Rechecks: 4.2% (yellow) - Unable to Classify: 6.2% (blue) - **QwQ-32B**: - Unnecessary Rechecks: 48.6% (green) - Rethinks: 40.5% (red) - Necessary Rechecks: 3.7% (yellow) - Unable to Classify: 7.2% (blue) #### Dataset: MATH500 - **gpt-oss-20b**: - Unnecessary Rechecks: 56.5% (green) - Rethinks: 29.9% (red) - Necessary Rechecks: 6.9% (yellow) - Unable to Classify: 6.8% (blue) - **DeepSeek-R1-Distill-Qwen-7B**: - Unnecessary Rechecks: 38.3% (green) - Rethinks: 46.2% (red) - Necessary Rechecks: 6.8% (yellow) - Unable to Classify: 8.6% (blue) - **Qwen3-8B**: - Unnecessary Rechecks: 52.8% (green) - Rethinks: 38.6% (red) - Necessary Rechecks: 3.2% (yellow) - Unable to Classify: 5.4% (blue) - **QwQ-32B**: - Unnecessary Rechecks: 49.6% (green) - Rethinks: 39.8% (red) - Necessary Rechecks: 3.3% (yellow) - Unable to Classify: 7.3% (blue) ### Key Observations 1. **Unnecessary Rechecks Dominance**: - The **gpt-oss-20b** category consistently shows the highest Unnecessary Rechecks across all datasets (e.g., 59.5% in AMC). - **QwQ-32B** models exhibit the lowest Unnecessary Rechecks (29.5% in AIME24). 2. **Rethinks Variability**: - **DeepSeek-R1-Distill-Qwen-7B** has the highest Rethinks in AIME24 (54.4%) and AIME25 (50.2%). - **QwQ-32B** models show the lowest Rethinks (37.7% in AIME25). 3. **Unable to Classify Outliers**: - **QwQ-32B** in AIME25 has the highest "Unable to Classify" rate (27.6%), suggesting potential reliability issues. - **DeepSeek-R1-Distill-Qwen-7B** in AIME25 has the second-highest (10.4%). 4. **Necessary Rechecks**: - **QwQ-32B** models have the lowest Necessary Rechecks (3.2–4.8%), indicating fewer corrections. - **gpt-oss-20b** in AIME24 has the highest (10.1%). ### Interpretation - **Model Performance Trends**: - The **gpt-oss-20b** category prioritizes Unnecessary Rechecks, suggesting over-cautiousness or inefficiency in task resolution. - **DeepSeek-R1-Distill-Qwen-7B** models exhibit high Rethinks, indicating frequent self-correction or uncertainty. - **QwQ-32B** models show balanced performance but struggle with "Unable to Classify" in AIME25, hinting at task-specific limitations. - **Dataset-Specific Insights**: - **AMC** and **MATH500** datasets reveal higher Unnecessary Rechecks for **gpt-oss-20b**, possibly due to complexity or ambiguity in these tasks. - **AIME24** and **AIME25** datasets highlight **DeepSeek-R1-Distill-Qwen-7B**'s reliance on Rethinks, suggesting iterative refinement is critical for these benchmarks. - **Anomalies**: - The **QwQ-32B** model in AIME25 has an unusually high "Unable to Classify" rate (27.6%), which may indicate architectural or training gaps. - **Qwen3-8B** in AMC has the lowest Necessary Rechecks (4.2%), implying efficient task handling. This analysis underscores trade-offs between model architectures and their adaptability across datasets, with **gpt-oss-20b** favoring caution and **QwQ-32B** showing mixed reliability. </details> Figure 8: Proportion of reflection types for Qwen3-8B, QwQ-32B, Deepseek-R1-Distilled-Qwen-7B and gpt-oss-20b annotated by GPT-5 To investigate the semantic composition of reflection steps, we analyze four recent models—Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), gpt-oss-20b (OpenAI, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025) —across a diverse set of benchmarks, including AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC (AMC12, 2023), and MATH500 (Hendrycks et al., 2021). This setup allows us to examine how reflection behaviors vary across model scales and problem domains. From Figure 8, we observe a persistent inefficiency in self-verification behaviors across models and benchmarks. Specifically, the ratio of unnecessary rechecks to necessary rechecks remains consistently high. This pattern indicates a fundamental limitation of current chain-of-thought (CoT) paradigms: models exhibit difficulty in discerning when verification is warranted, leading to substantial computational overhead due to redundant verification steps. ## Appendix C Human Evaluation To evaluate the reliability of the LLM-based reflection classifier, we conducted a human evaluation on a random subset of 1,000 reflection steps. Each step was independently annotated by a human expert following the same reflection schema. We compared LLM and human annotations in terms of label distributions and computed both overall agreement and Cohen’s $\kappa$ to quantify alignment beyond chance. | Corrective Rechecks Confirmatory Rechecks Rethink | 54 (5.4%) 428 (42.8%) 518 (51.8%) | 48 (4.8%) 374 (37.4%) 489 (48.9%) | | --- | --- | --- | | Unable to Classify | - | 89 (8.9%) | Table 3: Distribution of reflection types in human and LLM annotations ( $n=1000$ ). Table 3 shows that the LLM’s predicted label distribution closely matches that of the human annotator across the primary reflection categories, with minor discrepancies attributable to the LLM’s additional “Unable to Classify” label. The confusion matrix in | Corrective Rechecks Confirmatory Rechecks Rethinks | 47 1 0 | 1 369 4 | 1 17 471 | 5 41 43 | | --- | --- | --- | --- | --- | | Unable to Classify | 0 | 0 | 0 | 0 | Table 4: Confusion matrix between human annotations (rows) and LLM predictions (columns) over 1,000 reflection steps. Table 4 further demonstrates that most disagreements occur between conceptually adjacent categories (e.g., corrective vs. confirmatory rechecks), indicating that misclassifications primarily arise from boundary ambiguity rather than systematic errors. Quantitatively, the LLM achieves an overall agreement of 88.7% with human annotations and a Cohen’s $\kappa$ of 0.81, suggesting strong concordance beyond chance. Notably, the model rarely confuses non-adjacent reflection types, reinforcing the semantic coherence of its predictions. These results indicate that the LLM provides an accurate and reliable approximation of expert judgment for reflection classification, supporting its use as an automated annotation tool in large-scale analyses. ## Appendix D Example Query Example (recheck activation and upper context) Then pairwise intersections: Numbers divisible by 3 and 23: lcm(3,23)=69. floor(2003 / 69). 69*29 = 2001, so floor(2003 / 69) = 29. Correct. Numbers divisible by 3 and 29: lcm(3,29)=87. floor(2003 / 87). 87*23 = 2001, so floor(2003 / 87) = 23. Correct. Numbers divisible by 3 and 2003: lcm(3,2003)= 3*2003. Since 3*2003 = 6009 ¿ 2003, floor(2003 / 6009)=0. Correct. Numbers divisible by 23 and 29: lcm(23,29)=667. floor(2003 / 667). 667*3 = 2001, so floor(2003 / 667)=3. Correct. Numbers divisible by 23 and 2003: lcm(23,2003)=23*2003, which is way larger than 2003, so 0. Correct. Numbers divisible by 29 and 2003: same, 0. Correct. So sum of pairwise intersections: 29 + 23 + 0 + 3 + 0 + 0 = 55. Correct. Then subtract 55 from 824: 824 - 55 = 769. Correct. Then triple intersections: Numbers divisible by 3,23,29: lcm(3,23,29)=3*23*29=2001. floor(2003 / 2001)=1. Correct. Other triplets: 3,23,2003: lcm=3*23*2003, which is way bigger than 2003, so 0. Similarly others. So total triple intersections: 1. So add 1: 769 + 1 = 770. Correct. Four-way intersection: 0. So total numbers not coprime: 770. Therefore, numbers coprime: 2003 - 770 = 1233. Wait, but let me check if that answer makes sense. Top-1 Example “Context”:{ So, subtract 55 from the previous total: 824 - 55 = 769. Now, add back the triple intersections. Numbers divisible by lcm(3,23,29) = 3*23*29 = 2001. floor(2003 / 2001) = 1. Numbers divisible by lcm(3,23,2003) = 3*23*2003, which is way larger than 2003, so 0. Similarly, numbers divisible by lcm(3,29,2003) = 3*29*2003, also larger than 2003, so 0. Numbers divisible by lcm(23,29,2003) = 23*29*2003, also larger than 2003, so 0. Therefore, the triple intersections sum up to 1 + 0 + 0 + 0 = 1. So we add 1: 769 + 1 = 770. Now, subtract the four-way intersection: numbers divisible by lcm(3,23,29,2003) = 3*23*29*2003, which is way larger than 2003, so floor(2003 / that number) = 0. Therefore, subtract 0: 770 - 0 = 770. Therefore, the total number of numbers not coprime to n is 770. Therefore, the number of numbers coprime to n is total numbers (2003) minus 770, which is 2003 - 770 = Wait, but hold on. Let me check my calculations again, because that seems a bit high. Let me verify each step again. First, total numbers: 2003. Correct. First part: numbers divisible by 3, 23, 29, or 2003: 667 + 87 + 69 + 1 = 824. Correct. Then subtract pairwise intersections: Numbers divisible by 3 & 23: 29. 3 & 29: 23. 3 & 2003: 0. 23 & 29: 3. 23 & 2003: 0. 29 & 2003: 0. Total pairwise: 29 + 23 + 0 + 3 + 0 + 0 = 55. Correct. So 824 - 55 = 769. Then add back triple intersections: Numbers divisible by 3, 23, 29: 2001. floor(2003 / 2001) = 1. The other triplets: 3,23,2003: floor(2003 / (3*23*2003)) = 0. Similarly others. So total triple intersections: 1. So 769 + 1 = 770. } “Label”:{ “Unnecesasry” } ## Appendix E Prompts Reflection Identifier Prompt # Reflection Step Classification Task **Task:** You are given a single step from a model’s reasoning process. **Goal:** Decide whether this step is a *reflection step*. — ## Core Rule (Strict) A step is a reflection **only if it explicitly refers to the model’s own reasoning process** and is about *monitoring, evaluating, or revising that reasoning.* It must clearly do **at least one** of the following: - Verify, check, audit, or critique earlier reasoning or results - Propose changing, reconsidering, or comparing approaches or strategies This must be about the **reasoning itself**, not the problem. — ## Required Signal The step should contain **explicit self-referential or metacognitive language**, such as: - ”I should check…” - ”This approach might be wrong…” - ”Let me reconsider…” - ”So far, my reasoning assumes…” - ”I may have made a mistake…” - ”Another strategy could be…” If it does **not** monitor or revise the reasoning process, it is **not** a reflection. — ## Not a Reflection (Always False) Do **not** classify as reflection if the step is mainly: - Solving the problem - Doing calculations, algebra, or transformations - Applying formulas, rules, or definitions - Deriving new results or conclusions - Explaining why a step works - Stating what to do next without evaluating the reasoning Even if it uses words like ”think”, ”so”, or ”therefore”, it is **not** a reflection unless it critiques or evaluates the reasoning itself. — ## Output Format (Strict) Output only: True or False No explanations. No extra text. Reflection Type Classifier Prompt You are an annotation assistant. You are given: - an earlier reasoning step - several later lines of context from the same reasoning trace - the reasoning step to be classified Your task is to classify the step. You must output exactly one label: a. Successful Correctness Repair Action b. Unsuccessful Correctness Repair Action c. Strategy Exploration d. Unable to classify Only output the single letter. — ## Core Concepts ### A. Correctness Repair Action (CRA) A step is a Correctness Repair Action IF AND ONLY IF: 1) There exists a prior calculation, result, assumption, bound, interpretation, or conclusion earlier in the trace. AND 2) The PURPOSE of the step is to evaluate whether that earlier calculation is correct or incorrect. AND 3) The step performs or initiates a verification action, such as: - recomputation - checking constraints - plugging values back in - testing cases - searching for counterexamples - validating optimality/minimality/maximality The action must be aimed at CONFIRMING or REFUTING a prior calculation/result. — ## B. Strategy Exploration A step is Strategy Exploration IF AND ONLY IF: 1) Its purpose is to propose, compare, or shift solution approaches. AND 2) It is NOT primarily verifying or refuting a prior belief. Examples: - proposing a new method - suggesting an alternative representation - reframing how to approach the problem — ## C. Successful vs Unsuccessful CRA (STRICT) ### ABSOLUTE RULE A step MUST NOT be labeled **Successful Correctness Repair Action** if the resulting calculation/result is the SAME as before. If the check confirms the earlier calculation/result, it is ALWAYS **Unsuccessful**. — ### Successful Correctness Repair Action (a) Label **a** if and only if ALL are true: 1) A prior calculation/result in the trace is objectively WRONG. 2) This step performs a genuine verification or repair attempt. 3) This step REVEALS the calculation/result is wrong. 4) The calculation/result is REPLACED with a correct one. 5) No new error is introduced. If any condition fails → not successful. Typical outcomes: - wrong value recomputed correctly - false assumption invalidated - flawed argument repaired — ### Unsuccessful Correctness Repair Action (b) Label **b** if ANY are true: - The prior calculation/result was actually correct. - The step checks something but the conclusion does NOT change. - The step fails to detect a real error. - The step checks the wrong thing. - The step introduces a new error. This explicitly includes: - rechecking and getting the same answer - confirming a correct result - reaffirming a wrong result Examples (b): - ”Let me recompute… I still get 70.” - ”Plugging it back in, it works.” - ”Double-checking confirms the previous conclusion.” — ## Lexical Guidance (non-binding) Verification signals: check, verify, double-check, recompute, re-calculate, plug in, test whether, confirm, see if this holds, counterexample Strategy signals: maybe, try, consider, alternatively, another approach, instead Lexical cues do NOT override outcome rules. — ## Final decision checklist (must follow): 1) Is this step trying to verify or repair a prior belief? - No →c or d 2) Is it proposing or comparing approaches rather than checking correctness? - Yes →c 3) Was there an actually wrong prior belief? - No →b 4) Did this step expose the error and replace it with a correct belief? - Yes →a - No →b — Only output: a, b, c, or d. Recheck Activation Extraction Prompt You are an annotation assistant. Your task is to extract ONLY sentences where the model checks, verifies, or attempts to falsify the correctness of something it has ALREADY stated. We annotate correctness repair actions. We do NOT annotate strategy exploration or forward reasoning. — Definition: Correctness Repair Action A sentence qualifies IF AND ONLY IF: 1) There exists a prior belief, result, assumption, bound, interpretation, or conclusion stated earlier in the rollout (explicitly or implicitly). 2) The sentence’s PURPOSE is to evaluate whether that earlier belief is CORRECT or INCORRECT. 3) The sentence performs or initiates a verification action, which may include: - re-computation - checking constraints - testing candidates - searching for counterexamples - validating optimality / minimality / maximality as long as these actions are used to CONFIRM or REFUTE a prior claim. — Lexical guidance (strong signals): Typical verification phrases: check, verify, double-check, re-check, confirm, re-calculate, recompute, plug in, test whether, see if this holds. If a sentence contains “maybe” or “let me” but does NOT explicitly reference checking correctness (e.g., check / verify / confirm / see if this holds), do NOT annotate it. And do NOT annotate conclusion sentences before starting to check. — Examples (annotate these): 1. Re-computation (explicitly redoing a prior step) - ”Wait, let me compute this again carefully.” - ”Let me double-check the arithmetic here.” 2. Checking constraints (validating a prior result against conditions) - ”Let me check if this satisfies the constraint that X and Y must be inside the square.” - ”Let me plug this back into the equation to see if it works.” 3. Testing candidates (verifying a prior claim via examples or nearby cases) - ”Let me test a few cases around this value to confirm it’s maximal.” - ”Let me try a couple of examples to see if this holds.” 4. Searching for counterexamples (attempting to falsify a prior claim) - ”Let me see if I can find a counterexample.” - ”Let me check if this ever breaks down.” 5. Validating optimality / minimality / maximality - ”Let me check if this is indeed the minimum.” - ”Let me verify that no other placement yields a smaller value.” — Do NOT annotate: - Summaries, conclusions: “Therefore, the answer should be…”, ”Therefore, this suggests…” - Strategy shifts or planning: “To solve the prblem, maybe try…”, “Alternatively, consider…” - Idea generation without correctness intent: “Maybe there is a larger number…” - Forward computation stated for the first time: “Compute…”, “We obtain…”, “Thus…” - Meta-cognition without verification: “Let me think again.” — Extraction rules: - Copy the sentence EXACTLY as it appears in the rollout. - Do NOT annotate fragments or partial clauses. - Do NOT paraphrase, invent, or duplicate sentences. Recheck Activation Extraction Prompt You are an annotation assistant. Your task is to extract ONLY sentences where the model checks, verifies, or attempts to falsify the correctness of something it has ALREADY stated. We annotate correctness repair actions. We do NOT annotate strategy exploration or forward reasoning. — Definition: Correctness Repair Action A sentence qualifies IF AND ONLY IF: 1) There exists a prior belief, result, assumption, bound, interpretation, or conclusion stated earlier in the rollout (explicitly or implicitly). 2) The sentence’s PURPOSE is to evaluate whether that earlier belief is CORRECT or INCORRECT. 3) The sentence performs or initiates a verification action, which may include: - re-computation - checking constraints - testing candidates - searching for counterexamples - validating optimality / minimality / maximality as long as these actions are used to CONFIRM or REFUTE a prior claim. — Lexical guidance (strong signals): Typical verification phrases: check, verify, double-check, re-check, confirm, re-calculate, recompute, plug in, test whether, see if this holds. If a sentence contains “maybe” or “let me” but does NOT explicitly reference checking correctness (e.g., check / verify / confirm / see if this holds), do NOT annotate it. And do NOT annotate conclusion sentences before starting to check. — Examples (annotate these): 1. Re-computation (explicitly redoing a prior step) - ”Wait, let me compute this again carefully.” - ”Let me double-check the arithmetic here.” 2. Checking constraints (validating a prior result against conditions) - ”Let me check if this satisfies the constraint that X and Y must be inside the square.” - ”Let me plug this back into the equation to see if it works.” 3. Testing candidates (verifying a prior claim via examples or nearby cases) - ”Let me test a few cases around this value to confirm it’s maximal.” - ”Let me try a couple of examples to see if this holds.” 4. Searching for counterexamples (attempting to falsify a prior claim) - ”Let me see if I can find a counterexample.” - ”Let me check if this ever breaks down.” 5. Validating optimality / minimality / maximality - ”Let me check if this is indeed the minimum.” - ”Let me verify that no other placement yields a smaller value.” — Do NOT annotate: - Summaries, conclusions: “Therefore, the answer should be…”, ”Therefore, this suggests…” - Strategy shifts or planning: “To solve the prblem, maybe try…”, “Alternatively, consider…” - Idea generation without correctness intent: “Maybe there is a larger number…” - Forward computation stated for the first time: “Compute…”, “We obtain…”, “Thus…” - Meta-cognition without verification: “Let me think again.” — Extraction rules: - Copy the sentence EXACTLY as it appears in the rollout. - Do NOT annotate fragments or partial clauses. - Do NOT paraphrase, invent, or duplicate sentences. Recheck Filtering Prompt You are a strict binary classifier. Task: Given ONE sentence from an LLM rollout, decide whether this sentence is a ”correctness repair action onset”: It explicitly initiates or performs a CHECK / VERIFICATION / FALSIFICATION of correctness (including re-computation, checking constraints, testing candidates to confirm/refute, searching for counterexamples, validating optimality). Label rules: - Output ”1” only if the sentence itself clearly expresses verification intent (e.g., ”check”, ”verify”, ”double-check”, ”recompute”, ”plug in”, ”test whether this holds”, ”see if this works”, ”counterexample”, ”confirm it’s minimal/maximal”). - Output ”0” otherwise. Important: - Do NOT output 1 for pure planning/strategy (”Maybe try…”, ”Consider symmetry…”, ”Let me try coordinates…”). - Do NOT output 1 for generic meta-cognition without checking (”Let me think again.”). - Do NOT output 1 for summaries/conclusions (”Therefore…”, ”Thus…”) unless it explicitly says it is checking/validating. - Return ONLY a single character: 1 or 0. Outcome Annotation Prompt You are an annotation assistant. You will be given: (1) a recheck onset sentence previously extracted from a rollout, and (2) its surrounding context (a short window of text before and after). Your task: Decide whether the recheck that begins at the onset sentence is NECESSARY or UNNECESSARY, using ONLY evidence in the provided context window. Definitions (outcome-based) - NECESSARY (corrective): The recheck discovers an error/inconsistency and leads to a correction. Evidence includes: explicit admission of mistake, retraction, changed equation/value, revised claim, changed plan/approach due to the check, or a different conclusion/answer. - UNNECESSARY (confirmatory): The recheck does not change anything substantive. It only confirms correctness, repeats the same derivation/result, or proceeds with the same claim after checking. - INCONCLUSIVE: The excerpt does not contain enough information to tell whether the check caused a correction or merely confirmed correctness (e.g., the check starts but the outcome is not shown). Rules: - Use ONLY the provided context window. Do NOT assume anything outside it. - Base the decision on explicit textual evidence (e.g., “I was wrong…”, “should be…”, changed numbers, “checks out…”, “consistent…”). - If there is ANY correction caused by the check (even a small arithmetic fix), label NECESSARY. - If the check finishes and the claim stays the same, label UNNECESSARY. - If unclear, label INCONCLUSIVE.