---
title: 'LeanTree: Efficient Tree Methods in ML & Proof Search'
url: https://www.emergentmind.com/topics/leantree
type: topic
---

# LeanTree: Efficient Tree Methods in ML & Proof Search

Searching arXiv for the cited LeanTree-related papers and closely related work.
I’ll look up the arXiv records to ground the article in the relevant papers.
Searching for "LeanTree" and the specified arXiv IDs.
LeanTree is a name used for multiple distinct tree-based methods in contemporary machine learning and automated reasoning research. In the sources considered here, it denotes three different systems: a guided tree-search procedure for large language model reasoning introduced under the title "LiteSearch: Efficacious Tree Search for LLM" [2407.00320]; a label-tree construction method for extreme multi-label classification [2106.00730]; and a Lean 4 toolkit and dataset for white-box proof search with factorized states [2507.14722]. The shared motif is not a single unified algorithm, but the use of tree structure to make large search or prediction spaces computationally tractable.

## 1. Distinct meanings of the term

The three uses of LeanTree differ in domain, object of search, and optimization target.

| Domain | Tree object | Primary trade-off |
|---|---|---|
| LLM mathematical reasoning | Partial chain-of-thought search tree | Accuracy versus tokens generated |
| Extreme multi-label classification | Label tree over a very large label set | Latency versus statistical performance |
| Lean 4 automated theorem proving | Factorized proof-state tree / AND-OR structure | Proof success versus state size, parallelism, and verifier interaction |

In the LLM setting, the root is the question \(q\), and each node is a partial chain of thought \(\mathcal{S}_i=(q,s_1,\dots,s_i)\) [2407.00320]. In the extreme classification setting, each leaf corresponds to one label and internal nodes support binary decisions during beam search [2106.00730]. In the Lean 4 setting, a proof state is a finite sequence of open goals, and factorization is defined by the connected components of a dependency graph over metavariable sharing [2507.14722].

This suggests that the term "LeanTree" is best understood as a recurrent naming convention for efficiency-oriented tree structuring, rather than as a single research lineage.

## 2. Guided tree search for LLM reasoning

In "LiteSearch: Efficacious Tree Search for LLM," LeanTree refers to a guided tree-search algorithm designed for multi-step mathematical reasoning [2407.00320]. The motivation is explicit: greedy decoding ("System 1") is fast but error-prone on multi-step math problems, whereas off-the-shelf tree searches such as DFS, BFS, and MCTS can improve accuracy but typically consume \(5\text{–}10\times\) more LLM compute, measured in tokens generated.

The core design has three parts. First, a learned value network estimates the "promise" of a partial reasoning node without requiring step-wise labels. Second, node selection combines estimated future success with current progress along the greedy trajectory. Third, each selected node receives a node-level exploration budget \(b\), interpreted as the maximum number of children to expand, with the budget shrinking as estimated value rises and as depth grows. The search alternates between selection and budgeted expansion until either a complete answer with value exceeding a threshold is found or the iteration budget is exhausted.

