如何在不调整模型权重的情况下击败 GRPO

你以为“多跑点采样、算个奖励就行了”，其实大部分有用信号都被你自己扔掉了。GRPO 每次采样生成一条长达 5000 token 的轨迹，里面塞满推理、工具调用、自我纠正和错误信息，却最终被压成一个标量奖励。等于只把“好/坏”这 1 bit 反向传播回去，剩下成千上万 bit 的结构化细节全浪费掉。

伯克利团队做了件看似“反直觉”的事：他们完全不改模型权重，只改提示，让另一个 LLM 来读这些轨迹、总结失败模式、重写提示。结果是在 35 倍更少的采样预算、几乎不需要 GPU 训练的前提下，在标准基准上比 GRPO 高出 10 分。有用户反馈，在内部多模块代理上切到 GEPA 后，调参时间从几周缩短到几天。

接下来我们从信号利用、算法细节和实战案例三个角度，把 GEPA 拆开讲清楚，再说说它和 GRPO、MIPROv2 等方法怎么搭配用更香。

据论文实验数据，GEPA 在复合 AI 系统上能以 10–50 倍更少的计算资源，达到甚至超过 GRPO 的效果；而且整个过程不需要任何梯度更新或 PPO 管线。

一、GRPO 把信号压扁了，GEPA 让信号自己说话

强化学习里的“信号压缩灾难”

语言模型上的强化学习有个经常被忽略的坑：信号被压得太狠。每次采样，代理会生成一条大约 5000 token 的轨迹，里面包含：

  • 推理步骤
  • 工具调用和返回
  • 自我纠正过程
  • 编译或运行错误
  • 评判和解释理由

这些内容本身极其结构化，正是你想要模型学会的“诊断线索”。但 GRPO 在训练时，把整条轨迹压成一个数字奖励，再用策略梯度更新权重。中间所有“为什么错”“错在哪一步”“哪种模式反复出现”都被抹平了。

GRPO 信号压缩示意

结果就是：

  • 信号本身并不稀疏，但被压成标量后变得极其稀疏
  • 你需要成千上万条轨迹，才能让梯度“猜”出哪些 token 该被奖励
  • 训练成本高得离谱，很多团队连完整跑一轮 GRPO 的预算都没有

据公开实验，标准 GRPO 在一些复杂任务上往往需要数万次采样才能收敛，这也是很多人一听到 RL 就头疼的原因。

让 LLM 读轨迹：GEPA 的反常识思路

GEPA 反思流程

GEPA 的核心翻转点是：既然轨迹本身就是自然语言，那就别急着把它压成数字，让 LLM 直接读。具体做法是：

  • 把完整轨迹和任务反馈一起交给一个“反思型”大模型
  • 问它：“哪里出错了？应该怎么改提示，才能避免这种失败？”
  • 反思模型写出一个新提示
  • 用同一批示例测试新提示，如果指标变好，就把新提示加入候选集合

整个过程完全不涉及梯度、PPO 或 KL 惩罚，只是“读 → 想 → 改提示 → 复测”的循环。

GEPA 优化循环

论文在 2025 年 7 月发布，被 ICLR 2026 接收，DSPy 直接把 GEPA 做成一等公民优化器，Hugging Face 和 OpenAI 也都给出了教程示例。有意思的是，很多团队一开始只是抱着“试试”的心态，结果发现 GEPA 在他们的多模块代理上跑得比内部 RL 管线还稳。

一位做搜索问答系统的工程师分享过体验：他们原来用 GRPO 调一个多跳检索代理，GPU 集群跑了两周才勉强收敛；换成 GEPA 后，只用几十个高质量示例和一台推理服务器，三天内就把整体准确率拉高了 8 个点。

二、GEPA 到底在优化什么：复合系统里的“提示种群”

复合 AI 系统：不止一个提示在工作

GEPA 针对的是复合 AI 系统，而不是单一“一个 prompt + 一个模型”的简单场景。这类系统通常由多个带独立提示的 LLM 模块组成，通过 Python 控制流串起来。比如一个多跳问答代理，可能包含：

  • 第一跳查询生成器
  • 检索器
  • 摘要器
  • 第二跳查询生成器
  • 最终回答模块

多模块管道示意

