A Canonical Method-Evolution Implementation: The MetaDE Architecture

Conventional Differential Evolution (DE) leaves the mutation strategy and key control parameters to be preset by the researcher, and keeps them fixed throughout the search. MetaDE's core shift is this:the algorithm's own configuration becomes an object of evolution as well—the outer evolution searches the algorithm space, while the inner layer evaluates performance in the solution space, turning "how to evolve" from a manual preset into an adaptive search.

Two-layer structure: the outer layer searches for algorithms, the inner layer solves problems

Inner layer: the routine process by which differential evolution solves the original optimization task, responsible for producing real task performance.
Outer layer: takes one DE algorithm configuration as an individual and applies selection, crossover, mutation, and elimination to the configuration space.

The roles of the two layers must not be confused: the outer layer's optimization target is thealgorithm configuration, and the inner layer's optimization target is theproblem solution. The former determines "how to search", the latter determines "how good the result is".

What the outer layer evolves

An outer individual does not encode a few numbers but an entire set of algorithm behaviors: mutation strategy (rand/1, best/1, current-to-best/1, etc.), crossover method (binomial, exponential), and control parameters such as the scaling factor F, crossover probability CR, and population size. Differences between individuals correspond to how the same algorithm family tends to behave under different problem characteristics.

Verification loop: candidate configurations must be run for real once

No candidate configuration can be kept or discarded based on meta-metrics or prior judgment alone; it must be sent into the original task to actually run and face the test of real performance. The outer layer then uses the fitness fed back by the inner layer to perform selection, elimination, and retention, deciding which configurations are inherited and propagated. This forms an iterative loop of "configuration generation → task verification → feedback-based selection", in which outer fitness can only come from the inner layer's real execution results.

Differences from fixed DE

In traditional DE, the strategy and parameters are preset by the researcher and fixed throughout; MetaDE hands this decision to the outer evolution, giving the algorithm adaptive capability for problem characteristics—for example, preferring the more exploratory rand/1 with a larger F in the early search, then shifting to the faster-converging best/1 with a smaller F later on.

Cost and prerequisites

Each candidate configuration must run the inner task in full (usually with multiple independent runs averaged to suppress randomness), and the evaluation cost multiplies with the outer population size and number of generations. MetaDE therefore depends heavily on engineering foundations such as parallelization, tensorization, and runtime scheduling—this is exactly the engineering reason it needs to be built on a tensorized Runtime.

Minimal runnable example

Take a set of continuous optimization tasks as an example: an individual in the outer population is encoded as "rand/1 + binomial crossover + F=0.5, CR=0.9". This configuration is sent into the inner task for multiple independent runs, and the average fitness is taken as the outer individual's fitness; based on this, the outer layer selects, mutates, and retains better configurations, forming an iterative loop of "configuration generation—task verification—feedback-based selection". This step is the minimal runnable form of "improving evolutionary algorithms with evolutionary algorithms".

Positioning: MetaDE is the concrete implementation of "inner-outer two-layer evolution and adaptive mechanisms" as it moves from concept to buildable architecture, and it also provides a methodological paradigm for subsequent algorithm-structure evolution work (AutoPSO, EvoGO).

MetaDE Two-Layer Structure and Task Verification Flow

The diagram illustrates MetaDE's two-layer flow: the outer layer treats an entire DE configuration as an individual and applies selection, crossover, mutation, and elimination, while candidate configurations must be sent into the inner original task to actually run—usually with multiple independent runs averaged—and the results are fed back to decide retention and propagation. This turns settings such as mutation strategy, crossover method, F, and CR from manual presets into an adaptive search.

Question 1

In MetaDE, what does the outer evolution directly operate on?

The inner task's fitness function itself

A set of candidate solutions to the original optimization task

The upper bound on the outer population size

The differential evolution algorithm configuration, including mutation strategy, crossover method, and control parameters

Question 2

Why must every candidate configuration be run for real on the original task instead of being scored only by meta-metrics?

Because the inner task needs parameters provided by the outer layer to start

Because running it for real once reduces the outer population size

Because meta-metrics are computationally heavier than real runs

Because only real execution results provide a reliable fitness basis for outer selection; prior judgment often diverges from actual performance

Question 3

Compared with traditional fixed-parameter differential evolution, what is MetaDE's most critical change?

The strategy and control parameters are no longer fixed throughout, but dynamically determined by the outer evolution

It replaces differential evolution with a completely different optimization algorithm

It eliminates the fitness evaluation step

It applies only to discrete combinatorial optimization problems

Question 4

Where does MetaDE's main computational cost come from?

The length of the configuration encoding string

The sorting overhead of the outer selection operator

Every candidate configuration must fully execute the inner task once, and the evaluation cost multiplies with the outer population size and number of generations

The rendering cost of the verification channel in the architecture diagram

Question 5

Regarding the relationship between MetaDE and subsequent work (AutoPSO, EvoGO), which statement is correct?

MetaDE provides a practical paradigm for "improving evolutionary algorithms with evolutionary algorithms", offering methodological reference for subsequent algorithm-structure evolution

MetaDE is unrelated to algorithm-structure evolution

Both AutoPSO and EvoGO are methods with parameters fixed throughout

MetaDE replaces the inner solving process with outer evolution

Case: MetaDE Configuration Under a Limited Evaluation Budget

Read the scenario and answer the two questions below.

A team wants to perform automatic algorithm configuration on a suite of continuous optimization benchmark functions. They treat one DE configuration (mutation strategy + crossover method + scaling factor F and crossover probability CR + population size) as an outer individual, start with an outer population size of 20, and plan to evolve for 15 generations; each candidate configuration is run independently 10 times on the corresponding inner task, and the average fitness is taken as that individual's fitness. The number of inner tasks the cluster can run in parallel per round is limited, so the team's total evaluation budget is constrained.

1. Why can't candidate configurations be scored using only meta-metrics or historical experience, and why must each one be run on the original task?

Answer:
Because there is no reliable guarantee of consistency between meta-metrics or prior experience and actual task performance, the quality of a configuration can ultimately only be defined by real execution results. Only by using the fitness fed back by the inner task as the selection basis can the outer layer's selection, elimination, and retention rest on trustworthy evidence—precisely the necessary condition of MetaDE's verification loop. If surrogate scoring were used instead, the outer layer could easily retain configurations that "look reasonable but actually perform poorly", systematically steering the evolution off course, and the final result would be a set of configurations that look good on meta-metrics but are ineffective on real tasks.

2. Given limited cluster parallelism, how would you trade off the outer population size and number of generations against the inner repetition count? Provide a plan and your reasoning.

Answer:
The first step is to estimate the total evaluation count budget: outer population size × generations × inner repetition count. The second step is to allocate accordingly: moderately compress the outer population size or number of generations, and give priority to keeping the inner repetition count no lower than the level needed to stably estimate the mean (for example, 5 to 10 runs). The reasoning is that when the inner repetition count is too small, individual fitness is dominated by randomness, outer selection is effectively chasing noise, the evolutionary signal is polluted, and no amount of subsequent search will converge. At the same time, increase the degree of parallelism by dispatching the inner tasks of same-generation individuals in parallel, so that wall-clock time decreases with parallelism rather than growing linearly with the budget; if necessary, use early stopping or surrogate models for pre-screening to save budget—but any candidate that enters the final comparison and determines retention must still undergo the real verification of the original task.