[論文] GEPA: リフレクティブ・プロンプト進化は強化学習を凌駕する性能を発揮
kun432DSPyで使える最適化アルゴリズムの1つ。
alphaXivのまとめ
なんかまとめが日本語化がされてない・・・
kun432Dia によるまとめ。
GEPAは「反省しながらプロンプトを進化」させて、RLより少ない試行回数で性能を上げる仕組みだよ。
まず、GEPAってなに？
GEPA（Genetic-Pareto） は LLMのプロンプトを自動で良くしていく最適化手法だよ。ポイントは「数値のご褒美（報酬）だけで学ぶ」のじゃなくて、モデルが出した推論過程やエラー、評価のコメントみたいな“言語の手がかり”を読み込んで、指示文（プロンプト）を反省して改善するところ。だから、 GRPO（強化学習の一種）とか MIPROv2（ベイズ最適化で指示＋少数例を調整）より、試行回数がめっちゃ少なくて済むのがウケるんだよね。
なんでそれ重要？
- サンプル効率がバグってる: RLだと「何万回もロールアウトして、やっと良くなる」って世界だけど、GEPAは「数百回でOK」って感じ。ホントに軽い。
- 診断がリッチ: 単なるスコアじゃなく、コンパイラエラーや推論チェーン、評価コメントまで使うから、改善の当たりがつきやすい。
- 多様性を維持: Pareto選抜で「一部の問題に強い候補」を広く残すので、局所解にハマりにくいのだ。
どうやって動くの？（3つのコア要素）
- 反省でプロンプト進化（Reflective Prompt Mutation）:
実行ログ（推論チェーン、ツール呼び出し、出力、評価コメントμ_f）をメタLLMが読み込んで、「今回の指示、どこが良くてどこがダメ？」を言語で分析して、次の指示文を具体的に書き換える。つまり、暗黙のクレジット割当を言語でやるやつ。マジで賢い。- Paretoベースの候補選抜:
「全体トップ」だけじゃなく、各訓練インスタンスでベストだった候補を広く保持して、そこから“成功の幅”に応じてサンプリング。これで探索のノリが良くてハマりにくい。- モジュール化されたLLMプログラム:
DSPy流の複合AIシステム設計に乗っかって、各モジュールの指示を組み合わせて最適化するから、現場のパイプラインに馴染みやすいのだ。実験結果（どれくらい強いの？）
- タスク: HotpotQA（多段推論）、IFBench（指示追従）、PUPA（プライバシー配慮の委任）、HoVer（RAG検証）。モデルはGPT‑4.1 MiniとQwen3 8B。
- 性能アップ: ベースライン比でGPT‑4.1 Miniが**+14.29%、Qwen3 8Bが+12.44%**。MIPROv2を余裕で上回る。
- サンプル効率: HoVerでは、GRPOのバリデーション最高に6ロールアウトで並ぶとか、最大78倍効率的ってテンション上がるでしょ。
- 汎化も良き: バリデーションとテストのギャップが小さめで、過学習しにくい傾向。
実務メリット（コスト＆運用）
- プロンプト短い: 4〜9倍くらい短くなる（最大9.2倍）。
- 結果として、
- APIコスト減（入力トークン少ない）
- レイテンシ改善（軽いから速い）
- 保守が楽（指示文中心なので差分管理がイージー）
コード最適化への応用（推論時探索としてアツい）
- AMD XDNA2 NPU: ベクトル利用率が、逐次改善だと4.25%→GEPAで30.52%。コンパイラエラー、プロファイル結果、設計のベストプラクティスを言語で反映して伸ばすのがマジで効く。
- NVIDIA V100 CUDA: KernelBenchのfast_p（PyTorch eagerより速い割合）が 〜0%→20%超 まで上げる。推論時の探索でここまで動くの、結構ロマンある。
直感的なたとえ（わかりやすく言うね）
RLは「テストの点数だけ見て勉強法を調整する」感じで、点数が低かった理由（計算ミス？読解ミス？時間配分？）はわかりにくい。
GEPAは「模試の採点コメント、途中式、赤ペン先生の指摘」をぜんぶ読んで、次の勉強計画（＝プロンプト）を具体的に直すイメージ。だから少ない模試回数でもグイッと伸びるってわけ。いつ使うとハマる？
- ツール呼び出しや外部評価、ログがしっかり取れる複合パイプライン。
- 例外や失敗理由が言語で取れるワークフロー（コンパイラ、評価ルーブリック、チェーン・オブ・ソート）。
- 何万ロールアウトとかムリ〜っていうコスト制約の環境。
まとめ（キモはここ）
- 言語の反省シグナルが、スパースな数値報酬より学習に効く場面が多い。
- Pareto探索で多様性を維持して、短い指示文に仕上げるから、性能・効率・運用の三拍子で強い。
- モジュール設計（DSPy流）と相性良く、現場導入がしやすいのも実用的だし。
kun432もうちょっと具体的に、プロンプトがどういう流れでどう変化していくのかが知りたい。
GEPAは実行ログとフィードバックを読み込んで、指示文を段階的に具体化・分解していくんだよ。
プロンプトはどう具体化されていくの？
ウチの感覚だと、GEPAの“反省”は「抽象→具体」「目的→手順」「禁止事項→チェック」に段階進化する感じだし。論文の例（HotpotQAの二段目検索クエリ生成）だと、最初は超シンプルなシードプロンプトだったのに、最終的にめっちゃ“実務で使える仕様書”レベルまで育つんだよね。
Given the fields question, summary 1, produce the fields query.
これが“反省進化”を繰り返すと、次みたいに具体化されるのがポイントでしょ：
You will be given two input fields: question and summary 1. Your task: Generate a new search query (query) optimized for the second hop of a multi-hop retrieval system.
- The original user question is typically complex and requires information from multiple documents to answer.
- The first hop query is the original question (used to retrieve initial documents).
- Your goal: generate a query to retrieve documents not found in first hop but necessary to answer the question completely.
Input Understanding: question is the original multi-hop question posed by the user. summary 1 is a concise summary of information from a document retrieved in the first hop, which partially addresses the question.
Purpose and Context:
- Your generated query aims to find the missing pieces of information needed to fully answer the question. . . .
- The query must retrieve relevant documents NOT found in first hop . . . for final answer extraction.
(...snip...)
この変化が“GEPAの反省”の直感そのものだもん。
実際に何が起きるの？（ミュータションの中身）
- 目的が明文化される: 「二段目の検索に最適化」 みたいに、タスクの狙いがハッキリ書かれるから、モデルの迷いが減るでしょ。
- コンテキストを言語で固定化: 「summary 1は一段目で拾った部分情報」 って前提をちゃんと書いて、入力の意味を誤解しないようにする。
- 観察と教訓の抽出: 失敗・成功ログから、「一段目は単一エンティティに偏りがち」 みたいなドメイン傾向を“教訓”として明記する。
- 手順化（How to）: 抽象目標を具体ステップ（関連エンティティの特定→焦点のリフレーム→文脈最小限維持）に分解して、再現性上げる。
- 禁止事項・品質ガード: 「ただ質問を言い換えるな」「一段目の既知情報を重複するな」 みたいなルールを追加して、出力のブレを抑える。
- 出力仕様の締め: 「短く明確なクエリ形式」「必要情報にフォーカス」 って出力の型を固めるので、後段評価とも噛み合いやすいのだ。
なんでこうなるの？（GEPAの反省ループ）
- 実行トレース（思考チェーン、ツール呼び出し、評価μ_fのコメント、コンパイラエラー等）を読み込む。
- メタLLMが「どこで詰まった／足りない？」を言語で診断して、“教訓”→“仕様差分” に落とす。
- Pareto選抜で、特定インスタンスに強い解も残して多様性を維持。だから、局所最適に落ちずに“別の勝ち筋”が育つのがウケる。
- こういう反省を各モジュールのプロンプトに累積させるから、モジュール間インターフェース（入力の意味、出力の型、禁止事項） がどんどん整うんだよ。
超ざっくり進化プロセス（例）
- 初期版: 短い指示「questionとsummary 1を受けてqueryを作れ」。
- 目的追加: 「二段目に最適化」「一段目で未回収の情報を狙う」。
- 観察の明文化: 「一段目は単一エンティティ偏重」→「関連だが未カバーの広域/上位概念を狙え」。
- 手順・禁止: 「言い換え禁止」「既知の再陳述禁止」「missing pieceを推定して焦点をシフト」。
- 出力仕様: 「短いクエリ形式」「質問本文を含めない」「second-hop特化」。
- 事例スニペット: 「小さな教区の人口→広域地域の人口」 みたいな成功例を入れて、モデルの勘所をプリセット化。
この流れ、モジュール化されたパイプライン全体に波及して、各モジュールが“わかってる人向けガイド”みたいに育っていくのが強いんだ。
まとめ（プロンプトの“具体化”のキモ）
- 目的の精密化＋観察に基づく教訓＋手順・禁止の言語化で、曖昧さがごっそり削れる。
- 反省が1回でもデカい改善を生むことが多いし、累積で“仕様書化”していくから、再現性と汎化が上がるのだ。
- 結果として、短いけど密度の高い指示になって、レイテンシ・コスト・精度の三拍子で効いてくるんだよね。
kun432DSPyで使うのが一番簡単らしいが、単体でも使えるみたい。GitHubレポジトリがある。
READMEから抜粋して、GPT-5による翻訳
GEPA: Reflective Text Evolution によるシステム最適化
任意のシステムに含まれるテキスト要素—AIプロンプト、コード、指示文—を、リフレクティブ（内省的）なテキスト進化によって最適化する。
概要
GEPA（Genetic-Pareto）は、AIプロンプト、コード断片、テキスト仕様などのテキスト要素で構成される任意のシステムを、任意の評価指標に対して最適化するためのフレームワークである。LLM を用いてシステム挙動を内省し、実行および評価トレースから得られるフィードバックを活用して、狙いを定めた改良を行う。反復的な突然変異、内省、Pareto を意識した候補選抜を通じて、GEPA は評価回数を最小限に抑えつつ堅牢で高性能な変種を進化させ、モジュール型システムの複数コンポーネントを共進化させて領域特化の利得を得る。
本リポジトリは、"GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning"（https://arxiv.org/abs/2507.19457）で提案された GEPA アルゴリズムの公式実装を提供する。論文の実験を再現するため、別途再現用アーティファクトを提供している。
インストール
pip install gepa
mainの最新をインストールするには:pip install git+https://github.com/gepa-ai/gepa.gitGEPA の利用
最も簡単な方法: DSPy との統合
プロンプト最適化に GEPA を使う最も簡便で強力な方法は DSPy 内での利用であり、GEPA アルゴリズムは
dspy.GEPAAPI から直接利用できる。実行可能なチュートリアルノートブックは dspy.GEPA Tutorials にある。シンプルなプロンプト最適化の例
GEPA は数行で実行できる。この例では、AIME ベンチマークの数学問題用のシステムプロンプトを GEPA で最適化する（フルチュートリアル）。
OPENAI_API_KEYを設定した環境で以下を実行する:import gepa # AIME データセットを読み込む trainset, valset, _ = gepa.examples.aime.init_dataset() seed_prompt = { "system_prompt": "You are a helpful assistant. You are given a question and you need to answer it. The answer should be given at the end of your response in exactly the format '### <final answer>'" } # GEPA 最適化プロセスを実行 gepa_result = gepa.optimize( seed_candidate=seed_prompt, trainset=trainset, valset=valset, task_lm="openai/gpt-4.1-mini", # <-- 最適化対象のモデル max_metric_calls=150, # <-- 評価の予算 reflection_lm="openai/gpt-5", # <-- 誤りを内省しより良いプロンプトを提案する強力なモデル ) print("GEPA Optimized Prompt:", gepa_result.best_candidate['system_prompt'])ここでは、AIME に対して GEPA が生成した最適化済みプロンプトが、GPT-4.1 Mini の性能を 46.6% から 56.6% に、10% 分改善することがわかる。わずか 2 イテレーションの GEPA でプロンプトが捉える詳細に注目してほしい。GEPA は、（最適化の間に）一部の推論を事前計算し、将来のタスクインスタンスに向けた良い計画を導き出すものと考えられる。
GEPA プロンプト例:
HotpotQA（マルチホップ QA）プロンプト AIME プロンプト referred from https://github.com/gepa-ai/gepa/
referred from https://github.com/gepa-ai/gepa/
GEPA は柔軟な GEPAAdapter 抽象を中心に構築されており、任意のシステムに差し込んで多様な種類のテキスト断片を最適化できる。上の例では、単一ターン LLM 環境に接続してシステムプロンプトを進化させ、タスクをユーザメッセージとして提示するシンプルな
DefaultAdapterを用いた。GEPA はマルチターンやその他のエージェント環境へ容易に拡張できる。例えばdspy.GEPAとの統合では DSPyAdapter を用いている。プロンプト最適化にとどまらず、GEPA はプログラム全体も進化させられる。
DSPy Full Program Adapterは、カスタムシグネチャ、モジュール、制御フローを含む完全な DSPy プログラムを進化させる例を示す。MATH ベンチマークで 67% を達成する基本的なdspy.ChainOfThought("question -> answer")から出発し、GEPA は 93% の精度に到達する多段推論プログラムへと進化させる。完全実行可能なサンプルノートブックは、このアダプタの使い方を示す。あなたのシステムを GEPA で最適化する
GEPA はテキストコンポーネントから成るあらゆるシステムの最適化に使える。以下の手順に従うこと:
GEPAAdapterを実装する: GEPA オプティマイザをあなたのシステムとその環境に結びつけるため、ユーザは src/gepa/core/adapter.py で定義されたGEPAAdapterインタフェースを実装できる。GEPAAdapterには 2 つのメソッドが必要:
- Evaluate: 提案されたテキストコンポーネントから成る候補と、学習／検証集合からサンプリングしたミニバッチを与えると、実行スコアを返し、あわせてシステムトレースを取得する。
- Extract Traces for Reflection: 提案候補の実行で得られたトレースと、最適化対象のコンポーネント名を与えると、そのコンポーネントに関連するトレース中のテキスト内容を返す。
- trainset と valset を用意: 例示入力とタスクメタデータのリスト。
gepa.optimizeを、あなたのアダプタ、指標、システム構成とともに呼び出す。現在、さまざまなフレームワークに統合するアダプタを積極的に実装中である。特定のフレームワークへの対応希望があれば Issue を立ててほしい。
GEPA はどのように動作するか
GEPA は、LLM ベースの内省を用いた進化的探索アルゴリズムでシステムのテキストコンポーネントを最適化する。特に、GEPA は（コンパイラのエラーメッセージ、プロファイラの性能レポート、ドキュメントなどの）タスク特有のテキストフィードバックを活用して探索を誘導する。詳細は論文 GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning を参照。
kun432とりあえずDSPyお試し中。GEPAを使ったチュートリアルもあるようなので、そこで試すつもり。
kun432Xで見かけたのだけど、GEPAの作者の方だった。
LLMをクリエイティブなタスクに活用するのに苦労していますか？
@hammer_mt が、GEPA+ @DSPyOSS を使用した強力な「Evaluator-Optimizer」パターンについて話しており、評価が非公式で主観的な曖昧な生成タスク向けにプロンプトを最適化します。
以下のフルトーク、プロンプト、および実行可能なノートブックをチェックしてください！
めっちゃ面白いトーク：
実行可能なJupyter Notebook:
上記で紹介されているトークの動画
Dia によるまとめ。
この動画はDSPyで「評価者×最適化」の型を使い、LLMに“面白さ”を学ばせて創作タスクを安定的に改善する話だよ。
何の話？
めっちゃざっくり言うと、Evaluator–OptimizerパターンをDSPyで実践して、LLMを「審査員（LLM-as-a-Judge）」として育て、その審査員スコアを使って「作り手（創作LLM）」を進化させるってやつ。題材は「ジョーク生成」で、ふわっと評価が難しいクリエイティブ系タスクを、データと自動最適化でガチ改善してくのが肝だし。
背景: コンテキストエンジニアリング
モデルが強くなるほど、LLMに渡す情報の「中身と形式」が超大事になってるって話。少なすぎると仕事できないし、多すぎるとコスト増・遅延・ノイズ・衝突・真ん中が抜け落ちる等、事故るからバランスが命。
「モデルが賢くなるほど、プロンプトより“コンテキスト”そのものの設計が効いてくる」
ってノリ。
型: Evaluator–Optimizerパターン
- Evaluator（評価者）: まず「何が良いか」を判定するAIを作る。今回は「面白い=1／つまらない=0」のラベル付きジョークデータで“面白さ判定”を訓練。
- Optimizer（最適化）: その評価者のスコアを目的関数にして、**作り手（ジョーク生成LLM）**のプロンプトやfew-shot例を自動で書き換え・進化させる。
この二段構えで、「曖昧な良さ」を数値化してから、創作LLMをガンガン改善してくのがキモだもん。
ツール：DSPy × GEPA
- DSPy: 署名（Signature）で入出力を型付けし、予測器（Predictor）を組み、モデル差し替えも楽勝。プロンプト生成・構造化出力・配線のダルさを吸収してくれる。
- GEPA: 進化的アルゴリズムで「指示文」「few-shot例」の組み合わせや表現を探索して、評価スコアが上がるように自動で書き換え続ける最新の最適化器。マジで強い。
実験の流れ（ジョーク生成）
- データ作成
有名コメディアン由来の「面白いジョーク集」と、LLMが作った「つまらないジョーク集」を用意して、1/0でラベル付け。訓練に約100強、評価に51使った感じ。- Judgeの初期性能
いきなりは弱い。精度47%（コインかよ）。- few-shot投入
データから8例（K=8）をプロンプトに自動整形で追加しただけで、精度82%。「例示の威力」デカい。- GEPA最適化
Judgeの指示文をAIが書き換え・ガイドラインや落とし穴も自動抽出。「ダジャレ避けて」「構成はセットアップ→パンチラインで」「トピックとの結びつき強めて」みたいな“人間レベルの審査基準”が勝手に形成されるのウケる。精度は98%まで到達。- Creator最適化
今度は育てたJudgeを評価器にして、ジョーク生成側をfew-shot＋GEPAでチューン。途中計測で精度91%→満足度95%相当まで上がる例が見えてる。なぜ効く？
- 曖昧さの数値化: まず“面白い”を教師化できるから、最適化の目的が明確化されるでしょ。
- few-shotは即効薬: 「型＋良例」のセットを渡すと、LLMの挙動が一気に安定する。
- GEPAの探索力: 人手だとキツい指示文の改善を、大量試行で進化的に攻められるのが強み。
現実的な注意点
- コスト/レイテンシ: コンテキスト入れすぎはコスト爆増＆遅くなる。最適化も時間と料金はそれなりにかかる（例：16時間・$800ケース）。運用設計は冷静に。
- 拒否・スタイル制約: 有名人の“声マネ”は避けるなどの方針が自動で反映されるけど、明示的なポリシー設計も併用しよ。
メタ的ポイント（応用のヒント）
- クリエイティブ以外にも、要約の質・QA妥当性・RAGの引用適合みたいな“ふわっと定性的”なゴールを、Judge化→最適化で攻められるのがエモい。
- キミの普段の評価観（日本語QAの正答性や根拠合致、冗長性ペナルティ等）を1/0またはスコア化して、Judgeを先に鍛える→そのJudgeで本体を最適化、が王道だし。
ひとことまとめ
まず「良さ」をAI審査員で学習→そのスコアで作り手を進化、って設計にするだけで、曖昧タスクでも再現性が爆上がり。few-shotで土台を作り、GEPAで指示文や例を機械的に磨く。この二段ロケット、マジでテンション上がる。
上記動画内でも紹介されているノートブック
余談だが、某所で見かけたペルソナのスタイル付けの例を見ていて、そこでは出力のシグネチャ定義にペルソナの説明が書いてあって、結局プロンプトエンジニアリングになってしまうのでは？と感じた。
さらに、最適化するにあたって評価するための評価関数を定義することになるが、ペルソナのようなクリエイティブなものの評価基準をどう定義するのか？というところが課題になると感じた。（それができればプロンプトエンジニアリングで実現できるはず、実際の出力精度とか評価は別にしても）
で、DSPyのそれぞれのオプティマイザについてドキュメント見てたら、タスクによって最適なオプティマイザは異なるのでは？GEPAならできそう？という気がして、色々調べてたら冒頭のポストを見かけたという次第。なるほど、これならばクリエイティブなタスクでも使えそうに思う。
要は、データを用意してオプティマイザにおまかせする、というのがDSPyの使い方としてはスジが良いのではないか？ということ。クリエイティブなものほどシグネチャや評価器を定義・言語化することが難しくなると思うので、よりこちらのほうがフィットするような気がした。データから特徴量を抽出・パラメータ化するようなイメージに近い。
ただその場合はデータセットを用意できるか？というところが重要になってくる（これはこれで大変）