Algorithm Structure Evolution: AutoPSO and EvoGO

In methods like MetaDE, evolution happens at theparameter level: the inner algorithm solves real tasks while the outer algorithm tunes the inner algorithm's configuration and strategy. In contrast, AutoPSO and EvoGO raise the evolved object up another level—directly evolving thealgorithm structure itself: how components are combined, how candidates are generated, and how update rules are organized.

The Criterion: What Is the Outer Layer Actually Searching?

To distinguish "parameter tuning" from "structure modification," don't just look at the method's name—look at thehierarchical level of the outer search space. For methods like MetaDE, the outer search space consists of the inner algorithm's configuration and strategy (values such as learning factors, mutation probabilities, and selection pressure); for AutoPSO / EvoGO, the outer search space is the algorithm structure—which components participate in the combination, what the candidate generation process looks like, and how states are updated.

parameter level: structure is fixed, only values are tuned. The reachable scope is the "intensity" of behavior.
Structure level: components and connections are variable. The reachable scope is the "form" of behavior.

AutoPSO: Breaking Classic PSO into a Component Pool

The velocity–position update formula in classic PSO is hard-coded. AutoPSO decomposes this process into composable components: velocity terms, neighborhood topologies, perturbation terms, restart strategies, and more—then the outer layer of evolution selects and assembles them into new candidate generators. It no longer sticks to a fixed classic update structure; instead, the "update structure" itself becomes a searchable variable. Tuning learning factors only changes behavioral intensity; changing component combinations changes behavioral form.

EvoGO: Letting Historical Feedback Decide Where the Structure Changes

EvoGO focuses on integrating historical feedback into the structure evolution path: past search trajectories and performance records are no longer used merely for "selecting solutions" but to decide "where the structure changes next." Feedback thus shifts from a result filter to the steering wheel for structure updates—it changes the direction of the next round of structure candidates, rather than just picking a good result from a batch of completed candidates.

The Shared Two-Layer Skeleton and Its Engineering Implications

Both share the same skeleton: the inner algorithm runs on real tasks, and the outer layer evolves the structure based on inner-layer performance. The critical prerequisite is sample density—running large numbers of inner tasks in GPU-parallel batches makes the "structure–performance" comparison samples dense enough that the outer layer's selection is statistically meaningful and won't be swayed by the noise of a single run.

Engineering Implication

The algorithm shifts from "a one-off a priori choice" to "an object that can be continuously improved." The cost: structure-level evolution inherently brings a larger search space and higher evaluation costs, so its feasibility depends on a tensorized parallel foundation—which is also the direct motivation for the next section's GPU parallelization topic.

Structure Evolution Relationship: AutoPSO and EvoGO

The diagram contrasts parameter-level and structure-level evolution: MetaDE's outer layer searches over configuration values such as learning factors and mutation probabilities while the algorithm structure stays fixed; AutoPSO and EvoGO's outer layer searches over how components are combined and how candidate generation and update rules are organized. AutoPSO breaks PSO updates into a component pool—velocity terms, neighborhood topologies, perturbation, restart, and so on—for the outer layer to select and assemble, while EvoGO uses historical trajectory feedback to decide where the structure changes next.

Question 1

What is the most critical basis for judging whether a method belongs to "parameter tuning" or "structure modification"?

Whether the inner-layer tasks converge faster

Whether the outer search space is the inner algorithm's configuration and strategy, or the algorithm structure itself

Whether the population size exceeds one thousand

Whether GPU acceleration is used

Question 2

What is the core approach of AutoPSO?

Decompose particle swarm optimization into a composable component pool, with the outer layer of evolution selecting and assembling them into new candidate generators

Completely replace the velocity–position update with gradient descent

Fine-tune the learning factor from 2.0 to 1.494

Multiply the population size to cover more solutions

Question 3

How does the use of historical feedback in EvoGO differ from traditional approaches?

From selecting parents to setting stopping conditions

From evaluating fitness to initializing the population

From only "selecting solutions" to deciding "where the structure changes next"

From logging to chart visualization

Question 4

Why does the two-layer skeleton of AutoPSO / EvoGO require GPU-parallel batch runs of large numbers of inner tasks?

To reduce the number of composable components

To eliminate the need for inner-algorithm evaluation

To make "structure–performance" comparison samples dense enough for the outer layer's selection to be statistically meaningful

Because GPU compute is cheaper per unit than CPU

Question 5

Which of the following changes falls at a level unreachable by parameter tuning?

Adjusting the inertia weight from 0.9 to 0.7

Recombining velocity terms, neighborhood topologies, perturbation terms, and restart strategies into a new candidate generator

Adjusting the population size from 50 to 100

Adjusting the maximum number of iterations from 500 to 1000

Case Study: Upgrading a Fixed-Structure PSO Solver to a Structure-Evolvable System

Read the scenario, answer the questions, and provide actionable design specifications.

A team already has a fixed-structure particle swarm optimization solver for a logistics routing optimization task, currently evaluated serially on CPU. The team plans to upgrade it to a "structure-evolvable" system: the outer layer changes the algorithm structure, the inner layer solves on real road network instances, and they want historical search records incorporated into outer-layer decisions. Available resources: one server equipped with multiple GPUs.

1. Explain: How can you judge whether this upgrade truly crosses from "parameter tuning" to "structure modification"? Provide actionable criteria.

Answer:
The criterion is the hierarchical level of the outer search space. If the outer layer only adjusts numerical configurations such as inertia weight, learning factors, population size, or iteration count, then no matter how wide the value range, it remains at the parameter level and only changes behavioral intensity. Only when the outer layer can change component combinations and candidate generation methods—for example, re-selecting and assembling velocity terms, neighborhood topologies, perturbation terms, and restart strategies into new candidate generators, causing the behavioral form itself to change—does it truly cross into the structure level. An actionable test: freeze all numerical hyperparameters and allow only the outer layer to modify component combinations. If the system's search behavior can still fundamentally change, then the upgrade reaches the structure level.

2. To replicate EvoGO's approach, how should historical search trajectories enter outer-layer decisions? Provide a specific design point and explain how it differs from "using them only for solution selection."

Answer:
Design point: organize the inner-layer run records after each structure instantiation into structured feedback features, including the component combinations used, convergence trajectories, fitness curve shapes, failure or stagnation patterns, and so on; then have these features directly drive the outer layer's structure update rules—for example, letting feedback decide "which component to prioritize modifying next, which connection to add or remove"—rather than simply sorting all historical results and taking the best. The difference from "using them only for solution selection" lies in the direction of effect: when used only for selection, feedback is a post-hoc result filter affecting only which completed candidate is finally chosen; in the EvoGO-style usage, feedback is an ex-ante direction controller directly affecting where the next round of structure candidates changes. Moreover, because the structure-level search space is larger and evaluation costs are higher, this design must be paired with GPU-parallel batch runs of large numbers of inner tasks to accumulate sufficiently dense structure–performance comparison samples, making outer-layer selection statistically meaningful.