Designing a Blueprint for Bilevel Optimization Experiments

A bilevel optimization experiment blueprint must answer one concrete question:what value should the mutation factor F of Differential Evolution (DE) actually be set to. Its approach is not to keep hand-tuning, but to elevate F from a fixed hyperparameter intoan evolvable outer-layer object, while treating "running a DE solve task with a given F setting" as theinner-layer evaluation process; the outer layer then updates configurations based on the inner layer's task performance. This blueprint is feasible because it is built on EvoX's modern computational foundation: populations, evaluation results, and algorithm state are organized as holistically computabletensors, allowing candidate configurations to be mutated and evaluated in batches and routed through a computation graph for compiler optimization, after which the Runtime schedulerdispatches the computation to GPUs, accelerators, or distributed clusters, compressing what would otherwise be a long serial experiment cycle into an acceptable time window.

Inner Task: Turning Performance into a Comparable Signal

The inner layer is areproducible experiment. First select an optimization task or set of benchmark functions, then lock down the DE main structure, dimensions, evaluation budget, and random seed set—the only quantity that varies is the F configuration passed in by the outer layer. Each run must record: best value, convergence speed (number of generations to reach the threshold), success rate, constraint violations, multi-objective metrics (such as hypervolume), and candidate diversity. These records are all the information the outer layer can "see," and the only basis on which it judges quality. Evaluation is performed in batches in a tensorized manner, with the same batch of candidates sharing a single computation graph, avoiding the overhead of serial individual-by-individual evaluation.

Outer Strategy Object: F Is No Longer a Constant

What the outer layer searches is not a single value, but an F strategy. There are three common types of encoding: constant F; staged constants, such as the gene [F₁, F₂, F₃] switching across generation intervals; and scheduling functions controlled by a small number of genes, for example triggering different F values based on the current success rate, population variance, or generation ratio. For strategy-type encodings, in addition to the genes themselves, the input features and output rules must be specified; otherwise the same gene segment would produce entirely different results under different implementations.

Mapping Method: Genotype to Runtime Configuration

The mapping from the outer-layer genotype to the inner-layer runtime configuration must beexplicit and reproducible. For example, the gene [F_start, F_end, decay] maps to a schedule that decays with generations: F(t) = F_start + (F_end − F_start) × e^(−decay × t / T), where t is the current generation and T is the total number of generations; the gene [F₁, F₂, F₃] maps to a three-stage constant switching. The same genotype must always map to the same runtime configuration; otherwise the "good genes" learned by the outer layer cannot be explained, nor can they be transferred to new tasks.

Closed-Loop Process and Required Logs

The complete loop is: the outer population generates a batch of F configurations → the Runtime scheduler dispatches inner-layer DE tasks in parallel by tensorized batches → GPU batch evaluation → metrics aggregation → outer-layer selection, mutation, crossover, and update → proceed to the next round. This follows EvoX's layered organization: the algorithm layer carries both the outer-layer evolution and the inner-layer DE logic, the problem module supplies benchmark tasks, the Runtime scheduler handles dispatching batch computations to GPUs or distributed clusters, and the monitoring module collects metrics. The loop must leave behind replayable records: random seed, evaluation budget, task ID, hardware model, and stopping condition. Any conclusion of "the outer layer wins" should be reproducible under the same conditions.

Boundary Conditions and Baselines: Three Layers of Defense

Noise protection:When inner-layer evaluations fluctuate heavily, the result of a single run is unreliable; you must run multiple independent trials and report confidence intervals. Fitness can be aggregated using the mean, median, or worst-case quantile, and training tasks must be separated from validation tasks to prevent the outer layer from overfitting to a few lucky seeds.Cost protection:When inner-layer tasks are expensive, first use low-fidelity models or surrogate evaluations for coarse screening, then perform high-fidelity re-evaluation on a small number of candidates.Baseline protection:Fixed F = 0.5 and classic adaptive DE must be compared on the same footing, with ablation experiments confirming that the gains come from the outer-layer evolution itself rather than from more evaluation counts. If the outer-layer search space is too small, bilevel optimization degenerates into manual tuning; in that case you should expand the encoding space rather than simply increasing the budget.

Bilevel Optimization Experiment Blueprint and Workflow

The diagram uses the Differential Evolution mutation factor F as an example: the inner layer locks the task, dimensions, evaluation budget, and random seeds, letting only the F strategy passed in by the outer layer vary, and records the best value, convergence speed, success rate, constraint violations, hypervolume, and candidate diversity; the outer layer can encode a constant F, staged F, or scheduling function, which after explicit mapping is batch-evaluated and then selected and updated. The loop must also retain the seed, budget, task ID, hardware, and stopping condition to ensure conclusions can be re-run.