每个模块都有自己的提示，GEPA 会同时演化这些提示，形成一个“提示种群”。优化目标很直接：在给定采样预算下，让整体任务指标最大化。真正的创新点在于：

  • 如何把一条轨迹里的细节变成有用反馈
  • 如何在多个候选提示之间做选择，避免陷入局部最优

反馈函数：不再只有一个分数

GRPO 只看一个标量奖励，GEPA 换成了更丰富的反馈函数 μ_f。它返回两部分：

  • 一个类似 GRPO 的分数（方便比较好坏）
  • 一段自然语言描述，解释发生了什么、哪里做错了

反馈函数示意

在不同任务上，反馈函数会给出不同维度的诊断：

  • 多跳问答：返回检索到的黄金文档、遗漏的文档，以及每跳检索是否覆盖关键信息
  • 指令遵循：逐条说明哪些约束通过、哪些失败，以及失败原因
  • 代码生成：给出编译错误、运行时异常、性能分析轨迹
  • 隐私保护重写：拆分内容质量得分和个人信息泄露得分

GEPA 的反思 LLM就靠这些细粒度反馈，去“读懂”失败模式，然后写出更有针对性的提示。

三、GEPA 的 6 步循环：从种群到反思再到接受

GEPA 主循环

6 步算法流程

每次迭代，GEPA 的主循环会执行以下步骤：

  1. 从当前提示种群中选出一批候选父代（用帕累托采样，后面展开）
  2. 选择一个要变异的模块（通常轮流遍历各模块）
  3. 从训练集中采样 3 个示例，作为本轮评估用例
  4. 运行程序，收集完整轨迹和 μ_f 反馈
  5. 把轨迹和反馈交给反思 LLM，请它生成一个新提示
  6. 接受或拒绝：在同样的 3 个示例上重新运行，如果指标更好，就把新提示加入种群，否则丢弃

循环一直持续到采样预算用完，最后返回表现最好的候选提示组合。整个过程不需要任何梯度信息，也不需要 KL 惩罚之类的稳定技巧。

和 GRPO 的正面对比

GRPO 流程

GRPO 和 GEPA 都利用反馈改进系统，但路径完全不同：

  • GRPO：用标量奖励 + 策略梯度，直接更新模型权重
  • GEPA：用自然语言反馈 + 反思 LLM，间接更新提示文本

GEPA vs GRPO 对比

有个关键提醒很容易被忽略：

  • GRPO 可以改变模型的“知识”和“能力边界”
  • GEPA 只能改变你“怎么问”“怎么拆任务”

如果基础模型根本不具备某项能力，比如完全不会某个小语种，那你再怎么演化提示也没用。这种场景还是得上微调或 RL。GEPA 更适合的是：模型已经有潜在能力，但默认提示没把它调动出来。

四、一个 HotpotQA 的真实案例：从 38% 到 69%

任务背景：多跳问答里的第二跳查询

HotpotQA 是一个经典多跳问答基准，问题需要从两个不同的维基百科页面获取信息，单一文档无法回答。比如：

“包含 São Vicente 教区的地区人口是多少？”

合理的解题步骤是：

  1. 第一跳：搜索 “São Vicente 教区”，检索文档，发现它位于马德拉
  2. 第二跳：搜索 “马德拉人口”，检索对应文档，拿到人口数字
  3. 最终回答：结合两条信息给出答案

代理为每一跳都设了独立模块。我们关注的是“第二跳查询生成器”，它的职责是：在看到第一跳检索结果后，决定下一步要搜什么。

模块输入：

  • question：原始用户问题
  • summary_1：第一跳检索结果的摘要

模块输出：

  • query：第二跳搜索查询

初始种子提示非常朴素：

“给定字段 question、summary_1，生成字段 query。”

这个提示在验证集上的得分大约是 38%。说实话，这种“描述接口”的提示在工程里太常见了，但效果往往一般。

失败模式示意

GEPA 在一小批示例上运行后，发现一个反复出现的失败模式：

  • 第二跳查询经常只是复述原问题
  • 或者继续搜索同一个实体，导致检索结果和第一跳高度重复

在 São Vicente 这个例子里，模型会再次搜索“São Vicente 教区人口”，而不是去搜“马德拉人口”，自然就拿不到正确答案。

反思 LLM 写出的“策略化提示”

反思 LLM 读了多条失败轨迹后，写出了一个新的提示，大意是：

