BES：别只让模型往前猜，倒着拆目标再重组答案

你有没有见过这种场景：同一个数学题、同一个多跳问答，模型采样 64 次、128 次，答案堆了一地，verifier 最终挑出来的还是错的。

更烦的是，错法还挺像。模型并不是没有努力，它只是一直在自己熟悉的概率区域里打转。Best-of-N 是多抽几张彩票；tree search 是沿着几条看起来不错的路继续走。问题在于，如果正确解一开始就不在这些高概率路径附近，算力加上去也未必能救回来。

这篇 arXiv:2605.28814 的论文《Self-Improving Language Models with Bidirectional Evolutionary Search》抓住的就是这个痛点。作者提出 BES（Bidirectional Evolutionary Search，双向进化搜索）：一边让候选答案继续往前长，一边把目标倒着拆成可检查的子目标；更关键的是，它不只做自回归扩展，还会像遗传算法一样，把不同候选轨迹里的有用片段剪切、替换、拼接。

我的第一反应是：这个方向挺合理。现在很多 post-training 和 inference-time search 方案都太依赖“从模型分布里多采一点”。BES 这篇论文真正有意思的地方，不是又包了一层复杂搜索，而是把两个很朴素但长期被分开处理的问题放在了一起：搜索空间太窄，以及反馈太稀疏。

论文信息

• 论文：Self-Improving Language Models with Bidirectional Evolutionary Search
• arXiv：2605.28814v1
• 链接：https://arxiv.org/abs/2605.28814
• 作者：Guowei Xu, Zhenting Qi, Huangyuan Su, Weirui Ye, Himabindu Lakkaraju, Sham M. Kakade, Yilun Du
• 机构：Harvard University；MIT（arXiv 摘要页未单独列机构，HTML 正文显示该信息）
• 提交时间：2026 年 5 月 27 日
• 代码与模型：https://github.com/Embodied-Minds-Lab/BES

一句话概括：BES 用“前向进化重组 + 后向目标分解”改造搜索过程，在 post-training 的样本生成和 inference-time open problem solving 上都拿到了更稳的结果。

核心摘要：BES 想解决的不是“采样不够多”，而是“采样方式太老实”

传统 best-of-N 和 tree search 有个共同假设：只要从模型概率分布里采够多，正确解迟早会被碰到。这个假设在简单题上经常成立，在难题上就很悬。论文指出，纯自回归扩展会把候选限制在一个“窄熵壳”里，模型越相信什么，搜索越围着什么转；如果正确解需要跨出这个区域，继续加 rollout 只是在熟悉的错误附近绕圈。BES 的做法是双向的：forward search 负责生成和重组候选，backward search 负责把最终目标拆成可验证子目标，给中间轨迹打分。实验里，MuSiQue 多跳推理上 BES 把 Llama-3.2-3B 的准确率从 base 的 4.0% 拉到 7.0%，Llama-3.1-8B 从 6.6% 拉到 10.4%；在三个 open problem solving benchmark 上，BES 也超过 OpenEvolve、GEPA、ShinkaEvolve 等开源框架。说实话，绝对分数不算惊天动地，但它展示了一个很重要的信号：搜索质量比采样数量更值钱。

这篇论文到底在挑战什么？

LLM 自我改进里有两条常见路线。

一条是 post-training：让模型自己生成训练样本，再用 verifier 或 reward 选高质量轨迹继续训练。GRPO 就属于这个大框架里很典型的一类方法。DeepSeekMath 里提出的 GRPO 用组内相对奖励估计优势，少了 critic，工程上很轻便，所以后来在 reasoning RL 里用得很多。

另一条是 inference-time search：不改模型参数，只在推理时花更多计算，找更好的答案。Best-of-N、beam search、MCTS、Tree of Thoughts，还有近两年各种 evolutionary coding agent，都在这个方向上卷。

但这两条路都容易碰到同一个坑：

这篇论文的判断很直接：问题不只是“verifier 稀疏”，也不只是“搜索不够大”。真正麻烦的是，候选生成机制本身太单调。

你想想看，tree search 里的每个节点都来自前一个节点的自回归扩展。它看起来是一棵树，实际还是模型分布的影子。模型原本不太会走到的区域，树也很难突然走过去。

