こちらは、GEPAの論文をベースにしたClaudeとのやりとりを通じて記述しました。

はじめに

LLMのプロンプト最適化において、強化学習(GRPO)に代わる新しいアプローチ「GEPA(Genetic-Pareto)」が提案されました。本記事では、GEPAの核心的なアイデアを対話形式で解説します。

論文: Reflective Prompt Evolution for Compound AI System Optimization

GEPAの全体像

3つのコア原則

GEPAは以下の3つの原則に基づいて設計されています。

1. 遺伝的プロンプト進化(Genetic Prompt Evolution)
   → プロンプトを「突然変異」と「交叉」で改善
   → 候補プールを維持し、系譜を追跡

2. 自然言語リフレクション(Reflective Mutation)
   → 実行トレースとフィードバックをLLMで分析
   → 問題を診断し、改善案を提案

3. パレート最適化(Pareto-based Selection)
   → 複数の「勝ち戦略」を維持
   → 局所最適を回避

アルゴリズムの流れ

入力:
  - システム Φ(複数のLLMモジュール)
  - 訓練データ D_train
  - 評価関数 μ
  - フィードバック関数 μ_f
  - 予算 B

処理:
  D_trainを2つに分割:
    - D_feedback: 学習用
    - D_pareto: 検証用

  各イテレーション:
    ① SelectCandidate: 候補プールから親を選択
    ② SelectModule: 改善対象のモジュールを選択
    ③ ミニバッチでロールアウト実行、フィードバック収集
    ④ UpdatePrompt: LLMがフィードバックを基にプロンプトを改善
    ⑤ D_paretoで評価、パレートフロンティアを更新

出力: 最適化されたプロンプト集合

パレート選択とは

常に「現時点で最高スコアの候補」だけを選ぶと、局所最適に陥る危険があります。

【問題の例】
タスク1: 候補Aが最高(90点)、候補Bは80点
タスク2: 候補Aは60点、候補Bが最高(95点)
タスク3: 候補Aは70点、候補Bは65点

平均: A=73.3点、B=80点

→ 平均で選ぶとBだけを残す
→ しかしAはタスク1で最強の戦略を持っている
→ Aを捨てると、その戦略が失われる


【パレート選択の解決策】
各タスクで「1位」を取った候補をすべて保持

タスク1: A ✓(1位)
タスク2: B ✓(1位)
タスク3: B ✓(1位)

→ AもBもパレートフロンティアとして保持
→ 異なる「勝ち戦略」を維持できる

これにより、多様な候補から進化を続けることができます。

強化学習とGEPAの違い

強化学習(GRPO)のアプローチ

強化学習では、LLMの出力に対してスカラー報酬(単一の数値)で評価し、勾配更新でモデルの重みを調整します。

入力: "東京タワーの高さは？"
LLM出力: "333メートルです"
報酬: 1.0(正解)

入力: "東京タワーの高さは？"  
LLM出力: "634メートルです"
報酬: 0.0(不正解)

GRPOの問題点: 情報の損失

マルチホップQAタスクでの例を見てみましょう。

質問: "トム・ハンクスが主演した映画の監督で、
      スピルバーグと同じ大学を卒業したのは誰？"

【LLMシステムの実行トレース】
├─ ホップ1: "トム・ハンクス 主演映画" を検索 ✓
├─ ホップ2: "フォレスト・ガンプ 監督" を検索 ✓
├─ ホップ3: "スピルバーグ 大学" を検索 ✓
├─ ホップ4: "ロバート・ゼメキス 大学" を検索 ✗(失敗)
└─ 最終回答: "不明"

【GRPOが受け取る情報】
報酬 = 0.0(不正解)

→ どのホップで失敗したか不明
→ なぜ失敗したか不明
→ どう改善すべきか不明

豊富な実行情報が「0」という1つの数字に圧縮されてしまいます。

GEPAのアプローチ

GEPAでは、テキストフィードバックを活用し、LLM自身に内省させてプロンプトを改善します。

【同じタスクでGEPAが受け取る情報】

フィードバックテキスト:
"ホップ1-3は成功。ホップ4で失敗。
 
 失敗の原因分析:
 - クエリ「ロバート・ゼメキス 大学」は曖昧
 - 「どの大学を卒業したか」という意図が不明確
 - 「学歴」「卒業」などのキーワードが欠如"

GEPAの処理フロー

全体の流れ

① タスクがある
   例: マルチホップQA、プライバシー保護変換など

② そのタスクをLLMにやらせるためのプロンプトがある
   「こういう手順で、こういう点に注意して処理せよ」

③ 実際にタスクを実行する
   入力 → LLM(プロンプトに従う) → 出力

④ 出力を評価し、フィードバックを生成
   「ここが失敗」「この情報が欠落」など

⑤ フィードバックを基にLLMが内省
   「なぜ失敗したか」「どう改善すべきか」

⑥ より良いプロンプトを生成
   改善点を反映した新しい動作指針

③〜⑥を繰り返す

この文脈での「プロンプト」とは

GEPAの文脈では、プロンプトはLLMへの動作指針・命令書を意味します。

【一般的な使い方】
プロンプト = ユーザーがLLMに送る質問や依頼
例: 「東京タワーの高さを教えて」

【GEPAの文脈】
プロンプト = LLMへの動作指針
例: 「あなたは検索クエリ生成モジュールです。
     以下のルールに従ってクエリを生成してください...」

フィードバックと内省

フィードバックの生成方法

フィードバックは必ずしもLLMが生成するわけではありません。主に以下の方法で生成されます。

タスク	フィードバック生成方法
IFBench(制約付き生成)	ルールベースで制約違反をチェック
コード生成	コンパイラのエラーメッセージをそのまま利用
マルチホップQA	実行ログを整形

