Optimizing Expensive Simulators Without Pretending You Need Global Optimality

Some optimization problems are not hard because nobody knows how to write an objective function. They are hard because the only way to score a decision is to run a painful simulation. Each candidate policy might require thousands of Monte Carlo replications. One evaluation can take an hour. The search space can be combinatorial, discrete, high-dimensional, and absurdly large.

In that world, pretending you need global optimality is usually the wrong starting point. The practical goal is to find a decision that is materially better than the current policy, robust enough to survive uncertainty, and cheap enough to discover within the compute budget.

That is not giving up. That is being honest about the economics of the problem.

The problem with brute force

Suppose you have hundreds of decision variables, each with many possible values. The number of possible configurations is not large. It is effectively infinite from an operational standpoint. If one full Monte Carlo evaluation takes an hour, you cannot test every configuration. You cannot even test a meaningful fraction of the space.

The mistake is to treat the simulator like a normal objective function that can be called whenever the algorithm wants. It cannot. The simulator is the scarce resource. The optimization method has to be designed around that fact.

The core question becomes: which configurations deserve expensive evaluation?

Separate cheap search from expensive truth

A practical workflow should separate cheap approximation from expensive validation.

Start with a diverse initial design. Use Latin hypercube sampling, quasi-random sampling, domain-informed rules, or structured perturbations of existing policies. The goal is not to solve the problem in the first batch. The goal is to learn the shape of the response surface and identify which regions are promising.

Then build a surrogate model that predicts simulation performance from configuration features. The surrogate does not need to be perfect. It needs to be useful enough to rank candidates, estimate uncertainty, and guide search toward better regions. This might be a Gaussian process for smaller structured problems, a random forest or gradient boosting model for larger tabular spaces, or an ensemble when uncertainty estimates matter.

Finally, use the expensive simulator only on candidates that are likely to matter. The simulator is the judge, not the search engine.

Do not spend the full Monte Carlo budget too early

A common mistake is to run every candidate with the full number of replications from the beginning. That feels statistically clean, but it can waste enormous compute on bad configurations.

Early in the search, you often only need enough replications to distinguish obviously bad policies from potentially good ones. As the search narrows, you allocate more replications to contenders. This is the same logic as racing algorithms, sequential testing, and optimal learning: spend information budget where it can change the decision.

The final candidates deserve full Monte Carlo evaluation. The early candidates usually do not.

Use common random numbers

When comparing policies under simulation, use common random numbers whenever possible. This means evaluating different candidate policies against the same underlying random scenarios. The point is to reduce noise in the comparison.

If candidate A is tested on a lucky demand sequence and candidate B is tested on an unlucky one, the ranking may reflect simulation noise instead of policy quality. Common random numbers make the comparison fairer by exposing policies to the same uncertainty. That can dramatically improve the signal you get from each simulation dollar.

Add the optimizer after you understand the decision

For very large discrete spaces, the search layer can combine multiple methods. Use surrogate-assisted search to propose promising regions. Use local search, genetic algorithms, simulated annealing, or tabu search to move through combinatorial neighborhoods. Use Bayesian optimization or knowledge gradient to choose expensive evaluations. Use MILP when parts of the structure can be modeled exactly.

The strongest systems often combine methods. MILP handles structure. Simulation handles uncertainty. Surrogates reduce expensive calls. Bayesian or optimal learning methods decide what to evaluate next. Domain expertise defines neighborhoods that actually make operational sense.

This is not algorithm shopping. It is architecture.

Evaluate policies, not just configurations

The final output should not be a brittle configuration that only wins one simulation leaderboard. It should be a policy or parameterized decision rule that performs well across plausible futures.

That means validating the winner across held-out scenarios, stress cases, demand regimes, lead-time shocks, and operational constraints that were not overfit during the search. It also means comparing against the current business policy, not just against other experimental candidates. If the new policy is not materially better than the status quo after accounting for risk and complexity, it is not a win.

The practitioner takeaway

When simulations are expensive, optimization becomes a learning problem. You are not just searching for the best decision. You are deciding what to learn next under a limited evaluation budget.

Do not brute-force the impossible. Do not demand global optimality when the simulator makes that fantasy meaningless. Build a workflow that explores broadly, learns cheaply, evaluates selectively, and validates seriously.

The goal is not to prove that no better solution exists somewhere in a universe you cannot search. The goal is to produce a decision that beats the current system, survives uncertainty, and can actually be deployed.