Google Research releases a middle-mile logistics generator

The middle mile is the segment where goods move between regional distribution centers. The post says this segment covers the longest distance of the journey, accounts for a large share of total cost, and decides whether goods arrive fresh or stale. Even so, research has clustered around the first mile from producers to consolidation points and the last mile to consumers.

The reason is data. The post says "most logistics companies treat their network topologies and demand volumes as highly sensitive proprietary information." Without public, high-quality data, academic progress was blocked.

The shape of the problem differs too. In the first and last mile a shipment stays in one vehicle from origin to destination, and optimization is about deciding which vehicle handles which shipments in what order. In the middle mile a single shipment changes vehicles repeatedly across a continental network and may arrive a week after departure. The post says "the middle mile functions as a relay race."

What the transfers create is a synchronization problem. At intermediate distribution centers a shipment is unloaded, sorted by destination, consolidated with other freight, and loaded onto the next vehicle. If it does not arrive within a specific time window to catch its scheduled outgoing truck, it sits at the center until the next cycle and the delay grows sharply.

The post opens by asking how a Dutch pastry can reach a home 700 kilometers away the very next day, crediting logistics optimization. The example that follows runs from Groningen in the Netherlands to Versailles in France. The goods gather at the regional center in Utrecht, move to Antwerp the same day, take a second truck the following day because the most immediate truck to Paris is full, arrive in Paris at night, and enter the last mile the next day. One shipment splits the journey across three days.

Existing tools do not solve this. Google models the problem as a multi-commodity flow on a space-time graph, where nodes represent a specific distribution center in a specific time interval and arcs represent vehicle movements or a shipment being held at a center. Fixed timetables, hourly sorting throughput limits at centers, and the synchronization that makes one vehicle's arrival a prerequisite for another's departure are all hard to relax, so the post says "existing VRP solvers cannot apply to the middle mile."

What the generator holds is a balance between realism and privacy. Distribution centers are placed using gravity models or spatial clustering to reflect real population and industrial density, and demand is generated as origin-destination pairs following realistic volume and weight distributions. Vehicle schedules are structured rather than arbitrary links between nodes, connecting either two major centers or a major center and its neighboring smaller ones. These distributions interpolate between publicly available information from industrial actors and privately disclosed data.

The implementation is C++ and it uses Protocol Buffers for serialization. One instance fits in one file, so solvers written in other languages can read it directly. Unlike the vehicle routing side, which keeps separate variants for capacities or time windows, this format puts fixed schedules, throughput limits, and synchronization prerequisites all inside a single file format.

The post METAL read also sets out the range of instances to come. It spans academic toy-problem sizes for testing exact algorithms up to continent-wide industrial problems that need advanced heuristics, with medium sizes in between. It also leaves room for building large datasets to train machine learning algorithms.

The work is a collaboration between Google and academic partners at UniBrescia and ENPC Paris. Google says it is building a solver and API specialized for middle-mile operational problems, and calls this a first step toward a standardized benchmark suite for the middle mile, comparable to what CVRPLIB is for the vehicle routing community. The team also wrote that it hopes to start a challenge to draw academics and industrial solver developers in.

METAL has reported on R4T, which eases inference bottlenecks in complex AI search, and has also reported on a library of learning interactives teachers build themselves. All three aim at the same place: reshaping a problem into a form that can be worked on, rather than growing the model. The next advance in supply chain optimization is now more likely to come from a public problem set than from a larger model.