BES 试图打破这个惯性。

图 1：BES 的核心直觉，一张图就讲清楚了

图1：左边的 tree search 只能沿着 expansion 扩展，蓝色椭圆代表它容易覆盖的候选区域；右边的 BES 通过 evolution 把不同路径的片段重组出去，再用 backward decomposition 把目标拆成多个可验证子目标。绿色节点是目标或子目标，红色箭头是最终验证。

我挺喜欢这张图。它没有把 BES 说成“更大的树”，而是强调一个更微妙的点：搜索不是只往前长，也可以横向重组，还可以从目标倒推反馈。

左边的 tree search 走法很熟悉：从 problem 出发，一步步扩展 search step，最终试图碰到 goal。问题在于，扩展出来的候选都在“reachable solutions by expansion”这块蓝色区域里。论文后面把它形式化成窄熵壳。

右边的 BES 多了两件事。

一件是紫色虚线的 evolution：候选轨迹之间可以互相借片段。一个路径的前半段可能是对的，另一个路径的后半段可能是对的，标准 tree search 很难把它们合成一个新候选；BES 会尝试这样做。

另一件是绿色的 decomposition：最终 goal 被拆成 subgoal。哪怕某个候选暂时没解决完整问题，只要它满足了某个子目标，也能获得中间反馈。这个反馈会反过来指导 forward search 选择父节点和操作符。

这就是 BES 的“bidirectional”。不是普通意义上的双向 BFS，而是“生成方向”和“目标分解方向”同时动。

方法拆开看：Forward Search 负责造候选，Backward Search 负责给方向

论文把任务写成：

这里 \(x\) 是问题，\(V(x,y)\in[0,1]\) 是 verifier，\(y\) 是候选轨迹。目标是在所有终止轨迹里找 verifier 分最高的那个：

公式不复杂。工程上可以理解成：你有一道题、一个评分器、一堆半成品答案，想在预算内尽快拼出一个高分完整答案。

BES 维护一个候选池 \(\mathcal{P}\)。每个候选节点是部分轨迹：

每一步搜索会做两件事：从候选池里选父节点，生成新候选；再用 backward goal tree 给新候选打分。

Forward Search：不再只会 Expansion

普通 expansion 还是保留。给定当前节点 \(n=(y_1,\dots,y_t)\)，模型继续采样若干步：

这就是大家熟悉的自回归往前写。

但 BES 真正的变化来自 evolution operators。

图2：BES 的 forward search 操作。Expansion 继续生成新步骤；Combination 拼接两个分支的不同后缀；Deletion 删除中间错误步骤；Translocation 把另一路径中的局部步骤移植过来；Crossover 用另一条路径的尾部替换当前路径尾部。

这五类操作很像把推理轨迹当作“可编辑对象”。

Expansion 是常规续写。Combination 会把两个有公共前缀的轨迹后缀拼起来。Deletion 删掉一个内部步骤，适合处理“中间绕错但后面还有价值”的轨迹。Translocation 更激进，它从路径 B 拿一个步骤替换路径 A 中某个步骤。Crossover 则像遗传算法，把 A 的前半段和 B 的后半段接起来。

坦率地讲，这些操作单看都不神秘。真正的难点是：什么时候该对哪两个候选做哪种操作？如果随便拼，生成的大概率是一坨语义不通的东西。

这里 backward search 就派上用场了。

Backward Search：把“最终正确”拆成“局部有用”

Backward search 从根目标 \(g_{\texttt{root}}\) 开始，也就是“解决完整问题”。模型会递归地把目标拆成子目标，形成一棵 goal tree。每个目标 \(g\) 都有一个局部 verifier：

候选 \(n\) 对目标 \(g\) 的分数定义为：

如果 \(g\) 是叶子目标，分数就是 \(V_g(x,n)\)。如果某个目标已经完全满足，直接短路为 1。

这个设计有个很实际的好处：一个候选不必立刻解完整题，只要它完成了某些子目标，就能被保留下来。

比如多跳问答里，完整问题可能需要三步：找到歌曲、找到唱片公司、找出后来归属。普通 verifier 只有最终答案对错；BES 可以把这些中间目标拆出来。某条路径虽然最终答错，但它正确找到了“谁录制了这首歌”；另一条路径虽然另一个环节错了，但找到了“唱片公司后来被谁收购”。这两个半成品就有机会被 translocation 拼成正确答案。