“生成针对多跳检索第二跳优化的搜索查询。第一跳查询是原始问题，第一跳文档已覆盖直接提及的实体。你的目标是检索第一跳未覆盖但回答完整所需的文档。避免复述原问题。目标是 summary_1 中提及但问题中未明确的相关或更高级实体。例如，如果 summary_1 描述的是教区，但问题询问更广区域的总人口，查询应针对该区域而非教区。因此，对于关于 São Vicente 区域的问题，查询应为‘马德拉群岛人口’，而非‘São Vicente 人口’。”

新提示在验证集上的得分直接提升到 69%，远超原来的 38%。模型和任务都没变，唯一变化的是这个模块的提示内容。

反思 LLM 不只是“换个说法”，而是从失败中总结出了一套策略：

  • 不要简单复述原问题
  • 第一跳已经覆盖了直接提到的实体
  • 第二跳要去找更高一层、能连接这些实体的概念
  • 用具体示例把策略讲清楚

这些策略性信息，很难通过策略梯度直接编码进去。RL 只会告诉你“这条轨迹比平均差 0.3”，然后让梯度在几千个 token 里自己摸索。GEPA 则是用自然语言把教训写出来，变成新提示的一部分。

五、帕累托选择：避免“只盯着一个最优解”带来的翻车

为什么不能只变异当前最优提示

演化提示这个想法本身不新，很多早期工作都是：

  • 每轮从当前平均得分最高的提示出发
  • 做一点变异，看看能不能更好

听起来合理，但有个大坑：很容易陷入局部最优。想象一下，有三个候选提示 A、B、C，在四个任务上的表现如下：

多任务表现示意

  • C 在平均分上最好
  • 但 A 是唯一在任务 1 上表现很强的
  • B 则在任务 2 上有独特优势

如果你只从 C 继续变异，A 和 B 的“局部专长”会被彻底丢掉，系统最终可能在某些子任务上一直拉胯。

帕累托采样：保留每个维度的“冠军”

GEPA 借鉴质量多样性优化，用了帕累托选择策略：

  • 保留在至少一个任务上表现最好的候选（帕累托前沿）
  • 按“赢的任务数”给这些候选加权采样，作为下一轮的父代

帕累托选择示意

这样一来：

  • C 仍然最有可能被选中，因为它整体表现最好
  • 但 A 和 B 也会被保留，并有机会把自己的优势“交叉”到新提示里

这一步设计，是 GEPA 和早期演化提示方法拉开差距的关键之一。我自己也不太确定是不是所有场景都需要这么复杂的选择策略，但从论文和后续生产实验看，在多任务、多模块系统里，这种“保留多样性”的做法确实更稳。

六、GEPA 在技术版图中的位置：不是替代 RL，而是补位

方法谱系示意

和其他方法怎么区分

快速对比一下常见几类方法：

  • APE、OPRO：

    • 用 LLM 生成提示候选，再用标量指标打分
    • APE：从输入输出示例生成候选，直接选最优
    • OPRO：把历史提示和分数喂给元提示，让 LLM 生成改进版
    • 特点：单提示、无轨迹反思

  • EvoPrompt、Promptbreeder：

    • 对提示种群做“交叉 + 变异”，也是靠 LLM 来改写
    • Promptbreeder 甚至会演化“变异提示”本身
    • 选择仍基于标量适应度，主要针对单提示场景

  • Reflexion：

    • 代理在每次尝试后，根据任务反馈写一段反思
    • 把反思存进记忆缓冲区，用于下一次尝试
    • 关注单实例行为改进，不做训练集层面的种群演化

  • TextGrad：

    • 类 PyTorch 反向传播，但用自然语言批评代替数值梯度
    • LLM 沿计算图传播文本反馈，给每个变量生成改进建议
    • 每轮只有一个候选，没有种群

  • MIPROv2（DSPy 旧旗舰）：

    • 从训练数据自动抽取少样本示例
    • 生成基于数据摘要和轨迹的指令候选
    • 用贝叶斯优化（Optuna TPE）在“指令 + 示例”联合空间里搜索
    • 所有候选一次性生成，没有反思式演化

  • GRPO：

    • 真正的 RL，直接更新模型权重
    • 每个提示采样一组轨迹，用组均值做基线算优势
    • 加 KL 惩罚稳定训练，是目前少数能系统性改写模型知识的方案

