We run the Mittelman VRPLib benchmarks at Timefold (and beat other open source solvers like or-tools in 95%+ of the X datasets).
But they are not representive of the real world, at all.
The Mittelman VRPLib benchmarks have only 1-2 constraints. Skills? No need. Working hours? Unlimited. Maps integretion? Cars can fly and the earth is a flat Euclidean space.
Any VRP algorithm optimized for the vrplib datasets is overfitted and not the best one in reality.
Take HGS for instance. Brilliant for CVRPTW. Crumbles to dust in field service routing for telco operations etc.
That is fair, which is why you should not over-index on academic benchmarks. But a frontier solver should be within a small margin from the competitors in these benchmarks. If you are 10x slower, there is no way you can catch up (at least not without a ton of work from the practitioner side).
Our version of a Solver as a Service deals with cases of up to 390'000 shifts in a single dataset for shift scheduling and 30'000 visits for vehicle routing problems.
Some our customers want to go even higher, and we're working on that.
There is an audience for such platforms - Timefold Platform optimizes 1,000,000 visits and 2,000,000 shifts per week - but only if it's more than just orchestration.
If it handles explainabily, what-if scenarios and insights to fulfill business needs.
And that's where supporting many solvers becomes the blocker.
A lowest common denominator design.
Those solvers are a black box. They don't expose what they're running, why they made certain decisions or how they can scale to large datasets or complex business requirements.
We've picked our poison: one solver, which we've built in the open, in the last 20 years, versatile enough to handle any scheduling problem. That delivers.
None of these solvers genuinely focuses on the quality of the features that matter in real-world operations.
Many of them, including Timefold, lack a realistic, financially grounded model of the world. They do not adequately account for traffic, driver preferences, or other factors that require a continuous feedback loop between what actually happened in practice and what the optimizer expected to happen.
A vehicle-routing problem without real-world feedback is little more than a gimmick. Even assuming the world could be modelled perfectly, what happens when an unpredictable event disrupts the plan? Is the supposedly “globally optimal” solution robust enough to adapt, or will it create a backlog that forces the business to hire additional workers because the system failed to build in sufficient redundancy?
That being said:
I fully agree that the solver industry as a whole has focused for far too long on global optima for academic requirements, instead of real-world use for the actual business requirements, and how to deal with business objective changes each quarter.
Sounds similar to Timefold Platform: app.timefold.ai
That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai
But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.
Timefold tackles the same class of problems, but I thiink their's need a backend while mine runs in browser entirely. So mine works by running the C++ browser by compiling it directly to WebAssembly, so I didn't touch the solver code. The original library has bindings to python, so I did use AI to transpile that interface and tests so that the Typescript API mirrors the Python API.
Nonsense. Timefold Solver and other open source vehicle routing problem solvers deliver better results in less time, with affordable hardware, especially for real-world complexity.
Without involving the human planners, the project won't succeed. We're empowering them, with PlanningAI assistance, so they can focus on what they planning must do, for who, instead of how it gets there. So when the plan goes off the rails - 5 people call in sick - they can get it back on the rails in seconds with Real-Time Planning.
The engineering work is only half the work, or less. Fitting the technology into the human processes is another big chunk. Half of my videos on youtube deal with such cases: Continuous Planning, Real-Time Planning, Non-distruptive Replanning, Pinning, ... Not code, not technology, but design patterns.
And even then, this is far from 100% of the solution. Technology and education is still not enough.
That human planner with 30 years of business knowledge in his/her head is still a critical: he/she will always need to tweak, oversee and sometimes overrule the planning solution in production.
But they are not representive of the real world, at all.
The Mittelman VRPLib benchmarks have only 1-2 constraints. Skills? No need. Working hours? Unlimited. Maps integretion? Cars can fly and the earth is a flat Euclidean space.
Any VRP algorithm optimized for the vrplib datasets is overfitted and not the best one in reality.
Take HGS for instance. Brilliant for CVRPTW. Crumbles to dust in field service routing for telco operations etc.