Dynamic Configuration for Cutting Plane Separators via Reinforcement Learning on Incremental Graph

We thank the reviewer for the insightful and valuable comments. We respond to your comments as follows and sincerely hope that our rebuttal could properly address your concerns. If so, we would deeply appreciate it if you could raise your score（"3: Borderline Reject"). If not, please let us know your further concerns, and we will continue actively responding to your comments and improving our submission.

Q1. Lmited scope of hyperparameter tuning, ignoring critical hyperparameters.

A1.

Thank you for the insightful comment. We claim that our proposed DynSep framework is inherently extensible to a broader set of solver hyperparameters beyond separator activation and timing. This is achieved by adapting the policy network: we model the outputs of additional parameters as a logistic‑normal distribution, followed by optional discretization to support both integer and continuous parameters. This enables flexible, differentiable control of arbitrary solver parameters.

To validate this, we conducted additional experiments on three critical hyperparameter groups (as suggested), while retaining the original tuning mechanism for separator activation and max round.

• para group 1: Cut Depth / Aggressiveness (sepastore/age in SCIP). Controlled by solver parameters separating/cutagelimit and separating/poolfreq.
• para group 2: Cut selection thresholds (e.g., efficacy vs. orthogonality). Controlled by solver parameters separating/minefficacy and cutselection/hybrid/minortho.
• para group 3: Separation frequency per node. Controlled by solver parameters separating/cutagelimit and separating/poolfreq.

We provide the experimental results as follows.

We evaluated our method on three benchmark datasets: Knapsack, Corlat, and MIPLIB mixed supportcase, measuring solving time (Time), primal–dual gap integral (PD integral), and primal–dual gap (PD gap). All three metrics are lower-is-better.

We compared our original DynSep method with its extended versions incorporating three additional parameter groups. Results show that:

1. Across all datasets, DynSep and its extended variants consistently outperform the default solver configuration reported in the main paper.

2. The differences among the parameter groups are relatively small, yet certain combinations yield further performance improvements in both Time and PD integral.

These results validate that DynSep can flexibly extend to control a broader set of solver hyperparameters. Furthermore, carefully chosen parameter combinations can yield additional gains in solving speed and convergence.

Q2. Limited scope of testing datasets (MIPLIB neos and supportcase)；

A2.

Thank you for raising this point. We have extended our evaluation beyond MIPLIB mixed neos and mixed supportcase, including two real-world datasets from the Distributional MIPLIB benchmark [1]:

• Maritime Inventory Routing Problem (MIRP). MIRP arises in bulk shipping logistics, integrating vessel routing and port inventory decisions, featuring 15080 binary variables, 19576 continuous variables, and 44430 constraints.
• Seismic‑Resilient Pipe Network Planning (SRPN). SRPN involves optimizing municipal water pipe network design to ensure resilience under seismic disturbances, featuring 3016 binary variables, 3016 continuous variables, and 5917 constraints.

We set the time limit to $600$ seconds. The results are summarized in the table below.

These results show that our method (DynSep) delivers marked performance gains on additional real‑world datasets (MIRP and SRPN). Compared to the other configuration methods, DynSep significantly improves both convergence speed (evidenced by reduced PD integral) and solution quality (evidenced by lower PD gap).

Q3. Specification of MIPLIB mixed neos and mixed supportcase.

A3.

We apologize for the confusion. MIPLIB mixed neos and mixed supportcase evaluated in our paper are two well-established subsets derived from MIPLIB 2017 [2], which were constructed by the prior learning-based MILP research [3].

Each subset comprises a cluster of similar instances selected from MIPLIB 2017, where similarity is quantified using 100 human-designed instance features [1]. Briefly, a seed instance is first selected: neos‑1456979 for the mixed neos set, representing knapsack‑constraint problems, and supportcase40 for the mixed supportcase set, representing set‑packing problems. Then, a data-driven clustering algorithm [3] is applied to gather MIPLIB instances that closely match the seed instance in feature space, constructing the mixed neos and mixed supportcase subsets.

