Tree Search Reasoning: Allocating Inference Budget Across Prefixes

Tree search spends inference budget on partial reasoning prefixes, using local verifier scores, frontier expansion, and max backups to decide which branches deserve more thought.

Advanced · Undergraduate mathematics · about 32 minutes

Reading map and next steps

Intuition

The idea in plain words, before the symbols.

Best-of-NN search spends all extra compute on complete traces. It samples whole solutions, scores them, and returns the best sampled solution.

Tree search asks a sharper question: after seeing a partial reasoning prefix, which branch deserves more budget?

That changes the unit of allocation. The search state is a prefix hh: a partial derivation, proof, plan, or scratchpad. A generator proposes next steps. A process reward model or local verifier scores those steps. In the finite teaching model below, a max-backup rule lets a good visible continuation raise the value of the earlier prefix that led to it.

This page teaches a finite prefix-tree mechanism inspired by ToT and PRM-style scoring: visible prefixes, local verifier scores, frontier expansion, max backup, and a toy noisy-verifier failure. Full MCTS, UCT, rollouts, visit counts, PUCT, and AlphaZero-style search are part of the larger family, but they are not taught here.

The page also holds a second, separately named method. Layerwise pruning generates every child of each prefix it kept, scores each new prefix once, keeps the bb best across the whole layer, and discards the rest before any of their continuations exist. That is the breadth-first shape of Algorithm 1 in Yao et al., with omissions stated below. It changes what a wrong answer can mean. The correct continuation may never have been generated, because its prefix was pruned; it may have been generated and still not returned; or the search may have stopped because it could not afford its next whole layer. These failures call for different next inspections, and the final answer alone does not separate them. The search trace shows what was generated, kept, returned and charged, which is enough to see a budget stop. Telling the other two apart also needs to know which unreturned or never-generated terminals are correct. The layerwise pruning miniature supplies that as an answer key for every terminal and shows all three failures on one seven-node tree; without such labels, a real trace can leave the reason for a wrong answer unidentified.

Background. Cobbe et al., "Training Verifiers to Solve Math Word Problems", Lightman et al., "Let's Verify Step by Step", Brown et al., "Large Language Monkeys" and Wang et al., "Self-Consistency Improves Chain of Thought Reasoning" study verifiers and repeated sampling over complete solutions. Yao et al., "Tree of Thoughts", search over partial solutions, and Kocsis and Szepesvári, "Bandit Based Monte-Carlo Planning", introduced the UCT rule behind many Monte Carlo tree searches. This page follows Yao et al. for search over partial states and Lightman et al. for step-level scoring.

Study prompts for this section: Intuition
Study prompts

Each button copies a prompt about this section to your clipboard, for an AI assistant you already use. Nothing is sent by this site.

Mathematics

Definitions, assumptions and the derivation.

Fix one prompt xx and a finite rooted tree T\mathcal T of possible reasoning prefixes. The root is the empty prefix ∅\emptyset. A node is a prefix hh, taking next step aa creates child prefix haha, the generator proposes that edge, and the local verifier scores it:

h=(a1,…,at),ha=(a1,…,at,a),πθ(a∣h),rϕ(h,a).h=(a_1,\dots,a_t), \qquad ha=(a_1,\dots,a_t,a), \qquad \pi_\theta(a\mid h), \qquad r_\phi(h,a).

Here rϕ(h,a)r_\phi(h,a) is the process-reward-model style judgment of whether step aa is valid after prefix hh.

At search step tt, let Tt\mathcal T_t be the visible subtree. The frontier, cumulative local verifier score, deterministic expansion rule, and the max backup used on this page are:

