評価ハーネス内で候補コード エントリをスコアリング、正規化、ペナルティを適用する方法を決定する際は、次のアーキテクチャ原則を適用します。
目標を直接最大化する
AlphaEvolve は、最大化検索のみを実行し、すべての最適化ターゲットを山登りタスクとして扱います。レイテンシやエラー率などの指標を最小限に抑えるには、最終的な計算値を否定する必要があります（score = -latency_ms # AE maximizes -> minimizes latency）。
関数の厳密な単調性を維持する
単調スコアリング関数のみを実装してください。返される数値スコアは、候補ソリューションが改善されるにつれて一貫して増加する必要があります。非単調スコアを組み込むと、検索パフォーマンスが低下し、最適化パスに論理的な不整合が生じます。
詳細で詳細な指標を提供する
詳細なスコアは、検索品質の全体的な向上に直接つながります。単一のコアビジネス目標を最適化する場合でも、二次指標またはプロキシ指標を組み込むことで、AlphaEvolve は複雑な検索空間をより効果的にナビゲートできます。個々のサブスコアを構造化された分析情報としてシステムに返します。これにより、LLM は世代間のパフォーマンスのトレードオフを明示的に推論できます。
まばらな結果よりも部分的な成功を重視する
最終的な結果や二者択一の結果に完全に依存するのではなく、部分的な成功に報酬を与えます。スパースなスコアリング シグナルよりも、高密度のスコアリング シグナルを優先します。
バイナリまたは低解像度の目標（トーナメント ベースのゲーム問題で勝利した試合を追跡するなど）では、複数の候補が同点となる大規模なパフォーマンスの停滞が発生します。この動作により、AlphaEvolve はニアミスと不適切なソリューションを区別できなくなり、親選択ループが停止します。
探索勾配の方向を維持するには:
きめ細かいサブシグナルを追加する: 最終目標に向けた段階的な進捗（試合内で獲得した個々のポイントなど）を測定することで、AlphaEvolve は同点の候補をランク付けし、有望なソリューション空間に向けてヒルクライムを行うことができます。
アライメントと重みを慎重に調整する: サブシグナルが真の目標と単調にアライメントされ、その下で安全に重み付けされていることを確認します。適切に重み付けされていない場合、AlphaEvolve は実際の目標を犠牲にしてプロキシ指標を最適化します（報酬ハックが発生します）。
たとえば、ポイントを論理的なタイブレーカーとして使用して、スカラー目的関数を作成します。use score = matches_won + w * (points_scored / points_possible)
重みの制約を w < 1 に設定して、追加のターミナル勝利が常にマッチ内のポイント累積を上回るようにし、サブシグナルを厳密にタイブレーカーとして扱います。
まず、1 つの目標を設定します。
まずは、1 つの目的関数を使用して実装を開始することを検討してください。包括的なパレート最適フロンティア追跡による多目的最適化は、データベースでネイティブに完全にサポートされています。MAP-Elites は指標ごとに最適なプログラムを追跡し、システムはすべての指標にわたって実行中のパレート最適フロンティアを維持します。ただし、初期デプロイ時に推論とデバッグを行うには、単一のスカラー目標の方がはるかに簡単です。問題に複数の目標が必要な場合は、それらを 1 つの重み付きスカラーに結合するか、最初からマルチ指標トラッキング ツールを活用します。
結合する前に再スケーリングと正規化を行う
最適化バイアスを回避するために、指標全体に厳密なスケール バランシングを適用します。
範囲全体で再スケーリングする: 指標を結合する前に、比較可能な範囲に正規化します。明示的な再スケーリングを行わずに、有界スコア（
0～1）と無界スコア（0～infinity）を組み合わせると、無界指標が適応度ランドスケープを支配することになります。乗算の組み合わせよりも加算構造を優先する: 乗算の目標は、分母のわずかな変動に過度に敏感になり、検索の精度と安定性が損なわれる可能性があります。代わりに、加算重み付き合計（
w1*A - w2*L - w3*M）を実装します。この形式を使用すると、パフォーマンス パラメータごとに重みを簡単に調整できます。初期値に対して正規化する: スケールの違いによって検索パスが歪まないように、各指標をそれぞれの初期ベースライン値で除算して、重みを適用して結合する前に、すべての指標が
1.0のベースラインから始まるようにします。
わずかな数値の違いを強調する
数値スコアの小さな違いは、基盤となる LLM に有用な最適化シグナルを提供しない可能性があります。強力な候補のスコアが 1e-7 で、弱い候補のスコアが 1e-8 の場合、LLM はコンテキストを確認する際に、それらを意味のある方法で区別できない可能性があります。最終スコアを、人が読める明確な範囲（0～100 など）に再スケーリングして、コードの段階的な改善が生成プロンプト内で数値的に明らかになるようにします。