HEMO: Making Search Frameworks Self-Evolve — A New Paradigm for Multi-Objective Combinatorial Optimization

Title

HEMO: Making Search Frameworks Self-Evolve — A New Paradigm for Multi-Objective Combinatorial Optimization

Meta Description

HEMO treats the framework of automated operator design itself as the object of self-evolution. Through single-module updates, discounted UCB scheduling, and a persistent memory file system, it lets the search process for multi-objective combinatorial optimization adapt to shifting Pareto trade-offs, outperforming traditional evolutionary, neural network, and LLM baselines across eight tasks and two evolutionary backbones.

Article Content

Automated operator design for multi-objective combinatorial optimization (MOCO) has recently begun to leverage large language models to generate search and mutation operators. But a key contradiction has long been overlooked: the operators keep evolving, while the process that discovers them remains fixed. HEMO proposes treating the "framework" itself as the object of self-evolution, upgrading automated operator design from "building tools" to "transforming how tools are built."

The Bottleneck of Automated Operator Design: Only the Operators Evolve, Not the Process

Existing LLM-based automated operator design (AOD) methods generally have the model generate search and mutation operators for a specific problem, then retain them based on solution quality. The benefits of this approach have been validated by multiple works, but its evolutionary boundary is clear: only the operators evolve. The process logic that determines "which experiences to retrieve, which operators to improve, which parents to select, and how to orchestrate the search steps" remains static throughout.

When new Pareto trade-offs emerge and the interactions between operators change, judgments about where the search should go and how it should proceed ought to adjust accordingly — and a fixed process cannot do this. HEMO's starting point is precisely to fill this gap: treating the harness of AOD (the framework that carries the entire automated design process) itself as the optimization target.

Multi-objective combinatorial optimization (MOCO) refers to combinatorial optimization problems that simultaneously optimize two or more conflicting objectives, with typical examples including the multi-objective traveling salesman problem, the multi-objective knapsack problem, and the multi-objective vehicle routing problem. The solutions to such problems are not a single optimum but a set of mutually non-dominating solutions forming the Pareto front. "Mutually non-dominating" means that solution A is better than solution B on at least one objective and no worse on the others. The goal of a search algorithm is to approximate the true Pareto front as closely as possible while maintaining solution diversity. Because the trade-offs among objectives vary with problem instances, operators need to continuously adapt to new frontier shapes — which is exactly the root cause that fixed processes struggle to address.

HEMO's Core Mechanism: Change Only One Module at a Time

HEMO maintains a persistent harness state and updates it module by module, one at a time. According to the paper, its revision logic covers four levels: which experience to retrieve, which operator to improve, which parents to select, and how to orchestrate the search steps. This "single-module update" design reduces the coupling of the search space, making the effect of each change easier to attribute.

What drives these updates is the quality and runtime of downstream solutions — that is, the framework is not adjusted by hand-crafted rules but selected based on actual optimization performance. This shares some similarity with common meta-learning ideas, except that HEMO adjusts process modules with clear semantics rather than black-box parameters.

Harness, in the context of software testing and LLM agents, refers to the outer framework that wraps the system or model under test, driving its execution while providing inputs and collecting outputs and feedback. In automated operator design, the harness determines process-level decisions such as "which historical experiences to provide to the LLM, which operator it should improve, how to select parents, and in what order to execute search steps." Treating the harness as the optimization target means not merely having the LLM generate better operator code, but enabling the system to learn how to adjust the way it organizes its own search. This is fundamentally different from optimizing only prompts or only operator code: the harness state is persistent and accumulates across multiple rounds of evolution.

Discounted UCB Scheduling and Persistent Memory: Making Accumulation Count

Framework self-evolution faces two practical problems: module utility changes over time, and how historical experience is retained across state switches. HEMO addresses these with two components.

The first is a discounted UCB scheduler. Based on changes in each module's utility, it directs adaptation resources toward more promising modules, avoiding continued investment in already saturated directions. The second is a persistent memory file system that preserves candidate results and diagnostic feedback across harness states, enabling subsequent states to build on previously accumulated optimization experience rather than resetting each time. Together, the two effectively extend the exploration–exploitation trade-off to the framework level.

UCB (Upper Confidence Bound) is a classic exploration–exploitation strategy in the multi-armed bandit problem: each time, it selects the arm with the highest "average reward + exploration bonus," where the exploration bonus is typically inversely proportional to the square root of the number of times that arm has been selected, thereby giving opportunities to high-uncertainty options. Discounted UCB introduces a discount factor on top of this, causing the weight of earlier observations to decay over time and thus adapting to non-stationary environments where reward distributions change. In HEMO, each updatable module can be viewed as an "arm," whose "reward" is measured by downstream solution quality and runtime; the discount mechanism ensures that when a module's utility declines, the scheduler can promptly redirect adaptation resources to other modules rather than being locked in by historical average rewards.

Experimental Performance: Eight Tasks, Two Evolutionary Backbones

The paper validates HEMO on eight MOCO tasks and two structurally different evolutionary backbones. Results show that HEMO performs strongly against traditional evolutionary methods, neural network methods, and LLM-based AOD baselines, and can effectively transfer to related tasks. The significance of this setup lies in testing both task breadth and backbone generality — if it were only effective on a single evolutionary framework, the case for framework self-evolution would be considerably weaker.

It should be noted that the above conclusions come from the paper's own experimental report; the specific magnitude of cross-task transfer and the boundaries of applicability still await more independent reproductions for confirmation.

From Optimizing Operators to Optimizing "the Process of Discovering Operators"

HEMO's positioning can be summed up in one sentence: advancing automated operator design from evolving individual operators to improving the search process that discovers those operators. The value of this shift is that when changes in problem structure cause the Pareto front to move, the system does not need to rely on external redesign of the process — it has the ability to adjust the organization of its search on its own.

For researchers working on combinatorial optimization and LLM-driven algorithm design, this line of work points to a direction worth attention: the object of self-evolution need not be limited to solutions or operators; the framework that carries the entire search can also be a learnable, evolvable entity. The cost is increased system complexity, and how the additional overhead from module updates and scheduling scales with task size is a question that future work needs to answer.

One-line Summary

HEMO treats the framework of automated operator design itself as the object of self-evolution, breaking through the limitation of evolving only operators.

Paragraph Summary

Addressing the bottleneck in existing LLM-based automated operator design — where only operators evolve while the process remains fixed — HEMO proposes treating the harness that carries the entire automated design process as the self-evolution target. It maintains a persistent harness state and revises the logic at four levels — experience retrieval, operator improvement, parent selection, and search step orchestration — one module at a time, driven by downstream solution quality and runtime. To handle module utility drift and the retention of historical experience, HEMO introduces a discounted UCB scheduler to allocate adaptation resources and uses a persistent memory file system to preserve candidate results and diagnostic feedback across states. Across eight MOCO tasks and two evolutionary backbones, it outperforms traditional evolutionary, neural network, and LLM baselines, and can transfer to related tasks.