这也是我觉得 BES 最像“人类调试推理”的地方。我们解复杂题时也不是只盯最终答案，而是会说：这一步有用，那一步别要，把另一个思路里的中间结论搬过来试试。

父节点怎么选？BES 用分数，也留一点探索空间

BES 对单父操作和双父操作分别设计了采样方式。

对 expansion、deletion 这种单父操作，父节点按 Boltzmann 分布采样：

其中：

论文里 \(\lambda=0.1\)。这相当于给还没当过父节点的候选一点小奖励，避免候选池过早围着少数高分节点转。

对 combination、translocation、crossover 这种双父操作，BES 会选一对父节点 \((n_a,n_b)\)。pair score 的关键不是两个候选各自多强，而是它们合起来覆盖了多少子目标：

这里的 \(\max\) 很关键。它会奖励互补性：A 满足子目标 1，B 满足子目标 2，那么这对父节点就值得被拿来重组。

这个地方其实挺工程。很多搜索方法失败不是因为没有候选，而是候选池里有一堆“局部正确、整体错误”的东西，没人知道该怎么组合。BES 用 backward sub-goal 给了一个可操作的组合依据。

理论部分：为什么普通 expansion 会被困住？

论文给了两个理论动机。

第一个叫 shell confinement and escape。粗略讲，纯 expansion-only search 采到的完整轨迹大多落在模型分布的典型集里：

论文证明，普通 expansion 跑出来的候选跳出这个集合的概率指数级小：

直觉很简单。自回归模型每一步都按自己的条件分布采样，长轨迹的整体概率会集中在一个典型范围。你采很多条，也主要是在这个范围里换花样。

Evolution operators 不一样。它们把不同轨迹的局部片段重新组合，生成的序列不再等价于从原模型分布单次 rollout 得到。论文用 \(Q=\bigotimes_{j=1}^{k}P_j\) 表示这种重组分布，并证明在一定条件下，evolution candidate 有正比例概率逃出原来的熵壳。

我不觉得这段理论能完全证明 BES 在真实 LLM 上一定成功，但它给了一个不错的解释框架：BES 的收益不是“采样数更大”，而是“候选分布变了”。

第二个理论动机来自 backward sub-goal signals。假设任务被拆成 \(m\) 个叶子子目标，每个子目标被满足的概率是 \(p_i\)。如果只看最终成功，采样复杂度大概是：

如果能利用子目标反馈，论文给出的量级是：

对称情况下，优势会随子目标数量呈指数级拉开。

当然，这里有个前提：子目标得拆得靠谱，局部 verifier 也要靠谱。真实任务里这两件事不总是免费成立。这个坑后面再聊。

Post-training 实验：困难任务里，BES 主要赢在样本生成质量

论文把 BES 用在两类 post-training 任务里：Knights-and-Knaves 逻辑推理，以及 MuSiQue 多跳问答。

Knights-and-Knaves：GRPO 和 MaxRL 不动，BES 还能往上爬

Knights-and-Knaves 是经典逻辑谜题：每个人要么永远说真话，要么永远说假话，模型需要推断所有人的身份。

设置如下：

• Base model：Gemma-3-1B-it
• Cold start：1K SFT examples，微调 3 epochs
• Post-training：5K problems，4 epochs
• 验证集：1.3K validation set
• Baselines：GRPO、MaxRL
• BES 叠加在 MaxRL 上，用更好的搜索替代普通样本生成

图3：Knights-and-Knaves 上的 EMA 平滑验证曲线。图中纵轴是负对数准确率，数值越往上对应准确率越好。红色 BES 曲线后半段明显优于 GRPO 和 MaxRL，论文正文没有给出精确表格数值。

这张图不要过度读具体点位，因为它是平滑曲线，也没有附数值表。但趋势很清楚：GRPO 和 MaxRL 基本原地震荡，BES 后半段持续改善。

我的理解是，这里 BES 不是直接改 RL 算法本体，而是在训练前拿到更好的候选轨迹。困难逻辑题里，普通 rollout 很难碰到完整正确解，reward 信号就会很差。BES 通过目标分解和轨迹重组，把“半对的推理”变成可用训练信号。

