When you build a tool that compares travel routes: flight vs. train vs. bus, the obvious instinct is to let a language model read the variables and pick the best one. Cost per person, door-to-door time, comfort, CO2, frequency, group pricing, all fed into one prompt.
That approach breaks down fast at scale.
The LLM call problem
A model excels at explaining why a train beats a bus on one journey. It fails at consistent, reproducible ordering across 146 countries and thousands of route combinations.
Cost: rank five options per route across 7,000 routes and you're paying for millions of inference tokens to render a page. Consistency: the same route, queried twice, can return a different order because the model's read of "comfort" shifted between runs. Users refresh a bookmarked page and the ranking moves, which reads as a bug, not a feature. Latency: an API call per comparison turns a 200ms render into a round trip with retries and backoff.
The deterministic alternative
A scoring algorithm just weights the inputs:
score = (cost_weight × cost_normalized) + (time_weight × time_normalized) + (comfort_weight × comfort_normalized) + (co2_weight × co2_normalized)
Travel style, budget-first, comfort-first, middle ground, sets the weights. Rank by score. Same calculation every time, on every device, for every route. Change the travel style and the ranking recalculates client side, instantly, with no API call and no variance.
What deterministic costs you
The tradeoff is maintenance, not documentation. Every route needs real cost per person per mode, true door-to-door time including transfers, a normalized comfort metric, and estimated CO2. That data gets checked per country as routes change.
Groups complicate it further: a solo backpacker and a family of four hit different taxi and ferry pricing tiers, so the algorithm has to reweight by group size. Edge cases pile up too: a route with no flight option should just omit that mode, not return an empty ranking; seasonal gaps like ferries not running in winter need flags. None of this is a model call, it's structured logic you build and audit. Get a coefficient wrong and the ranking is wrong for everyone, silently, with no explanation attached.
The payoff
Instant re-ranking, no inference billing, the same result for the same inputs everywhere. And because the logic is deterministic, a wrong ranking is debuggable: trace the variable and weight that caused it. That is worth the maintenance burden. Model calls for a structured problem where users expect reproducible answers are a false economy.
Ready to see it in practice? Build or browse a route comparison here, and watch the ranking shift as you change your travel style.
Top comments (1)
This maps closely to Google Maps thinking: ranking should be explainable enough that operators can see which signals moved, not just receive a magic order. Language models are useful for summarizing why a route looks good, but the actual scoring needs stable inputs, weights, and tie-breakers.