cuopt-multi-objective-exploration

Multi-Objective Exploration

cuOpt optimizes one objective per solve. Many real problems have several objectives that pull against each other — cost vs. service level, return vs. risk, makespan vs. overtime, distance vs. vehicle count. A single solve answers "what's optimal for one particular weighting," but it hides the tradeoff the user actually needs to see.

This skill turns a sequence of single-objective cuOpt solves into a Pareto frontier — the set of solutions where you can't improve one objective without giving up another — and gives the discipline to read it. It adds no solver features; it orchestrates the LP / MILP / QP solves already covered by the formulation and API skills.

When this applies

Reach for this workflow when the problem has two or more objectives with no agreed-upon weighting, signalled by language like:

• "balance X and Y", "trade off", "as cheap as possible without hurting service"
• "minimize cost and maximize coverage", "I want options, not one answer"
• any objective the user is willing to relax in exchange for another

If there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.

Core idea — one solve is one point on a curve

A single optimum encodes one implicit weighting of the objectives. Change the weighting and the optimum moves. The frontier is the curve traced by all the non-dominated optima.

A solution A dominates B when A is at least as good on every objective and strictly better on one. Dominated solutions are never worth choosing. The Pareto frontier is exactly the non-dominated set; the user's job is to pick a point on it, and yours is to show them the whole curve plus where the tradeoff is sharpest.

Do not collapse a multi-objective problem to a single weighted number and report its optimum as "the answer" — that silently makes the tradeoff decision for the user. Trace the frontier and let them choose.

Objectives and constraints are interchangeable. A requirement currently treated as fixed — a coverage floor, a fairness cap, a budget — is often a latent objective: its level was assumed, not given. Promoting such a constraint to a parametric ε-constraint and sweeping it reveals a tradeoff you'd otherwise hide, so read a single-objective model's hard constraints as candidate objectives, not just limits — but only when the level was an assumption. A genuinely fixed, non-negotiable limit (a hard budget cap, a regulatory minimum) stays a constraint; don't manufacture a tradeoff that isn't there. Express any promoted quantity linearly so it can serve as an ε-constraint (see cuopt-numerical-optimization-formulation).