这对 post-training 很关键。RL 不是魔法，如果采样阶段给不出好东西，优化器再漂亮也只能优化噪声。

消融：answer reweighting 和 evolution operators 都有贡献

图4：逻辑推理任务消融。完整 BES 表现最好；去掉 answer reweighting 或 evolution operators 都会变弱，但仍然强于 GRPO 与 MaxRL，说明 backward-guided search 本身已经带来收益，进化操作和重加权进一步加分。

图4 里有四条关键曲线：完整 BES、去掉 answer reweighting、去掉 evolution operators，以及 GRPO/MaxRL baseline。

这个消融给的信息挺有用。完整 BES 最强；少了 evolution operators，曲线明显弱一些；少了 answer reweighting 也会掉。但两个 ablation 仍然比普通 GRPO 和 MaxRL 好。

这说明收益不是某个 trick 单独撑起来的。Backward-guided search 自身有价值，evolution operators 让候选空间更开，answer reweighting 则帮助训练阶段更好利用答案质量。

MuSiQue 多跳问答：数字不大，但方向很清楚

MuSiQue 是多跳问答任务，需要模型跨多个文档检索、整合信息。论文采用 Tree-GRPO 的训练设置：agent 可以执行多次搜索动作，再给最终答案；搜索结果来自离线 Wikipedia server。

模型包括：

• Llama-3.2-3B-Instruct
• Llama-3.1-8B-Instruct

训练集是 MuSiQue 的 3–4 hop solvable subset，训练 2 epochs。作者还提到更多 epochs 会导致 training collapse。

主结果如下。

看到这个表，我有两个反应。

一个是 BES 的提升方向很干净。3B 上从 4.0 到 7.0，8B 上从 6.6 到 10.4。valid search、valid actions、finish ratio 也一起上去了，说明模型不是靠猜最终答案刷分，而是真的更愿意做搜索动作并完成任务流程。

另一个反应是：绝对准确率仍然很低。10.4% 不该被包装成“解决多跳问答”。这个任务确实难，baseline 也低，但从工程落地看，它更像 proof-of-concept：BES 能让搜索型训练少崩一点、多走几步，但离稳定可用还有距离。

成本表也值得看。

BES 比 Tree-GRPO 慢，从 240s 到 309s，增加不到 30% 的 wall-clock overhead。换来的是准确率从 3.9 到 7.0。这个 trade-off 我觉得可以接受，前提是你的瓶颈真的是“搜索样本质量”，不是 verifier 或检索系统本身太差。

Inference-time open problem solving：BES 更像一个“搜索增强器”

论文还把 BES 放到 open problem solving 里测试，包括三个任务：

• Circle Packing Square：在单位正方形里放 N 个圆，最大化半径
• Circle Packing Rectangle：在矩形里放圆，最大化半径
• Heilbronn Convex：在单位正方形里放点，最大化某类凸多边形的最小面积

Backbone model 是 GPT-5。BES 叠加在 ShinkaEvolve 上。baseline 包括 OpenEvolve、GEPA、ShinkaEvolve，参考值还列了 Human 和 AlphaEvolve。

因为这里的候选是可执行程序，不能像文本推理那样直接把两段输出硬拼起来。论文用 LLM prompting 实现 evolution operators，让模型根据操作意图去改候选程序。

这里 BES 的表现很稳。Square 平均值 2.623，高于 GEPA 的 2.613；Rectangle 平均值 2.349，高于 ShinkaEvolve 的 2.335；Heilbronn best 和 OpenEvolve/GEPA 持平，但平均更高、方差更低。

但也别忽略另一层信息：BES 距离 Human 和 AlphaEvolve 的 best 仍有差距。Square 上 BES best 2.632，Human 2.634，AlphaEvolve 2.635；Rectangle 上 BES best 2.360，Human 2.364，AlphaEvolve 2.3658。

所以我更愿意把 BES 定位成“开源搜索框架上的增强器”，而不是 open problem solving 的终局答案。

成本也更高。

Square 的成本从 13.0 美元涨到 18.6 美元；Rectangle 从 11.9 到 14.0；Heilbronn 从 11.5 到 13.7。

