TransitLM: Data-Driven Transit Route Planning
- TransitLM is a data-centric approach to map-free transit route planning, enabling end-to-end route generation learned from planning logs and station descriptions without explicit maps.
- The benchmark features over 13 million planning records from four Chinese cities, focusing on tasks like optimal route, preference-aware, and multi-route generation with detailed structural metrics.
- TransitLM systems also extend to GTFS reasoning and rider feedback analysis, integrating route synthesis, disruption-aware planning, and transit-domain text analytics for operational insights.
TransitLM denotes, in its most specific usage, a large-scale dataset and benchmark for map-free public transit route generation, introduced to train LLMs to produce complete routes directly from origin–destination information without explicit maps or routing engines. The dataset contains over 13 million planning records from four Chinese cities, and the reported models generate structurally valid routes while implicitly grounding arbitrary GPS coordinates to appropriate stations (Guo et al., 21 May 2026). In adjacent literature, the term also functions as a broader label for transit-specialized language-model systems built for GTFS understanding, transit data access, disruption-aware route replanning, and transit-domain text analytics (Jonnala et al., 2024).
1. Definition and research scope
TransitLM, as formalized in the benchmark paper, is a data-centric approach to public transit planning in which route generation is learned from planning logs, station descriptions, and line descriptions rather than computed from an explicit graph search over maps and schedules. Its central claim is that transit route planning can be learned entirely from data, enabling end-to-end, map-free route generation directly from origin-destination information; the model is reported to internalize spatial and topological knowledge from the corpus alone (Guo et al., 21 May 2026).
The name also sits within a wider transit LLM literature. Some studies use the concept to describe evaluation pipelines for GTFS comprehension and retrieval, some apply it to multimodal replanning under disruptions, and others to domain-adapted NLP for rider feedback or social-media intelligence. This broader usage does not define a single canonical architecture. Instead, it identifies a family of systems in which an LLM is specialized, prompted, or grounded for transit tasks such as route construction, timetable reasoning, policy question answering, or operational text mining (Jonnala et al., 2024).
2. Corpus design, representation, and benchmark tasks
The TransitLM dataset covers Beijing, Shanghai, Shenzhen, and Chengdu, with 12,945,264 planning sessions from one day of Amap logs, 120,845 stations, and 13,666 lines. The released continual pre-training corpus totals 13.9M records, comprising the 12.945M sessions plus 880,854 station descriptions and 147,918 line descriptions. Session records include city, origin and destination in GPS decimal degrees, optional POI names, a natural-language query, and multiple candidate routes containing transport modes, line identifiers, full station-ID sequences, transfer markers, segment-level travel distance and time, total distance, time, fare, first/last-mile access information, and a user selection label. For representation, all 120,845 station IDs are added as dedicated tokens so that each station is a single token (Guo et al., 21 May 2026).
The benchmark, TransitBench, defines three map-free generation tasks. Optimal Route Generation requires a single optimal route. Preference-Aware Planning adds one of four explicit preference types—Subway-first, Bus-first, Fewer transfers, or Shortest time. Multi-Route Generation requires three diverse feasible routes in one response. For each task, the supervised fine-tuning data comprise 30,000 training and 10,000 test examples, with the SFT period not overlapping with the continual pre-training corpus. Inputs include city and OD GPS, and outputs are structured JSON containing line sequences, station sequences with "[Transfer]" markers, total distance, total time, total fare, and first/last-mile transfer modes and distances (Guo et al., 21 May 2026).
Evaluation emphasizes structural validity, access feasibility, route overlap, and numeric field accuracy. The core structural metric is Connectivity,
and exact-match accuracy is reported as Route Exact Match,
Access feasibility is split into Station Grounding, which checks whether predicted access stations fall within mode-specific Haversine thresholds, and Distance Plausibility, which requires predicted access distances to satisfy and at both ends. Numeric fields are scored with Estimation Accuracy and MAPE, while Preference Compliance and Route Diversity serve as task-specific measures (Guo et al., 21 May 2026).
3. Training pipeline and reported performance
The reported TransitLM models use Qwen3-Base backbones at 0.6B, 1.7B, and 4B parameters, expanded with the station-token vocabulary. Training proceeds in two stages: continual pre-training over the 13.9M textual records using standard autoregressive next-token prediction, followed by per-task supervised fine-tuning for one epoch, with an additional 4B-Joint variant trained on the union of all three tasks. Continual pre-training uses packed sequences of length 4,096, AdamW, a cosine learning-rate schedule, LR , warmup 500 steps, weight decay 0.01, bf16, DeepSpeed ZeRO-3, and 64 Alibaba Cloud PPUs, while SFT uses dynamic sequence length, response-only loss masking, LR , warmup 15 steps, batch 8 per device, and 8 PPUs. Decoding is greedy with deterministic seed 1, max new tokens 4,096, and input cutoff 2,048 (Guo et al., 21 May 2026).
| Task | Best reported model | Key results |
|---|---|---|
| ORG | 4B-Joint | Conn 97.9%; SG 98.9%; DP 92.9%; LO 0.835; SSO 0.847; REM 73.7%; EA 98.6%; MAPE 1.30% |
| PRG | 4B-Joint | Conn 95.3%; SG 97.4%; DP 88.5%; LO 0.709; SSO 0.726; REM 52.6%; EA 92.8%; MAPE 1.88%; PC 90.5% |
| MRG | 4B-Joint | Conn 97.1%; SG 98.8%; DP 91.7%; LO 0.794; SSO 0.808; REM 67.2%; EA 98.1%; MAPE 1.33%; RD 0.547 |
Relative to general-purpose LLMs without tools, the reported gap is large. The strongest baseline in the lenient-output ORG comparison, Gemini-3.1-Pro, reached Connectivity 75.5%, Station Grounding 93.9%, Distance Plausibility 67.0%, Line Overlap 0.600, Station Sequence Overlap 0.569, and Route Exact Match 40.2%. Under GPS-only input, general LLMs largely collapsed, with Station Grounding dropping to 14–24% for most models and REM mostly at or below 0.6%, whereas the TransitLM 4B-Joint model remained stable on ORG GPS-only with Conn 98.0%, SG 98.8%, DP 92.6%, LO 0.827, SSO 0.839, REM 72.9%, EA 98.1%, and MAPE 1.52%. Data scaling results further showed monotonic improvement on ORG, where REM rose from 49.9% to 71.0% and MAPE fell from 3.26% to 1.33% as the continual pre-training sessions increased from 6.25% to 100%. The paper also reports that tool-augmented general LLMs can reach REM up to 74.4% on a 1k test set when coupled to the Amap routing API, but that configuration is explicitly not map-free and inherits external routing outputs (Guo et al., 21 May 2026).
4. TransitLM as route replanning and GTFS reasoning
A complementary line of work treats transit LMs not as map-free generators but as reasoning layers over external transit representations. TraveLLM is a prototype for planning public transit routes in the presence of disruptions and user-specific constraints, using an LLM Planner for free-form reasoning over text and map images and an LLM Summary for standardized route output. It evaluates GPT-4, Claude 3 Opus, and Gemini Pro 1.0 across nine scenarios involving weather disruptions, emergency events, avoidance constraints, buses, Citi Bike, and a DC Metro transfer task. Averaged across scenarios, GPT-4 achieved Connectivity 0.78, Avoidance 0.78, Approximate Time 0.51, and Transfers 4.00, outperforming Claude 3 and Gemini Pro; map-image ablation reduced Connectivity from 0.78 to 0.67 and Avoidance from 0.78 to 0.44, while removing the separate summarizer degraded Connectivity to 0.44 and raised Format violations from 0.11 to 1.00 (Fang et al., 2024).
A more evaluation-oriented formulation appears in the San Antonio GTFS case study, which separates GTFS “understanding” from information retrieval. The experiments use VIA Metropolitan Transit’s feed, trimmed from 98 routes to three routes—242, 243, and 246—with 34 trips and 60 unique stops to fit context limits. The benchmark contains 195 original GTFS multiple-choice questions plus 780 augmented variants, and an 80-question IR set with 42 simple and 38 complex questions. GPT-4o and GPT-3.5-Turbo are evaluated zero-shot, with GTFS content concatenated into prompts for retrieval. Reported Understanding accuracy spans 47.97% to 98.44%, IR spans 60.53% to 90.48%, and GPT-4o is roughly 15% higher on simple IR and about 8% higher on complex IR; both models remain weak on categorical mapping and show sensitivity to option substitution (Jonnala et al., 2024).
TransitGPT extends this tool-mediated paradigm by having an LLM generate Python code that is executed against a server-side GTFS feed. The system uses moderation, a main code-generation LLM, sandboxed execution with retries, and a summary LLM, with dynamic few-shot examples selected by TF-IDF similarity from 12 curated code pairs. On a 100-task benchmark spanning five feeds and eight task categories, GPT-4o improved from accuracy 0.74 to 0.90 under the TransitGPT+ configuration, and Claude-3.5-Sonnet improved from 0.84 to 0.93. A related framework, presented as TransitTalk Digital Assistant, applies GPT-3.5-Turbo, Chain-of-Thought prompting, vector retrieval, and GTFS/GTFS-RT integration to three applications—Tweet Writer, Trip Advisor, and Policy Navigator—thereby positioning the LLM as an intermediary between natural-language queries and structured or unstructured transit resources (Devunuri et al., 2024, Wang et al., 2024).
5. Rider feedback, social sensing, and transit-domain language modeling
TransitLM has also come to denote domain-adapted models for rider-facing text. MetRoBERTa is trained on approximately 120,000 strongly labeled instances derived from about 180,000 anonymized WMATA CRM complaints from 2017–2022, with the labels organized into eleven broad topics: Operations/Delay/Procedures; SmarTrip Card/Fares; Customer Service; Cleanliness/Maintenance; Information Provision; Unsafe Driving; General; Route Suggestions; Fare Evasion; Crowding; and Crime/Harassment/Security. Built by fine-tuning RoBERTa for 11-way classification, the model achieved about 90% accuracy and outperformed TF-IDF-based baselines; aggregate results report Logistic Regression with accuracy 0.88 and MetRoBERTa with accuracy 0.90. The model was then integrated into a pipeline for roughly 300,000 WMATA Twitter mentions, coupled with sentiment analysis and asset matching, to generate topic-aware dashboards over time and geography (Leong et al., 2023).
Transit Pulse applies Llama 3 (8B) and Retrieval-Augmented Generation to TTC-related social media. From 631,691 collected records between Feb 5 and Dec 31, 2015, 27,312 tweets remained after removing duplicates and low-information retweets. The pipeline jointly extracts topic, sentiment, sarcasm, unusual problems, and location in a single JSON-like output, with RAG grounding supplied by TTC station names, the system map, and GTFS documentation. The reported GTFS multiple-choice accuracy improved from 57.43% to 73.85% with RAG, and programming-question accuracy improved from 24.14% (21/87) to 52.87% (46/87). In the downstream classification comparisons, BERT achieved 78.02% on Sentiment Analysis, 82.64% on Sarcasm Detection, and 91.50% on Problem Topic Classification, outperforming TF-IDF baselines (Wang et al., 2024).
Taken together, these works broaden the meaning of TransitLM beyond route synthesis. The term increasingly refers to transit-specialized language systems that add structure to rider narratives, detect spatial and temporal anomalies in public feedback, and connect operational intelligence with agency workflows. This suggests that map-free generation is one branch of a larger transit-language modeling agenda rather than its only endpoint.
6. Limitations, misconceptions, and future directions
A recurrent misconception is that TransitLM implies universally deployable, real-time transit planning. The benchmarked map-free TransitLM is static: it is derived from a one-day sample of Amap logs, released without timestamps or user identifiers, covers only four Chinese cities, and uses Chinese prompts and station-ID tokens. The paper explicitly notes unresolved transfer to non-Chinese cities and languages, the absence of real-time dynamics such as congestion or closures, and vocabulary-scaling concerns: nationwide coverage may require roughly 1.8M station tokens, motivating future hierarchical or compressed encodings (Guo et al., 21 May 2026).
A second misconception is that general-purpose LLMs already solve transit reasoning unaided. The transit-specific studies do not support that conclusion. TraveLLM reports connectivity errors, image-processing failures, and no use of GTFS or real-time feeds; the San Antonio GTFS benchmark shows persistent failures on categorical mapping and more complex multi-file retrieval; and TransitGPT is explicitly limited to static GTFS and is not a routing engine (Fang et al., 2024, Jonnala et al., 2024, Devunuri et al., 2024).
Future work in the literature follows two main directions. One direction deepens transit specialization through better grounding, such as higher-resolution maps, clearer visual markings, separate summarization modules, schema-aware prompts, validators, RAG indexing, GTFS-Realtime integration, and hybrid tool use. The other moves toward broader transportation foundation models. TransLLM, for example, unifies traffic forecasting, EV charging demand prediction, and taxi dispatch through a lightweight spatiotemporal encoder, learnable prompt routing trained with Actor–Critic, structured embeddings inserted through placeholder tokens, and task-specific output heads, with strong supervised and zero-shot results across seven datasets and three tasks. While this framework is not a public-transit route generator, it indicates that transit-specialized LMs may increasingly be embedded within larger urban transportation foundation architectures (Leng et al., 20 Aug 2025).
