Research website · v0 · November 2026
LLM4Rail tests whether large language models, working with optimization solvers and independent checkers, can move the best known bounds on open railway benchmarks: periodic timetabling, timetabling with passenger routing, and real-time train dispatching.
Railway planning problems are hard, valuable, and unusually well benchmarked. That makes them a good test of what LLMs add to optimization.
LLM4Rail studies whether LLMs can help improve feasible timetables and dispatching solutions, tighten lower bounds, and reproduce known optima. Of the 166 model entries in the catalogue, 87 have optima reported by a paper or benchmark library, and 2 have matching bounds across sources. The remaining 77 have no published proof of optimality.
All 18 PESPlib railway instances and all 21 TimPassLib railway and urban rail instances remain open.
Of the 112 DISPLIB instances, 72 are reported optimal in Tables 5–6 of Stärk et al. For two more, nor5_small_1 and nor5_small_5, the verified feasible objective values match the lower bounds reported in Table B.13 of Fuchs et al. The remaining 38 open instances are all 32 Wabtec instances, nor5_small_2, and nor5_large_1 through nor5_large_5.
MIPLIB 2017 marks all 15 tracked railway models as optimal in its official solution file, version 37.
LLM4Rail follows the research design of LLM4MIP, which applied LLM-assisted, solver-backed workflows to the open instances of MIPLIB. We ask the same question for railway problems, where the LLM can also draw on the structure of lines, periods, transfers and track layouts.
Two things we commit to from the start: no result is accepted from LLM output alone, and every reported result names the model, the solvers and the compute it used.
Planning covers periodic timetabling, passenger routing and railway slot allocation. Operations covers real-time dispatching and timetable rescheduling after delays.
Periodic event scheduling: find a timetable that repeats every period and minimises weighted slack. The catalogue covers railway instances R1L1–R4L4 and two railway variants.
Periodic timetabling and passenger routing optimised together. Networks include S-Bahn Hamburg, the Athens metro, regional and long-distance railways, and the 16 PESPlib railway networks with passenger demand.
Train dispatching: re-route and re-schedule trains after delays. Real instances from Siemens Mobility (Italy), SINTEF (Norway), SBB (Switzerland) and Wabtec.
Models from MIPLIB 2017 for periodic timetabling, railway slot allocation and train rescheduling.
Later extensions: problems from the INFORMS RAS Problem Solving Competition (yards, blocking, switching), and Flatland for comparison with reinforcement-learning methods.
The tracked PESPlib instances sit 30% to 50% from their lower bounds. The 21 TimPassLib data sets in the catalogue have gaps from 0.1% to 3.1%. DISPLIB has 38 instances with a positive gap.
(best known − best lower bound) ÷ |best known| · hover a bar for the values
Source: PESPlib records table, read 2026-11-11. PESPlib notes that lower bounds are not verified.
Source: TimPassLib solutions page, read 2026-11-11. Lower bounds come from the library's routing relaxation.
The LLM proposes. Solvers compute. An independent checker decides what counts.
The benchmark file, its current best bounds, the official verifier, and what the lines and stations mean.
Reads the structure, then proposes decompositions, neighbourhoods, reductions and lower-bound arguments.
MIP solvers and dedicated algorithms search for solutions and compute bounds, with full run logs.
The library's own verifier, exact certificate replay, and hashes of every file. Failures go back to step 2.
Decompose by line and corridor, re-optimise neighbourhoods around the incumbent, and warm-start from the best known timetable.
Find strong cycle constraints and decompositions, and emit lower-bound certificates that can be replayed in exact arithmetic.
Fast re-routing and re-scheduling for DISPLIB instances, with lower bounds to show how far each solution is from optimal.
Each skill will be compared on equal time and hardware against two arms: the same LLM workflow without the skill, and the solvers alone.
LLM4Rail experimental results carry the evidence grades below. The instance catalogue lists the sources of the published baseline bounds.
A bound or optimality proof that replays in rational arithmetic.
A solution accepted by the library's own checking program.
A bound reported by a solver within its default tolerances.
A result that holds only under a stated numerical tolerance.
Four phases. Each ends at a gate that has to be passed before the next starts.
Until the technical report is out, please cite the website.
@misc{cao2026llm4rail,
author = {Cao, Buyun and Li, Yang and Wang, Jiayi and Shen, Zhaoping and Tian, Weilin and Zhang, Chengwei and Wang, Zhuoyu and Che, Yunzhou and Yao, Shan and Jiang, Huaxiao and Lin, Zhongyang and Li, Xin and Yang, Liner and Ding, Ding and Huang, Yaping},
title = {How Much Can {LLMs} Help Solve Railway Optimization Problems?},
year = {2026},
month = nov,
url = {https://llm4rail.github.io/},
note = {Research website}
}