IFBenchの例:

# 制約: 「500文字以内」「"however"を含む」
# LLMの出力: 620文字、"however"なし

# フィードバック生成(プログラム的に)
if len(output) > 500:
    feedback += "文字数超過: 620/500"
if "however" not in output:
    feedback += "必須キーワード欠落: however"

内省(Reflection)でLLMを使う

フィードバック自体はルールベースや外部ツールで生成しますが、そのフィードバックを読んで「なぜ失敗したか」「どう直すべきか」を考える内省フェーズでLLMを使います。

【役割分担】

【フィードバック】
  生成者: コンパイラ、検索エンジン、ルールチェッカー等
  内容:  「何が起きたか」の事実
          ↓
【内省(Reflection)】
  実行者: LLM
  内容:  「なぜ失敗したか」「どう直すべきか」の分析
          ↓
【新しいプロンプト】
  生成者: LLM
  内容:   改善された動作指針

内省用のメタプロンプト

内省にはメタプロンプト(固定)が使われます。

私はアシスタントに以下の指示を与えてタスクを実行させました:

'''
[現在のプロンプト]
'''

以下は入力、出力、フィードバックの例です:

'''
[ミニバッチのサンプル]
'''

あなたの課題は新しい指示を書くことです。
- 入力形式とタスクの詳細を推測してください
- フィードバックからドメイン知識を抽出してください
- 成功パターンを一般化して指示に含めてください

階層構造としては以下のようになります。

【レベル1: タスク実行】
  プロンプト → LLM → 出力

【レベル2: 内省・改善】
  メタプロンプト(固定) → LLM → 新しいプロンプト
       ↑
  「現在のプロンプト + フィードバック」を入力として含む

なぜLLMに「言葉で教える」のか

2つの学習方法の比喩

【方法A: 試行錯誤(強化学習)】
先生: 「弾いてみて」
子供: ♪(演奏)
先生: 「違う」(それだけ)
子供: ♪(別の弾き方)
先生: 「違う」
...
→ 何千回も繰り返して「体で覚える」

【方法B: 言語的説明(GEPA)】
先生: 「弾いてみて」
子供: ♪(演奏)
先生: 「3小節目のシャープを忘れてるよ。
       この曲は短調だから必ずシャープが必要」
子供: 「なるほど、調号を確認すればいいんだ」
→ 数回の説明で「原理を理解」

GEPAの核心的アイデア

LLMはもともと「言葉を理解する」能力を持っています。GEPAはこの能力を自分自身の改善にも使おうという発想です。

【従来】
LLMの言語理解能力 → ユーザーの質問に答える

【GEPA】
LLMの言語理解能力 → ユーザーの質問に答える
                  → 自分の失敗を分析する ← 新しい
                  → 改善方法を提案する  ← 新しい

「LLMに数字(0/1)で教えるのではなく、言葉で教える。
LLMは言葉を理解できるのだから、言葉で教えた方が効率的。」

学習効率の違い

1回のロールアウトで得られる情報量

【GRPO】
報酬: 0.0
→ 1ビット程度の情報
→ 「失敗した」という事実のみ

【GEPA】
- どのステップで失敗したか
- なぜ失敗したか(原因分析)
- 何が足りなかったか(欠落情報)
- どう改善すべきか(具体的提案)
→ 数百〜数千トークンの情報
→ 直接的な改善指針を含む

実験結果

論文の実験では、GEPAはGRPOに比べて平均10%高い性能を、最大35分の1のロールアウト数で達成しました。

タスク	GRPO	GEPA	効率化
HotpotQA	43.33	62.33	60倍
IFBench	35.88	38.61	73倍
HoVer	38.67	52.33	20倍
PUPA	86.66	91.85	78倍

プロンプト進化の具体例

論文のPUPAタスク(プライバシー保護クエリ変換)での進化を見てみましょう。

【候補0: 初期プロンプト】スコア: 82.26
"プライベートなユーザークエリを、外部LLM用の
 プライバシー保護リクエストに変換せよ。"

    ↓ 反省: PIIの特定方法が不明確

【候補2: 1回目の改善】スコア: 90.99
"+ PIIの特定と一般化に関する詳細なガイダンス
 + クエリ意図の分析と変換理由の説明を追加"

    ↓ 反省: 出力形式が不統一

【候補4: 2回目の改善】スコア: 94.44
"+ 出力を「推論」と「リクエスト」に分離
 + 名前/コードの明示的禁止
 + 抽象化の具体例を追加"

    ↓ 反省: 透明性が不足

【候補11: 最終形】スコア: 97.60
"+ 厳格なステップバイステップのPII抽象化
 + 部分的な墨消しの禁止
 + 監査可能なプライバシー保護の徹底"

各改善ステップで、なぜその変更が必要かが自然言語で記録されています。

まとめ

観点	GRPO(強化学習)	GEPA
学習信号	スカラー報酬(0/1)	テキストフィードバック
改善の単位	モデルの重み	プロンプト(テキスト)
改善の可読性	不可読	可読(自然言語)
必要サンプル数	数万〜数十万	数百〜数千
計算資源	GPU必須	API呼び出しのみ
局所最適回避	なし	パレート選択

GEPAは「LLMの言語理解能力を学習にも活用する」という発想で、効率的なプロンプト最適化を実現しています。

GEPAの3つのポイント

フィードバック: 外部ツール(コンパイラ、ルールチェッカー等)が「何が起きたか」を記録
内省: LLMがフィードバックを読み、「なぜ失敗したか」「どう直すべきか」を分析
パレート選択: 複数の「勝ち戦略」を維持し、局所最適を回避