Due to space limitations in the rebuttal, we only present a subset of MIPLIB mixed neos and mixed supportcase datasets used in our experiments:

• Mixed neos contains 17 instances: neos-1456979, icir97 tension, etc.

• Mixed supportcase contains 37 instances: supportcase40, acc-tight2, acc-tight4, etc.

Q4. The latency of policy inference during B&C.

A4.

Thank you for raising this point. We have provided per-decision latency (the latency of policy inference per decision step) and the total inference time through the solving process as follows.

• Per-decision latency: The table below reports the average ("Avg. latency") and worst-case ("Max. latency") time taken for a single policy call across the entire branch-and-cut process.

Our results reveal that per-decision latency increases as instance size grows. The average inference latency stays below 0.5 seconds across all datasets, with the exception of the largest load balancing (LB) instance.

---

The two tables below provide the total inference time ("Infer. Time") over different datasets and solver time limits, along with the inference overhead rate ("Overhead Rate"), which represents the percentage of policy inference in the total solving runtime.

• Total inference time (nine datasets in our manuscript, $300$-second time limit):

• Total inference time (hard datasets in our manuscript, $3600$-second time limit):

These tables show that on larger, more complex instances and with longer solver time limits, a smaller share of the total solving time is spent on decision making. This implies that the computational cost of our policy calls becomes more justifiable at scale, enabling meaningful improvements in overall solver efficiency with only modest overhead investment.

Q5. Memory/compute inference overhead is not discussed.

A5.

We have analyzed the compute inference overhead in Q4. Here, we focus on the memory inference overhead.

• Per-decision memory overhead: The table below show the peak GPU memory usage per policy call.

• Peak memory overhead for overall inference:

The memory footprint required to store the encoder and policy model weights is $2.08$ MB for each dataset. We track the peak GPU memories during the reference via the tool torch.cuda.max_memory_allocated(), which are list in the table below.

Q6. Which scenarios and practical cases the data-driven approach is appropriatML-guided MILPe should be addressed.

A6.

Our data‑driven configuration approach proves effective across both synthetic and real‑world MILP benchmarks [1,2,3]. It is particularly well‑suited to scenarios where one has access to a batch of instances drawn from the similar distribution as the unseen examples. In these cases, the policy network can be trained on those example instances and then deployed during branch‑and‑cut to flexibly tune solver parameters via the solver’s existing parameter interfaces, dynamically adapting to individual problem structure.

[1] Huang, et al. "Distributional MIPLIB: a multi-domain library for advancing ml-guided milp methods." arXiv 2024.

[2] Gleixner, et al. "MIPLIB 2017: data-driven compilation of the 6th mixed-integer programming library." Mathematical Programming Computation(2021).

[3] Wangi, et al. "Learning cut selection for mixed-integer linear programming via hierarchical sequence model."ICLR (2023).

Dear Reviewer Fjx6,

Thank you for clicking the “Mandatory Acknowledgement” button to confirm you’ve read the authors’ rebuttal. Please also leave comments as soon as possible on whether the authors have addressed your concerns and any follow-up questions in your mind, if any.

Thank you for your continued contributions to the review process.

Best, AC

We thank the reviewer for the positive and insightful comments. We respond to each comment as follows and sincerely hope that our rebuttal will properly address your concerns. If so, we would deeply appreciate it if you could raise your score. If not, please let us know your further concerns, and we will continue actively responding to your comments and improving our submission.

Q1. The difficulty / flexibility of adapting their framework to configure other parameters.

A1.

Thank you for the insightful comment. We claim that our proposed DynSep framework is inherently extensible to a broader set of solver hyperparameters beyond separators (e.g., branching, heuristics). This is because DynSep is inherently a node-level adaptive configuration framework in the B&C tree.

Compared to configure separator, adapting DynSep to branching or heuristics requires nontrivial solver-specific engineering because they expose different plugin/callback interfaces. Specifically, adapting to branching or heuristics would involve:

