評価ハーネス内の候補コード エントリのスコアリング、正規化、ペナルティの方法を決定する際は、次のアーキテクチャ原則を適用します。
目標を直接最大化する
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 つの目標から始めます。
実装は単一の目的関数から始めることを検討してください。包括的なパレート フロンティア トラッキングによる多目的最適化はデータベースでネイティブに完全にサポートされていますが、MAP-Elites は指標ごとに最適なプログラムをトラッキングし、システムはすべての指標でパレート フロンティアを維持します。単一のスカラー目的は、初期デプロイ時の推論とデバッグが大幅に簡素化されます。問題に複数の目標が必要な場合は、それらを単一の重み付けされたスカラーに結合するか、最初からマルチ指標トラッキング ツールを活用します。
結合前にリスケールして正規化する
最適化のバイアスを回避するために、指標全体で厳密なスケーリング バランシングを適用します。
範囲全体でリスケール: 指標を結合する前に、比較可能な範囲に正規化します。明示的なリスケーリングなしで、境界のあるスコア（
0～1）と境界のないスコア（0～infinity）を組み合わせると、境界のない指標が適合度ランドスケープを支配します。乗法的な組み合わせよりも加法的な構造を優先する: 乗法的な目標は、分母のわずかな変動に過敏になり、検索の精度と安定性が損なわれる可能性があります。代わりに、加法的な重み付き合計（
w1*A - w2*L - w3*M）を実装します。この形式では、パフォーマンス パラメータごとに重みを簡単に調整できます。初期値に対する正規化: スケールの違いによって検索パスが歪まないように、各指標をそれぞれの初期ベースライン値で除算して、重みを適用して組み合わせる前に、すべての指標が
1.0のベースラインから始まるようにします。
数値のわずかな違いを増幅する
数値スコアの差が小さい場合、基盤となる LLM に有用な最適化シグナルを提供できないことがあります。優秀な候補者のスコアが 1e-7 で、劣る候補者のスコアが 1e-8 の場合、LLM はコンテキストをレビューする際に、両者を意味のある形で区別できない可能性があります。最終スコアをわかりやすい人間が読める範囲（0～100 など）にリスケールして、生成プロンプト内でコードの改善が数値的に明らかになるようにします。