ROAM pairs AI travel suggestions with route optimization

Separating suggestions from scheduling

In a preprint posted on November 6, 2026, Ye Zihao and Lin Xiaoheng describe ROAM, short for Retrieval-Augmented Optimization for Feasible Multi-Day Itinerary Planning. The work is not established peer-reviewed evidence.

Its central idea is to avoid asking a language model to solve every part of travel planning in one response. Instead, ROAM retrieves potentially relevant attractions, groups and orders them using explicit algorithms, checks the schedule, and supplies the resulting information to the model.

How the pipeline works

First, a language model converts a request into structured preferences and constraints: themes, must-see attractions, exclusions, daily hours and mobility assumptions. A Chinese-language embedding model then matches the request to a curated database. Embeddings represent text numerically so that requests and attraction descriptions can be compared by similarity.

Next comes geographic organization. ROAM identifies groups of nearby attractions, combines them into day-sized clusters and balances attraction counts across days. A route-search method called simulated annealing seeks an efficient visiting order. Its scoring gives better-rated attractions a limited advantage when weighing travel costs.

The system normally uses road distances from the Open Source Routing Machine. If that service is unavailable, it substitutes straight-line geographic distances multiplied by 1.4—an approximation, not a measured road route.

ROAM then simulates the schedule. When it finds a timing violation, it tries swapping the offending attraction with later stops. Attractions that remain unrepairable are dropped after a bounded repair process.

Weather forecasts, operating hours and transport information are added to the generation prompt. The language model produces a structured itinerary for map display. A conversational editing agent can replace attractions and invoke route optimization and feasibility checks again. These editing capabilities are described, but the paper does not report a separate quantitative evaluation of them.

What the evaluation found

The authors tested three-day plans using 36 queries and 510 attractions across Fuzhou, Guangzhou, Shenzhen and Shanghai. They compared ROAM with a bare language model and a retrieval-only system that supplied attraction information without explicit route optimization or time-window repair. All three used the same serving model, DeepSeek V4 Flash.

In the reported sunny-condition results, ROAM averaged 27.5 attractions per trip, compared with 19.25 for the bare model and 17.0 for retrieval alone. Those differences amount to approximately 42% and 62% more scheduled attractions.

Against retrieval alone, its reported route-cost measure fell from about 2,101 to 677 metres, a 3.1-fold reduction. This metric is a transport-mode-weighted average distance between stops, not total trip distance or observed journey time.

The bare model scored approximately 633 metres on the same measure—slightly lower than ROAM, not higher. ROAM therefore did not win every route comparison. Its distinguishing result was substantially greater attraction coverage alongside much lower route cost than the retrieval-only system. More stops, however, do not necessarily mean a more enjoyable holiday.

Under rainy forecasts, ROAM averaged 26.25 attractions. Shanghai’s count fell from 33 to 15; the authors attribute this to limited indoor options in their database. That result highlights how database coverage constrains the available plans.

Component-removal experiments suggest that spatial optimization drives the route-cost improvement. Removing time-window repair reportedly caused roughly 30% of visits to arrive after closing. These ablations are presented qualitatively, without detailed uncertainty estimates.

Why feasibility remains a qualified claim

The study evaluated generated plans offline, not completed journeys. There was no human study, each query was run once, and the paper reports neither variance nor significance tests. The small query set and four-city database limit generalization.

Some metrics also need caution. The retrieval-only baseline recorded zero commuting time because it did not calculate it—not because its trips required no travel. Semantic-match and daily-balance scores offered little separation between systems.

The scheduling model simplifies travel conditions. Its repair stage estimates inter-attraction travel at 30 kilometres per hour, while later transport recommendations may include walking or cycling. Real-time traffic, queues and ticket availability are outside scope. The written feasibility conditions also check arrival against closing time without explicitly requiring the entire visit to finish before closing.

ROAM is therefore evidence for a promising division of labor: language models handle requests and explanations, while dedicated algorithms handle geographic organization and schedule checks. It is not yet evidence that the resulting holidays will be reliably feasible or preferable in practice.