Scoring approaches

Apply the following architectural principles when determining how to score, normalize, and penalize candidate code entries within your evaluation harness.

Maximize objectives directly

AlphaEvolve exclusively performs maximization searches, treating every optimization target as a hill-climbing task. To minimize a metric like latency or error rates, you must negate the final calculated value: score = -latency_ms # AE maximizes -> minimizes latency.

Maintain strict function monotonicity

Ensure that you implement monotonic scoring functions only. The returned numerical score must consistently increase as candidate solutions improve. Incorporating non-monotonic scores degrades search performance and introduces logical inconsistencies into the optimization path.

Provide detailed, granular metrics

Detailed scores directly improve overall search quality. Even when optimizing for a single core business objective, incorporating secondary or proxy metrics helps AlphaEvolve navigate a complex search space more effectively. Pass individual sub-scores back to the system as structured insights so that the LLM can explicitly reason about performance tradeoffs across generations.

Reward partial success over sparse outcomes

Reward partial success instead of relying entirely on terminal or binary outcomes. Always prefer a dense scoring signal over a sparse one.

A binary or low-resolution objective (for example, tracking matches won in a tournament-based game problem) creates massive performance plateaus where multiple candidates tie. This behavior prevents AlphaEvolve from distinguishing a near-miss from a poor solution, which stalls parent selection loops.

To maintain search gradient direction:

  • Add a fine-grained sub-signal: Measure incremental progress toward the ultimate goal (such as individual points scored within a match) so that AlphaEvolve can rank otherwise-tied candidates and hill-climb toward promising solution spaces.

  • Align alignment and weights carefully: Ensure the sub-signal is monotonically aligned with the true objective and weighted safely below it. If it is not weighted properly, AlphaEvolve will optimize the proxy metric at the expense of the actual goal (causing a reward hack).

For example, construct a scalar objective function using points as a logical tie-breaker: use score = matches_won + w * (points_scored / points_possible).

Configure the weight constraint to w < 1 so that an additional terminal win always outranks any within-match point accumulation, treating the sub-signal strictly as a tie-breaker.

Begin with a single objective

Consider starting your implementation with a single objective function. While multi-objective optimization with comprehensive Pareto frontier tracking is fully supported natively in the database, where MAP-Elites tracks the best program per metric and the system maintains a running Pareto frontier across all metrics a single scalar objective is considerably simpler to reason about and debug during initial deployment. If your problem requires multiple objectives, you can either combine them into a single weighted scalar or leverage multi-metric tracking tools from the start.

Rescale and normalize before combining

Apply strict scale balancing across your metrics to avoid optimization bias:

  • Rescale across ranges: Normalize metrics to comparable ranges before combining them. Combining bounded scores (ranging from 0 to 1) and unbounded scores (ranging from 0 to infinity) without explicit rescaling causes the unbounded metric to dominate the fitness landscape.

  • Prefer additive structures over multiplicative combinations: Multiplicative objectives can become hyper-sensitive to minor variations in the denominator, compromising search accuracy and stability. Implement additive weighted sums instead: w1*A - w2*L - w3*M. This format allows straightforward weight adjustments per performance parameter.

  • Normalize relative to initial values: To prevent scale differences from skewing your search path, divide each metric by its respective initial baseline value so that all metrics start at a baseline of 1.0 before you apply weights and combine them.

Amplify minimal numerical differences

Small numerical score differences may not provide a useful optimization signal to the underlying LLM. If a strong candidate scores 1e-7 and a weaker candidate scores 1e-8, the LLM might not meaningfully distinguish between them when reviewing the context. Rescale your final scores to an obvious, human-readable range (such as 0 to100) so that incremental code improvements become numerically apparent within the generation prompt.