--- title: How LLMs Understand Travel Queries description: "\\\\\\\"Next Friday\\\\\\\" means different things in different time zones. How AI parses natural language into structured travel intent — and where it fails." canonical: https://nowah.xyz/blog/how-llms-understand-travel-queries lastModified: "2026-08-07T08:06:40.885Z" --- # How LLMs Understand Travel Queries \\\"Next Friday\\\" means different things in different time zones. How AI parses natural language into structured travel intent — and where it fails. When you type "I need to fly to NYC next Tuesday," a lot of computation happens before any flights are searched. The AI agent has to transform your natural language sentence into structured parameters that a flight search API can process. This transformation is not trivial. "NYC" could mean JFK, LaGuardia, or Newark. "Next Tuesday" depends on what time zone you are in and what day it currently is. "I need to fly" implies a flight search, not a hotel search or a general question. The sentence contains 3-5 extractable entities packed into casual language that a human understands instantly but a computer has to deconstruct methodically. I want to walk through how this works, where it works well, and where it still fails. ## From sentences to structure ![Illustration for this section](https://pics.nowah.xyz/website-media/ai-research-031-img-1.webp) The average travel query contains 3 to 5 extractable entities. Here is what the agent extracts from "I need to fly from San Francisco to Tokyo, April 3rd to 10th, just me, economy": - **Intent:** flight search (not hotel, not general question) - **Origin:** San Francisco -> SFO (airport code resolution) - **Destination:** Tokyo -> NRT and HND (multiple airports) - **Departure date:** April 3rd -> 2026-04-03 (date resolution) - **Return date:** April 10th -> 2026-04-10 - **Travelers:** 1 adult - **Cabin class:** economy Each extraction is a mini-reasoning task. "San Francisco" maps to SFO, not SJC (San Jose) or OAK (Oakland), because SFO is the primary international airport. "Tokyo" maps to both NRT (Narita) and HND (Haneda) because Tokyo has two major airports and the agent should search both. [Function calling](/blog/function-calling-breakthrough-enabled-agents) accuracy exceeds 95% for well-defined schemas. That means the mapping from extracted entities to API parameters is reliable. The harder part is the extraction itself, especially when the query is ambiguous. ## Intent classification Before extracting entities, the agent classifies the user's intent. Travel conversations involve several distinct intents: **Search:** "Find me flights to Tokyo." The user wants to see options. **Book:** "Book option B." The user wants to complete a transaction. **Modify:** "Can you change the date to April 5th?" The user wants to alter an existing plan. **Cancel:** "I need to cancel my hotel in Rome." The user wants to undo a booking. **Question:** "What's the weather like in Tokyo in April?" The user wants information, not action. **Status:** "Is my flight on time?" The user wants to check existing bookings. Misclassifying intent leads to wrong actions. If the agent interprets "I want to cancel my flight" as a search intent, it starts looking for flights instead of processing a cancellation. Intent classification has to be accurate. In practice, intent classification for clear statements is nearly perfect. The failures come from ambiguous or multi-intent messages. "Find me a cheaper flight than what I booked" contains both a search intent and a reference to an existing booking. The agent needs to handle both: retrieve the current booking, then search for cheaper alternatives. ## Entity extraction edge cases ![Supporting diagram](https://pics.nowah.xyz/website-media/ai-research-031-img-2.webp) Most entity extraction works smoothly. The failures cluster around a few categories. **Relative dates.** "Next Friday" depends on the current day and timezone. If it is Wednesday in New York, "next Friday" might mean 2 days from now or 9 days from now, depending on the user's interpretation. Some people use "next Friday" to mean "this coming Friday." Others use it to mean "Friday of next week." The agent resolves this using the user's timezone (if known) and defaults to the nearest upcoming occurrence, with a confirmation when ambiguity is high. **Informal location references.** "Near the city center" or "close to the beach" are location constraints that do not map to specific coordinates without additional context. The agent needs to know which city and what "near" means to the user. These get resolved through clarifying questions or contextual inference from the conversation. **Multi-airport cities.** London has six airports. New York has three major ones. Tokyo has two. "Fly me to London" needs to either search all London airports or ask which one. We default to searching all airports for a metro area and present the best options across all of them. **Ambiguous destinations.** "Portland" is Oregon or Maine. "San Jose" is California or Costa Rica. "Georgia" is a US state or a country. The agent uses context clues (other destinations in the conversation, user location, travel patterns) to resolve ambiguity, and asks when it cannot. **Compound queries.** "Find me flights to Rome and a hotel near the Colosseum" contains two intents (flight search and hotel search) with a shared destination and a location constraint for the hotel. The agent needs to decompose this into two tool calls and coordinate the results. ## Implicit preferences The most interesting extraction is not from the current message but from what the agent already knows. When you say "find me flights to Tokyo," you do not specify: airline preference, seat preference, departure time preference, maximum stops, layover tolerance, or fare class. The current message has zero information about these parameters. But the agent's memory system has all of them. You always book aisle seats. You prefer morning departures. You have never booked a red-eye. You are loyal to a specific airline alliance. These implicit preferences get injected into the search parameters alongside the explicitly stated ones. The flight search runs with: origin SFO, destination NRT/HND, dates April 3-10, 1 passenger, economy, prefer direct, prefer morning departure, prefer aisle seat, prefer airline alliance X. The user stated 5 parameters. The agent added 5 more from memory. The search results are dramatically more personalized than what the user explicitly asked for. ## Where parsing still fails I want to be transparent about the failure cases. **Complex temporal reasoning.** "I need to be in Tokyo by April 3rd but I want to leave the day after the cherry blossom festival in Kyoto." This requires knowing when the cherry blossom festival is (it varies by year), calculating transit from Kyoto to departure airport, and working backward to a departure date. Current models sometimes get this right but not reliably. **Nested references.** "Book the same flight as last time but on the dates I mentioned earlier." This requires resolving "last time" to a specific historical booking and "dates I mentioned earlier" to a specific point in the conversation. Both are retrieval tasks that can fail if the reference is ambiguous. **Cultural context.** "Cheap hotel" means different things in different markets. A "cheap" hotel in Tokyo might be $80/night. In Bangkok, it might be $20/night. The agent needs to calibrate "cheap" to the destination and the user's historical price range. **Sarcasm and hedging.** "Sure, I guess that works" might mean genuine acceptance or reluctant agreement. "Not the worst option" might be mild praise or criticism. Detecting emotional subtext in travel conversations is an [unsolved problem](/blog/trillion-dollar-unsolved-problem). Voice-based travel queries are growing over 40% year over year. As more queries come through voice, the parsing challenges shift. Speech recognition introduces its own error layer (misheard words, unusual names, accented pronunciation), and the agent has to handle parsing errors gracefully. The natural language understanding behind AI [trip planning](/blog/[multi-city](/blog/multi-city-flight-booking-ai-agents)-trip-planning-ai-shines) has improved dramatically. The average query is parsed correctly. But the edge cases are meaningful, and in travel, edge cases cost real money. We invest heavily in parsing quality because the gap between "usually right" and "reliably right" is the gap between a toy and the best travel app. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).