mcpField
A
alpha-evolve

alpha-evolve

github.com/gaasherデータ・データベース17839 回インストール17 週間前に更新
リポジトリ

alpha-evolve について

alpha-evolveは、編集可能なモデルやプログラムコードを対象に、集団ベースの進化的探索を行うスキルです。複数の候補を並列評価し、島ごとのMAP-Elitesアーカイブで高性能と多様性を維持します。

主な機能

  1. 01集団ベースのプログラム探索
  2. 02SEARCH/REPLACEによる変更
  3. 03段階的な評価実行
  4. 04島をまたぐMAP-Elitesアーカイブ
  5. 05複雑さと多様性の追跡
  6. 06島間移行とチェックポイント

活用シーン

  1. 01複数のモデルコード案を並列探索
  2. 02多様な高性能候補の維持
  3. 03固定された学習実行予算での探索

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/gaasher/agent-loop-skills --skill alpha-evolve

インストール後、Claude Code で/alpha-evolveを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
run.example.yaml
roles/
Mutator.md
schemas/
result.schema.json

詳細

Alpha-Evolve

参考資料(アルゴリズムの詳細が必要な場合はお読みください):AlphaEvolve — https://arxiv.org/abs/2506.13131 · OpenEvolve(オープンソース実装)— https://github.com/algorithmicsuperintelligence/openevolve

プログラムを対象とする集団ベースの進化ループです。成果物は編集可能なモデルコードです。子とは、親に対する分析に基づいた 1 つのSEARCH/REPLACE 差分であり、フィードバック信号は段階的に評価されるトレーニング実行(<metric>、スモークテストからフル実行まで)です。子は、複雑度と多様性を軸とする島々にまたがる MAP-Elites アーカイブに配置されるため、より優れているか、より新規性が高いかのいずれかによって生き残ります。単に優れているだけではありません。この手法が徹底する原則は、多様性を保ち、収束させないことです。多様で高性能な候補が共存し、1 つの局所最適解だけが勝つことはありません。コントローラーであるあなたは、親とインスピレーションの候補を選び、並列の Mutator を起動して子を提案・評価し、それらを配置し、島の間で移行させ、チェックポイントを作成します。固定の計算予算に達するか、中断されるまでループを実行します。

使用する場面

多くのバリアントを一度に探索し、アーカイブが探索済みのフロンティアを維持する、モデル/プログラムに対する並列かつ多様性を維持する探索に使用します。デフォルトでは島々を幅広くカバーします。品質の向上が停滞したら、上位エリートの活用を重視するよう選択を調整します。カバレッジが停滞したら、空のセルを優先するよう調整します。逐次的な autoresearch ループ(1 回に 1 つの変更を行う)や、既知の異常の修正には適していません。

登場する役割(どちらもこのフォルダー内):roles/Mutator.md は子を 1 つ生成し、段階的に評価します(生成ステップ)。schemas/result.schema.json は Mutator が返す結果です。

セットアップ

バインディングを対話形式で解決します。作業ディレクトリに loop.run.yaml がある場合は、それを読み込み、値を一行で確認して、ループに進みます。ない場合は、Claude Code では(AskUserQuestion ツールが利用可能で、<host> = claude-code)、各バインディングのもっとも妥当な値を推定し、推奨オプションとして提示します。他のホストでは(<host> = other)、引用符付きのプレーンテキストの質問として、それぞれ尋ねます。その後、loop.run.yaml(形式:examples/run.example.yaml)を書き込み、ほかのファイルを作成する前に値を確認します。<host> は実行方法も決定します。Claude Code は実際の Agent Mutator を最大 <concurrency> 個並列で起動します。他のホストでは、各世代の子を逐次実行する方式に切り替わります(アルゴリズムは同一です)。

まず環境を調べてください(必須 — <concurrency> は推測せず、測定してください)。 以下を記録して報告します。

  • CPU コア数 → <cores>:python3 -c "import os; print(os.cpu_count())"。
  • RAM → <ram_gb>:macOS では sysctl -n hw.memsize、Linux では grep MemTotal /proc/meminfo。
  • アクセラレーター → <accelerator>/<vram>/<gpu_count>:NVIDIA の場合は nvidia-smi --query-gpu=name,memory.total,count --format=csv、それ以外は macOS の Apple GPU/MPS、さらにそれ以外は CPU のみ。