GEPA 有点像把这些思路拼在一起：

  • 像 Reflexion 一样用自然语言反思，但作用对象是“提示种群”，不是单个代理记忆
  • 像 EvoPrompt 一样有选择压力和演化过程，但变异由诊断性反馈驱动，而不是盲目改写
  • 像 MIPROv2 一样面向多模块管道，但通过多轮反思迭代演化，而不是一次性生成所有候选
  • 再加上帕累托选择，保证每个子任务上表现最好的策略不会被轻易丢掉

2026 年的现实检验：GEPA + RL 的混合趋势

GEPA 一开始被宣传成“击败 GRPO 的方法”，但业界很快发现，它并不是 RL 的对立面。现在更常见的做法是：

  • 用 GEPA 把复合系统的提示和模块接口调到一个比较好的起点
  • 再用 GRPO 或其他 RL 方法，在这个基础上做权重级别的微调

论文也明确提到，混合方案是自然的下一步。最近一两年，很多生产系统都在这么干，尤其是在采样成本高、但又希望挖掘模型极限性能的场景。

还有一个挺有意思的发现：

  • Decagon 在 2026 年 3 月的一次生产消融实验里发现
  • GEPA 用 20–100 个示例时效果最好
  • 把训练集扩到 500 个示例，反而性能下降

原因是：

  • GEPA 从失败模式中学习
  • 少量精选示例信号清晰，反思 LLM 容易抓到共性
  • 示例太多时，反思开始追逐噪声，出现“过拟合反馈”的现象

所以更推荐的做法是：

  • 用一小批高质量、覆盖典型失败模式的示例
  • 不要盲目堆数据量

这点和传统“多多益善”的直觉有点冲突，但在 GEPA 这种“读轨迹 + 写反思”的框架下，确实更合理。

七、在 DSPy 中上手 GEPA：一行替换 MIPROv2

在 DSPy 里，用 GEPA 替换 MIPROv2 几乎只需要改一行代码：

  • 原来：optimizer = dspy.MIPROv2(...)

  • 现在：

    optimizer = dspy.GEPA(
    metric=metric_with_feedback,
    auto="medium",
    reflection_minibatch_size=3,
    candidate_selection_strategy="pareto",
    reflection_lm=dspy.LM("gpt-5", temperature=1.0, max_tokens=32000),
    use_merge=True,
    track_stats=True,
)

optimized = optimizer.compile(program, trainset=train, valset=val)

关键在于你的指标函数签名要长这样：

def metric(gold, pred, trace=None, pred_name=None, pred_trace=None):
    # 返回 dspy.Prediction(score=float, feedback=str)

也就是说：

  • score：一个浮点数，用来比较好坏
  • feedback：一段自然语言，描述哪里做对了、哪里做错了

如果你只返回“答案错误”这种一句话，GEPA 就退化成“带标量分数的 MIPROv2”，效果会明显变差。更好的做法是：

  • 指出漏掉了哪个实体
  • 标明检索了哪个文档，而黄金文档是哪一个
  • 标记出哪一步格式错误或逻辑断裂

反馈越具体、越诊断性，反思 LLM 写出的提示就越有针对性。

八、什么时候用 GEPA，什么时候用 GRPO？

方法选择决策树

如果你现在在搭一个复合 AI 系统，可以按下面这个思路来选：

  • 优先考虑 GEPA，当：

    • 训练数据不多，但质量不错
    • 采样成本高（比如调用大模型 API）
    • 没有模型权重的访问权限
    • 任务指标可以用自然语言解释

  • 用 GRPO，当：

    • 有大量廉价采样（自家模型、离线日志等）
    • 能直接访问和更新模型权重
    • 终端奖励可自动验证（比如代码是否通过测试）

  • 用 MIPROv2，当：

    • 特别需要从训练数据中自动挖掘少样本示例
    • 更关心“指令 + 示例”整体配置，而不是多轮反思

  • 用 TextGrad，当：

    • 你的计算图很深，包含多个中间变量
    • 希望对每个变量都有显式的文本批评和改进建议

从 2026 年的实践看，大多数复合系统的默认选择已经从“先上 RL”变成了“先上 GEPA，再看要不要叠 RL”。当阅读一条轨迹的成本远低于再跑一万条采样时，RL 不再是唯一的答案。

如果你想系统补齐强化学习的底层概念，可以顺手看下这个系列课程：

