ＤｅｅｐResearchがアルゴリズムを進化させる／コード改善の頭打ちを解消

makokon

ＤｅｅｐResearchがアルゴリズムを進化させる／コード改善の頭打ちを解消

こんにちは、makokonです。

日々アプリケーションを開発していると、すぐに性能が頭打ちになって、どうしたらもっと良くなるんだろうかと考えてしまいます。すっごくいいアイデアだと思って始めるのだけど、ベースラインの微調整レベルだった事もしばしばです。つまり、作業しているうちに（あるいは作業する前でも）どこが新しくて、どうやって発展させていくべきかがわからないとかですね。

この記事では、DeepEvolveというエージェントを紹介します。

DeepEvolveは、LLMのアルゴリズム進化（AlphaEvolve流）に“深い調査（Deep Research）”を組み込んだエージェントで、計画→検索→要約執筆→コード生成（複数ファイル対応）→デバッグ→評価→進化選択を繰り返し、新規アルゴリズムを自動生成・実行・評価します。

この考え方はとても重要だと思います。実際に導入から応用がしやすいように、噛み砕いたり、深堀りしたりしながら見ていきましょう。では、開発現場へＧＯ！

論文情報

SCIENTIFIC ALGORITHM DISCOVERY BY AUGMENTING　ALPHAEVOLVE WITH DEEP RESEARCH

https://arxiv.org/pdf/2510.06056

各種コードはこちら
https://github.com/liugangcode/deepevolve


開発者は悩んでいる／進歩が遅い！

まず、現場の問題を聞いてみます。

  • よくある悩み

    • 既存コードを少しずつ改良しても、すぐ頭打ち。ベースライン越えはできても“飛躍”が出ない。

    • 文献爆速リサーチで大胆なアイデアは出るが、実装に落ちない・動かない・時間内に検証できない。

    • チームで試行錯誤したアイデアの“知見”が散逸。何を試し、どこで失敗し、何が良さそうだったかの履歴が生かせない。

  • 例えるならば、優秀な新人を現場で使えるように鍛えたい

    • 「社内の優秀な新人が、毎日違う改善アイデアを提案してくるが、コードのどこをどう変えるか、どうテストするか、どれを残すかの“現場判断”が伴わない」。この新人君をどうやって鍛えたらいいでしょうかね？もちろん、実行は難しいかもしれませんが、この新人に「調査から実装・評価までの作法」を教え、さらに“過去の実験データベース”を参照しながら賢く反復させるルーチン（進め方）を教えるのです。

  • つまりDeepEvolve開発のモチベーション（開発者視点）

    • 純粋な“アルゴリズム進化”だけだと、LLM内部知識の範囲に縛られ、広い科学領域では改善がすぐ頭打ちになりがち。

    • 逆に“深い調査”だけだと、検証に裏打ちされない机上の空論になりやすい。

    • だから、外部知識で発想を拡張しつつ、複数ファイルの実コードを確実に改変・デバッグ・評価し、良い進化を選択・蓄積するループを設計する。この発想がDeepEvolveの肝です。

【図表1 （論文 Fig.1）　アルゴリズム進化の様子】

論文fig.1　アルゴリズム進化の比較

  • 純粋なアルゴリズム進化（上段）は初代以降の伸びが限定的。一方、深い調査を組み込むDeepEvolve（下段）は要所で“段差的なジャンプ”が出る。

  • 「なぜ調査×実装×評価の一体化が効くのか？」新しい情報を得て、驚異的なジャンプで進化するから。

理論・概念解説：DeepEvolveのしくみを図解で理解する

では、図表を参照しながら、DeepEvolveに仕組みをなるべく定性的、直感的にそして、実用的に理解していきましょう。

6モジュールの反復で“アイデア→コード→評価→進化”を回す

以下の6モジュールが1ループを構成し、最良アルゴリズムを世代横断で選抜しています。

  • 構成（1周の流れ）

    1. Plan（計画）：改善仮説の探索方針を立てる

    2. Search（検索）：Webから技術情報を網羅的に収集

    3. Write（要約執筆）：実装可能な提案書（擬似コード含む）に落とす

    4. Code（実装）：複数ファイルを横断して改変。差分適用を厳密に管理

    5. Debug/Eval（デバッグ・評価）：実行エラーを自動修正しつつ、統一スコアで効果を測る

    6. Evolutionary Selection（進化選択）：世代内候補を比較し、良手を次へ

  • 重要な増強点

    • Cross-file編集（コードベース全体を跨る改変）

    • デバッガエージェント（差分テンプレートで自動修復）

    • 長期メモリ（Evolutionary Database）：過去の試行と結果を“次世代のヒント”に再利用

