optimisation engine

optimisation engine

Autotuning

Autotuning is how Optrak fits the optimiser to one particular operation. Instead of running the same fixed set of methods and settings for everybody, Optrak tries different combinations against real days from your own work, keeps the one that most reliably produces the best plans, and writes it down as the way your runs will be done from then on. It happens when you are first set up, again when the operation changes, and again when Optrak gains new methods that might suit you.

Last updated: 2026-08-11

Key Capabilities

  • Tuned to your own work, not to an average of everybody's — and re-tuned when the operation changes, rather than fixed on the day you went live
  • Chooses both the methods used to build and improve a plan and the settings they run with
  • Judged against a spread of real days from your operation, so a winner has to be good across the range and not lucky on one day
  • Scored on how good the plan is at every point during a run, so 'best after five minutes' is measured rather than assumed
  • The result is a short script that drops straight into your live system — no change to the software itself
  • An agent decides which trials to run next and how much computer time to give them; it never touches a route, a cost, or a setting

Getting It Right Before You Go Live

The most important moment for autotuning is when a new operation is set up. Before you go live, the optimiser is tuned against real days from your own work — your orders, your fleet, the rules you work to. It starts from the settings of an existing operation that runs much like yours, and then works through trial after trial over several hours, running each one against a spread of your days and keeping whichever comes out best across all of them.

What you get at the end is a system set up with an optimisation script ready to run, arrived at by measurement. Nobody sits with the dials and turns them by feel.

Why Fixed Settings Go Stale

An optimiser set up on the operation you had on day one is tuned to the operation you had on day one. Three years later it is a different operation: different customers, a different mix of vehicles, different fuels, different delivery windows. Settings that suited the old shape suit the new one less well, and the cost of that shows up quietly — as plans the planner has to rework by hand, or as savings the optimiser would have found two years ago and no longer does.

There are two usual responses. The careful one is to leave the settings alone and put up with the drift. The hopeful one is to treat re-tuning as a project: get the supplier in, commission some work, wait a few months. Both leave money on the table. The third option is to make re-tuning cheap and repeatable — something that can simply be run again whenever the operation changes or Optrak gains something new, and that produces working instructions at the end of it without anybody writing bespoke software.

How the Search Works

Optrak keeps a detailed record of every run: what it tried, and how good the best plan was at each point as the run went on. Autotuning searches over its own settings and judges each candidate against that record. There are two kinds of decision.

Which methods to use. Optrak has around thirty families of method for building and improving a plan, set out on the methods and how they are combined page. Autotuning decides which of them to use for your work, and in what order.

What numbers to run them with. For the chosen combination, the settings that get the best results: how many changes to try at each stage, how long each stage lasts.

Trying every combination is out of the question, so the search uses well-established methods rather than brute force:

  • Learning as it goes. Rather than trying settings at random, it builds up a picture of which ones tend to help and uses that to choose what to try next. Each trial is expensive, so it pays to spend them well.
  • Cutting the weak ones early. Every candidate gets a short run first. The worse half is dropped, the survivors get longer, and so on. Little time is wasted giving a full run to something that was never going to win.

What Decides the Winner

Two things stop a winner being a fluke.

The first is that candidates are judged against a spread of days that represent the real range of your work — a heavy Monday, a light Thursday, the week before Christmas — rather than one day that happened to suit them.

The second is when they are judged. Optrak records how good the best plan is throughout a run, not just at the end, so a single long trial tells you how that candidate would have done at one minute, at five, and at twenty. If your planners work to a five-minute run, the winner is the one that was best at five minutes — measured, not assumed.

Who Decides What to Try Next

Deciding which trial to run next, and how much computer time to give it, is done by an AI agent. It reads what has happened so far, picks the next thing to try, watches the result, and stops when more work has stopped paying — handing over the finished instructions along with the ranking of everything it tried and the evidence behind the decision, so the whole exercise can be checked or repeated.

The agent directs the work; it does not do it. It never produces a route, never works out a cost, and never picks a setting itself — it chooses which of the established methods to run next.

Where This Fits With AI Generally

Autotuning is one of several places machine learning appears in Optrak. For the wider picture — what “AI in route planning” does and doesn’t mean, where Optrak uses it and where decades of operational research do the work, and why letting a neural network plan the routes outright isn’t ready for production — see AI in route optimisation.

When It Runs Again

When you are onboarded, autotuning runs against days drawn from your work and the best result becomes your standard settings. After that it is run again at the points where it pays: when the operation changes shape — new customers, a different fleet mix, different delivery windows — and when new methods are added to Optrak, whether because the research field has moved on or because new fuels and vehicle types have created new kinds of problem.

On each re-run, existing operations are checked to see whether the new methods would help them, and the standard settings are only replaced if a candidate beats them across the whole spread of days. That is how an installed Optrak keeps getting better: by being measured again, deliberately, rather than by being left alone.

Example: An Operation That Adds Electric HGVs

A regional distributor wins a chilled multi-temperature contract and runs the work on diesel HGVs. The optimiser is tuned for that: methods that are good at protecting tight delivery windows, and settings suited to how closely packed the drops are.

Eighteen months later they commit to two electric HGVs to take over the shorter regional rounds. The operation is now a mixed fleet. Energy use varies with the load on each leg, charging has to be planned into the longer rounds, and the shape of a workable round has changed because the electric vehicles have a different useful range. The best mix of methods has moved with it: the ones that pay attention to energy matter more than they did, the specialist charging methods now earn a place on every run.