Question 1

In the inner-layer task of a bilevel optimization experiment blueprint, to make differences between F configurations attributable, which elements besides F should be fixed?

Randomly restart each run and take the best one

Only fix the random seed; allow other elements to vary automatically

Fix the outer population size and let the inner layer run freely

Fix the DE main structure, dimensions, evaluation budget, and random seed set

Question 2

If the outer-layer gene is encoded as [F_start, F_end, decay], which of the following F forms does it correspond to?

A continuous schedule F(t) that decays exponentially with generations

A rule randomly triggered by population variance

A three-stage constant switched across generation intervals

A constant F independent of the generation

Question 3

In the closed-loop process of bilevel optimization, after the outer population generates a batch of F configurations, what step immediately follows?

Skip directly to the next iteration to save time

The Runtime scheduler dispatches inner-layer DE tasks in parallel and performs tensorized batch evaluation on the GPU

Immediately update the outer fitness using this batch of configurations

Manually review each configuration before running

Question 4

When inner-layer evaluations are noisy, which of the following best prevents the outer layer from overfitting to specific random seeds?

Directly enlarge the outer population and cover the noise with more individuals

Merge multiple seeds into one extremely long run

Run multiple independent trials and aggregate by median or worst-case quantile, while separating training tasks from validation tasks

Take the best value from a single run as the fitness

Question 5

To prove that the outer-layer evolution truly brings gains, what is the most rigorous approach?

Compare on the same footing against baselines such as fixed F = 0.5 and classic adaptive DE, and run ablation experiments to confirm the source of gains

Keep extending inner-layer runtime until the outer results beat the baseline

Add more GPUs to make the inner layer run faster

Only report the result of the best configuration found by the outer layer on a single run

Case Study: Building a Bilevel Optimization Blueprint for the DE Mutation Factor

Read the scenario and answer the two questions below, providing an actionable blueprint design.

An algorithms team wants Differential Evolution to perform better on a continuous optimization benchmark suite. They decide to stop manually tuning the mutation factor F, and instead build a bilevel optimization experiment blueprint: the outer layer evolves the F strategy, while the inner layer evaluates the strategy's real performance on benchmark tasks. The available resources are 4 GPUs and a 24-hour machine room window. The team must deliver a plan that any colleague can replay under the same conditions, and explain how to determine whether the outer-layer evolution is truly effective.

1. Design the mapping rule from the outer-layer genotype to the inner-layer runtime configuration, and explain why this mapping must be explicit and reproducible.

Answer:
It can be designed as a continuous schedule: the gene [F_start, F_end, decay] maps to F(t) = F_start + (F_end − F_start) × e^(−decay × t / T), where t is the current generation and T is the total number of generations; it can also be designed as a staged constant: the gene [F₁, F₂, F₃] switches sequentially across generation intervals; if a strategy-type encoding is used, the input features (such as the current success rate and population variance) and the corresponding output rules must also be specified. The mapping must be explicit and reproducible because the gene itself carries no semantics—only through the mapping does it become the F actually used by the inner layer. Only when the mapping is fixed can you explain why the outer layer wins, transfer the configuration to new tasks, and let third parties re-run the validation under the same conditions. If implicit default values remain in the mapping, the same gene will yield different results under different implementations, and the outer-layer conclusion loses its meaning.

2. Provide the evaluation metrics and outer-fitness aggregation scheme for this blueprint, and explain how to validate the outer gains with baselines and ablation experiments.

Answer:
At the inner level: each F configuration is independently repeated 20 times on the chosen benchmarks with the same budget, locking the DE structure, dimensions, and seed set, and recording the best value, convergence generations, success rate, and run variance. At the outer level: first aggregate task performance into a feedback signal, for example outer fitness = average best-value rank + 0.1 × convergence generations + 0.05 × variance penalty, switching to more robust aggregations such as median, worst-case quantile, AUC convergence, or hypervolume when needed. In practice, training tasks must be separated from validation tasks—perform outer-layer evolution on training tasks and judge the winner on validation tasks. For baselines, fixed F = 0.5 and classic adaptive DE must be run under the same budget, same hardware, and same seed set; for ablation, an additional control group that "turns off outer-layer evolution and simply randomly samples the same number of F configurations" is needed to rule out gains stemming purely from more evaluations. Only when the outer scheme wins consistently on validation tasks and the confidence intervals do not overlap can the structure be judged effective; if the advantage disappears on validation tasks, it is judged a failure, and you should go back and check whether the inner-layer noise level and budget are sufficient.