强化学习课程第一部分 涵盖：

  • 强化学习 vs 监督/无监督的根本区别
  • 代理–环境交互循环
  • 探索–利用权衡
  • 多臂老虎机与四种动作选择策略（贪婪、ε-贪婪、乐观初始化、UCB）
  • 经典 10 臂测试平台的完整实现与结果分析

九、一个可以反复用的判断标准

如果只留一个判断方法放在手边，我会建议你记住这条：

  • 当你觉得“奖励信号太粗糙、太贵、太难设计”时，优先考虑 GEPA

具体可以用下面这份小清单来快速判断：

  • 你的系统是否由多个 LLM 模块组成？
  • 每条轨迹是否包含丰富的自然语言过程（推理、工具调用、错误）？
  • 你能否为每条轨迹写出一段有诊断性的文字反馈？
  • 你是否无法或不想动模型权重？

如果以上有三条以上回答是“是”，GEPA 通常会比直接上 GRPO 更划算。这个判断方法在不少团队内部已经被反复验证，值得收藏下来，遇到类似项目时拿出来对照一遍。

常见问题

Q：GEPA 真的能完全替代 GRPO 吗？

A：不能，GEPA 更像是 GRPO 的补充而不是替代。原因在于 GEPA 只能通过修改提示来挖掘模型已有能力，无法扩展模型的知识边界或学习全新技能，而 GRPO 这类 RL 方法可以直接更新权重，改变模型在整个输入空间的行为。比较稳妥的做法是：先用 GEPA 把复合系统的提示和模块接口调到一个高水平，再在关键模块上用 GRPO 做精细微调，这样既省采样又能拿到更高上限。

Q：如果我只有十几个示例，还值得用 GEPA 吗？

A：值得，甚至可以说这是 GEPA 最擅长的区间之一。GEPA 的反思循环依赖的是“失败模式的清晰度”，而不是样本数量本身，十几个精挑细选、覆盖典型错误的示例，往往比几百个噪声很大的示例更有用。你可以先用这十几个示例跑几轮 GEPA，看提示是否明显变得更具体、更策略化，再视情况逐步扩充到 30–50 个示例，避免一开始就堆太多数据让反思 LLM 迷失在细节里。

Q：反馈字符串应该写到多细才合适？

A：建议细到“能让另一个人根据这段话重现你的判断过程”。原因是 GEPA 的反思 LLM 会把反馈当成诊断报告，如果只写“答案错误”或“检索不准”，它几乎无从下手，只能做一些表面改写。更好的做法是指出具体差异，比如“漏掉实体 X”“错误检索了文档 Y，黄金文档是 Z”“在步骤 3 把 A 和 B 混淆”，并尽量用结构化的句式描述。实践中，一条反馈控制在 2–5 句，覆盖 2–3 个关键错误点，通常是比较好的平衡。

Q：GEPA 会不会过拟合那一小批训练示例？

A：会有这个风险，尤其是在你给了太多示例、但分布又不够均匀的时候。论文和后续生产实验都发现，当示例数量从 20–100 扩展到 500 时，GEPA 的泛化性能反而下降，说明反思循环开始“追逐噪声”。为了降低过拟合风险，可以：一是控制训练集规模在几十到一百左右；二是在验证集上频繁评估，发现性能开始波动时及时停止；三是刻意挑选覆盖不同模式的示例，而不是简单随机抽样。

Q：如果我的指标很难自动化评估，还能用 GEPA 吗？

A：可以，但需要多花点心思在“半自动反馈”上。原因是 GEPA 只要求你提供一个 score + feedback 的函数，这个函数可以部分依赖人工标注、启发式规则或小模型打分。实操建议是：先用一小批人工标注的数据训练一个轻量级评估器，让它输出粗粒度分数和错误类型，再在此基础上拼接成更详细的自然语言反馈。这样既不用全程人工评估，又能保证反馈足够有信息量，适合在资源有限但任务主观性较强的场景下使用。

——

如果你正纠结“要不要上 RL、要不要买更多 GPU”，不妨先用一批高质量示例把 GEPA 跑起来。很多时候，一条写得好的提示，比多花几百万算力更值当。等你亲眼看到轨迹里的那些细节被“翻译”成可执行策略，大概就会明白，为什么这么多团队开始把 GEPA 当成复合系统的默认起点了。