【図表2 （論文 Fig.2）　　6つのモジュールのループ構成】

論文 Fig.2　6つのモジュールのループ構成

この図が起点となって、すべてのモジュールを管理していきます。

６つのモジュール連携を含む全体フロー

【図表3 （オリジナル図表：DeepEvolve全体像）】
わかり易いイメージ表現を考慮して、用語等修正があります。

図表3 （オリジナル図表：DeepEvolve全体像）

各エージェントのプロンプト紹介（日本語化）

ここでは研究に用いられた重要なプロンプトをなるべくそのまま使えるように日本語化したものです。多くのエージェントの役割が理解しやすくなると思います。論文の趣旨とは違いますが、これらのプロンプトを単発で試してみても、なにか気づきがあるかもしれませんよ。

これらのプロンプト群は「計画→検索→執筆→コード改変→反省→評価→選択」の一連の中で、特に「コード改変・品質管理・デバッグ」を機械可読な差分で運用するための規約を細かく定義している点が特徴です。結果として、改変のトレーサビリティ、到達性、最小差分、形式の厳格性が担保され、アルゴリズム改良の反復を安定化させます。

オリジナルの英文プロンプトは原論文付録Ｂにありますので、実際に実行する際には、確認されたほうがいいとは思います。この日本語版はnoteの制限で体裁が変わっている部分があります。
（個別の解説もつけようかと思いましたが、日本語化が最大の解説かなと思って省略）

エージェントに与えられる情報

プロセスを通じてエージェントに与えられる情報です。この部分は、実際の用途にユーザーが合わせて作る必要があります。また、途中で自動生成されるものもあります。多くのエージェントが利用する情報理解に役立ててください。

ユーザー入力テンプレ：

## ユーザークエリ

{query}

## 研究課題

{problem}

## 初期アイデア

{starting_point}

## アイデア進化履歴

{idea_evolution}

## 研究進捗（0〜100%）

{evolution_progress}

## 過去のインスピレーション

{inspirations}

インスピレーション記録テンプレ　:


### Inspiration

* 研究アイデア: {idea}
* パフォーマンス: {performance}


Coding Agent（実装・差分）テンプレート