这不是免费的提升。要不要用 BES，取决于你对“更高 best candidate”和“更低方差”的价值判断。如果你在做一次性高价值搜索，比如算法发现、程序优化、复杂 agent workflow，贵一点可以接受；如果只是线上每次 query 都跑，成本可能很快压不住。

图 5：一个多跳问答 case，展示 translocation 为什么有用

图5：BES 的多跳问答案例。两个 expansion 分支都走向错误答案，但右侧分支里有一个可移植的中间推理步骤。Translocation 把该步骤搬到左侧分支，生成正确答案。下方 backward search 把问题拆成多个子目标，并用绿色虚线给满足子目标的候选提供反馈。

这张 appendix 图其实很适合理解 BES 的工程价值。

题目涉及 James Blunt、Back to Bedlam、唱片公司归属。两个 forward 分支单独看都错：一个过早认定是 Atlantic Records，另一个说 Custard Records 和 Atlantic Records 都参与过，但没给出最终需要的唱片公司归属。

Translocation 做的事是，把右分支里有用的局部信息移植到左分支，得到正确答案：最初录制 Back to Bedlam 的唱片公司是 Custard Records，后来发行权被 Atlantic Records 收购，所以该艺术家现在属于 Warner。

这就是“半对答案”的价值。普通 verifier 只会说两个分支都错；BES 的 backward search 会看到它们分别满足某些子目标，然后 evolution operator 尝试把局部正确拼起来。

说实话，这个机制在 agent 任务里很有吸引力。很多失败轨迹并非全错，而是某个工具调用、某个检索结果、某段推理链有价值。把这些局部资产复用起来，比从头再采样聪明得多。

BES 和几类相关方法放在一起看

为了避免被“自我改进”“双向进化”这些词带着跑，我更建议把 BES 放进现有方法谱系里看。

BES 不是凭空出现的。它像是把 tree search、evolutionary search、goal decomposition 三条线拧在一起。

这也是它的优点和风险来源。优点是信息利用率更高；风险是系统复杂度上来了，每一环都可能出问题。

我觉得最有价值的三个点

1. 把“候选生成分布”作为核心问题，而不是只谈搜索预算

很多 inference-time scaling 讨论都在问：N 要多大？beam 要多宽？预算要加多少？

BES 换了一个问法：如果候选都来自同一个自回归分布，加预算真的能扩展到新区域吗？

这个问题很重要。尤其在 hard reasoning 里，模型的高概率路径经常是“看起来合理但最终错误”的路径。继续沿这些路径扩展，容易把错误包装得更完整。

Evolution operators 给了一个突破口。它未必总是生成自然轨迹，但至少让搜索有机会组合原模型不会单次采出的候选。

2. 子目标反馈让失败轨迹重新有价值

在复杂任务里，失败轨迹占绝大多数。如果每条失败轨迹都只能拿到 0 分，训练和搜索都会浪费大量信息。

BES 的 backward goal tree 把失败轨迹拆开看：你最终错了，但你可能找到了正确实体；你最终程序性能不好，但某个局部策略可能有用。

这个思想可以迁移到很多 agent 场景。比如数据分析 agent，即使最终报告错了，中间 SQL、检索 query、图表代码可能有局部价值。一个更好的搜索系统应该能复用这些局部结果。

3. Pair score 的互补性很关键

我之前看很多 multi-agent 或候选重排方法，总觉得它们对“多样性”的处理太粗。常见做法是 embedding 距离远一点、答案文本不一样一点，就算多样。

BES 的 pair score 更具体：不是文本长得不一样就好，而是覆盖的子目标互补才好。

这比泛泛地鼓励 diversity 更可落地。

但我也有几个保留意见

子目标分解质量是 BES 的软肋

Backward search 依赖模型把目标拆对。复杂任务里，目标分解本身就可能错。一个错误子目标会把 forward search 带偏，而且这种偏差不一定容易被最终 verifier 及时纠正。

论文里理论结果假设子目标和局部 verifier 比较干净。真实系统里，这个假设挺强。

如果我要在工程里用 BES，会优先在两类任务上试：一类是子目标天然清晰的任务，比如多跳检索、工具调用、程序测试；另一类是局部 verifier 很可靠的任务，比如单元测试、形式化检查、可执行评估。

