The optimization target represents the single number AlphaEvolve maximizes during each generation. Before you write any evaluator code, answer these three questions:
What value does this number represent?
How does the system compute it?
Where does the computation run?
AlphaEvolve strictly requires an automated, programmatic target computation for every candidate solution with no human intervention. This automation makes the problem a fit for AlphaEvolve. If a person must judge a solution's quality manually, AlphaEvolve cannot search on it.
Use the following considerations for estimating the performance of a generated candidate solution on the different optimization objectives and validation constraints:
- Can the optimization objectives be calculated directly using business or product logic, without needing empirical measurement?
- Can the optimization objectives be measured directly by running performance and load tests on the generated solution's code?
- Can the optimization objectives be estimated using deterministic surrogate functions established, reliable simulation methods?
- Can the optimization objectives be estimated by designing a custom surrogate function (such as a predictive model or another non-deterministic estimator) that requires tuning on empirical observations and validation on out-of-sample data?
Core steps to quantify your target
Follow a structured approach to ensure that AlphaEvolve has a reliable, automated feedback loop to guide its search. Complete the following steps to establish your metric, define how it is measured, and determine where the execution occurs.
1. Express the target as a single score that increases as solutions improve
Configure your core optimization metric to scale linearly or monotonically with true performance gains so the search path has a clear directional gradient.
Scalar maximization: AlphaEvolve always maximizes one scalar value. Convert whatever you care about into a single number where higher is better. To minimize latency, cost, or error, negate it:
score = -latency_msMonotonicity: The score must be monotonic, it must rise whenever the solution genuinely gets better. A score that moves inconsistently gives the search no direction to climb.
Deterministic execution: The score is computed in your evaluator never by the LLM, and never by a person. Compute it deterministically so the same candidate always gets the same score.
Conjoint analysis for subjective goals: If you cannot write a scoring formula but can compare two solutions by eye, build one with conjoint analysis. Generate pairs of candidate outputs, have a domain expert pick the better one in each pair, fit a logistic regression on those choices, and use the fitted model as your metric. This turns subjective judgment into a deterministic, differentiable score. Don't use a raw LLM rubric as the live score because it is slow, noisy, and quick to reward-hack; distill it into a fixed function first.
2. Choose how the score is computed
How you produce the number depends on what you are measuring. Pick the method from the table that matches your objective. Almost every real deployment uses one of these four, and many combine two, a cheap method to drive the search and an expensive one to confirm the winners.
| Measurement method | Use it when the target is… | How the score is produced | What it needs to run |
|---|---|---|---|
| Direct calculation | A quantity you can compute in closed form from the candidate's output using business or product logic | The evaluator runs the candidate and applies a formula (sum, ratio, count, cost) | The controller's own process — no extra infrastructure |
| Performance or load test | The runtime, throughput, or memory of the candidate code itself | Run the candidate on representative hardware and measure it; gate on correctness first | The target hardware (GPU or TPU or CPU); warmup and best-of-N to cut timing noise |
| Deterministic surrogate / simulation | Expensive or noisy to measure directly, but a reliable proxy or a replay of real conditions exists | Compute a deterministic proxy, or replay fixed, seeded operating scenarios | Any environment; fully reproducible with fixed seeds |
| Out-of-sample validation | The quality of a model or data pipeline the candidate produces | Train/fit the candidate, then score it on held-out or freshly generated data | Your training/eval stack; a strict train-vs-validation split; re-validate winners on the held-out set |
For more information, see the AlphaEvolve announcement on the Google Cloud blog.
If none of these can produce a number automatically, the problem is not yet ready for AlphaEvolve. The core task then is to construct a surrogate or simulation that can.
3. Handle multiple goals and constraints
Real objectives usually mix several concerns. Use one of the following two ways to handle them:
Scalar blending (simplest—recommended to start): Rescale each metric to
a comparable range, negate any you minimize, then add them:
score = w1*A - w2*L - w3*M.
Prefer additive sums over ratios like A/(L⋅M), which are
numerically unstable.
Return a dictionary of named scores: Let AlphaEvolve optimize them jointly. The evaluator can return several named metrics instead of one number:
```JSON
{
"scores": [
{"metric": "accuracy", "score": 0.95},
{"metric": "latency_ms", "score": -120.0}
]
}
```
Higher is better for each, so negate anything you minimize. This triggers a genuine multi-objective search, not just reporting: the population database keeps the best program per metric (MAP-Elites), maintains a Pareto frontier across the metrics, and samples parents diversely across the different metrics. It can also draw parents directly from the Pareto frontier when that sampling is enabled. A single headline score still drives the reported hill-climb, but every returned metric shapes the search.
Keep to 3–5 metrics: With too many metrics, Pareto dominance degenerates almost every program is non-dominated on something and the search wanders. Aggregate or drop metrics beyond that threshold.
Isolate correctness and feasibility: Keep correctness as a hard gate, not part of the reward function. A candidate that is wrong or infeasible gets a failure score regardless of how fast or cheap it is. This is the primary defense against the agent gaming your metric.
Constraint optimization: Hold one objective as a constraint and optimize the other, applying a penalty when the constraint is violated. Running this workflow at several constraint levels traces out the Pareto front.
4. Decide where the evaluator runs
AlphaEvolve never runs your evaluator directly. It proposes candidate programs and receives scores; you host and run the code that computes the score. The environment is entirely your choice and a candidate that cannot run on Google Cloud is not a blocker. You run the evaluator wherever the objective can be measured and submit the score back.
To ensure an efficient and secure deployment, you must align your compute infrastructure with your specific measurement strategy while adhering to universal execution limits. Use the following guidelines to select your execution environment and understand the core operational boundaries that apply to all setups.
Match the execution environment to the measurement method
Direct calculation or surrogate: The controller's own process, or a single Cloud Run container.
Performance or load test: The target hardware such as a GPU or TPU node on GKE, your own on-premises or custom hardware, or a third-party or ISV tool (for example, an EDA or Verilog simulator).
Out-of-sample validation or heavy jobs: Your training stack fanned out across Cloud Run or GKE, or offloaded to Google Cloud batch using the Cluster Toolkit for large HPC or accelerator workloads.
Two limits apply regardless of environment
Strive to keep each evaluation to roughly 10 minutes or less so the evolutionary loop keeps moving. For expensive objectives, use an evaluation cascade a check on every candidate, running the full evaluation only for promising ones.
You own the evaluator's networking, security, and access controls. AlphaEvolve does not deploy or manage the evaluator, on Google Cloud or anywhere else.
Once you have decided on the metric, how to compute it, and where it runs, see evaluator implementation patterns for how to structure the evaluator.