下面给你一套“只提质量”、面向你这种 RAG + planner + writer + validator + tool caller 复合系统的 GEPA 落地与优化配置。我会尽量把关键点落到：怎么定义 \($\mu,\mu_f$\)、怎么分配 1000 美元预算、怎么让 GEPA 更稳更快地产生有效 prompt 迭代。
---
0) 目标与前提（按论文 GEPA 的设定对齐）
- 优化变量：各模块 prompt（\(\Pi=\langle \pi_{\text{rag}},\pi_{\text{planner}},\pi_{\text{writer}},\pi_{\text{validator}},\pi_{\text{tool}}\rangle\)）
- 不优化：权重 \(\Theta\)、控制流 \(C\)（先固定，后续再谈 co-design）
- 唯一目标：提升质量指标 \(\mu\)（不把成本、token、延迟纳入目标）
- 预算：单次优化约 $1000（仍然要做“省验证”设计，否则 GEPA 很容易把钱烧在候选验证上）
1) 数据与评测拆分（GEPA 成败的 80%）
按论文做法，把数据拆成：
- \(\mathcal{D}_{feedback}\)：用于产生“学习信号”（反思 + prompt 更新）
- \(\mathcal{D}_{pareto}\)：用于候选选择/排名（论文用验证集充当）
1. Train/Val/Test 三划分（严禁 test 参与任何候选选择） 2. 令：
- \(\mathcal{D}_{feedback}=\) train（可抽子集，但要覆盖失败模式）
- \(\mathcal{D}_{pareto}=\) val（建议 *不要太大*，见第 4 节“省验证”）
2) 质量指标 \(\mu\)（你是“只提质量”，就把它做强、做稳）
2.1 如果是开源 QA / 指令任务（常见）
- 可直接用：EM / F1 / Pass@k / 约束满足率（IFBench 类）
- writer 输出若有结构要求（JSON/schema），把结构合法性也计入 \(\mu\)（否则会“高分但不可用”）
2.2 如果需要 Judge（无标准自动分）
用一个固定 Judge（LLM-as-a-judge），但要：- 固定 rubric（评分维度 + 打分规则）
- 固定温度、固定提示模板
- 记录方差：同一候选至少评 2 次（或在关键阶段复评）
---
3) 反馈函数 \(\mu_f\)：把“开源评测文本”变成 GEPA 的燃料
论文强调 \(\mu_f\) 能返回评测过程的文本 trace（不仅是标量分）。你现在说“评测文本为开源数据集”，通常意味着你能拿到标准答案/证据/约束说明/错误类型。建议给每个模块做模块级反馈字段（这会显著提升反思的“信用分配”质量）。
下面是一个通用的 \($\mu_f$\) 返回结构（建议 JSON）：
{
"score": 0.0,
"global_feedback": "...",
"module_feedback": {
"rag": { "missing_evidence": [...], "retrieval_errors": "...", "notes": "..." },
"planner": { "plan_issues": "...", "notes": "..." },
"tool": { "tool_errors": "...", "bad_params": "...", "notes": "..." },
"writer": { "answer_errors": "...", "citation_errors": "...", "notes": "..." },
"validator": { "failed_constraints": [...], "fix_suggestions": "...", "notes": "..." }
},
"traces": {
"planner_trace": "...",
"tool_calls": [...],
"rag_docs": [...],
"draft_answer": "...",
"final_answer": "..."
}
}
各模块“可做的最强反馈”（不依赖闭源工具）
- RAG
- 若数据集提供 supporting docs / evidence：返回“缺哪些 gold evidence”“检索到的证据里哪些无关”
- 若无 gold evidence：用规则/embedding 相似度给出“可能证据不足”的提示（保守）
- planner
- 若任务可分解：标注“计划是否覆盖子问题”“是否遗漏必要信息源/工具”
- 常见失败标签：*过早回答、未规划就调用工具、计划不可执行*
- tool caller
- API error、参数缺失/类型错误、调用顺序错误（这些都能从工具返回/异常栈里抽）
- writer
- 与 gold 的差异摘要（缺关键实体/数值/否定关系错误）
- 若要求引用：引用缺失/引用与答案不一致
- validator
- 直接返回：哪些约束失败（格式、长度、禁词、schema、拒答策略等）
- 给出最小修复建议（例如“只输出 JSON，不要解释”）
---
4) 在 $1000 预算下，让 GEPA 更“值钱”的两处优化（强烈建议）
论文自己指出：GEPA 很多 rollouts 花在 \(\mathcal{D}_{pareto}\) 的候选验证上。你预算不算无限，所以建议做两级验证：
4.1 分层验证（先小后大）
- 门控评测：minibatch \(b\)（来自 \(\mathcal{D}_{feedback}\)）用于“是否加入候选池”
- 轻量 Pareto 验证集：\(\mathcal{D}_{pareto}^{small}\)（例如 80–200 条）用于候选选择
- 全量 val 只用于少数精英复评：比如每 10 次新增候选，挑当前前 3 名去全量 val 评一次
4.2 缓存（必须做）
对每个候选系统 \(\Phi_k\) + 输入样本 \(x_i\)：- 缓存完整 trace、评分、工具输出
- 同一候选不重复评测同一样本（除非你显式要求“复评降噪”）
5) GEPA 超参建议（适配你这类多模块 agent）
给一套默认可用的起点（你可以直接照这个跑）：
5.1 关键超参
- minibatch size：\(b=5\)（比论文的 3 稍稳，预算也允许）
- \(|\mathcal{D}_{pareto}^{small}|\)：100–200
- 迭代上限：按预算动态停止（见第 6 节）
- 模块选择：
- 80%：failure-driven（根据 \(\mu_f\) 失败类型选模块）
- 20%：round-robin（防止模块长期不更新）
5.2 候选选择（保留论文 Pareto，但加“温度”更稳）
论文按 \($f[\Phi]$\) 频次采样。你可以加温度退火：$$ P(\Phi)\propto f[\Phi]^{1/T} $$
- 前期 \(T=2\)（更探索）
- 中后期降到 \(T=1\)（回到论文默认强度）
- 最后 \(T=0.7\)（更利用，收敛）
6) 预算分配（$1000 怎么花不冤）
你没说使用哪个模型与单价，我给一个可执行的预算框架（用“每 rollout 平均成本”记作 \(c_r\)）：
1. 预留 15%：最终精英候选在全量 val + 少量复评 2. 预留 10%：失败 case 回归集（专门盯住你最在意的失败模式） 3. 剩余 75%：GEPA 主循环（mutation + 小 Pareto 验证）
停止条件建议：
- 已连续 \(N=20\) 次迭代没有通过 minibatch 提升门控（说明卡住）
- 或当前最佳候选在 \(\mathcal{D}_{pareto}^{small}\) 上 3 次复评都稳定（方差很小）
7) 反思更新（UpdatePrompt）的“硬约束”，避免越改越胖/越改越玄学
GEPA 的 meta-prompt（论文附录 B）会引导模型把“niche/domain facts”写进新指令。对 agent 系统我建议你额外加三条硬约束（非常实用）：
1. 必须写成“可执行规则”（Do/Don’t + when/then），禁止空泛口号 2. 必须绑定模块 I/O schema（输入字段、输出字段、禁止输出什么） 3. 长度上限：每次更新后的 prompt token 不超过父代的 1.2×
这样你会得到更像“系统规范”的指令，而不是越来越长的散文。
---