技術的サマリー：optimize_anything

問題定義

現在の大規模言語モデル（LLM）最適化システムは、アーティファクトの種類と最適化モードによって大きく分断されています。AlphaEvolve や OpenEvolve などの既存ツールは単一タスクのコード進化に特化しており、GEPA や MIPROv2 などのフレームワークは汎化能力を備えたプロンプト最適化にのみ焦点を当てています。コードやプロンプトからエージェントアーキテクチャ、画像生成パラメータに至るまで、根本的に異なるテキストアーティファクトを同時に最適化できる単一のシステムは、これまで存在しませんでした。さらに、先行するシステムは、診断フィードバック（サイド情報）を活用するための統一メカニズムを欠いていたり、関連する問題間で知見が転移するマルチタスク検索をサポートしていなかったりすることが多いです。

本論文は、広範な最適化問題が単一の定式化の下で統一可能であると仮説を立てています。すなわち、スコアとオプションの診断フィードバックを返すスコアリング関数 $f(x)$ によって評価されるテキストアーティファクト $x$ を最適化する、という定式化です。目的は、単一タスク検索、問題間転移を伴うマルチタスク検索、そして多様なドメインにおける未見の入力への汎化を支援する汎用 API を構築することです。

手法：optimize_anything

著者は、汎用的なテキスト最適化ループを実装する宣言的 API であるoptimize_anythingを提示します。このシステムはバックエンドに依存しませんが、デフォルトでは任意のテキストアーティファクトに適応させた GEPA アルゴリズムの拡張版を採用しています。

コアインターフェース

このシステムは、以下の 3 つの主要な入力を必要とします：

1. シードアーティファクト：開始用のテキスト文字列（例：コード、プロンプト、エージェント定義）。「シードレスモード」では、システムは自然言語の目的のみから最初の候補をブートストラップします。
2. エバリュエーター：アーティファクトを実行し、スコア（高いほど良い）と**サイド情報（SI）**のタプルを返す関数。
3. データセット/検証セット：最適化モードを定義するためのオプション入力。

3 つの最適化モード

このシステムは、データセットの有無によって決定される 3 つの異なるモードを単一のインターフェースで統合します：

• 単一タスク検索：特定の課題（例：円の充填）に対して単一のアーティファクトを最適化します。エバリュエーターはアーティファクトを直接スコアリングします。
• マルチタスク検索：関連するタスクのバッチを同時に最適化します。システムはタスク間で共有されるパレートフロンティアを維持し、あるタスク（例：CUDA カーネルの最適化）で発見された最適化パターンを他のタスクへ転移させることを可能にします。
• 汎化：トレーニングセット上で良好に動作するアーティファクトを最適化し、別々の未見の検証セットで検証します。このモードはプロンプトを超えて、エージェントアーキテクチャやスケジューリングポリシーへと拡張されます。

主要なアルゴリズム的メカニズム

1. 第一級契約としてのサイド情報（SI）：スカラーフィードバックに依存する従来の勾配ベースのオプティマイザーとは異なり、optimize_anything は診断フィードバック（コンパイラエラー、プロファイラデータ、実行トレース、レンダリングされた画像など）を主要な入力として扱います。LLM プロポーザーは「リフレクション」ステップ中にこの SI を使用して失敗を診断し、対象を絞った修正を提案します。これは、プロトタイプを反復するエンジニアを模倣するものです。
2. パレートベースの検索：多次元のスコアを単一の集約値に縮小するのではなく、システムはタスクごとまたはメトリックごとのスコアを追跡します。支配されない候補のパレートフロンティアを維持します。これにより、タスク A では優れているがタスク B では平均的な候補など、相補的な強さを保持し、早期収束を防ぎます。
3. 候補の選択とリフレクション：候補は、パレートフロンティア上での出現頻度に基づいて変異のために選択されます。プロポーザーには、改善されたアーティファクトを生成するために、ミニバッチの例とそれに対応する SI が提示されます。「リファイナー」ステップは、評価前に一般的な生成アーティファクト（構文エラーなど）を捕捉します。

主要な貢献