对于开放式写作、策略规划、产品方案这类任务，子目标 verifier 很容易主观化，BES 的收益就没那么稳。

重组轨迹不等于语义一致

Combination、translocation、crossover 听起来很美，但文本推理不是 DNA。两个片段拼在一起，可能出现前提冲突、代词指代错乱、步骤顺序不合法。

论文在 open problem solving 里也承认，候选是程序时不能直接拼接模型输出，而要通过 LLM prompting 实现操作。这其实暴露了一个问题：evolution operator 的质量高度依赖 LLM 的编辑能力。

如果 backbone 弱，重组可能只是制造更多噪声。

实验覆盖还不够让我放心

MuSiQue 的提升明确，但绝对准确率偏低；Knights-and-Knaves 的图没有给出完整数值表；open problem solving 的结果不错，但 backbone 是 GPT-5，且 API 成本上升。

我会希望看到更多任务：数学证明、代码修复、web agent、长程工具调用，尤其是那些失败轨迹可局部复用的场景。BES 的设定在那里可能更有说服力。

还有一点，论文把 BES 叠加在 MaxRL 或 ShinkaEvolve 上，说明它更像一个搜索模块，而不是端到端替代方案。这没问题，但读结果时要记住：收益来自组合系统，不是单一算法包打天下。

如果你想自己复现或改造，工程上可以怎么做？

不用一上来实现完整 BES。我会从一个最小版本开始。

# 一个极简 BES 风格伪代码，不是论文官方实现
pool = [empty_trace()]
goal_tree = decompose(root_goal)

for step in range(budget):
    scored = [(trace, backward_score(trace, goal_tree)) for trace in pool]

    if should_use_two_parents():
        a, b = sample_complementary_pair(scored, goal_tree)
        op = choose(["combine", "translocate", "crossover"])
        candidate = llm_edit_with_operator(a, b, op)
    else:
        parent = sample_by_boltzmann(scored)
        op = choose(["expand", "delete"])
        candidate = apply_single_parent_op(parent, op)

    candidate_score = backward_score(candidate, goal_tree)
    pool.append(candidate)

    if step % decompose_interval == 0:
        goal_tree = refine_unsolved_goals(goal_tree, pool)

    if is_terminal(candidate) and verifier(candidate) == 1:
        return candidate

return best_terminal(pool, verifier)

真正落地时，我会特别盯四个指标：

还有一个经验判断：如果你的任务连最终 verifier 都不稳定，就别急着上 BES。先把 verifier 做扎实。BES 会放大反馈质量，好的反馈被放大，坏的反馈也会被放大。

这篇论文的真实定位

我不想把 BES 吹成“让语言模型自我进化”的大突破。它还没有证明自己能稳定扩展到所有推理任务，也没有解决 verifier 可靠性这个老问题。

但我确实觉得它值得细读。

原因很简单：它把搜索失败的原因讲得更具体了。过去我们常说“模型需要更多 inference compute”，但 BES 提醒我们，更多 compute 如果只是更多同分布 rollout，收益会很快变钝。真正值得做的是改变候选生成方式，让中间失败也能变成可利用信息。

这点对 agent 系统尤其重要。

未来的自我改进模型，很可能不是“采样很多答案然后挑一个”，而是维护一大池半成品经验：某些工具调用是对的，某些中间实体是对的，某些程序片段是对的，某些推理分支虽然最终失败但局部有价值。系统要做的，是把这些局部资产拆出来、验证、重组。

BES 给了一个相对清晰的框架。

我的判断是：如果你在做长程推理、工具型 agent、程序搜索或复杂任务的 post-training，这篇论文可以认真看。不是因为它给了一个马上能复制粘贴的万能算法，而是它提出了一个很实在的问题：

别再只问模型能不能多想几次了。要问它能不能把几次失败里真正有用的部分拼起来。

参考链接

• arXiv 论文：https://arxiv.org/abs/2605.28814
• arXiv HTML：https://arxiv.org/html/2605.28814v1
• 项目代码：https://github.com/Embodied-Minds-Lab/BES
• DeepSeekMath / GRPO：https://arxiv.org/abs/2402.03300

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我