Ft=Frontier(Tt),Gϕ(h)=∑(g,a)∈path(h)rϕ(g,a),ht=arg⁡max⁡h∈Ft[Gϕ(h)+bϕ(h)],Vt(h)={0,h is terminal,bϕ(h),h∈Ft,max⁡a:ha∈Tt[rϕ(h,a)+Vt(ha)],h is expanded.\begin{aligned} \mathcal F_t &= \mathrm{Frontier}(\mathcal T_t),\\ G_\phi(h) &= \sum_{(g,a)\in \mathrm{path}(h)} r_\phi(g,a),\\ h_t &= \arg\max_{h\in\mathcal F_t} \left[G_\phi(h)+b_\phi(h)\right],\\ V_t(h) &= \begin{cases} 0, & h \text{ is terminal},\\ b_\phi(h), & h\in\mathcal F_t,\\ \max\limits_{a:ha\in\mathcal T_t}\left[r_\phi(h,a)+V_t(ha)\right], & h \text{ is expanded}. \end{cases} \end{aligned}

A terminal trace zz also has hidden correctness

u(z)∈{0,1},u(z)\in\{0,1\},

but uu is used only for evaluation, not for search.

Here bϕ(h)b_\phi(h) is a prefix heuristic: how promising an unfinished prefix looks before its children are revealed. The hth_t line is the simplest deterministic expansion rule: choose the visible unfinished prefix with the highest current path score plus heuristic.

Expanding hth_t reveals its children and scores their incoming edges. This is the unit of inference budget.

The backed-up residual value on the visible tree is the VtV_t recurrence above: terminal nodes contribute no future score, unfinished frontier nodes use their heuristic, and expanded nodes inherit the best visible child continuation.

The recommended visible path follows the best backed-up child:

a⋆(h)=arg⁡max⁡a:ha∈Tt[rϕ(h,a)+Vt(ha)].a^\star(h)= \arg\max_{a:ha\in\mathcal T_t} \left[r_\phi(h,a)+V_t(ha)\right].

This is not a convergence theorem or a claim about perfect planning. It means only: among the continuations currently visible under this prefix, choose the one with the highest verifier-backed score.

A compact cost model is

Ct=∑h expanded∣At(h)∣(cgen+cscore),C_t= \sum_{h\ \mathrm{expanded}} |A_t(h)|(c_{\mathrm{gen}}+c_{\mathrm{score}}),

where At(h)A_t(h) is the set of generated children revealed when prefix hh is expanded.

The contrast with best-of-NN is the frontier. Complete-trace search samples τ(1),…,τ(N)\tau^{(1)},\dots,\tau^{(N)} and selects

τ⋆=arg⁡max⁡isϕ(τ(i)).\tau^\star= \arg\max_i s_\phi(\tau^{(i)}).

There is no visible prefix frontier and no bottom-up backup. Tree search replaces "sample another whole trace" with "expand another prefix."

A second method: layerwise pruning

Keep the prefix notation but change the rule. Let v(h)v(h) be a given score of a generated prefix hh: a number attached to that state alone. It is not an edge score, a probability, a continuation estimate or correctness, and it is never added along a path or backed up. Let k=2k=2 be the number of children each expanded prefix proposes, b∈{1,2}b\in\{1,2\} the width and D=2D=2 the depth. Start from S0={∅}S_0=\{\emptyset\} and, for d=1,…,Dd=1,\dots,D,

Cd=⋃h∈Sd−1A(h),Sd=top⁡b(Cd; v),Pd=Cd∖Sd.C_d=\bigcup_{h\in S_{d-1}} A(h), \qquad S_d=\operatorname{top}_b\bigl(C_d;\,v\bigr), \qquad P_d=C_d\setminus S_d .

A(h)A(h) is revealed only when h∈Sd−1h\in S_{d-1} is expanded, so no continuation of a pruned prefix in PdP_d is ever generated or scored. top⁡b\operatorname{top}_b ranks the whole layer CdC_d by vv, not the children of each parent separately, and breaks ties by the lexical order of node IDs. The miniature returns the highest-scoring prefix in SDS_D, with the same tie rule.

Each newly generated prefix costs one generation unit and one scoring unit, cgen=cscore=1c_{\mathrm{gen}}=c_{\mathrm{score}}=1. Before layer dd the search checks the whole layer against the budget BB,

spentd−1+∣Sd−1∣ k (cgen+cscore)≤B,\mathrm{spent}_{d-1}+|S_{d-1}|\,k\,(c_{\mathrm{gen}}+c_{\mathrm{score}})\le B,

using the fixed kk, never a look at the unseen children. If the check fails, the search stops with no answer; it does not shrink the width or expand part of the layer. The root layer costs 44 units; width 1 completes at 88 and width 2 at 1212.

The seven-node tree has root children L (v=.40v=.40) and R (.90.90); under L, LG (.95.95) and LB (.20.20); under R, RB1 (.80.80) and RB2 (.70.70). Only LG is correct. The search reads scores only; correctness is read after it, to grade what it returned and, because every terminal here is labelled, to diagnose the trace.

  • b=1b=1, B=8B=8: S1={R}S_1=\{\mathrm{R}\} and P1={L}P_1=\{\mathrm{L}\}, then S2={RB1}S_2=\{\mathrm{RB1}\}. RB1 is returned, wrong, at cost 8. LG and LB are never generated.
  • b=2b=2, B=12B=12: all six prefixes are generated, S2={LG,RB1}S_2=\{\mathrm{LG},\mathrm{RB1}\}, and LG is returned, correct, at cost 12. Width changed the cost as well, so this is not a comparison at equal resources.
  • b=2b=2, B=8B=8: after the root layer 4 units remain and the next layer needs 8. There is no answer, and its grade is not applicable.
  • v(L)=.96v(\mathrm{L})=.96 with b=1b=1, B=8B=8: L is kept and LG returned at cost 8. Changing only an unseen leaf's score at b=1b=1 changes nothing, because LG and LB are never scored.
  • v(LG)=.60v(\mathrm{LG})=.60 with b=2b=2, B=12B=12: LG is generated, then pruned at depth 2 behind RB1 and RB2, and RB1 is returned. Generating the correct terminal did not repair its score.

Scores are not path sums. Adding ancestors would give LG .40+.95=1.35.40+.95=1.35 against RB1 .90+.80=1.70.90+.80=1.70 at width 2 and reverse the return. Unlike VtV_t above, nothing is backed up.

Source statements, local rules and inference

Source statements. In Yao et al. (arXiv v1, §3 and Algorithm 1), a state is the input together with the thoughts so far. At each step the breadth-first variant generates continuations of every retained state, evaluates the new states and keeps the bb highest-valued. Generation may sample thoughts independently or propose them in sequence; evaluation may value each state separately or vote across states, and repeated evaluations can be aggregated. After the last step, Algorithm 1 generates once more from the highest-valued retained state to produce its output. The Game of 24 experiment (§4.1) keeps five states and samples three values for each thought. Lightman et al. (arXiv v1, §§2.1, 2.4 and 2.6, Appendix F.1–F.2) train a process reward model on human labels, each of which judges one written step, in the context of the steps before it, as positive, negative or neutral; supervision stops at the first incorrect step, and the model predicts the current step's label from the prefix that ends there. A complete solution's score is a separate aggregate of those step predictions: the score they adopt multiplies the steps' correctness probabilities, counting neutral with positive, and their best-of-NN evaluation selects a complete solution by that score before its final answer is graded.

Local rules. The miniature keeps layerwise proposal, evaluation and global top-bb retention. It substitutes hand-written children and scores for model calls, reads each score once instead of sampling or voting, and adds a lexical tie rule and the whole-layer budget above. It omits the final generation and returns a depth-2 terminal directly. Its costs count abstract node operations, not the paper's model calls, tokens, latency or money. This is not a reproduction of either paper, and no result from either is reproduced here.

Inference. A label judges the current written step in its preceding context, as positive, negative or neutral; the whole-solution product is a separate aggregate of such step predictions. Neither target by itself establishes that an unfinished prefix can reach a correct terminal under a specified generator, depth and budget, and the hand-set vv here is not a trained reward model. Using a step-label predictor as the state score in this search would need evidence that its ranking of unfinished prefixes tracks observed reachability under that generator and budget, such as graded terminals from continuing many scored prefixes on held-out prompts. This is not evidence that process reward models cannot guide search.

What a trace identifies. A search trace records the generated, kept and pruned prefixes with the scores the search read, the return and the units charged. That alone identifies a whole-layer budget stop. Grading the return uses one more fact, the returned terminal's label. Saying that a correct alternative was pruned before generation, or generated and not returned, needs more still: independently known labels for those alternatives, or counterfactual evidence such as continuing the pruned prefixes and grading their terminals. The miniature has a label for every terminal, so it can make that diagnosis. A real trace without such evidence can leave the reason for a wrong return unidentified: the same width-1 trace fits LG being correct (pruning loss), RB2 being correct (misselection) or no terminal being correct. The labels never enter the search.

Study prompts for this section: Mathematics
Study prompts

Each button copies a prompt about this section to your clipboard, for an AI assistant you already use. Nothing is sent by this site.

Code

The same calculation as runnable code, in the notation of the derivation.

This code runs the same finite prefix tree as the demo for 2(x+3)=142(x+3)=14. In clean mode, the best-first frontier reaches a correct terminal trace. In noisy mode, an invalid shortcut is falsely scored high, and the max backup sends the root toward the wrong terminal.

NODES = {
    "root": {"children": ["A", "B", "C"]},
    "A": {"parent": "root", "children": ["A1"], "clean": -1.2, "noisy": 1.2, "b_clean": -0.3, "b_noisy": 1.1},
    "A1": {"parent": "A", "terminal": True, "correct": False, "clean": -0.4, "noisy": 1.6},
    "B": {"parent": "root", "children": ["B1", "B2"], "clean": 0.8, "noisy": 0.8, "b_clean": 0.9, "b_noisy": 0.9},
    "B1": {"parent": "B", "terminal": True, "correct": True, "clean": 1.0, "noisy": 1.0},
    "B2": {"parent": "B", "terminal": True, "correct": False, "clean": -0.6, "noisy": -0.6},
    "C": {"parent": "root", "children": ["C1", "C2"], "clean": 0.7, "noisy": 0.7, "b_clean": 1.3, "b_noisy": 1.3},
    "C1": {"parent": "C", "children": ["C1a", "C1b"], "clean": 0.9, "noisy": 0.9, "b_clean": 0.8, "b_noisy": 0.8},
    "C1a": {"parent": "C1", "terminal": True, "correct": True, "clean": 0.8, "noisy": 0.8},
    "C1b": {"parent": "C1", "terminal": True, "correct": False, "clean": -0.6, "noisy": -0.6},
    "C2": {"parent": "C", "terminal": True, "correct": False, "clean": -0.8, "noisy": -0.8},
}

ORDER = ["root", "A", "A1", "B", "B1", "B2", "C", "C1", "C1a", "C1b", "C2"]

def score(node_id, mode):
    return NODES[node_id][mode]

def heuristic(node_id, mode):
    return NODES[node_id].get(f"b_{mode}", 0.0)

def cumulative(node_id, mode):
    if node_id == "root":
        return 0.0
    parent = NODES[node_id]["parent"]
    return cumulative(parent, mode) + score(node_id, mode)

def run(mode="clean", budget=2):
    visible = set(["root", *NODES["root"]["children"]])
    expanded = {"root"}

    def is_frontier(node_id):
        node = NODES[node_id]
        return node_id in visible and not node.get("terminal") and node_id not in expanded

    for _ in range(budget):
        frontier = [node_id for node_id in ORDER if is_frontier(node_id)]
        if not frontier:
            break
        chosen = max(frontier, key=lambda node_id: (cumulative(node_id, mode) + heuristic(node_id, mode), node_id))
        expanded.add(chosen)
        visible.update(NODES[chosen].get("children", []))

    def value(node_id):
        node = NODES[node_id]
        if node.get("terminal"):
            return 0.0
        if node_id not in expanded:
            return heuristic(node_id, mode)
        return max(score(child, mode) + value(child) for child in node["children"] if child in visible)

    path = ["root"]
    while path[-1] in expanded and not NODES[path[-1]].get("terminal"):
        children = [child for child in NODES[path[-1]]["children"] if child in visible]
        if not children:
            break
        path.append(max(children, key=lambda child: (score(child, mode) + value(child), child)))

    terminal = path[-1] if NODES[path[-1]].get("terminal") else None
    return {"path": path, "root_value": value("root"), "terminal": terminal}

clean = run("clean", budget=2)
noisy = run("noisy", budget=2)

assert clean["path"] == ["root", "C", "C1", "C1a"]
assert NODES[clean["terminal"]]["correct"] is True
assert noisy["path"] == ["root", "A", "A1"]
assert NODES[noisy["terminal"]]["correct"] is False
print(clean)
print(noisy)

A second program: layerwise pruning

This second block runs the seven-node layerwise method from the Math section. The search receives only a proposal function and a scoring function; the answer key is used afterwards, by grade, which needs the returned prefix's own True or False label and has no default. Width and budget must be integers no larger than 253−12^{53}-1, the range in which both this code and the figure's TypeScript count units exactly. read records every score the search asked for, so a prefix it never generated can be seen never to have been scored. It produces the same traces as the layerwise pruning figure.

PROPOSALS = {"root": ["L", "R"], "L": ["LG", "LB"], "R": ["RB1", "RB2"]}
SCORE = {"L": 0.40, "R": 0.90, "LG": 0.95, "LB": 0.20, "RB1": 0.80, "RB2": 0.70}
ANSWER_KEY = {"LG": True, "LB": False, "RB1": False, "RB2": False}  # grading only
K, DEPTH, UNITS_PER_PREFIX = 2, 2, 1 + 1  # children per prefix, layers, generation + scoring
SAFE = 2**53 - 1  # the integer range both this code and the TypeScript model count exactly

def layerwise(propose, score, width, budget):
    if type(width) is not int or not 1 <= width <= SAFE or type(budget) is not int or not 0 <= budget <= SAFE:
        raise ValueError("width must be an integer in 1..2**53 - 1 and budget one in 0..2**53 - 1")
    kept, spent, layers, seen = ["root"], 0, [], {"root"}
    for depth in range(1, DEPTH + 1):
        required = len(kept) * K * UNITS_PER_PREFIX  # the fixed branching, not a peek
        if spent + required > budget:
            return {"returned": None, "spent": spent, "stopped_before": depth, "required": required, "layers": layers}
        generated = []
        for parent in kept:
            children = propose(parent)
            assert len(set(children)) == len(children) == K and not seen.intersection(children)
            seen.update(children)
            generated += [(score(child), child) for child in children]
        spent += len(generated) * UNITS_PER_PREFIX
        ranked = sorted(generated, key=lambda item: (-item[0], item[1]))  # whole layer; ties by id
        kept = [child for _, child in ranked[:width]]
        layers.append({"depth": depth, "ranked": [child for _, child in ranked], "kept": kept, "spent": spent})
    return {"returned": kept[0], "spent": spent, "stopped_before": None, "required": None, "layers": layers}

def grade(result, key=ANSWER_KEY):
    if result["returned"] is None:
        return "not applicable"
    label = key[result["returned"]]  # a missing label raises KeyError: there is no default
    if type(label) is not bool:
        raise TypeError("an answer-key label must be True or False")
    return "correct" if label else "wrong"

def run(width, budget, **changed):
    scores, read = {**SCORE, **changed}, []
    def score(prefix):
        read.append(prefix)
        return scores[prefix]
    result = layerwise(PROPOSALS.__getitem__, score, width, budget)
    return {**result, "read": read, "grade": grade(result)}

narrow = run(1, 8)
assert (narrow["returned"], narrow["grade"], narrow["spent"]) == ("RB1", "wrong", 8)
assert "LG" not in narrow["read"] and "LB" not in narrow["read"]
assert run(1, 8, LG=0.10, LB=0.99)["layers"] == narrow["layers"]  # unseen leaves cannot revive L
wide = run(2, 12)
assert (wide["returned"], wide["grade"], wide["spent"]) == ("LG", "correct", 12)
short = run(2, 8)
assert (short["returned"], short["grade"], short["spent"], short["required"]) == (None, "not applicable", 4, 8)
repaired = run(1, 8, L=0.96)
assert (repaired["returned"], repaired["spent"]) == ("LG", 8)
misscored = run(2, 12, LG=0.60)
assert misscored["layers"][1]["kept"] == ["RB1", "RB2"] and misscored["returned"] == "RB1"
assert run(2, 12, LB=0.85)["layers"][1]["kept"] == ["LG", "LB"]  # global top b, not one per parent
assert SCORE["L"] + SCORE["LG"] < SCORE["R"] + SCORE["RB1"]  # path sums would reverse the width-2 return
for case in (narrow, wide, short, repaired, misscored):
    print(case["returned"], case["grade"], case["spent"])
Study prompts for this section: Code
Study prompts

Each button copies a prompt about this section to your clipboard, for an AI assistant you already use. Nothing is sent by this site.

Demo

Change an input, predict the result, and see which quantities respond.

ExploreChange one control at a time and name what responds.An optional observation guide follows the demo.

Explore Tree Search Reasoning: Allocating Inference Budget Across Prefixes

Loading the interactive demo…

Observation guide

Optional and ungraded. Opening a guide saves nothing.

Choose what to inspect in Tree Search Reasoning: Allocating Inference Budget Across Prefixes, then open its guide.

Use the Prefix Budget Explorer to expand visible prefixes under a clean or noisy verifier. Before revealing the backed-up path, predict which root branch the visible verifier values will recommend. Hidden correctness can be shown afterward for diagnosis, but the search rule never uses it.

Below it, the layerwise pruning miniature runs the second method on the seven-node tree. It opens on the complete width-1 trace with its answer and grade; no prediction is needed. Switch between the worked cases, or change one of width, budget, L's score and LG's score, and read the tree, the ledger and the diagnosis together. The optional walkthrough steps through one layer transition at a time. The mapping beside it lines the trace up against Algorithm 1 and says what is omitted.

Study prompts for this section: Demo
Study prompts

Each button copies a prompt about this section to your clipboard, for an AI assistant you already use. Nothing is sent by this site.

In focus

Concept: Tree Search Reasoning: Allocating Inference Budget Across Prefixes

What is the smallest example of Tree Search Reasoning you can work through by hand, and what does it show?

BeforeTest-Time Compute: Spending Inference Budget on SearchNextSparse Autoencoders: Feature Dictionaries for Mechanistic Interpretability
DetailsScaling

After the first pass

Go deeper

Optional material for a second reading. Sources are always shown; the other panels open from their headings or from these links, and closing one keeps what you wrote or revealed.
What to look for in each sectionChoose a section and what you expect to see in it, then read short advice.

Section by section

Choose what to look for in each section

Tree search spends inference budget on partial reasoning prefixes, using local verifier scores, frontier expansion, and max backups to decide which branches deserve more thought.

Choose what to look for (no demo yet)01 / Intuition
Illustration of selective tree expansion, verifier gauges, budget ticks, and value backup arrows.
What to look for

Start with the picture, metaphor, or geometric mechanism.

Choose first

Choose what you expect to see in this section of Tree Search Reasoning: Allocating Inference Budget Across Prefixes.

Questions to ask of the pictureChoose a part of the picture and what you expect, then read short advice.

Looking at the picture

Questions to ask of the picture

Tree search spends inference budget on partial reasoning prefixes, using local verifier scores, frontier expansion, and max backups to decide which branches deserve more thought.

4 of 4 sections writtenNo live demo yet
Question

Which part of the picture should you look at first?

Choose first

Pick the part of the picture you expect to explain Tree Search Reasoning: Allocating Inference Budget Across Prefixes.

Sources

References for this page

A reference shows where an idea comes from; it does not vouch for every step on this page.
paper · 2023Tree of Thoughts: Deliberate Problem Solving with Large Language ModelsYao et al.
Why it is cited

Defines Tree of Thoughts as search over partial solution states, with thought generation, state evaluation and breadth- or depth-first search (NeurIPS 2023; section numbers on this page refer to arXiv v1).

Open source
paper · 2024Let's Verify Step by StepLightman et al.
Why it is cited

Trains process-supervised reward models that predict whether each intermediate reasoning step is correct (ICLR 2024; section numbers on this page refer to arXiv v1).

Open source
paper · 2006Bandit Based Monte-Carlo PlanningKocsis and Szepesvári
Why it is cited

Introduces UCT, which chooses which branch of a search tree to sample next with an upper-confidence bandit rule (ECML 2006).

Open source
What each claim rests on2 claims, each with its sources, where it appears on this page, and its caveats.

Claims and sources

Tree search spends inference budget on partial reasoning prefixes, using local verifier scores, frontier expansion, and max backups to decide which branches deserve more thought.

1 of 2 claims checked against the cited passages

The checks were made by this site, not by an independent reviewer.

Tree-search reasoning allocates inference budget over visible partial prefixes: a generator proposes next thoughts, verifier-style scores rank prefixes, a frontier rule expands promising nodes, and max backups propagate visible continuation scores; the demo shows noisy scores can select a wrong path.
What the sources support

Yao et al. define ToT as search over states representing partial solutions, with thought generation, state evaluation, and BFS/DFS-style search. Lightman et al. ground PRMs as step-level correctness predicto...

Where to see it on this page
Equation 1
h=(a1,…,at),ha=(a1,…,at,a),πθ(a∣h),rϕ(h,a).h=(a_1,\dots,a_t), \qquad ha=(a_1,\dots,a_t,a), \qquad \pi_\theta(a\mid h), \qquad r_\phi(h,a).
Equation 2
Ft=Frontier(Tt),Gϕ(h)=∑(g,a)∈path(h)rϕ(g,a),ht=arg⁡max⁡h∈Ft[Gϕ(h)+bϕ(h)],Vt(h)={0,h is terminal,bϕ(h),h∈Ft,max⁡a:ha∈Tt[rϕ(h,a)+Vt(ha)],h is expanded.\begin{aligned} \mathcal F_t &= \mathrm{Frontier}(\mathcal T_t),\\ G_\phi(h) &= \sum_{(g,a)\in \mathrm{path}(h)} r_\phi(g,a),\\ h_t &= \arg\max_{h\in\mathcal F_t} \left[G_\phi(h)+b_\phi(h)\right],\\ V_t(h) &= \begin{cases} 0, & h \text{ is terminal},\\ b_\phi(h), & h\in\mathcal F_t,\\ \max\limits_{a:ha\in\mathcal T_t}\left[r_\phi(h,a)+V_t(ha)\right], & h \text{ is expanded}. \end{cases} \end{aligned}
Caveat

This checks the page's finite prefix-tree teaching model. It does not claim full MCTS/UCT/PUCT, convergence or optimal-planning guarantees, calibrated verifier scores, real serving cost, or immunity to rewar...

StatusChecked against the cited passages.

Checked the papers' LaTeX source: Yao et al. support ToT as search over partial solution states with thought generation, state evaluation, and BFS/DFS-style exploration; Lightman et al. support PRMs as step-level correctness predictors used to score generated solutions. The page's max-backup and noisy-verifier behavior is shown by its own small example in the equations, code and demo, and is not claimed to be Yao et al.'s exact algorithm.

The page's seven-node layerwise miniature keeps ToT's per-layer generation, state evaluation and top-b retention, so continuations of a pruned prefix are never generated; it omits model sampling, repeated valuation and Algorithm 1's final generation, and its node-operation costs are local.
What the sources support

Yao et al. v1 §3 and Algorithm 1: states are input plus thought prefix; each step generates continuations of retained states, evaluates them and keeps the b highest-valued, then generates once more from the...

Caveat

Hand-written proposals and scores, not a reproduction or measured result. A step-label target is not shown to equal continuation value, and the local unit counts are not model calls, tokens or cost.

StatusNot yet checked against its sources.
Explain it without the pageWrite your own explanation before asking for feedback. Your draft and any hints stay while this page is open.

Practice · Tree Search Reasoning: Allocating Inference Budget Across Prefixes

Try the idea in your own words

Tree search spends inference budget on partial reasoning prefixes, using local verifier scores, frontier expansion, and max backups to decide which branches deserve more thought.

Concept · Selected for practice

Tree Search Reasoning: Allocating Inference Budget Across Prefixes

What it rests on: Sources: Tree of Thoughts: Deliberate Problem Solving with Large Language Models; Let's Verify Step by Step; Bandit Based Monte-Carlo Planning

Context and links
Choose a task

Explain the mechanism

For Tree Search Reasoning: Allocating Inference Budget Across Prefixes: What is the smallest example of Tree Search Reasoning you can work through by hand, and what does it show? Explain your answer, including what changes, why, and which assumption matters.

No answer yet

A rough first thought is enough. Your draft stays when you change tasks.

Your draft stays on this page and is cleared when you leave or reload.

A little help · Explain

Open one hint at a time. These are suggestions, not your answer or a grade.

0 of 3 hints shown for this question.

    Clearing your answer keeps this help record. Outside help is your own report; this page cannot check it.

    Where am I stuck? (optional)
    Your own description, not an automatic diagnosis

    Choose one, or leave this unspecified. Select it again to clear it.

    Take your draft to a feedback conversation

    No AI feedback runs here. You can copy a prompt to use elsewhere; nothing is sent automatically. Review the text before sharing, and leave out private information.

    Write an attempt before copying a feedback prompt.

    A draft, or an AI reply to it, is not a test of what you have learned. To check that, try a different case later without help.

    Ask about this pagePick one item on this page and copy a prompt about it into an AI assistant you already use. Notes you write here stay in this browser.
    Ask about this pageClose
    ConceptTree Search Reasoning: Allocating Inference Budget Across PrefixesSources: Tree of Thoughts: Deliberate Problem Solving with Large Language Models; Let's Verify Step by Step; Bandit Based Monte-Carlo PlanningNODES = { "root": {"children": ["A", "B", "C"]}, "A": {"parent": "root", "children": ["A1"],...

    Your question

    Choose what your question is about

    Pick the idea, equation, source, code, claim, misconception or demo state you want to ask about. The prompt you copy includes it, so the answer can stay on that item.
    Next local actionNo local draft saved yet

    Open the draft below to save one note and next action in this browser.

    conceptScaling

    Tree Search Reasoning: Allocating Inference Budget Across Prefixes

    Starting question

    What is the smallest example of Tree Search Reasoning you can work through by hand, and what does it show?

    SourcesCheck the 3 cited sources listed under Sources.Notes can be saved for this item
    Points of view on this item

    Fixed prompts generated from this item. They are not comments from people or independent reviews.

    Learner’s first stepAsk what would make "Tree Search Reasoning: Allocating Inference Budget Across Prefixes" feel predictable rather than familiar.
    Assumption

    The 3 cited sources must support this exact item, not just the surrounding topic.

    Source-checking summary

    Connect the definition to one equation, piece of code or demo before widening the discussion.

    Proposed experiment

    Change one input, then check that the same relationship holds in the mathematics, the code and the demo.

    Next action

    You can state the mechanism in your own words

    Evidence4 checks
    ObservationChecking for a saved observation
    ActionReady for one action
    PromptLearner prompt ready to copy
    Go to this item
    01ObservationChecking what this browser has saved
    02EvidenceChecking for a saved observation
    03SourcesCheck the 3 cited sources listed under Sources.
    04Next stepSave one next action
    Local action draftNo local draft saved yetOpen when you are ready to write one next action
    Local action draft

    This draft stays in this browser and is attached to this item only.

    No local draft saved.
    Evidence to inspect
    • What the 3 cited sources say about this exact item
    • The definition, its prerequisites, and a contrasting concept
    • The equation or code that makes the concept concrete
    • One demo state that shows what stays the same as the inputs change
    What would resolve this
    • You can state the mechanism in your own words
    • You can name the prerequisite that would clear up the confusion
    • You can predict how the result changes when one input changes
    Reference idconcept/concept-notebook/scaling/tree-search-reasoning concept:scaling/tree-search-reasoning