スコアリング アプローチ

評価ハーネス内で候補コード エントリのスコアリング、正規化、ペナルティを決定する際は、次のアーキテクチャ原則を適用します。

目標を直接最大化する

AlphaEvolve は最大化検索のみを実行し、すべての最適化ターゲットを山登りタスクとして扱います。レイテンシ やエラー率などの指標を最小限に抑えるには、最終的に計算された値を否定する必要があります。 score = -latency_ms # AE maximizes -> minimizes latency

厳密な関数単調性を維持する

単調なスコアリング関数のみを実装してください。候補ソリューションが改善されるにつれて、返される数値スコアが常に増加する必要があります。 単調でないスコアを組み込むと、検索パフォーマンスが低下し、最適化パスに論理的な不整合が生じます。

詳細で粒度の細かい指標を提供する

詳細なスコアは、検索品質の全体的な向上に直接つながります。単一のコアビジネス目標の最適化を行う場合でも、二次指標またはプロキシ指標を組み込むことで、AlphaEvolve は複雑な検索空間をより効果的にナビゲートできます。個々のサブスコアを構造化された分析情報としてシステムに返すと、LLM は世代間のパフォーマンスのトレードオフについて明示的に推論できます。

まばらな結果よりも部分的な成功を重視する

最終的な結果やバイナリの結果に完全に依存するのではなく、部分的な成功を重視します。常に、まばらなスコアリング シグナルよりも密度の高いスコアリング シグナルを優先します。

バイナリまたは低解像度の目標(トーナメントベースのゲーム問題で獲得した試合数をトラッキングするなど)では、複数の候補が同点になる大規模なパフォーマンス プラトーが作成されます。この動作により、AlphaEvolve はニアミスと不適切なソリューションを区別できなくなり、親の選択ループが停止します。

検索グラデーションの方向を維持するには:

  • 粒度の細かいサブシグナルを追加する: 最終目標(試合内で獲得した個々のポイントなど)までの進捗状況を測定することで、AlphaEvolve は同点の候補をランク付けし、有望なソリューション空間に向けて山登りできます。

  • アライメントと重みを慎重に調整する: サブシグナルが真の目標と単調にアライメントされ、その目標よりも安全に重み付けされていることを確認します。 適切に重み付けされていない場合、AlphaEvolve は実際の目標を犠牲にしてプロキシ指標を最適化します(報酬ハックが発生します)。

たとえば、ポイントを論理的なタイブレーカーとして使用して、スカラー目的関数を作成します。use score = matches_won + w * (points_scored / points_possible)

重み制約を w < 1 に構成すると、追加の最終的な勝利 は常に試合内のポイントの累積よりも上位にランク付けされ、サブシグナル は厳密にタイブレーカーとして扱われます。

単一の目標から始める

単一の目的関数から実装を開始することを検討してください。包括的なパレート フロンティア トラッキングによる多目的最適化は、データベースでネイティブに完全にサポートされています。MAP-Elites は指標ごとに最適なプログラムをトラッキングし、システムはすべての指標で実行中のパレート フロンティアを維持します。単一のスカラー目標は、初期デプロイメント時の推論とデバッグが大幅に簡素化されます。問題に複数の目標が必要な場合は、それらを 1 つの重み付きスカラーに結合するか、最初から複数の指標をトラッキングするツールを活用できます。

結合する前にリスケールして正規化する

最適化のバイアスを回避するため、指標全体で厳密なスケール バランシングを適用します。

  • 範囲全体でリスケールする: 指標を結合する前に、比較可能な範囲に正規化します。明示的なリスケールを行わずに、境界のあるスコア(01)と境界のないスコア(0infinity)を結合すると、境界のない指標が適合度ランドスケープを支配します。

  • 乗法的な組み合わせよりも加法的な構造を優先する: 乗法的な目標は、分母のわずかな変動に過敏になり、検索の精度と安定性が損なわれる可能性があります。代わりに、加法的な重み付き合計を実装します。w1*A - w2*L - w3*Mこの形式では、パフォーマンス パラメータごとに重みを簡単に調整できます。

  • 初期値に対して正規化する: スケールの違いによって検索パスが歪まないようにするには、各指標をそれぞれの初期ベースライン値で除算します。これにより、重みを適用して結合する前に、すべての指標が 1.0 のベースラインで開始されます。

最小限の数値の違いを拡大する

数値スコアの差が小さい場合、基盤となる LLM に有用な最適化シグナルが提供されない可能性があります。強力な候補のスコアが 1e-7 で、弱い候補のスコアが 1e-8 の場合、LLM はコンテキストを確認する際にそれらを意味のある方法で区別できない可能性があります。最終的なスコアをわかりやすい 人間が読める範囲(0100 など)にリスケールすると、コードの改善が 生成プロンプト内で数値的に明らかになります。