1. Implement analogous instrumentation via the BRANCH and HEURISTIC plugin callbacks, such as BRANCHEXECLP and HEUREXEC.
2. Augment the state representation with relevant branching/heuristic signals provided by the solver.
3. Adapt the policy network of DynSep: model the outputs of other parameters as a logistic‑normal distribution, followed by optional discretization to support both integer and continuous parameters. This enables flexible, differentiable control of arbitrary solver parameters.
4. Train the policy with the same PPO-based scheme.

Due to time constraints, we have not yet migrated DynSep to branching or heuristic configuration, but we have already extended it to additional cut-related parameters to demonstrate feasibility. We conducted additional experiments on three critical hyperparameter groups, while retaining the original tuning mechanism for separator activation and max round.

• para group 1: Cut Depth / Aggressiveness (sepastore/age in SCIP). Controlled by solver parameters separating/cutagelimit and separating/poolfreq.
• para group 2: Cut selection thresholds (e.g., efficacy vs. orthogonality). Controlled by solver parameters separating/minefficacy and cutselection/hybrid/minortho.
• para group 3: Separation frequency per node. Controlled by solver parameters separating/cutagelimit and separating/poolfreq.

We provide the experimental results as follows.

We evaluated our method on three benchmark datasets: Knapsack, Corlat, and MIPLIB mixed supportcase, measuring solving time (Time), primal–dual gap integral (PD integral), and primal–dual gap (PD gap). All three metrics are lower-is-better.

We compared our original DynSep method with its extended versions incorporating three additional parameter groups. Results show that:

1. Across all datasets, DynSep and its extended variants consistently outperform the default solver configuration reported in the main paper.

2. The differences among the parameter groups are relatively small, yet certain combinations yield further performance improvements in both Time and PD integral.

These results validate that DynSep can flexibly extend to control a broader set of solver hyperparameters. Furthermore, carefully chosen parameter combinations can yield additional gains in solving speed and convergence.

Q2. Robustness studies in terms of separator frequency and maximum separation round.

A2.

We conducted robustness ablations over separator frequency (1, 5, 10, 20) and maximum separation rounds (3, 5, 10, 20) on three benchmarks (MIK, Corlat, and MIPLIB mixed Neos). Overall, across almost all tested settings, DynSep outperforms the default configuration, showing that the approach is reasonably stable to these hyperparameters.

On each benchmark, we report three metrics: solving time (Time), primal–dual gap integral (PD integral), and primal–dual gap (PD gap). All three metrics are lower-is-better. Below is our key observations.

• Frequency: Moderate frequency (e.g., 5&10) gives the better trade-off. That is, small frequency causes separators to fire excessively, incurring high cut-generation overhead, whereas large frequency reduces opportunities for timely dual-bound tightening.

• Maximum separation rounds: Setting this value too low produces weak cuts and degrades performance, while setting it excessively high increases the computational cost of cut generation. Although this parameter shows some dataset sensitivity, MaxRound=5 is empirically near-optimal in our tests.

Q3. Can the authors conduct experiments on gurobi (or other MILP solvers)?

A3.

We appreciate the reviewer’s suggestion to apply our method to ohter MILP solvers like Gurobi. Although our current experiments are conducted in SCIP, translating our approach for separator-activation tuning to Gurobi is technically feasible. Below, we outline the feasibility and limitations of such an implementation.

• Feasibility. Gurobi provides separators like CliqueCuts, FlowCoverCuts, MIRCuts, StrongCGCuts, etc., each accepting a configuration parameter in {0, 1, 2} (or –1 for automatic). 0 disables the cut separator, 1 enables it moderately, and 2 enables it aggressively—precisely matching DynSep’s configuration schema. These parameters can be set statically via model.setParam("CliqueCuts", value) and can also be changed dynamically at the node level via cbSetIntParam(...) within a where == GRB.Callback.MIPNODE callback. By using these interfaces, our separator configuration method can be ported to Gurobi fairly directly.
• Limitation. Gurobi’s callback mechanism only invokes user code once per node for separators, which prevents us from adjusting parameters at a finer, per-separation-round granularity. However, node-level tuning remains effective for most practical scenarios.

