スコアリング アプローチ

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

目標を直接最大化する

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 が指標ごとに最適なプログラムをトラッキングし、システムがすべての指標で実行中のパレートフロントを維持します。単一のスカラー目標は、初期デプロイメント時に推論とデバッグがはるかに簡単です。問題に複数の目標が必要な場合は、それらを単一の重み付きスカラーに結合するか、最初から複数指標のトラッキング ツールを活用できます。

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

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

  • 範囲全体でリスケールする: 指標を結合する前に、比較可能な範囲に正規化します。明示的なリスケールなしで、上限のあるスコア（0～1）と 上限のないスコア（0～infinity）を組み合わせると、 上限のない指標が適合度ランドスケープを支配します。

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

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

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

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