Without autotuning, the day-one settings are now the wrong ones. That shows up as rework on the electric rounds specifically — something the planner notices without being able to say what the cause is. With autotuning, a fleet change of that size is exactly the trigger for a re-tune: a fresh exercise runs against how the operation looks now, finds that the energy-aware and charging methods have earned their place, and puts the new settings live. Nobody has to commission a consultancy project.

What Autotuning Does Not Do

It does not replace the planner’s judgement. The optimiser produces plans; the planner reviews, edits and approves them. That division is the right one — there are things about an operation that are hard to write down as rules and easy to handle as a planner’s edit: a driver who knows a difficult site, a customer where timing matters more than cost.

It also does not make the plans jump about. Tuning changes how the optimiser looks for a plan, not the plan itself. Where you want particular rounds kept the same from day to day, that is a rule you set, quite separately from how the optimiser is tuned.

How This Compares

Most routing software lets you adjust a few weights and time limits, usually set when the system is installed and rarely looked at again. Some suppliers offer a tuning exercise as a one-off piece of paid work. What Optrak does differently is treat re-tuning as something automatic and repeatable, built on well-documented methods rather than a bespoke engagement — cheap enough to run when you are set up, when your operation changes, and whenever Optrak gains new methods.

Whether other suppliers do something similar internally is hard to know from outside; what their published material describes is mostly settings fixed at installation. Adapting within a single run is well covered in the research literature. A layer that searches between runs, learns which settings suit an operation, and is driven by an agent is less commonly offered as a standing part of the product.

Frequently Asked Questions

What does autotuning actually do?

Two things, both judged against a spread of real days from your operation. First, it picks the methods: how first plans get built, what order the work is done in, and how willing the search should be to accept a change that looks worse at the time. Second, it settles the numbers those methods run with — how many changes to try, how long each stage lasts, how much of a step backwards to allow. What comes out is a short script that drops straight into your live system, so nothing about the software itself has to change.

When does autotuning run?

At the points where it pays off, not constantly in the background. The main one is setting you up: before you go live, the optimiser is tuned against real days from your own work, starting from the settings of an operation that runs much like yours. After that it is run again when the operation changes shape — new kinds of vehicle, new rules to work to — when Optrak gains new planning methods that might suit you, and on a periodic refresh. Each run is a bounded exercise, and the new settings only replace the old ones if they beat them across the whole spread of days.

Why not just use the one best method?

Because there isn’t one. Route planning is not the kind of problem that has a single best approach: an operation with hundreds of drops a round behaves quite differently from one with six, tight delivery windows behave differently from loose ones, and a mixed fleet behaves differently from a uniform one. Methods that shine on one shape of work are ordinary on another. Choosing per operation beats picking one method and applying it to everybody.

Is this ‘AI’ in the sense people mean it now — large language models?

Two layers, and the difference matters. The searching and the planning are long-established methods from operational research and automated tuning; no language model touches a route, a cost, or a setting. On top of that sits an agent that runs the exercise: it reads what has happened so far, chooses which trial to run next, decides how much computer time to give it, and judges when the result is good enough to use. The agent directs; it does not plan. Which model runs the agent is a deployment choice, deliberately kept separate from the optimiser itself.

How does this compare with an optimiser whose settings are fixed?

Fixed settings can work very well on the operation they were set up for, and go quietly stale as that operation changes — new customers, a different fleet, different delivery windows. Autotuning makes re-tuning cheap and repeatable, so the settings can be refreshed whenever the operation moves on or Optrak gains something new, rather than being frozen at the point the system was installed.

Will it make our plans jump around from day to day?

No. Tuning changes how the optimiser goes looking for a plan, not the plan itself, and it happens between runs rather than during them. Where you want particular rounds kept the same — fixed trips for certain drivers or customers — that is something you set as a rule, quite separately from how the optimiser is tuned.

What is the difference between this and the way the optimiser adapts during a run, on the parallel heuristics page?

They work on different timescales. The one described on that page happens inside a single run: methods that are earning their keep in the last few minutes get used more, ones that aren’t get used less. Autotuning happens between runs, looking back over the record of many of them, and decides which methods and settings to use in the first place. One picks the approach; the other adjusts within it.

Related

Technical Summary

Autotuning is the off-line layer that searches the optimisation engine’s own configuration space — constructors, phase structures, and parameters — for the script that performs best on a given operation’s work. It is implemented with standard algorithm-configuration methods rather than a bespoke search: Bayesian model-based configuration (SMAC3) over a conditional parameter space derived from the DSL family registry; Hyperband/ASHA early-stopping to kill weak candidates at low budget; and a diverse seed-pool sampler (“sample-and-keep”) that separates construction-phase seed variance from later parameter tuning. Candidates are evaluated against a portfolio of representative datasets and scored on the full convergence curve the engine logs — (time, best-objective) throughout a run — so a single long run scores every shorter time budget, and “best at five minutes” is measured rather than assumed. The search is orchestrated by an agent that reads run history, chooses which method to run next, bounds its compute budget, and decides when a result is good enough to deploy — a language model at the orchestration layer only; no language model touches a route, a cost, or a parameter value. Tuning outputs a script in the optimisation language, so decisions take effect without engine changes. It draws on two traditions — offline selection hyper-heuristics (Burke/Ochoa) for strategy choice, and automated algorithm configuration (SMAC3, Hyperband/ASHA) for parameter tuning — and complements the on-line HeuristicPromoteDemote selector that adapts within a single run. It runs per operation — primarily at onboarding, when the heuristic library gains new families, and on periodic refresh — not as a fixed install-time exercise. Tuning is at the algorithm-selection level, not the plan level; explicit route stability is a separate constraint.

See Optrak on Your Own Routes

Book a demo and we'll model your fleet, depots and constraints — and show the savings on real data.