Given the preceding discussion, the adaptation requires substantial solver-specific engineering to rewire state collection, accommodate Gurobi’s callback semantics, and translate our dynamic decision logic to its API. Due to time constraints, we have not yet completed the Gurobi experiments. Nevertheless, we remain confident that DynSep’s separator-configuration strategy can be properly implemented in Gurobi. We will prioritize these tests and include preliminary Gurobi results once feasible.

Q4. A lightweight decision model to retrain historical information across the global B&B tree.

A4.

Here we provide more discussion on the potential ways that can address the mentioned limitation. The current DynSep only reasons over the local, per-node incremental graph. To capture global, historical dynamics across the entire branch-and-bound tree, one could:

• Maintain a tree-wide memory of separator performance and variable bound changes (e.g. via a lightweight recurrent summary or graph coarsening).
• Aggregate cut efficacy statistics at each depth level (or over recent sibling nodes) to inform decisions in new nodes—trading off memory overhead against improved long-term planning.

While logging every cut and bound update could incur runtime overhead, designing rational sampling techniques could keep this overhead minimal. Embedding such a lightweight global module would allow DynSep to adapt not only to per-round shifts but also to the evolving solver trajectory across the entire search tree.

Dear Reviewer E4cm,

Thank you for clicking the “Mandatory Acknowledgement” button to confirm you’ve read the authors’ rebuttal. Please also leave comments as soon as possible on whether the authors have addressed your concerns and any follow-up questions in your mind, if any.

Thank you for your continued contributions to the review process.

Best, AC

We thank the reviewer for the positive and insightful comments. We respond to each comment as follows and sincerely hope that our rebuttal will properly address your concerns. If so, we would deeply appreciate it if you could raise your score. If not, please let us know your further concerns, and we will continue actively responding to your comments and improving our submission.

Q1. Extension to commercial solvers. (e.g., Gurobi, CPLEX)

A1.

We appreciate the reviewer’s suggestion to apply our method to commercial solvers like Gurobi or CPLEX. Although our current experiments are conducted in SCIP, translating our approach for separator-activation tuning to Gurobi is technically feasible. Below, we outline the feasibility and limitations of such an implementation.

• Feasibility. Gurobi provides separators like CliqueCuts, FlowCoverCuts, MIRCuts, StrongCGCuts, etc., each accepting a configuration parameter in {0, 1, 2} (or –1 for automatic). 0 disables the cut separator, 1 enables it moderately, and 2 enables it aggressively—precisely matching DynSep’s configuration schema. These parameters can be set statically via model.setParam("CliqueCuts", value) and can also be changed dynamically at the node level via cbSetIntParam(...) within a where == GRB.Callback.MIPNODE callback. By using these interfaces, our separator configuration method can be ported to Gurobi fairly directly.
• Limitation. Gurobi’s callback mechanism only invokes user code once per node for separators, which prevents us from adjusting parameters at a finer, per-separation-round granularity. However, node-level tuning remains effective for most practical scenarios.

Given the preceding discussion, the adaptation requires substantial solver-specific engineering to rewire state collection, accommodate Gurobi’s callback semantics, and translate our dynamic decision logic to its API. Due to time constraints, we have not yet completed the Gurobi experiments. Nevertheless, we remain confident that DynSep’s separator-configuration strategy can be properly implemented in Gurobi. We will prioritize these tests and include preliminary Gurobi results once feasible.

Q2. Integration with advanced or user-defined cutting plane families.

A2.

SCIP exposes a plugin API for user-defined separators: once a custom separator is registered in SCIP, it appears in the separator nodes of our triplet graph alongside the other built-in separators. DynSep treats every separator node uniformly—built-in or custom—so any new separator simply becomes an additional token whose activation status can be tuned. In fact, our own “configuration separator” is implemented via this same API, and is invoked ahead of all other separators to adjust their parameters dynamically.

