DHEvo: Data-Algorithm Co-Evolution Framework

• DHEvo is a framework that jointly evolves data artifacts and algorithmic heuristics, explicitly addressing instance heterogeneity and dynamic data distributions.
• It iteratively refines solutions by coupling representative data selection with algorithmic evolution across MILP, multi-task DNN, LLM refinement, and other domains.
• Empirical results demonstrate that DHEvo outperforms static optimization methods by reducing performance variance and boosting generalization on diverse benchmarks.

Searching arXiv for the cited DHEvo-related papers to ground the article in current records. arxiv_search query="(Wang et al., 2024) AdaBridge Dynamic Data and Computation Reuse for Efficient Multi-task DNN Co-evolution in Edge Systems" max_results=5 [arXiv search] Query: ([2407.00016](/papers/2407.00016)) AdaBridge Dynamic Data and Computation Reuse for Efficient Multi-task DNN Co-evolution in Edge Systems; ([2507.15615](/papers/2507.15615)) DHEvo Data-Algorithm Based Heuristic Evolution for Generalizable [MILP](https://www.emergentmind.com/topics/mingenome-milp) Solving; ([2501.02906](/papers/2501.02906)) Evolving Generalizable [Parallel](https://www.emergentmind.com/topics/additive-parallel-correction) Algorithm Portfolios via Domain-Agnostic Instance Generation; ([2007.00501](/papers/2007.00501)) Few-shots Parallel Algorithm Portfolio Construction via Co-evolution; ([2509.24726](/papers/2509.24726)) [Socratic-Zero](https://www.emergentmind.com/topics/socratic-zero); ([2510.12728](/papers/2510.12728)) Data-Model Co-Evolution; ([2512.09209](/papers/2512.09209)) Beyond Algorithm Evolution Data-Algorithm Co-Evolution Framework (DHEvo) denotes a class of iterative optimization schemes in which the data artifacts that determine adaptation and the algorithmic artifacts being optimized are updated jointly rather than in isolation. In the canonical formulation for mixed-integer linear programming (MILP), DHEvo iteratively selects representative instances and evolves corresponding heuristics so that instance heterogeneity enters the evolution loop directly, rather than being averaged away (Zhang et al., 21 Jul 2025). Related formulations map the same coupling principle to asynchronous multi-task DNN evolution in edge systems (Wang et al., 2024), living test sets and prompt instructions for LLM behavior refinement (Lee et al., 14 Oct 2025), autonomous curriculum generation for reasoning models (Wang et al., 29 Sep 2025), and instance–portfolio co-evolution for few-shot combinatorial optimization (Wang et al., 6 Jan 2025, Tang et al., 2020).

1. Conceptual basis and motivation

The central motivation for DHEvo is the inadequacy of static or weakly coupled optimization pipelines when the relevant data distribution is heterogeneous, drifting, or only sparsely observed. In the MILP setting, the relevant unit is a problem class, defined as the set of MILP instances generated from the same mathematical model. Although such instances share model structure, they vary in parameters such as costs, bounds, and right-hand sides, which produces intra-class heterogeneity in structural and statistical features. Prior LLM-based heuristic evolution methods are described as evolving code on a few randomly sampled instances and averaging fitness, thereby implicitly assuming equal representativeness across instances; DHEvo is introduced specifically to incorporate instance heterogeneity into the evolution process (Zhang et al., 21 Jul 2025).

The same structural critique appears in other domains. In multi-task edge DNN evolution, single-task evolution is insufficient because it overfits to local data, misses cross-client data and computation reuse, and duplicates similar retraining computations under limited compute, memory, bandwidth, and energy budgets (Wang et al., 2024). In LLM application development, the rigid separation between data work and model refinement is identified as a historical barrier; prompt editing makes rapid instruction changes possible, but robustness requires a living test set that evolves in tandem with those instructions (Lee et al., 14 Oct 2025). In data-free reasoning, static datasets and single-shot distillation are characterized as mismatched to a moving target, because the Solver’s capability changes the distribution of informative questions; Socratic-Zero therefore treats question generation and Solver improvement as a closed-loop process (Wang et al., 29 Sep 2025).

A common misconception is to reduce DHEvo to either algorithm evolution or data curation alone. The cited literature instead treats the two as mutually conditioning components. The data side may be representative MILP instances, drift-aware sensor samples, semantically probed LLM test cases, failure-conditioned synthetic questions, or generated optimization instances; the algorithm side may be heuristic code, shared backbones plus adapters, editable prompt instructions, Solver policies, or parallel algorithm portfolios. The defining property is the feedback coupling between these two sides.

2. Formal structure and optimization objectives

In the MILP formulation, DHEvo is introduced for primal heuristic evolution over a standard MILP model,

$$z^{\dagger} := \min_{x \in P^{\dagger}} c^{\top}x,\quad P^{\dagger} = \left\{ x \in \mathbb{R}^{n} \mid Ax < b,\ \underline{\pi} \leq x \leq \overline{\pi},\ x_j \in \mathbb{Z}\ \forall j \in \mathcal{I} \right\}.$$

The framework couples an instance $I$ and a heuristic $h$ into a data-code pair $(I,h)$. Fitness is evaluated at the instance level via $\text{Perf}(h,I)$, primarily the negative of the relative primal gap when evolving diving heuristics, and final selection is based on aggregated average performance over representative instances,

$$f_{\text{avg}}(h)=\frac{1}{k}\sum_{i=1}^{k}\text{Perf}(h,I_i).$$

Representativeness is tied to two stated insights: instances with smaller integrality gap $\Delta(I)=|z^*_{LP}-z^*|$ tend to yield heuristics with lower performance variance $\sigma^2(h)$ across similar instances, and smaller feasible-region irregularity $\nu(I)$ correlates with more stable heuristic performance (Zhang et al., 21 Jul 2025).

Other DHEvo-style formulations preserve the same joint optimization logic while changing the artifacts being optimized. In the prompt/test-set formulation, the variables are editable instruction parameters $\theta$ and a living test set $I$0, with objective

$I$1

subject to coverage, traceability, and human-in-the-loop auditing constraints. Here $I$2 measures task performance and alignment, $I$3 is an ambiguity penalty, and $I$4 is a violation penalty (Lee et al., 14 Oct 2025). In Socratic-Zero, the evolving state consists of the Solver parameters $I$5, Generator parameters $I$6, and curriculum $I$7, with the Solver updated by DPO and the Generator by value-weighted supervised fine-tuning centered on a target success rate $I$8 (Wang et al., 29 Sep 2025).

In edge systems, the joint objective is resource-constrained multi-task evolution. A representative formulation minimizes

$I$9

subject to energy, memory, and latency constraints, while scheduling and caching maximize an accuracy-weighted utility minus resource costs (Wang et al., 2024). In portfolio construction, DACE casts the interaction between a parallel algorithm portfolio and a generated instance population as a min–max problem in which the portfolio maximizes performance while the instance generator seeks hard yet class-consistent instances via a neural instance representation (Wang et al., 6 Jan 2025).

3. Iterative co-evolution loop

The canonical DHEvo workflow in MILP begins by sampling an initial instance set $h$0 and generating an initial heuristic population $h$1 with a multi-agent LLM system. For each instance, candidates are generated and evaluated instance-wise; the best performer for each instance forms a data-code pair. Top-$h$2 pairs are then selected by instance-level performance, optionally with temperature-controlled retention, and iterative refinement proceeds by prompting the multi-agent system with distilled code or prompts from the current best heuristic for each retained instance. Final heuristics are selected by aggregated average performance over the representative instance set (Zhang et al., 21 Jul 2025).

A notable feature of this formulation is the MA-Evolution System. The Designer produces an algorithmic design plan and procedural outline; the Coder implements the scoring function; the Reviewer compiles and checks logic and compatibility; and the Judge makes final accept-or-revise decisions. In the solver integration used for diving heuristics, the generated code must implement myheurdiving(...) and operate on solver-state features such as candsfrac, nlocksdown, nlocksup, pscostdown, pscostup, obj, objnorm, rootsolval, nNonz, and isBinary (Zhang et al., 21 Jul 2025).

Edge-system instantiations express the same loop differently. AdaBridge comprises client-side reuse-friendly mobile sensor data resampling and edge-side asynchronous multi-task retraining computation scheduling. The client side performs runtime accuracy profiling, detects drift, constructs an $h$3 mapping function approximating other tasks’ data distributions, and uploads only top-$h$4 samples according to a score

$h$5

The edge side then schedules retraining using adapter-based multi-task learning, partial forward-pass reuse, feature caches, similarity thresholds $h$6, and memory I/O-aware batch reordering (Wang et al., 2024).

Prompt/test-set co-evolution follows a different but structurally parallel sequence: edge-case discovery, rationale articulation, neighborhood probing, instruction revision, and iterative evaluation. Every discovered failure becomes a persistent test case with labels, policy tags, and rationale; revisions to instructions are evaluated against the expanded test set, often with an LLM-as-judge seeded by user labels (Lee et al., 14 Oct 2025). Socratic-Zero adopts a similar closed loop at training scale: Teacher verification and refinement create failure-conditioned enhanced questions, Solver rollouts produce winning and losing trajectories, automated preferences supervise DPO updates, and a Generator distills the Teacher’s enhancement strategy to scale the curriculum (Wang et al., 29 Sep 2025).

4. Domain instantiations

The term DHEvo is used most explicitly for MILP heuristic evolution, but the co-evolutional pattern recurs across several domains.

Setting	Data-side artifact	Algorithm-side artifact
Generalizable MILP solving (Zhang et al., 21 Jul 2025)	Representative instances and data-code pairs	Diving heuristics generated by a multi-agent LLM system
Edge multi-task DNN evolution (Wang et al., 2024)	Drift-aware selected samples and cached feature maps	Shared backbones, task adapters, and asynchronous schedulers
LLM behavior refinement (Lee et al., 14 Oct 2025)	Living test set with rationales and neighborhood probes	Editable prompt instructions and policy-bearing prompts
Data-free reasoning (Wang et al., 29 Sep 2025)	Teacher-enhanced questions and preference pairs	Solver policy updated by DPO and Generator updated by WSFT
Few-shot optimization portfolios (Wang et al., 6 Jan 2025, Tang et al., 2020)	Generated or mutated hard instances	Parallel algorithm portfolios and parameterized search configurations

In the MILP case, DHEvo’s stated novelty lies in the co-evolution of data and algorithm, instance-level fitness, representative-instance selection, and a portfolio finalization step over representative instances (Zhang et al., 21 Jul 2025). In AdaBridge, the mapping to DHEvo is explicit: drift detection, sample scoring, cross-task reuse, continual/domain-adaptive multi-task updates, shared-feature coupling, cache-based computation reuse, and resource-aware scheduling together instantiate data and algorithm co-evolution on edge devices (Wang et al., 2024).

The LLM-oriented works broaden the notion of “algorithm.” In the prompt/test-set formulation, the editable system prompt is the model from the application developer’s perspective, and policies, rationales, and test cases become first-class co-evolving artifacts (Lee et al., 14 Oct 2025). In Socratic-Zero, the Solver policy is the algorithm, while the evolving curriculum of questions and preference-labeled trajectories is the data (Wang et al., 29 Sep 2025). In portfolio construction, CEPS and DACE embed the same idea in few-shot optimization: algorithm populations are challenged by increasingly hard instance populations, with DACE replacing domain-specific instance generators by a neural instance representation and hypernetwork-based generator (Wang et al., 6 Jan 2025, Tang et al., 2020).

A further extension appears in the framework for collaborative evolution of swarm intelligence algorithms and guiding prompts. There, the paper’s main object is algorithm–prompt co-evolution, but it also presents a proposed extension beyond the paper that generalizes this setup to DHEvo by adding data policies such as curriculum schedules, subset selection, instance weights, and augmentation policies, together with explicit overfitting and leakage regularizers (Cen et al., 10 Dec 2025).

5. Empirical findings

The empirical record presented across these works is heterogeneous but broadly consistent with the claim that coupling data evolution to algorithm evolution improves generalization or robustness relative to static-data baselines. In MILP, DHEvo is reported to outperform human-designed heuristics and existing LLM-based methods across synthetic and real-world benchmarks. On Setcover, DHEvo achieves an average relative primal gap of 9.74 versus 20.39 for EoH, with a reported 61.8% improvement over the best LLM baseline and a 46.9% variance reduction. On Facilities solving efficiency, it improves time by 6.7% versus EoH and reduces PDI by 2.8%. On NNVerify, the reported off-cut comparison is 72.42 / 5413.32 for DHEvo versus 669.15 / 38455.17 for SCIP, described as more than 9× faster with much lower PDI (Zhang et al., 21 Jul 2025).

In the edge DNN setting, AdaBridge is evaluated on two clients—a mobile unmanned car and a UAV—using compressed Faster-RCNN with a ResNet-50 backbone and an edge server with two RTX 3080 GPUs. The reported outcome is that co-evolution with AdaBridge improves the lowest accuracy by 11% compared to independent evolution and stabilizes accuracy over time under drift; the paper also reports reduced memory I/O via feature-similarity-driven reuse and scheduling, although precise latency and energy numbers are not provided (Wang et al., 2024).

In the prompt/test-set formulation, a controlled user study with $h$7 compares the co-evolution workflow to a baseline prompt-editing interface. Mean instruction length rises from 82.2 to 112.4 words, the mean test-set size from 7.17 to 13.42, and holdout F1 alignment from 0.58 to 0.68; the reported statistical effects are strongest for adapting to personal criteria, confidence that the AI behaves as intended, defining policy boundaries in realistic scenarios, clarifying policy decisions, and satisfaction or intention to reuse (Lee et al., 14 Oct 2025).

In autonomous reasoning, Socratic-Zero reports that starting from only 100 seed questions, Socratic-Solver-8B achieves an average gain of +20.2 percentage points across seven mathematical reasoning benchmarks and reaches 56.1% average accuracy at Stage 3. The Generator attains a 95.6% validity rate, and synthetic data generated by Socratic-Generator-32B produces downstream effectiveness of 37.72% average, exceeding the teacher model’s generated data and several commercial LLM generators under the reported pipeline (Wang et al., 29 Sep 2025).

The few-shot optimization literature reports similar trends. DACE is said to achieve the best mean performance across all three evaluated binary optimization classes and dimensions, with illustrative mean normalized scores such as 1.0833±0.0663 on CIMP-100 and 1.0777±0.0249 on CCP-40, consistently exceeding CEPS and other baselines (Wang et al., 6 Jan 2025). CEPS reports the fewest timeouts and best average scores on the cited TSP and VRPSPDTW splits, with final PAPs improving over initial PAPs by an average improvement rate of 21.78% (Tang et al., 2020). The swarm-intelligence framework reports that full co-evolution of algorithms and prompt templates outperforms algorithm-only evolution on ALP Airplane11, with 142.42% versus 132.99%, and achieves 105.66% average Perf on ALP against 43.04% for EoH and 56.04% for Reevo and FunSearch (Cen et al., 10 Dec 2025).

6. Trade-offs, limitations, and future directions

DHEvo formulations introduce additional control surfaces and therefore additional failure modes. In MILP, the reported limitations include a simplified retention-probability formula, nontrivial computational overhead from iterative evaluation over multiple heuristics and multiple instances, and dependence on correct solver feature extraction and compatible hooks (Zhang et al., 21 Jul 2025). These are structural rather than incidental limitations: once data selection and algorithm evolution are coupled, representativeness, evaluation noise, and systems integration become part of the optimization problem.

In edge systems, the main trade-offs are negative transfer, staleness, interference on shared backbones, privacy exposure, and resource contention. AdaBridge mitigates these with adapters, dynamic switching, incremental updates, freezing of the backbone under high conflict, staleness penalties, similarity checks, distillation and alignment regularizers, and scheduling based on urgency and reuse potential (Wang et al., 2024). In prompt/test-set co-evolution, the limitations are different: binary labeling can be insufficient for borderline cases, generated examples may lack diversity, scaling the living test set increases cognitive load, and LLM-as-judge can mislead or induce automation bias (Lee et al., 14 Oct 2025). In Socratic-Zero, the key dependencies are robust automatic verification, domain-specific evaluator design outside mathematics, and large compute budgets for Teacher inference and multi-round rollouts (Wang et al., 29 Sep 2025).

The portfolio-construction line highlights a further distinction between domain-agnostic and domain-specific co-evolution. CEPS requires domain-appropriate instance mutation operators and a suitable parameterized algorithm, while DACE replaces problem-specific instance generators with a neural instance representation but remains binary-only in its reported form and may drift if the learned representation is weak (Tang et al., 2020, Wang et al., 6 Jan 2025). The swarm-intelligence framework similarly warns that fixed prompt schemas can be brittle across tasks, that evaluation is noisy because both LLM generations and operators are stochastic, and that feasibility-only scoring may under-explore near-feasible regions (Cen et al., 10 Dec 2025).

Taken together, these works suggest that DHEvo is best understood not as a single algorithm but as a design pattern for joint adaptation under distributional uncertainty, resource constraints, or evolving objectives. Its recurring elements are representative or adversarial data selection, iterative algorithm refinement, explicit coupling mechanisms, and evaluation procedures that measure not only task performance but also stability, diversity, ambiguity, violations, resource cost, or generalization across held-out conditions. A plausible implication is that future DHEvo systems will increasingly connect these loops to CI-style evaluation pipelines, richer uncertainty-aware labels, domain-specific validators, and lightweight fine-tuning or adapter training once the co-evolved data artifacts have matured (Lee et al., 14 Oct 2025, Cen et al., 10 Dec 2025).