1. 統合されたクロスドメイン最適化：本論文は、単一の LLM ベースのシステムが、エージェントアーキテクチャ検索、クラウドスケジューリング、CUDA カーネル生成、プロンプト最適化、円の充填、画像生成という 6 つの根本的に異なるドメインで最先端の結果を達成できることを実証しています。
2. LLM 進化のための初のマルチタスクモード：このシステムは、関連する問題のバッチを解決することで最適化パターンの相互転移を可能にするマルチタスク検索モードを導入し、独立した単一タスク最適化を上回る性能を発揮します。
3. 実行可能なサイド情報：著者は、診断フィードバックを統一された API 契約として形式化しました。アブレーション研究により、実行可能な SI は、スコアのみによるフィードバックと比較して、収束が 4〜6 倍速く、最終スコアが大幅に高くなることが示されました。
4. オープンソース実装：このシステムは GEPA プロジェクトの一部としてリリースされ、複数のバックエンドをサポートし、変異プロンプト、アイランド設定、タスク固有のテンプレートなどを抽象化する宣言的インターフェースを提供します。

実験結果

このシステムは、以下の 6 つの主要なドメインで評価されました：

• エージェントアーキテクチャ（ARC-AGI）：10 行のシードから 300 行以上のシステムへとエージェントシステム（コード＋プロンプト）を最適化し、ARC-AGI テストセットにおける精度を 32.5% から 89.5% に 3 倍増やしました。
• クラウドスケジューリング：クラウドデータ転出コストを 40.2% 削減するスケジューリングアルゴリズム（CloudCast）を発見し、スポットインスタンスの利用率（Can't Be Late）を向上させ、既存のベンチマークを上回りました。
• CUDA カーネル：31 の PyTorch 演算用のカーネルを生成し、その 87% が PyTorch ベースラインと同等かそれ以上の性能を示しました。マルチタスクモードは、速度向上閾値において単一タスクモードを大幅に上回りました。
• プロンプト最適化：AIME 2025 の数学問題における GPT-4.1-mini の精度を 46.67% から 60.00% に向上させ、MIPROv2 を上回りました。
• 円の充填：26 個の円を充填する AlphaEvolve の報告された解を上回り、より少ない評価回数で半径の和を大きくしました。
• 画像生成：SVG および CAD コードを最適化し、ゼロショットベースラインよりも人間評価者が結果を好むことを確認しました。

アブレーション調査の結果：

• サイド情報：SI を除去すると最終性能が大幅に低下しました（例：円の充填スコアは最適値の 94% まで低下；カーネルの速度向上は 1.1 倍を超えるものが 40% から 0% に低下）。
• マルチタスク対単一タスク：マルチタスク検索は、パターン転移により関連タスク（CUDA カーネル）において一貫して単一タスク検索を上回りました。しかし、無関係なタスク（異なる $N$ の円の充填）では、マルチタスク検索はノイズを導入し、性能を低下させました。
• プロポーザーの感度：より大規模なモデル（GPT-5.1）はより高い最終品質を達成しましたが、安価なモデル（GPT-5-nano）でも、コストの断片でシードに対して大幅な改善を提供しました。

意義と主張

本論文は、LLM ベースの検索によるテキスト最適化を汎用的な問題解決パラダイムとして確立すると主張しています。最適化問題を、診断フィードバックを伴うスコアリング関数によって評価されるテキストアーティファクトの改善として扱うことで、ドメイン固有のアルゴリズムの必要性が軽減されると論じています。

その意義は以下の点にあります：

1. 統合：コード進化、プロンプトエンジニアリング、エージェント設計など、従来は異なるアルゴリズムを必要としていたタスクを単一のフレームワークの下で統合すること。
2. 転移のスケーラビリティ：最適化パターンが関連する問題間で転移可能であることを実証し、タスク数に応じて便益がスケーリングすること。
3. 実行可能なフィードバック：スカラースコアを実行可能な診断シグナル（SI）へ変換することが、LLM ベースの最適化の効率性と有効性にとって決定的であることを示すこと。

著者は、optimize_anything が、ユーザーが「何を」最適化するか（アーティファクト、エバリュエーター、目標）を定義し、システムが「どのように」最適化するか（検索戦略、リフレクション、選択）を処理する宣言的インターフェースを提供すると結論付けています。これにより、複雑な最適化タスクの実質的な民主化が実現されます。