Dear Reviewer rt7i,

It appears that you have not yet replied to the authors' rebuttal for Submission 22899, and the discussion period (July 31–August 6) is halfway over. Please get involved as soon as you can to give us time for a fruitful conversation.

In particular, do you feel the authors have addressed your concern regarding the applicability and the impact of the proposed method?

Lastly, don’t forget to click the “Mandatory Acknowledgement” button to confirm you’ve participated.

Thank you for your continued contributions to the review process.

Best, AC

We thank the reviewer for the positive and insightful comments. We respond to each comment as follows and sincerely hope that our rebuttal will properly address your concerns. If so, we would deeply appreciate it if you could raise your score. If not, please let us know your further concerns, and we will continue actively responding to your comments and improving our submission.

Q1. Lack of clarity in the formulation of the solution.

A1.

We apologize for the confusion. Below, we provide the detailed specifications as suggested, and we will include them in the revised manuscript.

1. Concept of separators. Separators are core components of a mixed‑integer programming (MIP) solver. Each separator implements a dedicated cutting‑plane algorithm to generate a family of valid inequalities (i.e., cuts) to tighten the LP relaxation. For example, the Gomory cut separator derives Gomory cuts from the current simplex tableau to remove fractional solutions.
2. Difference between cutting planes and separators. Cutting planes are valid inequalities that tighten the LP relaxation, which exclude fractional solutions while preserving all feasible integer solutions. Separators are built-in algorithms that generate these cutting planes.
3. Separator nodes. In our triplet graph, each separator is represented as a dedicated node. Separator node features comprise a one-hot encoding of its type, plus the separator's performance statistics (e.g., execution time, number of applied cuts, and dual-bound improvement) to capture historical efficacy. Full definitions of these features appear in Table 4 of the appendix. Notably, the set of separator nodes is fixed (corresponding to 22 SCIP’s built‑in separators) and remains the same for every instance, while their feature values are updated dynamically at each decision step.

Q2. How are actions tokenized/encoded for the transformer?

A2.

Each action $a_t = [m_t, \eta_{t,1},\dots, \eta_{t,K}]\in\mathbb{N}^{K+1}$ could be viewed as a block of tokens, consisting of one token for the maximum round threshold $m_t$ and $K$ tokens $\eta_{t,1},\dots, \eta_{t,K}$ for $K$ separators' activation status. Below, we describe the tokenized formulation of the action.

• Maximum‑round token $m_t$: drawn from an $r_{\max}$‑dimensional categorical distribution (its token space is $\\{1,\dots,r_{\max} \\}$).
• Separator‑activation tokens $\eta_{t,i}$: for each separator, one token drawn from a 3‑dimensional categorical distribution over $\\{-1,0,1\\}$ indicating three distinct activation statuses.

Notably, we clarify that we do not feed the sampled action $a_t$ back into the transformer. Instead, we execute the action $a_t$ in the solver environment and obtain the next incremental state $\Delta s_{t+1}$ (i.e., the incremental graph). We input $\Delta s_{t+1}$ as the subsequent token block into the transformer. This yields an autoregressive loop for both the training and reference phases--each next-step prediction $a_t$ conditions on the entire history of past incremental states $\\{\Delta s_{1:t}\\}$ (equal to $s_t$). Such procedure matches the modeling of standard online RL policy $a_t=\pi(s_t)$, where the policy $\pi$ depends only on the current state $s_t$, not on prior actions.

Q3. Why not use graph-based positional encodings (PEs) (e.g., spectral PE)?

A3.

We acknowledge that, since all separator nodes are fully connected to variable and constraint nodes, they share the same graph topology, thus receiving identical spectral PE. However, we deliberately opt for blocked PE for two main reasons:

