Problem Reformulation: From Choosing an Algorithm to Designing an Exploration Process

In real-world applications of evolutionary computation, a common mistake at the very start is to ask, "Should I use DE or PSO?" the moment a task lands on your desk. This question putsalgorithm selectionat the entrance to the solution process, but it only answers "which tool to search with"—not "what to search over, what counts as good, and what must never be violated." What truly determines success isthe quality of the problem definition.

What is meant byproblem reformulationis rewriting "which algorithm to choose" as "designing an exploration process": first clarify what can be changed in the real problem, how to evaluate those changes, and which constraints must be satisfied; then let the algorithm iteratively generate and filter candidates within this search space. Algorithm selection thus becomes one step within exploration process design, rather than its starting point.

Four Definitions That Must Be Settled First

Variable Objects: Defines which parameters, structures, strategies, or processes may be adjusted, thereby forming the search space and encoding boundaries. Without it, candidate solutions cannot be represented or generated.
Evaluation Method: Defines how to judge quality after changes, including the objective function, evaluation metrics, preference direction, and measures such as feasibility and diversity. The evaluation approach essentially determines which direction the search will take.
Core Constraints: Distinguishes hard constraints that must be satisfied from soft preferences that can be traded off. Blending hard constraints into the objective function as a "discount" easily produces solutions that look high-scoring but cannot actually be deployed.
Exploration Process: Formulates the problem as a closed loop of "candidate generation—evaluation—feedback—regeneration," letting evaluation results influence subsequent generation instead of locking in a solution approach from the start.

The Difference This Transformation Makes

When facing a parameter optimization task, the habitual approach is "pick an algorithm first—say, DE or PSO—then start tuning parameters." After the transformation, the approach is to answer three questions in order: Which parameters are tunable? Which metrics (or which conflicting metrics) are used for evaluation? Which constraints must never be violated? Once these three questions are answered, the task has been formalized as a multi-objective problem ready to plug into an evolutionary solver. Deciding which algorithm to use and with what operator configuration then becomes a replaceable engineering decision within the loop. In other words, the algorithm is not the answer itself—it is merely a configurable component of the exploration process. The quality of the problem definition is what sets the ceiling for exploration.

Common Pitfall

Attributing poor algorithmic performance directly to the algorithm itself while overlooking three more fundamental issues: a vague search space definition, evaluation metrics disconnected from real business objectives, and missing hard constraints. Fixing the problem definition before considering algorithm replacement is often more effective than repeatedly switching algorithms.

The Problem Reformulation Workflow

The diagram reframes the solving task from "DE or PSO first" into an explorable process: first define the variable objects, evaluation method, and core constraints, then let candidate generation, evaluation, feedback, and regeneration form a closed loop. Algorithm selection is therefore just a replaceable step within the loop; the quality of the problem definition is what sets the ceiling for exploration.

Question 1

When reformulating "which algorithm to choose" into "designing an explorable process," what should be clarified first?

Defining which parameters, structures, strategies, or processes may be adjusted, forming the search space and encoding boundaries

First fixing the population size at 100

First deciding whether to use DE or PSO

First determining the total number of iterations

Question 2

Regarding the role of the "evaluation method" in problem reformulation, which of the following descriptions is most accurate?

The evaluation method is automatically determined by the chosen algorithm, independent of the task

The evaluation method defines how to judge quality after changes, including the objective function, metrics, preferences, and measures such as feasibility and diversity

The evaluation method only needs to be computed once in the final iteration

The evaluation method is simply that higher accuracy is better, with no need for other metrics

Question 3

An online service's deployment requirement is "P99 latency must not exceed 80 milliseconds." In problem reformulation, which category does this belong to?

A coding dimension of the search space

A hard constraint that must be satisfied, which no solution produced by exploration may violate

A soft preference that can be traded off and abandoned if necessary

A bonus term in the objective function

Question 4

What is the key difference between formulating the problem as a closed loop of "candidate generation—evaluation—feedback—regeneration" versus a one-time algorithm selection?

The closed loop is always faster to compute than a one-time selection

The closed loop lets evaluation results change subsequent generation, continuously adjusting the search direction rather than locking in an approach from the start

The closed loop no longer requires defining any constraints

The closed loop only works with population-based algorithms

Question 5

Why is it said that "the algorithm is not the answer itself"?

Because algorithm implementations always have flaws

Because the quality of the problem definition sets the ceiling for exploration, and the algorithm is merely a configurable, replaceable component of the exploration process

Because algorithms run unstably on parallel hardware

Because evolutionary algorithms inevitably converge to local optima

Case Study: Multi-Objective Tuning of a Recommendation Ranking Model

Read the scenario below, rewrite the task from "choosing an algorithm" to "designing an explorable process," and answer the two questions.

An online recommendation system needs to optimize its ranking model. Adjustable objects include: learning rate, regularization coefficient, number of network layers, number of attention heads, and feature combination strategy. The team hopes to simultaneously improve offline AUC and reduce online inference cost through tuning. Available metrics include: offline validation set AUC, online P99 inference latency, model parameter count, and feature count. Known deployment requirements are: P99 latency not exceeding 80 milliseconds, memory usage not exceeding 12GB, and the resulting model must be directly deployable on the existing inference framework. Subject to these requirements, the team prefers models with fewer parameters and lower latency. The team is currently debating: should they use DE or PSO?

1. Please write this task as a problem definition in the form of "variable objects—evaluation method—core constraints," and clearly indicate which are hard constraints and which are soft preferences.

Answer:
Variable objects (search space and encoding): learning rate, regularization coefficient, number of network layers, number of attention heads, and feature combination strategy—these continuous values and discrete structures together form the encoding of candidate solutions. Evaluation method: This is a multi-objective problem—offline AUC must be maximized, online P99 latency and model parameter count must be minimized, and diversity among candidates can be used as an additional measure. There is a clear objective conflict between AUC and latency, so evaluation should output a candidate set rather than a single score. Core constraints: P99 latency ≤ 80 milliseconds, memory ≤ 12GB, and direct deployability on the existing inference framework. These three are hard constraints that must be satisfied; any candidate that violates them is infeasible. Soft preferences: "Fewer parameters, lower latency" are soft preferences that can be traded off under the hard constraints, used for ranking among feasible solutions rather than for filtering.

2. Why shouldn't we first ask "DE or PSO"? Please describe how this task can be organized as a closed-loop exploration process, and explain how to ensure the output is deployable.

Answer:
Algorithm selection is a step within process design, not the starting point of solving: before the search space, evaluation method, and constraints are clarified, any algorithm comparison lacks a unified basis, and discussing "DE or PSO" is merely comparing two exploration processes that have not yet been defined. Closed-loop organization: ① Candidate generation—sample hyperparameters and structural configurations over the search space; ② Evaluation—compute AUC in parallel on the validation set, measure or estimate inference latency and memory usage, and check hard constraints; ③ Feedback—update the search distribution and selection pressure based on multi-objective quality and preferences, concentrating resources on more promising regions; ④ Regeneration—produce a new generation of candidates from the updated distribution, repeating the cycle. Deployability assurance: treat P99 latency, memory, and framework compatibility as hard constraints, marking them infeasible and removing them at the generation or evaluation stage, avoiding solutions that "look great on metrics but cannot go live"; for expensive metrics like latency, use surrogate models or small-scale tests for initial screening, then perform full validation on a small number of candidates. The final output is a set of candidate solutions well distributed across objective trade-offs, handed off to engineering and product decisions, while the specific algorithm used (DE, PSO, or a hybrid strategy) is merely a replaceable component choice within the loop.