As compute continues to scale up, the way candidates are generated has fundamentally changed. In the past, candidate solutions often relied on manual enumeration or a single model output; today,GPU parallel exploration,structured construction by large modelsandmodel-assisted encoding and mutationtogether expand the sources of candidates. The core question is no longer just "can an answer be generated?" but "which changes can be generated, observed, retained, and inherited?"
Three New Sources of Candidate Generation
- GPU Parallel Exploration:Many possibilities are explored simultaneously, shifting candidate generation from serial trial-and-error to parallel space search. For example, tens of thousands of points in a parameter space can be sampled and evaluated in parallel.
- Structured Construction by Large Models:Large models can understand natural language and code, and construct structurally complex candidate solutions rather than merely generating textual answers. They can produce complete programs, test cases, or system configurations.
- Model-Assisted Encoding and Mutation:Manually designed encoding and mutation methods are now being partly generated by models. The source of candidates expands from human-written rules to model-generated rules and structures—for example, having a model propose new mutation operators or encoding strategies.
Defining Boundaries Before Evolution Begins
Before candidates enter evolution, the following boundaries must be clearly defined:
- What objects are allowed to change:Determine what is evolvable—code structures, hyperparameters, or the entire architecture?
- What outcomes can be observed:Define observable metrics, such as accuracy, latency, and resource consumption.
- What criteria determine whether a change should be retained:Establish retention criteria, typically a multi-objective evaluation function or threshold.
Layered Evaluation Strategy
Evaluation needs to be layered:parallelize evaluations whenever possible;use surrogate models to reduce costly evaluations. For example, simple performance metrics can be computed in parallel on GPUs, while expensive evaluations requiring real environment interaction are approximated by surrogate models, thereby expanding the search space within limited compute.
Identifying Evolvable Structures and Preserving Outcomes
It is necessary to identify which structures in existing methods can be further evolved, rather than only tuning numerical parameters. For example, treat module connection patterns in neural networks and control-flow structures in code as mutable objects. At the same time, code, tests, and verification evidence must be preserved so that the next round of work does not start from scratch, avoiding duplicated effort.
Connecting to the EvoX Loop
Once the above boundaries are clear, the task can be connected to the EvoX loop:Model proposes candidates,Tools execute changes,Environment returns feedback,Evolutionary mechanism completes selection,Runtime orchestrates computation,the persistent system inherits verified outcomes. In this way, scattered intelligent components can continuously accumulate, forming an ever-evolving system.
New Sources of Candidate Generation and the EvoX LoopThe diagram merges three paths—GPU parallel exploration, structured construction by large models, and model-assisted encoding and mutation—into a single entry point, showing that candidate sources have shifted from serial trial-and-error to parallel space search and structured construction. Candidates then enter the EvoX loop through boundary definition and layered evaluation, where the model proposes candidates, tools execute changes, the environment returns feedback, evolution performs selection, and verified outcomes are preserved.