The node-selection rule combines a value term \(v(\mathcal{S})\) and a progress term \(p(\mathcal{S})\):
\[
\mathcal{S}^*
=
\arg\max_{\mathcal{S}}
\bigl[v(\mathcal{S})+\lambda\,p(\mathcal{S})\bigr],
\]
where \(\lambda\ge 0\) balances exploitation versus fastest-progress. In practice, \(p(\mathcal{S})\) is described as \(\tfrac{\text{\#steps in }\mathcal{S}}{\text{\#steps in greedy chain}}\) or similarly for tokens.

Budget computation is depth- and value-dependent:
\[
b
=
\min\Bigl(
\Bigl\lceil\frac{\log(1-\epsilon)}{d\,\log\bigl(1-v'(\mathcal{S})\bigr)}\Bigr\rceil,
B
\Bigr),
\]
where \(\epsilon\) is a target cumulative success probability and \(B\) is a user-set upper bound. The calibrated value is
\[
v'(\mathcal{S})
=
\frac{\,v(\mathcal{S})+\tfrac{\hat v}{d}\,}{1+\tfrac1d},
\]
so that the first few steps are nudged toward the value \(\hat v\) of the corresponding greedy-chain node. The paper states the intended effects directly: the deeper \(d\) is, the smaller \(b\), and the higher the calibrated value \(v'(\mathcal{S})\), the smaller \(b\).

Value-network training uses only final-answer supervision. If \((s_1,\dots,s_n,\hat y)\sim\pi(q)\) is a sampled full chain and \(r=\mathbb{I}[\hat y=y]\in\{0,1\}\) indicates whether the final answer matches the gold answer, then every prefix \(\mathcal{S}_i\) receives that delayed reward under the MSE loss
\[
\mathcal{L}
=
\bigl(v(\mathcal{S}_i)-\mathbb{I}[\hat y=y]\bigr)^2,
\quad
\forall\,i=0,\dots,n.
\]
The model instantiation described in the source uses Llama3-8B’s last-token hidden state with a linear head \(\mathrm{Head}:\mathbb{R}^d\to[0,1]\).

Empirically, the paper reports near-MCTS/BFS performance at only \(\sim 20\%\) of the token cost. On GSM8K with Mixtral-8×7B, the reported figures include: Greedy \(0.607 @0.14\text{k}\), SoftVoting@10 \(0.830 @1.32\text{k}\), LeanTree-Batch \(0.823 @0.55\text{k}\), and LeanTree-Incr \(0.797 @0.41\text{k}\). On TabMWP with Mixtral-8×7B, the reported figures are: Greedy \(0.762 @0.07\text{k}\), SoftVoting@10 \(0.832 @0.73\text{k}\), LeanTree-Batch \(0.854 @0.29\text{k}\), and LeanTree-Incr \(0.863 @0.22\text{k}\). A further GSM8K comparison reports MCTS+Rerank at \(0.877\) accuracy and \(1.89\text{k}\) tokens, SoftVoting@20 at \(0.843\) and \(2.63\text{k}\), LeanTree-Batch at \(0.823\) and \(0.55\text{k}\), and LeanTree-Incremental at \(0.797\) and \(0.41\text{k}\).

The ablation claims are equally specific. Replacing the adaptive budget by a static \(B\) roughly triples the token cost with no accuracy gain, and removing the depth penalty or greedy calibration degrades either cost or performance. Sensitivity to \(B\) and \(\lambda\) is described as smooth, permitting explicit speed-versus-accuracy tuning. Deployment guidance distinguishes **Incremental** expansions as the lowest-cost mode and **Batch** expansions as the highest-accuracy mode; recommends a single mixed-domain value network in multiple reasoning domains; advises calibration of the first few steps with greedy-chain values; introduces an optional fallback threshold \(\alpha\) on \(v(\mathcal{S}_{\rm final})\); and notes that the value network can be deployed in parallel because its cost is \(\ll\) LLM decoding cost.

## 3. Label-tree construction for extreme multi-label classification

In "Enabling Efficiency-Precision Trade-offs for Label Trees in Extreme Classification," LeanTree denotes a method for constructing label trees in extreme multi-label classification (XMC) [2106.00730]. The formal setup uses training examples \(\{(x_i,y_i)\}_{1\le i\le n}\) with \(x_i\in\mathbb{R}^d\) and sparse label vectors \(y_i\in\{0,1\}^L\), where \(L\) may be \(10^5\text{–}10^7\). The motivation is that a naive 1-vs-All approach incurs \(O(L)\) inference cost per query, whereas a label tree can support \(O(\log L)\) inference when balanced.

The tree semantics are operational. Each leaf \(\ell\in[L]\) is assigned to one label. Each internal node trains a binary classifier to decide whether the set of true labels lies in the left subtree or the right subtree. Inference proceeds by beam search, extending only the top \(B\) partial paths at each level; if the tree is balanced, the expected number of node evaluations is \(O(B\log L)\).

The defining contribution is a multi-objective criterion that interpolates between latency and accuracy. For leaf depths \(d_T(\ell)\) and label marginals \(p_\ell=P\{\ell\in\text{true labels}\mid x\}\), the expected-depth proxy is
\[
E[\mathrm{Depth}(T)] = \sum_{\ell=1}^L p_\ell\cdot d_T(\ell).
\]
For empirical loss \(L(T)=\tfrac{1}{N}\sum_{i=1}^n L_i(\hat h_T,x_i)\), the combined objective is
\[
J_\lambda(T)
=
\lambda\cdot E[\mathrm{Depth}(T)] + (1-\lambda)\cdot L(T),
\]
where \(\lambda\in[0,1]\) trades off latency versus accuracy. The construction is top-down and recursive, with each split optimized by a fast alternating-maximization solver over label assignments \(\alpha\), unit vectors \(\mu_+\) and \(\mu_-\), and a balance constraint \(\alpha^T f(\lambda)=0\). The source describes the corresponding surrogate as combining "similarity-driven" clustering and "frequency-driven" splitting.

The method is explicitly linked to information theory. Entropy \(H(p)=-\sum_\ell p_\ell\log p_\ell\) is cited as a lower bound on the expected code length of any prefix-free code, and Fano’s code is invoked as a top-down scheme that splits the symbol set into two subsets with total probability as close to \(\tfrac12\) as possible, producing expected depth at most \(H(p)+1\). As \(\lambda\to 2\), the LeanTree surrogate reduces to a Fano-style frequency split at each node and thus nearly minimizes expected depth. At \(\lambda=0\), the method becomes balanced spherical 2-means on label embeddings \(v_\ell\), matching the similarity-driven extreme.

The recursive construction algorithm is defined by alternating updates. Given a label subset \(S\), if \(|S|\le \mathrm{leafSize}\), \(S\) becomes a leaf. Otherwise, node-specific weights \(f_\ell(\lambda)\) are computed, \(\alpha_\ell\) and \(\mu_\pm\) are initialized, and the algorithm repeats until stationary: with \(\alpha\) fixed, update \(\mu_+\propto \sum_{\ell:\alpha_\ell>0} f_\ell(\lambda)v_\ell\) and \(\mu_-\propto \sum_{\ell:\alpha_\ell<0} f_\ell(\lambda)v_\ell\), then normalize; with \(\mu_\pm\) fixed, compute
\[
\beta_\ell\leftarrow\frac{2-\lambda}{2}\,f_\ell(\lambda)\,v_\ell^T(\mu_+-\mu_-)
+
(\lambda-1)_+\,[f_\ell(\lambda)]^2,
\]
and solve
\[
\max_{\alpha\in[-1,+1]^m,\ \alpha^T f(\lambda)=0}\ \alpha^T\beta
\]
in \(O(m\log m)\) time by sorting \(\beta_\ell/f_\ell(\lambda)\). The full tree is built in \(O(L\cdot d\cdot \log L)\) time with \(O(Ld)\) memory for embeddings and \(O(L)\) for frequencies.

The empirical record spans public benchmarks and proprietary e-commerce data. On Wiki-500K, LeanTree with \(\lambda\approx 0.2\) reduces expected depth@1 by \(28\%\) relative to Parabel at equal precision@1. On Amazon-670K and AmazonCat-13K, the reported Pareto curves show that small increases in expected depth yield large gains in precision, and vice versa. Replacing FastText hierarchical-softmax with LeanTree at \(\lambda\approx 1.8\) improves p@1 on Wiki-500K by \(40.6\%\) at only \(+6.5\%\) increase in expected depth. On five e-commerce logs with \(705\text{K}\to 10\text{M}\) labels, LeanTree maintains p@1 while reducing expected depth@1 by \(10\text{–}20\%\).

Practical considerations are central to the paper. For \(k>1\), two heuristics for constructing the Fano-style frequency vector \(\tilde f\) are described: greedy removal and assigning each context to its most frequent label. Local optima are acknowledged, and \(3\text{–}5\) random restarts per node are reported to suffice in practice. The paper also notes that realizing expected-depth savings as wall-clock gains requires adaptive beam search that stops when \(k\) high-confidence leaves are found, rather than always traversing to fixed depth, and recommends Laplace smoothing \(\gamma\approx 0.1\) to guard against train/test distribution shift in frequencies.

## 4. White-box proof search with factorized states in Lean 4

In "LeanTree: Accelerating White-Box Proof Search with Factorized States in Lean 4," LeanTree denotes both a tool built in the Lean 4 language and a dataset of factorized intermediate proof states [2507.14722]. The paper frames the work against a standard distinction in automated theorem proving. In black-box ATP, the model receives a theorem statement \(T\) and must generate a complete proof \(\pi\) in one shot, with only final verification \(\mathrm{verify}(T,\pi)\in\{\mathsf{True},\mathsf{False}\}\). In white-box ATP, proof construction is incremental:
\[
S_0 \xrightarrow{t_1} S_1 \xrightarrow{t_2} \dots \xrightarrow{t_n} S_n,
\]
and success occurs when \(S_n\) has no open goals.

The difficulties for white-box search are identified as state-size explosion, branching factor, and lack of tooling and data. In Lean, a proof state \(S\) is a list of open goals, and each goal accumulates local hypotheses from previous steps. Tactics such as `cases` or `induction` create multiple subgoals; without factorization, the prover operates on a monolithic list of goals and loses the opportunity to solve independent subgoals in parallel.

The system architecture has two layers. At the verifier level, LeanTree patches the official Lean REPL to report open goals and contexts after each tactic, factorize states, and incremental-verify only the new assignments. At the orchestration level, a thin Python wrapper manages a pool of Lean processes and exposes three API calls: `load_file(path)`, `apply_tactic(state_id, tactic_str)`, and `factorize(state_id)`.

The formal representation is graph-theoretic. A proof state is
\[
S=(g_1,\dots,g_n),
\]
where each goal \(g_i\) is a metavariable \(?_i:\tau_i\) together with a local context \(\Gamma_i\). Two goals are coupled if they share at least one metavariable. This induces the dependency graph
\[
G_S=(V,E),\quad V=\{1,\dots,n\},\quad
(i,j)\in E \iff g_i,g_j\text{ share a metavariable.}
\]
Theorem 2.2 states that the connected components of \(G_S\) partition \(S\) into independent sub-states
\[
S = S_1\dot\cup\dots\dot\cup S_K,
\quad
S_k=\{g_i\mid i\in C_k\},
\]
and that no tactic that closes goals in \(S_k\) can affect goals in \(S_{k'}\) for \(k'\neq k\). The factorization algorithm therefore consists of building the dependency graph, finding connected components, and partitioning the goal list accordingly.

The associated dataset is large-scale. Its sources are *Mathlib 4*, contributing \(74\,706\) factorized tactic proofs, and *DeepSeek-Prover-V1*, contributing \(26\,201\) proofs. The total is
\[
|\mathcal{P}|=74\,706+26\,201=100\,907.
\]
Each theorem record stores imports and, for each `by`-block, a proof tree whose nodes contain `id`, `proof_size`, `proof_depth`, `state.goals`, `tactic_string`, `children`, and `tactic_depends_on`. Verification is performed by replaying each tree in Lean REPL with incremental kernel-checking. The average branch count is reported as
\[
\bar K
=
\frac{1}{|\mathcal{P}|}\sum_{p\in\mathcal{P}} K(p)
\approx 1.10,
\]
with the accompanying observation that most proofs are linear but a nontrivial tail has \(K(p)>1\).

The factorization analysis is quantitative. Original context complexity is defined as
\[
C_{\rm orig}(S)=\sum_{i=1}^n |\Gamma_i|,
\]
while factorized complexity is
\[
C_{\rm fact}(S)=\max_{1\le k\le K}\sum_{g\in S_k}|\Gamma_g|.
\]
The reduction ratio satisfies
\[
\frac{C_{\rm fact}(S)}{C_{\rm orig}(S)}\le \frac{1}{K}.
\]
For search time, serial roll-out cost is \(T_{\rm serial}=\sum_{k=1}^K T(S_k)\), ideal parallel cost is \(T_{\rm par}=\max_k T(S_k)\), and the speedup is described by
\[
\frac{T_{\rm serial}}{T_{\rm par}}
\approx
\frac{\sum_k T(S_k)}{\max_k T(S_k)}
\xrightarrow[K\gg1]{} K.
\]
The implementation also hashes factorized substates by their multisets of goals for state reuse and attaches Lean error codes to failing tactic edges to support pruning without discarding unaffected branches.

The reported experiments are preliminary but concrete. Using Llemma-7B on the Lean 4 version of MiniF2F with \(488\) test theorems, the procedure performs \(N=10\) independent linear rollouts of up to \(M=25\) tactics. The success rates are:

| Method | Success rate |
|---|---|
| Whole-proof generation | \(9.59\% \pm 0.71\) |
| Black-box linear rollout (\(N=10\)) | \(5.32\% \pm 0.37\) |
| White-box linear rollout (\(N=10\)) | \(18.36\% \pm 0.60\) |
| Best-first search | \(26.23\%\) |

The paper states that providing factorized states more than triples the success rate compared to black-box rollout, and that white-box linear rollout outperforms full proof generation in one shot.

## 5. Recurrent technical patterns across the three LeanTree usages

Despite the absence of a single common algorithm, the three LeanTree variants share several structural patterns. Each introduces a decomposition of a large combinatorial object into locally manageable units. In LLM reasoning, the units are partial chains of thought with value-guided node selection and node-level exploration budgets [2407.00320]. In extreme classification, the units are recursively partitioned label subsets with a tunable split criterion controlled by \(\lambda\) [2106.00730]. In Lean 4 proof search, the units are independent sub-states derived from connected components of a dependency graph over goals [2507.14722].

Each usage also defines a specific efficiency metric. The LiteSearch version measures compute in generated tokens and explicitly compares against greedy decoding, MCTS, BFS, and SoftVoting. The XMC version uses expected depth@\(k\) and precision@\(k\), and relates tree structure to prefix-code length and beam-search latency. The Lean 4 version defines context-size reduction, ideal parallel speedup, and theorem-proving success rate under verifier interaction. This suggests that "LeanTree" is repeatedly associated with controllable operating points rather than with a fixed optimization target.

A further commonality is that all three systems avoid purely exhaustive search. The LLM version shrinks the exploration budget for deeper or higher-valued nodes. The XMC version does not optimize solely for balanced depth or solely for similarity clustering, but interpolates between them. The Lean 4 version does not insist on monolithic proof-state expansion, but instead factorizes and reuses independent substates. A plausible implication is that the name has been attached, in multiple subfields, to methods that seek efficiency by selective expansion rather than brute-force enumeration.

## 6. Scope, misconceptions, and open directions

A common misconception would be to treat LeanTree as one method with a stable meaning across arXiv. The record here does not support that interpretation. The term refers, in different papers, to a lightweight value-guided tree search for LLM reasoning [2407.00320], a label-tree construction algorithm for XMC [2106.00730], and an open-source Lean 4 toolkit with a factorized-state dataset for white-box proof search [2507.14722].

Another misconception would be to view all three solely as accuracy-improvement methods. The explicit objectives are broader. The LiteSearch paper emphasizes competitive performance at significantly lower computational cost and reports \(15\text{–}25\%\) of the tokens relative to baseline methods. The XMC paper is organized around an efficiency-precision trade-off and states latency improvements such as \(28\%\) on Wiki-500K at equal accuracy and \(10\text{–}20\%\) on e-commerce logs while maintaining p@1. The Lean 4 paper foregrounds context reduction, parallel search across branches, efficient reuse of states, and feedback in case of errors, and describes its experimental findings as preliminary.

The open problems are domain-specific. In the LLM setting, deployment guidance already anticipates value-network misestimates via a fallback threshold \(\alpha\) and a small SoftVoting run. In XMC, the source highlights local optima in alternating maximization, sensitivity to frequency shift, and the engineering difficulty of translating expected-depth gains into wall-clock savings. In Lean 4 proof search, the paper lists future work including retrieval-augmented models in the white-box loop, more sophisticated AND-OR search algorithms such as MCTS or best-first, support for more advanced Lean tactics such as `calc` and `conv`, and reinforcement learning for discovering new proof strategies.

Taken together, these works show that LeanTree is not a single canonical technique but a family of efficiency-oriented tree formulations that appear in distinct research programs. The stable theme is explicit control over combinatorial growth: through value-guided budget allocation, information-theoretic tree construction, or graph-based factorization of proof states.

Source: https://www.emergentmind.com/topics/leantree