1. Computational Efficiency: Computing spectral or other graph‑based PEs requires eigendecomposition or additional operations on the graph Laplacian (or related matrices), which scales poorly on large graphs. In contrast, our blocked PE leverages the prior knowledge that separator nodes have no inherent sequence order and is aligned with minimal overhead.
2. Dynamic Temporal Modeling: Graph‑based PEs encode static topological similarity and cannot capture the evolving, time‑series nature of the dynamic separator configuration. In contrast, our blocked PE preserves the chronological order of each incremental subgraph while treating separator nodes as an unordered set. This ensures the model focuses on the temporal progression of separator activations rather than a fixed structural pattern.

Q4. Several notations appear before their first introduction.

A4.

We appreciate this feedback. We’ll move those definitions earlier for clarity.

Q5. The generalization of DynSep.

A5.

Thank you for raising this point. In our evaluation, DynSep policies are trained and tested within the same problem class.

• To evaluate the across-domain generalization, we train our policy on one problem family and apply the learned policy to unseen problem families. Specifically, we train 3 separate DynSep policies (on Knapsack, MIK, and Supportcase) and evaluate each of them across all nine benchmark families used in our manuscript. The table below lists the results, where we report solving time for easy and medium datasets, while reporting PD integral for hard datasets.

  As shown in the table, policies trained on one problem type yield improvements over SCIP’s default in most unseen benchmarks, indicating effective transfer of our learned configuration strategy across NP-hard families.

• To further demonstrate generalization, we also evaluated on real-world datasets. Although they come from the same application domain, geographic, temporal, and related variations induce significant distribution shift, thus cross-dataset performance could serve as a proxy for transfer to unseen problems.

As shown in the table below, our method (DynSep) delivers marked performance gains on two real‑world datasets (MIRP and SRPN) from the Distributional MIPLIB benchmark [1], providing evidence of its ability to generalize to unseen, distribution-shifted real-world instances.

Q6. How the GCN encoder is trained?

A6.

We use separate decoder-only Transformers for actor and critic. The GCN encoder is updated only during critic training (backpropagated with the critic loss); it is frozen during actor updates.

Q7. Can DynSep handle nonlinear or MINLP problems?

A7.

Thank you for the insightful comment. We believe DynSep can naturally extend to MINLPs because SCIP’s unified Constraint Integer Programming (CIP) framework handles both MILPs and MINLPs within the same branch‑cut‑and‑price architecture. When solving MINLPs, SCIP automatically applies nonlinear handlers and MINLP-specific separators. like RLT cut separator and minor cut separator, to strengthen relaxations via valid cuts.

By incorporating MINLP‑specific separators into the action space, our instance‑aware configuration method could extend seamlessly to nonlinear problems. Meanwhile, we could enrich our state representation to capture nonlinear structure following the existing approach [2]. In other words, the core decision‑making paradigm—choosing which separators to fire at each node and when to stop—remains valid for both MILP and MINLP, making this extension both straightforward and feasible.

Q8. How does the blocked positional encoding impact performance?

Q9. Would alternative architectures like graph transformers improve separator modeling?

A8. & A9.

We merged the results for Q8 and Q9 into a single table for compactness and easier comparison.

• w/o BlockPE (for Q8): This row show the results that replace the blocked positional encoding with a standard token-level positional encoding. Its degraded performance relative to DynSep indicates that masking intra-block order information (i.e., using BlockPE) benefits training and improves final performance.
• GT (for Q9): This row show the results that replace the encoder’s GCN with a custom bipartite graph transformer (GT): a multi-head TransformerConv for edge-aware message passing, followed by residual-connected LayerNorm and a two-layer feed-forward block. "GT" shows no consistent improvement over DynSep, which may be due to increased inference overhead or the need for finer stability/tuning to realize gains from the transformer-style aggregation.

Q10. Typo in Ablation Study.

A10.

Thank you for pointing this out. We will keep all statements consistent.

[1] Huang, et al. "Distributional MIPLIB: a multi-domain library for advancing ml-guided milp methods." arXiv 2024.