バインディング意味デフォルト推定方法
<metric> + <metric_direction>最適化するスカラー値。最小化/最大化—尋ねる。評価出力を調べ、報告されているメトリクスを確認する
<run_cmd> / <entrypoint>1 回のトレーニング実行に使うコマンド(評価器)—pyproject.toml/.venv/uv/README
<editable_files>進化させるプログラム(例:model.py、config.yaml)。ハーネスやデータは対象外—明示的に尋ねる — 変更対象となるコードです。デフォルト値を設定しない(Claude Code では複数選択)
<sandbox_root>lae/ を作成する場所./sandbox—
<gate> + <budget>1 回の完全な実行の規模:time/epochs とその量。すべてのプログラムに適用される固定の評価予算—時間の設定キーを特定する(例:train.epochs)。これにより、コントローラーがその値を上書きできます
<total_budget>総計算量 = 完全なトレーニング実行の回数(または実時間の分数)。コストを調整する唯一の設定—尋ねる
<concurrency>並列評価の数 C環境の調査結果から算出CPU のみ → max(1, <cores>//4)。GPU/MPS が 1 基 → 1(<vram> に収まる数がさらに多いか尋ねる)。複数 GPU → <gpu_count>(子をそれぞれ 1 基の GPU に割り当てる)

num_generations は導出値です:ceil(<total_budget> / <concurrency>)。カスケードも <budget> から導出されます(質問しません):スモーク = 約 1 エポック/小さなサブセット、フル = <budget>、ゲート = 子のスモーク <metric> ≥ 親のスモーク。<budget>/<metric>/評価用分割は固定です — 変更対象にしてはいけません(子がよい結果に見せるために「より長くトレーニング」することはできません)。これらを変更するには、ループ全体を再実行する必要があります。

詳細設定(任意)。 はい/いいえで 1 つ質問します:「進化設定にデフォルトを使いますか、それともカスタマイズしますか?」 デフォルトは AlphaEvolve/OpenEvolve に忠実な設定です。これを使う場合は、それ以上尋ねません。「カスタマイズする」の場合のみ、各設定について尋ねます(デフォルト値を推奨として提示):num_islands (4)、num_top (3)、num_diverse (2)、num_bins (10)、migration_interval (5)、diversity_reference_size (10)、pop_per_island (40)、seed (42)。軸は固定です:複雑さ × 多様性。形式については examples/run.example.yaml を参照してください。

解決したバインディング、環境の調査結果、導出した num_generations を表示し、ユーザーの確認を得るまでファイルを作成したり、実行を開始したりしないでください。確認後、サンドボックスを初期化します(ヘッダー行のみ。programs/ は子の評価時に作成されます)。

<sandbox_root>/lae/
├── archive.tsv     ← current elites = program database + checkpoint
├── history.tsv     ← append-only record of every child
├── leaderboard.md  ← rendered UI
└── programs/       ← one self-contained dir per program

コントローラー(ループ)

archive.tsv の num_islands 個の MAP-Elites マップ、追記専用の history.tsv、軸ごとの実行中パーセンタイル統計、leaderboard.md を管理します。共有ログへの書き込みはすべて、あなただけが行います — Mutator は結果を返すだけなので、書き込み競合は発生しません。このチェックリストをコピーして、項目にチェックを付けてください:

  • セットアップ完了:プローブを記録し、バインディングを確認し、サンドボックスを初期化し、num_generations を算出しました。
  • GEN 0 — 各アイランドでベースラインプログラム(<editable_files> のコピー)を作成し、任意で確率的なバリアントをいくつか作成します。カスケード評価を行い、アーカイブに格納します。
  • 世代ごと:タスクを必ず <concurrency> 個作成します(アイランドをラウンドロビンで選択し、シード済みルールで親を選び、上位 num_top 個と最も多様な num_diverse 個のインスピレーションを選択します)。親プログラムとハーネスをコピーして、子のディレクトリを作成します。
  • roles/Mutator.md、親のコード、インスピレーション、親の成果物、子のディレクトリ、スモーク/フルの予算をそれぞれ渡し、C 個のミューテーター(生成または劣化)を実行します。
  • 返された子ごとに history.tsv の行を追加します。evaluated の場合はニッチを計算し、セルを特定して、<metric> がより良い場合に限りアイランドマップに格納します(kept=y)。配置せずに smoke_dropped/crash を記録します。
  • leaderboard.md を再生成し、チェックポイントを作成します(チェックポイントは archive.tsv です)。ステータス行を出力します。
  • migration_interval 世代ごとに、上位エリートをアイランド k から k+1 へリング移行します。
  • <total_budget> まで実行し(合成用に少し予算を残します)、最後にレポートを合成します。

ニッチの計算(子のサンドボックスから計算します):

  • complexity = 学習可能なパラメーター数(取得できない場合は、編集可能なファイルの総 LOC +子が追加したファイル)。log10 スケーリングします。
  • diversity = プログラムの連結コード(編集可能なファイル+追加ファイル)と、アイランド内の diversity_reference_size 個のプログラムからランダムに抽出したサンプルとの、正規化済み編集距離の平均です(アイランドにほとんどプログラムがない場合はベースラインと比較します)。値が大きいほど新規性が高くなります。
  • 各軸を逐次的な約 5/95 パーセンタイルで正規化します(生の最小値/最大値ではなく、外れ値 1 つで範囲が潰れないようにします)。scaled = clamp01((v − p5)/(p95 − p5))、bin = min(num_bins−1, int(scaled × num_bins))、cell = (complexity_bin, diversity_bin) とします。パーセンタイルがセルの境界を動かすほど変化した場合は、既存のエリートを再ビニングします(衝突時はより高い <metric> を維持します。アーカイブは小規模です)。

ミューテーターのプロンプト(サンプラー): 親のコード+インスピレーション+親のレンダリング済み成果物(<metric>、クラスごとの精度、損失曲線、stderr)+SEARCH/REPLACE diff を 1 つ返す指示です。ハーネスのモデルは 1 つのみで、LLM アンサンブルは使用しません。ミューテーターは子のディレクトリで差分を適用し、FIXED <budget> でカスケード評価します(コントローラーが実行コマンドに時間のキーを挿入し、上限を設定します)。結果は schemas/result.schema.json に照らして検証されます。

{"child_id": "g3-i1-a2", "parent_id": "g1-i1-a0", "approach_summary": "add BatchNorm after conv2",
 "sandbox_path": "<sandbox_root>/lae/programs/g3-i1-a2", "status": "evaluated",
 "smoke_metric": 0.61, "metric": 0.71}

status ∈ {evaluated, smoke_dropped, crash}。metric は evaluated でない限り null です。ミューテーターはアーカイブに関する計算を一切行いません。コントローラーがサンドボックスからすべてのニッチを算出します。

プログラムのサンドボックス。 並列の個体群はブランチに対応しないため、各プログラムは自己完結した完全に実行可能なディレクトリ <sandbox_root>/lae/programs/<child_id>/ に配置します。アーカイブは ID で参照します。各子のディレクトリは、親の <editable_files> を実ファイルとしてコピーしてから差分を適用し、さらにインポートするハーネス/エントリーポイントのコードもコピーして作成します。そのディレクトリ内から評価します(cd <child_dir> && <entrypoint>)。大きな読み取り専用データのみシンボリックリンクにし、エントリーポイントやインポートする .py は決してリンクにしないでください。Python はシンボリックリンクされたスクリプトの __file__ をリンク先に解決するため、sys.path[0] が元のディレクトリになり、子の model.py/dataset.py がベースラインにひそかに覆い隠されます。その結果、アーキテクチャやデータの変更がすべて反映されなくなります(異なる「アーキテクチャ」で損失曲線が同一になるのが典型的な兆候です)。分離の健全性チェック: ハーネスにパラメーター数/コードフィンガープリントを記録させます。コードが変わっているにもかかわらず、親と同じ指標/損失曲線になった子は覆い隠されているものとして検出し、配置する前にサンドボックスを修正します。リポジトリの作業ツリーは変更しません。

最終合成。 全体最良のプログラムとその lae/programs/<id>/ パス、明らかになった複雑さ×多様性マップ(カバレッジと各領域の勝者)、アイランドごとの最良プログラム、そして特に多様性に富む次点候補を 2~3 件報告します。

台帳

3 つのログはすべて <sandbox_root>/lae/ にあり、タブ区切りです。自由記述内にカンマは使用しません。 書き込みを行うのはコントローラーのみです。中断した場合は、archive.tsv と history.tsv から再開してください。

archive.tsv — 現在のエリートとチェックポイント。ヘッダー island cell metric child_id parent_id sandbox_path complexity diversity:

island	cell	metric	child_id	parent_id	sandbox_path	complexity	diversity
0	(2,7)	0.7100	g4-i0-a1	g2-i0-a3	lae/programs/g4-i0-a1	2.1M	0.71

history.tsv — すべての子を記録し、追記のみで更新します。ヘッダー gen island parent_id child_id smoke_metric full_metric status kept cell:

gen	island	parent_id	child_id	smoke_metric	full_metric	status	kept	cell
4	0	g2-i0-a3	g4-i0-a1	0.61	0.71	evaluated	y	(2,7)
4	1	g2-i1-a0	g4-i1-a2	0.40	-	smoke_dropped	n	-

leaderboard.md — 各世代で再生成します。全体のベスト、島ごとのカバレッジ、<metric> 順に並べたアーカイブを記載します。停止時には最後に実行したプログラムではなく、ベストのプログラム、アーカイブのカバレッジ、多様性のある次点候補をいくつか報告してください。lae/ は未追跡のままにします。

制約

  • 子は、自身の lae/programs/<child_id>/ ディレクトリ内でのみ作業します。コピーされた <editable_files> を編集したり、その場所に新しいファイルを作成したりできますが、ディレクトリの外にあるファイルは変更しないでください(リポジトリ、読み取り専用のハーネス、データ、他のプログラムのディレクトリは、正解の基準または共有状態です)。
  • archive.tsv/history.tsv/leaderboard.md の書き込みを行うのはコントローラーのみです。そのため、並列で実行する Mutator がログの書き込みで競合することはありません。
  • <concurrency> はプローブとユーザーの確認に基づいて設定します。マシンの性能を決めつけないでください。複数 GPU の場合は GPU 1 台につき子を 1 つにします。実行時に OOM やスラッシングが発生した場合は、C を下げてそのことを伝えてください(子の設定を書き換えて合わせてはいけません)。マシンの上限は実際の制約であり、子を書き換えると比較が損なわれるためです。
  • <budget>(エポック数/時間)、<metric>、評価/テストの分割は固定であり、変更してはいけません。 コントローラーは実行のたびに <budget> を注入し、子が設定した実行時間を上書きします。そのため、「学習時間を延ばす」、評価指標を変更する、テストセットを変更するといった方法では決して勝てません。計算量や評価方法ではなく、モデル/オプティマイザー/データパイプラインを進化させてください。プログラム間の比較可能性を保つために必要です。
  • エントリーポイントやインポートされた .py ファイルを子のディレクトリにシンボリックリンクしないでください(sys.path[0] 経由で子のコードを隠してしまいます)。ハーネスのコードはコピーし、データのみシンボリックリンクします。また、子を配置する前に隔離の健全性ゲートを実行してください。コードが隠された結果は幻です。
  • 新しいパッケージをインストールしたり、評価ハーネスを変更したりしないでください。<metric> が正解の基準です。
  • 「続けますか?」と確認するために作業を中断しないでください。 <total_budget> まで(合成のために少し時間を確保して)実行するか、中断してください。カバレッジが伸び悩んだら空のセルを優先し、品質が伸び悩んだら上位のエリートを活用してください。ゲートの制限時間を超えた子は終了させ、crash として記録します。

コメント