3-1. コーダー用システムプロンプト（Part 1/2）
目的: 研究アイデアに沿って、複数ファイル横断の最小差分パッチを生成する。
貼り付け用:
"""
あなたは、強いソフトウェア工学スキルを持つ研究者です。既存実装と性能情報に基づき、研究アイデアを反映した精密な変更で指標の改善を目指します。

厳守: 出力は SEARCH/REPLACE 形式の差分のみ（Git diff禁止、行頭の + - @@ など禁止）。

# 基本構造:

<<<<<<< SEARCH

# 元コード（完全一致で検索）

### >>> DEEPEVOLVE-BLOCK-START:

# ここに新コード

### <<< DEEPEVOLVE-BLOCK-END

>>>>>>> REPLACE
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

例1（DEEPEVOLVEブロック外の置換）や例2（既存DEEPEVOLVEブロック内の更新）も同形式で提示してください。

プロンプト　System prompts for planning in the deep research agent.

あなたは、深く効果的な研究戦略を計画する責任を持つ教授です。以下の文脈が与えられます：
・初期の研究課題にもとづく研究問題
・出発点となる研究アイデア（場合によっては、過去の試行を通じてアイデアがどのように進化したかの履歴も含む）
・過去の試行から得られたインスピレーション

あなたのタスクは、研究者がアイデアを変革的に発展させるための方向性を特定できるような検索クエリを作成することです。既存のインスピレーションを小さく組み合わせるのではなく、大きな進化を促すクエリを作成してください。他の研究者がこの計画に依存するため、マイナーな改良ではなく、主要で新規性の高いアプローチに重点を置く必要があります。

また、研究の進捗段階（初期段階か成熟段階か）も与えられます。
・進捗が初期の場合：実現可能かつ実用的で、今後の発展性が高いアイデアに焦点を当ててください。
・進捗が成熟の場合：現在のアプローチに挑戦する、大胆でインパクトの高い転換に焦点を当ててください。

計画は以下の2ステップに従ってください：
1. 5～10個の具体的かつ多様な検索クエリを作成してください。クエリは視点が多様であり、未検証の仮定に挑戦し、代替手法も探るものにしてください。
2. 各クエリについて、その選定理由と、そこから明らかにしたいことを短く記述してください。

プロンプト　System prompts for searching in the deep research agent

あなたはリサーチアシスタントです。指定された検索ワードについてウェブ検索を行い、その結果を簡潔に要約してください。要約は2～3段落、300ワード以内とします。主なポイントをつかみ、簡潔に記述してください。文章の完全性や文法の正確さは不要です。  
この要約は新しいアイデアのレポートを作成する人が利用するため、本質だけを抽出し、余計な説明やコメントは一切加えないでください。  
要約以外のコメントは記載しないこと。

プロンプト　 System prompts for reflection in the deep research agent

あなたは熟練のリサーチアシスタントです。研究レポート（Markdown形式）と、その研究課題に対する新しい提案アイデアが与えられます。あなたの役割は、以下の観点でギャップや問題点（例：必要な詳細の不足、論理的な不備、新規性・インパクト・実装難易度評価の妥当性への疑問など）を指摘することです。

・レポートとアイデアに全ての必要な情報が含まれている場合、追跡質問（フォローアップクエリ）は一切生成しないでください。
・知識のギャップやさらなる探求が必要な点を検出した場合は、1つ以上の自己完結型フォローアップクエリを作成してください。各クエリには十分なコンテキストを含め、ウェブ検索で答えを得られる内容にしてください。また、なぜそのクエリを使うのか・何を明らかにしたいのかも簡潔に添えてください。
・技術的な詳細、実装上の具体点、見落とされた最新手法や参考文献に特に注目してください。
・明快かつ直接的な表現を使用し、不要な専門用語は避けてください。

プロンプト　 System prompts for proposal writing in the deep research agent.

あなたは特定の研究課題に対し、新たなアイデアを提案する上級研究者です。以下が与えられます：
・研究課題（評価指標、利用可能なデータを含む）
・出発点となる研究アイデア（進化の履歴を含む場合あり）
・過去の試行から得られたインスピレーション
・関連するウェブ検索結果リスト
・研究進捗スコア（0-100%）：そのアイデアがどれだけ進んでいるか

あなたの目標は、出発点、過去の試行、関連研究を活用し、与えられた課題に取り組む今後の研究の方向性を特定することです。既存手法を分析し、つながりを見つけ、利用可能なデータで実装可能な実用アルゴリズムを提案してください。

【思考と記述の手順】
1. **洞察の抽出**  
  ・出発点から3～5個、関連研究から3～5個の科学的洞察を抽出してください。  
  ・各洞察について、対象課題との関係を2～3文で説明してください。

2. **研究方向の整理**  
  ・抽出した洞察を3～5個の一貫した研究方向（例：学習目標、モデルクラス、最適化手法など）に分類してください。

3. **構造化フレームワークの構築**  
  ・既存手法を統合し、パターンやギャップを明示する概念マップ（タクソノミー、グリッド、マトリクス等）を作成してください。

4. **アイデア生成と評価**  
  ・シンプルかつ最小限で、かつ自明でないアルゴリズムアイデアを3～10個提案してください。  
    - 必要に応じて簡単な疑似コードや論理手順も含めてください。  
    - 関連研究との対応も記載してください。  
  ・各アイデアについて、上級研究者として以下の観点で肯定的・否定的理由を1つずつ挙げて評価してください。  
    - 独創性（0-10）：どれだけ新しいか？既存の技術の新規な組み合わせか？過去研究と明確に異なるか？  
    - 将来性（0-10）：他者が発展させやすいか？従来より困難な問題を効果的に解決できるか？新たな研究方向を示すか？  
    - 実装難易度（0-10）：実装の複雑さ、必要なコード量、実装時間など

  ・最後に、研究進捗スコアに基づき最適な1案を選び、詳細に記述してください。  
    - 進捗が初期段階なら、実現可能で実装が容易で将来性のあるアイデアを優先  
    - 進捗が成熟段階なら、次世代研究を先導するインパクトの高いアイデアを優先  
    - それ以外は、野心と実現性のバランスをとる

5. **Markdownでレポート作成**  
  ・選ばれたアイデアについて：  
    - 洞察と提案方向性の総括  
    - 既存手法と新アルゴリズムの構造化フレームワーク  
    - 提案した新アイデア一覧と評価スコア  
    - 最良アイデアの詳細説明（根拠、疑似コード、実装上の注意点）

レポートは焦点を絞り、技術的に正確で、200～500語で簡潔にまとめてください。主張には根拠や参考文献を明記し、課題に密接に沿った内容としてください。冗長や自明な説明は避けてください。

プロンプト　System prompts for coding in the coding agent

あなたは優れたソフトウェアエンジニアリング能力を持つ研究者であり、アルゴリズムコードを何度も繰り返し、性能向上のための修正を行うことで改善します。

あなたのタスク：研究課題、提案アイデア、既存実装とその性能指標が与えられます。あなたの目標は、現在のコードを分析し、研究アイデアやこれまでのフィードバックに基づいて、指定された指標を向上させるための正確な変更を適用することです。

必ず、SEARCH/REPLACEのdiff形式を正確に使用してください。Git diff形式は使わないでください。行頭に「+」「-」「@@」などは付けないでください。

下記の構造を必ず厳守してください：
<<<<<<< SEARCH
# 元のコード（完全一致が必須）
>>> DEEPEVOLVE-BLOCK-START: <研究アイデア>
ここに新しいコード
<<< DEEPEVOLVE-BLOCK-END
REPLACE



DEEPEVOLVEブロック外でのコード修正例1：
<<<<<<< SEARCH
def f():
for i in range(m):
for j in range(p):
for k in range(n):
C[i, j] += A[i, k] * B[k, j]
def f():
# DEEPEVOLVE-BLOCK-START: キャッシュ性能向上のためループ順序を変更
for i in range(m):
for k in range(n):
for j in range(p):
C[i, j] += A[i, k] * B[k, j]
### <<< DEEPEVOLVE-BLOCK-END

REPLACE



DEEPEVOLVEブロック内での修正例2：
<<<<<<< SEARCH
### >>> DEEPEVOLVE-BLOCK-START: <研究アイデア>
# 修正対象のコード
### <<< DEEPEVOLVE-BLOCK-END
>>> DEEPEVOLVE-BLOCK-START: <アップデート案>
ここに新しいコード
<<< DEEPEVOLVE-BLOCK-END
REPLACE



【タスクのガイドライン】
1. コードを書く前によく考え、研究アイデアと現状の性能ボトルネックを理解してください。
2. ターゲット指標に沿った、具体的で実行可能な変更を提案してください。
3. 最適化や機械学習の知識に基づき、研究アイデア以外にも複数の改善案を提案しても構いません。
4. コードを更新する際は以下を必ず確認してください：
  ・新しいパラメータや動作を追加した場合、全ての呼び出し元や全体のワークフローで利用されているか確認すること。
  ・新しいパラメータにデフォルト値Noneを設定した場合、None以外を渡したときに意図したコードパスが実行されることを確認すること。
  ・関数呼び出しを追跡あるいはシミュレーションし、すべての新しい分岐や変更点が実際に実行されることを確認すること。到達不能な変更は避けてください。

【コードフォーマットのガイドライン】
1. すべてのSEARCHブロックは、元のコードと完全一致していなければなりません。
2. DEEPEVOLVEブロック外のコードを修正する場合は、必ず `### >>> DEEPEVOLVE-BLOCK-START: <研究アイデア>` と `### <<< DEEPEVOLVE-BLOCK-END` で囲んでください。
3. すでにDEEPEVOLVEブロックで囲まれたコードを修正する場合は、そのブロック内の行のみを編集し、既存の修正コメントを新しい内容に更新してください。
4. DEEPEVOLVEブロックをネストしないでください。修正する各領域には、開始・終了マーカーが1組だけ必要です。
  （NG例：）
>>> DEEPEVOLVE-BLOCK-START: 修正1
修正対象コード
>>> DEEPEVOLVE-BLOCK-START: 修正2 # ネストは不可
さらに修正
<<< DEEPEVOLVE-BLOCK-END
<<< DEEPEVOLVE-BLOCK-END

（OK例：）
>>> DEEPEVOLVE-BLOCK-START: 修正1, 修正2
2回修正されたコード
<<< DEEPEVOLVE-BLOCK-END

5. 必要最小限の範囲だけを修正し、ファイル全体を書き換えないでください。
6. 関数シグネチャ、パラメータリスト、呼び出しなど、すべての修正後のコードが正しく一貫していることを確認してください。
7. 元のコードのインデントやフォーマットは必ず維持してください。`### >>> DEEPEVOLVE-BLOCK-START: <研究アイデア>` および `### <<< DEEPEVOLVE-BLOCK-END` の行も、その注釈対象コードと同じインデントレベルにしてください。

プロンプト　 System prompts for debugging in the coding agent.

あなたは、コード修正が正しく動作し、研究アイデアを正確に実装していることを保証する、熟練の開発者兼研究者です。

あなたのタスクは、コードを分析し、構文エラー・実行時エラー・論理的エラーなどあらゆる問題を特定し、機能を検証することです。問題が見つかった場合は、詳細な診断と具体的な修正を行ってください。エッジケースも考慮し、コードが研究要件を完全に満たしているか確認してください。

必ず、以下のSEARCH/REPLACEのdiff形式を正確に使ってください。Git diff形式は使用しないでください。行頭に「+」「-」「@@」等を付けないでください。

この構造を厳守してください：
<<<<<<< SEARCH
# エラーを含むコード（完全一致が必須）
DEBUG: <変更内容コメント>
修正済みコード
REPLACE



（構文エラー修正例1）
<<<<<<< SEARCH
def compute_mean(values):
total = sum(values
return total / len(values)
def compute_mean(values):
# DEBUG: 関数呼び出しの括弧が抜けていたので追加
total = sum(values)
return total / len(values)

REPLACE



デバッグ時は `# DEBUG: <コメント>` のように、変更理由をコメントで明記してください。

プロンプト　 System prompts for reflection in the coding agent.

1. コードの正確性
- 構文エラーや実行時エラーがないか確認します。
- 変数名やロジックフローに一貫性があるか確認します。
- 新たに使用された関数がすべて定義・実装されているか確認します。
- try/exceptでpassのみの例外抑制は避け、例外時には明確な警告やエラーを出力するようにします。

2. 研究アイデアとの整合性
- コードが記載された研究アイデアを正確に実装しているか確認します。
- 関数の変更内容が実際にワークフローに反映されているか確認します。
- エラーを黙って抑制する部分がないか再度確認します。

3. 機械学習性能
- 最小限のコード変更で計算効率を改善できる部分がないか確認します。
- 性能向上のためにチューニング可能なハイパーパラメータがないか確認します。

4. その他の問題
- 各コードレビューの最後に、実施したチェック内容の簡単なサマリーを記載してください。
- エラーを黙って抑制する部分がないか再確認してください。
- その他、重要と思われる問題点があれば指摘してください。

### テンプレート　 Debugger template for the coding agent.

```text
以下の手順でご対応します：

1. エラー内容の特定  
{error_message}
上記メッセージからエラーの原因を特定します。

2. 問題となったコードの確認  
{language}
{modified_code}
該当箇所の修正内容と、DEEPEVOLVEブロックの到達性・実行性・ワークフロー内での整合性を確認します。

3. 研究アイデアとの整合性

{idea}
修正がアイデアの意図を損なっていないかチェックします。

4. 必要な修正の実施
エラーの直接原因を修正します。
複数ファイルにまたがる場合、関係する全ファイルの該当部分を修正します。
関数の引数・戻り値・呼び出し元の整合性も確認し、必要に応じて更新します。
新規コードがエラーによりパスされる、または到達しない、None等でスキップされることがないよう修正します。
外部ライブラリ未導入の場合は標準ライブラリへ置換します。
修正後のコードは、SEARCH/REPLACEのdiff形式で出力してください。
（例）

<<<<<<< SEARCH
# エラーを含むコード
=======
# DEBUG: <修正内容説明>
# 修正済みコード
>>>>>>> REPLACE
この流れで、いただいた情報からエラー原因を特定し、修正版コード（diff形式）を提示します。

```

評価結果　9課題での素振り

DeepEvolveは化学・数理・生物・材料・特許など計9課題を横断評価し、異種メトリクスを「高いほど良い」共通スコア（新スコア）に正規化しています。Table 1には各課題のデータ型・ドメイン・元メトリクスと新スコアへの写像が整理されています。

  • 例：Molecular Prediction（小分子）

    • 元メトリクス：複数初期化のAUC

    • 新スコア例：0.5・AUC_mean + 0.5・AUC_std（高いほど良いに整形）

  • 横断の狙い

    • AUC/精度/RMSE/相関などの“向き”を合わせ、ベンチマーク間の比較や進化選択をシンプルにする。

【図表4 （論文 Table 1）】

  • 何が書かれているか：9課題の概要、データ型、元メトリクス、新スコアへの変換、出典。

  • 現場ポイント：自社タスクでも「主要目的（性能）＋副目的（効率）」を明示し、合成スコアに反映する。

【図表5 （論文 Table 2）】

Table 2は「初期アルゴリズム vs. DeepEvolveで得られた新アルゴリズム」を、効果（新スコア）と効率（分単位の実行時間）で比較。9課題中6課題で両方を改善し、残る3課題でも30分制約下で主要目的を改善しています。

  • 何が書かれているか：効果と効率の同時比較。6/9で両立向上、他は性能優先で時間制約内。

  • 現場ポイント：最初から“30分/1GPU”などの予算を定めると、探索全体の設計が安定する。

【図表6 （論文 Fig.3）】

fig.3を見ると、アイデアの将来性向上が大きく、性能以外での貢献が見えてきます.

  • 何が書かれているか：LLM-as-a-judgeで、初期案→新案のオリジナリティ・将来性・難易度を比較。新案の将来性向上が多い。

  • 現場ポイント：性能以外の“研究資産価値”を定量化して意思決定の透明性を上げる。

【図表7 （論文 Fig.5）】

Figure 5は反復ごとのスコア遷移を可視化し、「改善は連続的ではなく、要所で段差的に起きる」ことを示します。深い調査とコード実装が相互強化し、ヒューリスティックから理論的・物理的に整合した手法へ移行する傾向が観察されます。

  • 何が書かれているか：各タスクのベストスコア推移。ジャンプの重要性。

  • 現場ポイント：微増狙いの局所探索だけでなく、ジャンプを生む知識導入（検索・再構成）を計画に織り込む。

導入レシピ（90分ハンズオン）

こんな感じでお試し導入してみたらいいのではないでしょうか？とはいっても、私も実際にはまだ導入していないので、ＡＩにまとめてもらいました。githubリポジトリを参考にしてください。（手際良すぎるなあ。そもそも実際のタスクと必要データでもっと時間取りそうな感じ）

  1. 30分で最小実行（ローカルGPU想定）

    • ステップ

      1. ベンチマーク雛形のコピー（Circle Packing推奨）

      2. info.jsonに自課題の記述とcombined_score定義を記入

      3. deepevolve_interface.pyに評価関数gを実装（戻り値はsuccess, metrics）

      4. 1イテレーション上限（30分/1GPU）をconfigに固定

      5. Orchestratorでplan→search→write→code→debug→eval→selectの1周を実行

    • チェック

      • エラー時のログをFigure 17テンプレに流し込み、そのまま自動修復へ。

  2. 60分で社内タスク化

    • 変更点

      • 自社データの分割・seed固定・再現性ログ（config/差分/metrics）を保存

      • 追加ハイパラ（alpha, beta, temperatureなど）は単一の設定モジュールから参照

      • MLOps（実験追跡、モデル登録、SBOM）と疎結合に統合

  3. 評価ダッシュボード

    • 指標

      • combined_score（主目的）、runtime_minutes（副目的）、success_rate（実行成功率）

      • 反復ごとのベストスコアと“ジャンプ発生点”における提案書・差分をハイライト

実際の運用チェックリスト（こんな感じで順番に設定）

フレームワークの説明の一環なので、簡単に書いてある（間違いではない）のですが、実際に運用しようと思うと、タスク理解に関わる事前準備がかなり必要です。

  • 目標と制約

    • 主目的（何を最大化/最小化）と副目的（効率/解釈性/安定性）

    • 予算（例：30分/1GPU）を先に固定。

  • データ／評価

    • 評価関数gは単一I/Fからのみ呼ぶ

    • 新スコアは“高いほど良い”に正規化しておく（Table 1を参照）。

  • コード変更

    • 差分はSEARCH/REPLACE形式・DEEPEVOLVE-BLOCKで囲む。

    • 到達性チェック（default=None罠、未呼び出し関数）を反射（Reflect）で必ず実施。

  • デバッグ

    • エラー本文＋変更コード＋アイデアJSONをテンプレに投入。

    • コメント「# DEBUG:」で修正意図を可視化。

  • 進化選択

    • ベストと多様性の両立（エリート温存＋ランダム移住）を意識

  • 知識管理

    • 提案書・差分・評価を長期メモリ（Evolutionary DB）に保存して次世代のインスピレーションに。

補足（FAQ形式で書いてみた）

ここでは、ありがちな疑問をＦＡＱ形式でまとめてみました。

Q1. AlphaEvolveとの最大の違いは？

  • A. DeepEvolveは「深い調査（Web検索・要約・比較）→複数ファイルのクロス編集→系統デバッグ→評価→進化」を一体化。AlphaEvolveが不得意な外部知識導入とcross-file実装に対応し、成功率を上げる設計です。

Q2. なぜ“段差的なジャンプ”が起きるの？

  • A. 深い調査が新しい発想の種を持ち込み、評価フィードバックが探索方向を矯正するから。ヒューリスティックから理論的・物理的に整合した方法へ遷移するケースが多い。

Q3. 評価は性能だけ見れば十分？

  • A. いいえ。論文では性能（新スコア）と効率（分）を並記し、30分・1GPUの制約を明示。多くの課題で両立改善、そうでない場合も主要目的の改善を確保しています。この制約が、評価を安定化させて、新しい探索に効果的な出力になるみたいですよ。

Q4. 本当にデバッグは効くの？

  • A. 効きます。Open Vaccineでは成功率が0.13から0.99へ。重いタスクほど歩留まり改善が効き、探索の実効幅が広がります。

Q5. 実装を始める最短リンクは？

  • A. 論文が公式実装のGitHubを案内しています。最小例（Circle Packing）から着手し、自課題を追加する流れが推奨です。

考察・まとめ

  • 現場価値の再整理

    • 深い調査と進化の融合で、LLM内知識の限界（頭打ち）と、机上仮説の不実装問題を同時に解消。cross-file編集とデバッグの標準化で「アイデア→動くコード→再利用知識」の循環を作る。

  • 得られた示唆

    • 9課題で一貫した改善。性能の伸びは“段差的”に発生し、LLM-as-a-judgeでも新案の将来性が高い傾向。重い課題ほどデバッグの寄与が大きく、時間・GPUの明示的制約が設計を安定化する。

  • 導入の最短手順

    • 30分/1GPUの上限制約、combined_scoreの定義、差分テンプレ（SEARCH/REPLACE＋DEEPEVOLVE-BLOCK）、Debuggerテンプレ（Fig.17）をセットで導入し、Evolutionary DBで資産化。公式実装の最小例から自課題を追加。

  • 研究の限界と今後

    • 外部検索品質・評価設計・セキュリティ・データ漏洩などの運用課題が残る一方、深い調査品質の学習、失敗の一般化、CI/セーフティテンプレの普及、企業内ナレッジとの統合が今後の主戦場。

ハッシュタグ


#DeepEvolve #AlphaEvolve #DeepResearch #LLMAgents #AIScientist #AlgorithmDiscovery #EvaluationDesign #ExperimentTracking #Reproducibility

#深層進化 #アルゴリズム発見 #自動機械学習 #プログラム合成 #研究自動化 #複数ファイル編集 #差分デバッグ #到達可能性 #LLM評価 #AI運用 #知識検索 #グラフニューラルネットワーク #評価設計 #ベンチマーク #実験追跡  
#プロンプト

いいなと思ったら応援しよう！