[2] Tang, Bo, Elias Boutros Khalil, and Jan Drgona. "Learning to Optimize for Mixed-Integer Nonlinear Programming." (2024).

Dear Reviewer ZkPt,

It appears that you have not yet replied to the authors' rebuttal for Submission 22899, and the discussion period (July 31–August 6) is halfway over. Please get involved as soon as you can to give us time for a fruitful conversation.

In particular, please share whether their responses adequately address your concerns, especially regarding the technical clarity and the generalization of the proposed method.

Lastly, don’t forget to click the “Mandatory Acknowledgement” button to confirm you’ve participated.

Thank you for your continued contributions to the review process.

Best, AC

Thank you for raising the concerns about our generalization study. Below, we’ve improved our generalization study and detailed the real-world merits of domain-specific models.

• Improved generalization study for our method.

We select $168$ diverse instances from the MIPLIB 2017 benchmark [1] as our training set and learn a separator configuration policy on these instances. Notably, because the MIPLIB 2017 instances cover a wide variety of problem types and mixed-scenario structures [1], this learned policy could serve as a general configuration model. We then evaluate it—without any additional tuning—on four unseen, domain-specific datasets: Corlat, Load Balancing (LB), Maritime Inventory Routing Problem (MIRP), and Seismic‑Resilient Pipe Network Planning (SRPN).

As shown in Table 1, the general configuration model consistently outperforms the solver’s default settings in both solve time and convergence behavior, demonstrating good generalizability of our method.

Table 1. Generalization performance of our DynSep model trained on MIPLIB 2017, evaluated on four unseen MILP scenarios. (300-second time limit for Corlat & LB; 600-second for MIRP & SRPN)

---

• Real-world merits of domain-specific models.

Although a domain-general model reduces the workload of manually picking or retraining for each new scenario, the structural diversity of MILP instances makes domain-specific models considerably more competitive—especially in computationally intensive industrial settings, where these domain-specific models play a pivotal role in accelerating the solving process and enhancing solution quality within a time limit for particular problem sets. For example,

• By applying Gurobi’s parameter-optimization model to 97 quadratic knapsack instances from Beasley’s OR-Library, the solver highlights five key parameters and achieves up to 7‑fold runtime improvements. [2]

• SMAC, a configuration method applied to CPLEX’s 76 expert parameters, delivers up to 50‑fold runtime improvements over default settings on domain‑specific tasks such as combinatorial auction and knapsack problems.[3]

• Configuration approaches such as ParamILS [4] and irace [5] have shown significant, problem-specific speed-ups on real-world wildlife-corridor design problems.

These case studies illustrate that scenario-aware tuning could incur minimal overhead while delivering critical latency reductions in real-world scenarios.

• Clarification of our original generation results.

In our across-domain evaluation for the original rebuttal, each of the three trained policies outperforms the default configuration on the vast majority of problem families (see Table 2). As a result, any of the three trained policies can individually deliver reliable speed-ups on all tested datasets, eliminating the need for the model-selection step.

Table 2. Relative improvement over the default solver settings in solving time (Time) or primal-dual integral (PD integral), for three models trained on different problem families (Knapsack, MIK, Supportcase).

---

[1] Gleixner, et al. "MIPLIB 2017: data-driven compilation of the 6th mixed-integer programming library." Mathematical Programming Computation(2021).

[2] Rando, D., et al. "The importance of fine-tuning Gurobi parameters when solving quadratic knapsack problems: A guide for OR practitioners. Pure and New Mathematics in AI (2024).

[3] Hutter, Frank, Holger H. Hoos, and Kevin Leyton-Brown. "Sequential model-based optimization for general algorithm configuration." International conference on learning and intelligent optimization (2011).

[4] Hutter, Frank, et al. "ParamILS: an automatic algorithm configuration framework." Journal of artificial intelligence research 36 (2009).

[5] Pérez Cáceres, L., et al. "An experimental study of adaptive capping in irace: Supplementary material." (2017).