Asking the Right Questions: Improving Reasoning with Generated Stepping Stones
Abstract: Recent years have witnessed tremendous progress in enabling LLMs to solve complex reasoning tasks such as math and coding. As we start to apply LLMs to harder tasks that they may not be able to solve in one shot, it is worth paying attention to their ability to construct intermediate stepping stones that prepare them to better solve the tasks. Examples of stepping stones include simplifications, alternative framings, or subproblems. We study properties and benefits of stepping stones in the context of modern reasoning LLMs via ARQ (\textbf{A}king the \textbf{R}ight \textbf{Q}uestions), our simple framework which introduces a question generator to the default reasoning pipeline. We first show that good stepping stone questions exist and are transferrable, meaning that good questions can be generated, and they substantially help LLMs of various capabilities in solving the target tasks. We next frame stepping stone generation as a post-training task and show that we can fine-tune LLMs to generate more useful stepping stones by SFT and RL on synthetic data.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper asks a simple question: can an AI get better at solving hard problems by first asking itself the right, easier questions? The authors build a framework called ARQ (Asking the Right Questions) that teaches LLMs to create “stepping stone” questions—small, related practice problems that help the model think clearly before tackling the main problem. They test ARQ on challenging math tasks and show that good stepping stone questions can make a real difference.
What questions did the researchers ask?
- Do helpful “stepping stone” questions exist, and can LLMs generate them?
- If a model uses good stepping stones, does it actually solve more problems correctly?
- Are these good stepping stones useful for different models (not just the one that made them)?
- Can we train LLMs to ask better stepping stone questions using synthetic (computer-generated) data?
- Is it even better to use more than one stepping stone, and what’s the best way to sequence them?
How did they do it?
The ARQ idea (like a coach and a student)
Think of an LLM solver as a student trying to solve a difficult math problem. ARQ adds a “coach” model that suggests a simpler, related practice question (a stepping stone). The student first answers the practice question, then uses that experience to solve the main question.
Here’s the three-step process:
- Given the hard problem
x, the “coach” generatorφmakes a stepping stone questionz. - The solver
πsolveszto get an answery_z. - The solver tries the main problem
xagain, now with(z, y_z)as examples in its prompt.
They also test versions with multiple stepping stones:
- Sequential: each new stepping stone is designed to bring the solver closer to the main problem. Think of it as building a mini curriculum step by step.
- Recursive: each new stepping stone helps solve the previous stepping stone, working backward toward the main problem like a little tree of practice problems.
How they measured “good” stepping stones
A stepping stone is “good” if it raises the chance that the solver gets the main problem right. To estimate this, they repeatedly try solving the stepping stone and then the main problem (many rollouts), and compute a score: the average correctness when using that stone. Think of this like testing a drill: if practicing with it regularly leads to better scores on the real test, it’s a good drill.
Training models to ask better questions
The team didn’t rely on human-written stepping stones; instead, they:
- Generated many candidate stepping stones for each problem.
- Scored them by how much they help solve the main problem.
- Collected the best ones into a training set.
They fine-tuned models with:
- SFT (Supervised Fine-Tuning): show the model high-quality examples so it learns the format and style of good stepping stones.
- DPO (Direct Preference Optimization): teach the model to prefer better stepping stones over worse ones, like training a taste for better questions.
They tested this on math benchmarks AIME 2024, AIME 2025 (30 tough problems each), and BeyondAIME (100 much harder problems).
Explaining key terms in everyday language
- LLM: an AI that reads and writes text and can reason step by step.
- Chain-of-thought (CoT): the model’s “thinking out loud” process—like showing your work in math.
- Inference-time scaffold: a lightweight procedure that wraps the model with extra steps (like making it ask questions before solving).
- Rollouts: repeating the process multiple times to see how well it works on average.
- SFT: teaching by examples.
- DPO: training the model to pick the better option when shown two choices.
What did they find?
- Simple prompting tricks can hurt on modern reasoning models:
- Methods that ask the model to generate analogies or break problems into steps (Analogical Reasoner, Least-to-Most) actually made performance worse when used on strong modern LLMs that already think in long chains of thought.
- Good stepping stones exist and can substantially help:
- When the stepping stones were selected to be the best ones, models improved a lot—up to about 13% more problems solved correctly compared to solving directly with no stones.
- Using a less powerful question generator still helped, but less (about 5% improvement).
- Random stepping stones didn’t help.
- The helpfulness transfers across different solvers:
- Stepping stones chosen by one model also helped other models with different sizes and reasoning strengths.
- This suggests the stones are genuinely useful, not just tuned to one model’s quirks.
- Post-training makes models better at asking useful questions:
- Two models (Qwen2.5-32B and Qwen3-8B) got noticeably better at generating helpful stepping stones after SFT + DPO, improving average performance by roughly 3%.
- Before training, one of them couldn’t even produce properly formatted stepping stones; after training, it could and they were helpful.
- More stones can be even better (if you do it sequentially):
- Generating 2–3 stepping stones in a sequential curriculum improved both average and best-case performance across all tested models.
- The recursive strategy was less reliable and sometimes reduced performance.
Why is this important?
This work shows that teaching AI to ask the right questions can be as important as teaching it to answer questions. By creating simpler, relevant practice problems first, an AI can:
- Build intuition and test strategies cheaply and quickly.
- Solve harder tasks more reliably.
- Benefit from a portable “curriculum” that helps many different models.
Beyond math, these ideas could help in coding, science, and other complex reasoning tasks, where breaking problems into smart, verifiable steps speeds up learning and reduces mistakes. The paper also opens doors to training AIs that actively design their own practice path, scaling up to larger datasets and other domains, and exploring online RL to improve question-asking on the fly.
Knowledge Gaps
Knowledge Gaps, Limitations, and Open Questions
Below is a consolidated list of concrete gaps that remain unresolved and can guide follow-up research.
- Oracle-style stone selection: Best-stone analyses rely on ground-truth reward to pick stones; develop test-time selectors (learned scorers, bandits, or heuristics) that do not require labeled answers.
- Expensive scoring via Monte Carlo rollouts: Quantify variance vs. number of rollouts k; design low-cost proxies (solver uncertainty, likelihood-based signals, verifier confidence, self-consistency) to score stones more efficiently.
- Assumption of correct sub-solutions: The method treats stepping-stone solutions as correct; measure error propagation and contamination, and integrate verifiers (CAS, symbolic solvers, unit tests) or rejection/repair loops before conditioning on sub-solutions.
- Prompt sensitivity and formatting brittleness: No ablations on generator/solver prompts, role messages, or formatting; systematically study sensitivity and develop robust prompting/templates or structured outputs (function calls/JSON).
- What kinds of stones work: Build a taxonomy (special cases, analogous problems, subgoals, parameter simplifications, boundary cases) and run causal ablations to determine which types are most beneficial under which task regimes.
- Domain generalization: Validate ARQ beyond AIME-style math—coding (unit tests), formal logic, science QA, planning/agents, and multimodal tasks—with domain-appropriate verifiers.
- Cross-model transfer beyond one family: Test transferability of “good stones” across architectures and vendors (e.g., Llama, DeepSeek, Mixtral, GPT-4-class) and different training paradigms, not just within a single family and size ladder.
- Solver-capability dependence: Map when ARQ helps vs. hurts as solver strength increases; characterize the phase transition and derive policies that adaptively invoke ARQ based on solver uncertainty/capability estimates.
- Complementarity with other scaffolds: Empirically combine ARQ with majority voting/BoN, s1 test-time scaling, ToT/beam search, and self-refine; quantify compute-normalized gains and best allocation of budget between stone generation and solver sampling.
- Multi-stone strategy design: Recursive ARQ often degrades; diagnose failure modes (error compounding, topic drift, context interference) and propose mitigations (verification at each depth, bounded recursion, backtracking, beam search over stone chains).
- Curriculum selection at test time: Develop online selectors/schedulers that generate multiple candidates but pick a small, diverse, and solvable subset (e.g., UCB/successive halving, clustering + deduplication).
- Synthetic data bias: Training data are AIME-style math; extend curation to diverse domains and answer formats to avoid overfitting to integer-answer idiosyncrasies.
- Preference dataset robustness: DPO pairs are induced by a specific solver; test whether preferences are consistent across solvers and how sensitive the learned generator is to the reference solver used for labeling.
- Online RL for stone generation: Move beyond offline SFT/DPO to on-policy RL with verifiable rewards; address non-stationarity when co-optimizing generator against a changing solver.
- Joint vs. decoupled training: Explore co-training the generator and solver (shared encoders, auxiliary losses) vs. freezing the solver; analyze stability, credit assignment, and performance trade-offs.
- Evaluation beyond exact match: Add metrics for sample efficiency (tokens/latency), stability across seeds, calibration, robustness to paraphrases, and human judgments of interpretability/helpfulness of stones.
- Safety and reliability: Detect and filter misleading, unsolvable, or unsafe stones (especially in non-math domains); define reliability guarantees and fallback behaviors when stones are low quality.
- Passing CoT across modules: Authors strip “thinking” tokens; test whether passing distilled rationales/summaries between generator and solver helps and how to compress/share relevant reasoning.
- Hyperparameter sensitivity: Provide ablations over temperature, top-p, number of stones, context length, solver effort, and rollout count; derive practical defaults and scaling laws for ARQ.
- Compute–benefit trade-offs: Compare ARQ’s overhead to allocating the same compute to stronger solvers or more samples; report compute-normalized improvements and cost curves.
- Realistic selection without exhaustive sampling: Best-of-20 is not deployable; develop budgeted search (bandits, early stopping, surrogate models) to pick stones under tight compute constraints.
- Leakage vs. genuine help: Ensure stones do not trivially reveal the final answer; design constraints/validators and measure “answer leakage” to disentangle genuine reasoning gains from hinting.
- Robustness to rephrasings: Test if stones remain effective when target problems are paraphrased or perturbed (lexical and structural), indicating true strategic value rather than surface-form coupling.
- Long-horizon agents: Integrate ARQ with memory/tools in agentic settings; study how to persist and reuse stones across episodes and how stones interact with tool-use and planning modules.
- Multilingual and multimodal extensions: Evaluate ARQ in non-English settings and with diagrams/figures; adapt verifiers and prompts accordingly.
- Data and artifact release: Clarify public release of curated stone datasets, prompts, and scoring scripts to enable replication and comparative benchmarking.
- Theoretical foundations: Formalize conditions under which auxiliary problems provably improve expected reward (links to curriculum learning, value shaping, control variates); analyze bias–variance trade-offs of stone-conditioned inference.
- Diversity mechanisms: Encourage diverse yet relevant stones (e.g., determinantal point processes, conditional negative sampling) and study diversity–quality trade-offs on final-task performance.
- Detecting unsolvable stones: Train solvability predictors to downweight or discard stones the solver consistently fails; add early rejection criteria.
- Context budget management: Study how many stones and how much of each (question vs. rationale vs. solution) to include under token constraints; explore summarization/compression of stone contexts.
- Transferability metrics: Define standardized protocols and metrics for measuring cross-solver and cross-domain transfer of stones, including effect sizes and confidence intervals.
Practical Applications
Overview
The paper introduces ARQ (Asking the Right Questions), a framework that improves LLM reasoning by inserting a question-generation step that produces “stepping-stone” problems. These simpler, related subproblems are solved first and then used as context to solve the original, harder task. The authors show that:
- Good stepping stones meaningfully boost success rates (up to ~13% in math benchmarks), and gains persist across solvers (transferability).
- Stepping-stone quality can be improved via post-training (SFT + DPO) on synthetic data scored with an expected-reward estimator.
- Multiple stepping stones, generated sequentially (not recursively), further improve both average and best-case performance.
Below are practical uses, categorized by immediate deployability and longer-term prospects. Each item notes relevant sectors, candidate tools/workflows, and assumptions/dependencies that affect feasibility.
Immediate Applications
- Software engineering: subproblem-first code generation and debugging
- Sector: Software
- What: Before implementing complex features, the assistant generates and solves stepping-stone tasks (e.g., small function prototypes, interface stubs, edge-case unit tests), then uses those solutions to guide final implementation.
- Tools/workflows: IDE plugin or CI bot that wraps a “generator LLM” + “solver LLM”; integrates with unit-test frameworks for verification; extension for SWE-bench-like tasks.
- Assumptions/dependencies: Availability of unit tests or deterministic checkers; latency budget for multi-step inference; access to a reasonably capable solver model (generator may need to be stronger than the solver).
- Data science & analytics: analysis planning and query decomposition
- Sector: Software/Analytics
- What: Generate stepping questions (e.g., sanity checks, minimal EDA, small-sample trials) before running a heavy analysis; use intermediate results to de-risk final models or dashboards.
- Tools/workflows: BI assistant that proposes and runs fast “toy” analyses; SQL planner that drafts test queries first; confidence-based gating.
- Assumptions/dependencies: Availability of cheap, reliable partial evaluations (e.g., sample datasets); guardrails to avoid misleading pre-analyses.
- Customer support & troubleshooting assistants
- Sector: Customer Service/IT Operations
- What: Dynamic, ARQ-driven triage questions (stepping stones) to narrow diagnosis; present resolutions grounded in validated intermediate checks.
- Tools/workflows: Conversational flows that propose minimal checks first; integration with knowledge bases and device/telemetry APIs.
- Assumptions/dependencies: Quality of diagnostic knowledge base; ability to validate customer-side steps; strict timeouts and fallback to default flows if ARQ adds latency.
- Education: scaffolded tutoring and assessment
- Sector: Education
- What: Tutors generate sequences of stepping-stone questions (e.g., special cases, analogous problems) that students solve before attempting target problems; build an adaptive curriculum.
- Tools/workflows: LMS plugins for ARQ-based stepwise practice; teacher dashboards to review generated subproblems; sequential multi-stone prompting.
- Assumptions/dependencies: Curriculum alignment; correct grading for subproblems; prevention of over-scaffolding that reduces productive struggle.
- Research workflows: rapid prototyping via toy models
- Sector: Academia/R&D
- What: Before tackling complex research tasks, generate simplified “toy” settings to test hypotheses and validate methods; use results to inform the main experiment.
- Tools/workflows: Research assistants that suggest minimal datasets, ablations, or surrogate metrics; lab notebooks integrating ARQ suggestions.
- Assumptions/dependencies: Existence of cheap, verifiable mini-experiments; human-in-the-loop to judge relevance/feasibility.
- Risk and decision support: structured pre-mortems
- Sector: Finance/Operations
- What: Generate stepping questions to test assumptions (e.g., scenario slices, stress-test fragments) before final decisions.
- Tools/workflows: Decision dashboards where ARQ proposes “sanity-check” analyses first; integration with spreadsheet/unit-test style verifiers for key metrics.
- Assumptions/dependencies: Availability of simple, checkable proxies; clear escalation paths from stepping stones to full analyses.
- Legal & compliance checklists
- Sector: Legal/Compliance
- What: Produce targeted sub-questions (e.g., element-by-element checks, jurisdiction-specific clauses) before finalizing documents.
- Tools/workflows: Document review assistants that ask confirmatory stepping questions; audit trail of intermediate checks.
- Assumptions/dependencies: Accurate, up-to-date legal rules; human review for high-stakes outputs; clear limits on practice-of-law boundaries.
- Robotics and task planning (simulation-first)
- Sector: Robotics
- What: Generate and solve simplified sub-tasks in simulation (stepping stones) before executing full plans on hardware.
- Tools/workflows: Planner plugins that propose and validate subgoals; tree/graph search augmented with ARQ’s sequential stones.
- Assumptions/dependencies: Reliable simulators/validators; bridging from sim-to-real; real-time budgets.
- Knowledge worker productivity: plan-by-stepping-stones
- Sector: General/Enterprise Productivity
- What: For complex tasks (reports, proposals, migrations), propose a small sequence of stepping-stone tasks (e.g., outline drafts, stakeholder Q&A, small pilots) to de-risk the final deliverable.
- Tools/workflows: ARQ-enabled task planners; integration with project trackers (e.g., Jira, Asana).
- Assumptions/dependencies: Managerial acceptance of iterative workflows; time/cost allowance for additional steps.
- LLM product development: training and eval pipelines
- Sector: AI/ML
- What: Use ARQ’s synthetic data generation (scoring via expected reward) to create fine-tuning and DPO datasets that improve question-asking for domain models.
- Tools/workflows: Offline pipeline that samples candidate stones, scores them with Monte Carlo rollouts against a solver/verifier, and curates SFT/DPO datasets; integration with existing RLHF/DPO tooling.
- Assumptions/dependencies: Affordable compute for rollouts; existence of verifiers (unit tests, checkers) or reliable proxies; careful prompt formatting.
- Multi-agent/agentic frameworks: ARQ operator
- Sector: Software
- What: Add an “ARQ operator” to frameworks (e.g., LangChain/AutoGen/tree-of-thought) that handles stepping-stone generation and selection before main reasoning.
- Tools/workflows: A reusable module that orchestrates generator/solver calls; sequential multi-stone strategy as the default; score-based or heuristic selection.
- Assumptions/dependencies: Proper state management and cache of stones; confidence calibration to prevent harmful stones.
Long-Term Applications
- Clinical decision support (under supervision)
- Sector: Healthcare
- What: Generate diagnostic stepping questions (e.g., rule-in/rule-out tests, structured history taking) before final assessment.
- Tools/workflows: EHR-integrated assistants that propose intermediate confirmations and reference literature; record structured reasoning.
- Assumptions/dependencies: Regulatory approval; robust verification against guidelines; human oversight; privacy controls; strong bias/harm mitigation.
- Drug discovery and wet-lab automation (experiment curricula)
- Sector: Healthcare/Pharma
- What: Propose sequenced stepping experiments (e.g., assays with simplified conditions) before costly high-throughput trials.
- Tools/workflows: ARQ pipeline integrated with lab automation (e.g., ELN/LIMS); simulation-first then real experiments.
- Assumptions/dependencies: Physical verifiers and high-fidelity simulators; safety and reproducibility standards; multi-objective optimization.
- Grid/energy operations: de-risked optimization
- Sector: Energy
- What: Generate stepping stones (e.g., reduced-order models, local segment optimizations) before global grid adjustments.
- Tools/workflows: Operator consoles with ARQ-assisted scenario planning; digital twin verifiers.
- Assumptions/dependencies: Accurate simulations and constraints; auditability; real-time requirements; stringent reliability thresholds.
- Public policy design and impact assessment
- Sector: Government/Policy
- What: Generate and test stepping questions (e.g., effects on subgroups, local pilots) before broad policy changes.
- Tools/workflows: Policy sandboxes where ARQ proposes high-value, low-cost pilots; structured public consultation plans.
- Assumptions/dependencies: Access to data/evidence; governance processes to evaluate intermediate outcomes; ethical reviews.
- Safety evaluation and red-teaming for AI systems
- Sector: AI Safety
- What: Generate stepping-stone probes that target specific failure modes (e.g., jailbreak precursors, specification edge cases) before full stress tests.
- Tools/workflows: ARQ-driven test-case generators with verifiable checks; integration with eval suites and controlled environments.
- Assumptions/dependencies: High-quality reward signals for safety behaviors; interpretability tooling; careful risk management.
- Autonomy & robotics: hierarchical planners with guarantees
- Sector: Robotics/Autonomy
- What: ARQ-enhanced planning where stepping stones are chosen with verifiable safety/feasibility constraints and formal guarantees.
- Tools/workflows: Hierarchical task networks using ARQ-generated subgoals; formal verification layers; safe exploration.
- Assumptions/dependencies: Formal methods integration; real-time compute; reliable state estimation.
- Complex enterprise transformations (migration, compliance)
- Sector: Enterprise IT/Operations
- What: ARQ designs multi-stage migration/compliance stepping stones (e.g., staged rollouts, parallel runs) before irreversible changes.
- Tools/workflows: Portfolio-level planners that encode dependency graphs and propose validated pilot steps; automated gates.
- Assumptions/dependencies: Accurate dependency mapping; change management governance; rollback mechanisms.
- Finance: model risk management and audit trails
- Sector: Finance
- What: Use ARQ to generate testable sub-analyses (backtests, factor-specific checks) that explain and justify higher-level portfolio or pricing decisions.
- Tools/workflows: ARQ with auditor-facing evidence chains; integration with model validation pipelines.
- Assumptions/dependencies: Regulator-accepted verifiers; clear data lineage; human oversight; latency may preclude deep chains for trading.
- Cross-model “stepping-stone marketplaces”
- Sector: AI/ML Platforms
- What: Centrally curated libraries of high-scoring stones for common task archetypes (e.g., algorithm design patterns, coding idioms) reusable across solvers.
- Tools/workflows: Registry APIs; metadata on stone effectiveness across model families; automatic selection policies.
- Assumptions/dependencies: Generalization across models/domains; versioning/governance; privacy/IP considerations.
- Online RL for question-asking
- Sector: AI/ML
- What: Train generator models to ask better questions via online RL with verifiable or human-in-the-loop rewards in complex domains (coding, reasoning, planning).
- Tools/workflows: On-policy learning with reward models and deterministic tests (e.g., unit tests or checkers); adaptive compute budgets.
- Assumptions/dependencies: Stable reward shaping; safe exploration; compute costs; guardrails against reward hacking.
- Personal assistants: life projects and habit formation
- Sector: Consumer
- What: ARQ-driven planning where assistants propose small, verifiable stepping actions for larger goals (e.g., fitness, learning, relocation).
- Tools/workflows: Planner apps with sequential stepping stones and progress verification (e.g., sensors/logs).
- Assumptions/dependencies: Reliable tracking for verification; user acceptance of added steps; privacy.
Notes on Feasibility, Constraints, and Best Practices
- Verification is critical. ARQ works best when stepping-stone solutions can be checked (math checkers, unit tests, simulators). In unverifiable settings, keep a human in the loop and use conservative selection.
- Choose sequential over recursive multi-stone generation. The paper shows sequential stepping stones consistently improve average and best-case performance; recursive generation is less reliable.
- Not all stones help. Poor or irrelevant stepping stones can degrade performance. Include gating (confidence estimates, quick-check validators) and fallback to solver-only if a stone doesn’t clear thresholds.
- Transferability is a strength. Stones that help one solver tend to aid others—enabling reuse across teams or models within a family. Still, validate across model types where possible.
- Generator capability matters. More capable generators produce better stones. If possible, use a stronger generator than the solver, or post-train a generator via SFT+DPO on synthetic, scored data.
- Compute and latency budgets. ARQ adds extra calls and rollouts. Use caching, limit stone counts, apply early stopping, and reserve ARQ for high-value queries.
- Safety and compliance. In high-stakes domains (healthcare, finance, policy), require human oversight, audit trails, privacy safeguards, and regulatory compliance.
These applications leverage ARQ’s core insight: asking and solving the right intermediate questions first can materially improve success on complex tasks, and this behavior can be taught and productized through synthetic data and post-training.
Glossary
- Analogical Reasoners: A prompting method that has models generate and solve an analogous sub-problem before tackling the target problem. "Analogical Reasoners~\citep{yasunaga2024llm-analogical-reasoner} instructs models to generate and solve a related sub-problem as a precursor to the target math problem."
- ARQ: The paper’s framework (Asking the Right Questions) that introduces a question-generation step to create and solve stepping-stone problems before the main task. "In this work, we propose a straightforward framework, ARQ (Asking the Right Questions), to study this question from both inference and post-training perspectives."
- Best-of-N aggregation: A test-time strategy that samples multiple candidate solutions and selects the best according to some criterion. "majority voting and Best-of-N aggregation \citep{wang2023selfconsistencyimproveschainthought, brown2024largelanguagemonkeysscaling}"
- Chain-of-Thought (CoT): Explicit step-by-step reasoning traces produced by an LLM before the final answer. "eliciting extended Chain-of-Thought (CoT) traces through prompting alone."
- Direct Preference Optimization (DPO): A preference-based post-training method that optimizes models to prefer higher-quality outputs without on-policy RL. "or via Direct Preference Optimization (DPO) \citep{rafailov2023direct}, which bypasses the complexities of on-policy RL while enhancing reasoning effectiveness."
- in-context learning: Learning from examples provided in the prompt at inference time, enabling models to adapt behavior without weight updates. "that utilize in-context learning to induce models to generate auxiliary questions before addressing the primary task."
- Iterative refinement: An inference-time process in which a model repeatedly revises or improves its solution. "iterative refinement~\citep{self-refine, shinn2023reflexion}"
- LLM-as-a-judge: Using an LLM to evaluate, score, or verify candidate solutions. "LLM-as-a-judge~\citep{zheng2023judging}"
- long-horizon agentic environments: Settings where agents must plan and act over many steps to achieve goals. "decision-making in long-horizon agentic environments~\citep{chan2025mlebenchevaluatingmachinelearning, jimenez2024swebenchlanguagemodelsresolve}"
- Monte Carlo rollouts: Repeated stochastic simulations used to estimate expected reward or performance. "averaged over Monte Carlo rollouts of solutions to the generated stone"
- offline RL: Reinforcement learning performed from static datasets without online interaction during training. "followed by offline RL with DPO~\citep{rafailov2023direct}"
- Reinforcement Learning (RL): A learning paradigm where an agent optimizes actions to maximize expected reward. "Reinforcement Learning (RL) to further refine reasoning behaviors via human or verifiable feedback~\citep{li2025system,kumar2025llm}"
- Reinforcement Learning from Human Feedback (RLHF): RL methods guided by human preference signals via learned reward models. "on-policy methods using learned reward models (RLHF) \citep{ouyang2022traininglanguagemodelsfollow}"
- Self-Ask: A prompting approach where models explicitly query intermediate facts/questions before answering the main task. "Self-Ask~\citep{press2023measuringnarrowingcompositionalitygap} prompts models to retrieve intermediate facts"
- Self-bootstrapping: Generating additional training signals or rationales using models themselves to improve performance. "self-bootstrapping techniques~\citep{zelikman2022starbootstrappingreasoningreasoning, zhang2024rest}"
- stepping stone: An easier, related sub-problem posed to build intuition or validate strategies for the main problem. "generate stepping stone questions"
- test-time scaling: Improving performance by increasing inference-time compute or sampling (e.g., more traces, longer reasoning). "Since the introduction of test-time scaling~\citep{openai2024openaio1card},"
- thinking tokens: The intermediate “thinking” or hidden reasoning text produced by models, often removed before downstream use. "We remove the thinking tokens before passing these outputs to the next module"
- tree-based search strategies: Inference-time methods that explore branching reasoning paths (e.g., Tree-of-Thought) to find better solutions. "tree-based search strategies \citep{yao2023treethoughtsdeliberateproblem, besta2024got}"
- verifiable reward RL: RL that uses automatically checkable, deterministic objectives (e.g., exact-match correctness) as rewards. "verifiable reward RL~\citep{lambert2025tulu} utilizes automated, deterministic objectives"
Collections
Sign up for free to add this paper to one or more collections.



