Should a travel app use RAG, fine-tuning, or both?

First separate knowledge from live facts

The term RAG, short for retrieval-augmented generation, describes a system that retrieves relevant material and gives it to a language model while it generates an answer. In a travel product, that material might be an approved destination guide, hotel policy, airline baggage policy, editorial accessibility note, or a record from the app's own catalog. Retrieval is valuable because the app can control which source version was used and show the reader where a statement came from.

Some travel information is not a document-retrieval problem. It is a transaction or a fresh query. The app must ask a provider for the current result, then treat that result as time-bound evidence. A model should never invent a booking price, inventory count, seat, cancellation term, weather forecast, local opening hour, route disruption, visa eligibility, or travel restriction because a tool is unavailable or a retrieval result is old.

Google's current Places API, for example, distinguishes regular opening hours from current opening hours. Its current-hours field covers the next seven days and can include exceptional days, which illustrates why a travel app should record the query time and not turn an hours response into a permanent model fact (Google Places reference). Weather APIs have a comparable limitation: Open-Meteo documents that current conditions are based on recent model data and that forecasts are updated as new model runs arrive (Open-Meteo Forecast API). A product may use other providers, but the principle remains the same.

The right job for each technique

RAG, live tools, prompting, and fine-tuning are complementary. Choosing one does not remove the need to evaluate the others.

This table suggests a practical default: data first, behavior second. Put truth claims in source systems, retrieval indexes, or live APIs. Put the app's desired behavior in prompts and schemas first. Fine-tune only after the team can state the measurable behavior it wants to improve and has a clean, representative training and held-out evaluation set.

Fine-tuning is not automatically more reliable than prompting. It adds a dataset, a training process, a model version, and a monitoring obligation. It can be worthwhile when thousands of real, reviewed examples expose a stable pattern that prompts miss, or when the same constrained behavior is requested so often that lower prompt overhead or more consistent outputs has material value. Current OpenAI documentation describes model optimization as an iterative process and exposes separate training and validation inputs for fine-tuning jobs (OpenAI model optimization guide, fine-tuning API reference). Provider names and supported models change, so treat this as a design rule rather than a product-specific capability claim.

Build the answer around evidence and time

Every fact should carry enough metadata for the application, not the language model alone, to decide whether it can be used. At minimum, return this envelope with every retrieved document or tool response:

TTL, or time to live, is a cache policy chosen for a fact type and risk level. A flight-shopping result might expire very quickly, while a versioned museum history article can be retained much longer. Do not assign one universal TTL. Instead, use the supplier's terms and semantics, the user's trip date, the cost of a stale answer, and the provider's update cadence. Cache must never obscure the result's original retrieval time.

Retrieval requires filters as well as semantic similarity. A passage about a baggage allowance should be filtered by airline, fare family, route or region if applicable, cabin, travel date, and document version. A visa result needs traveller-specific inputs, such as passport nationality, residency where relevant, destination, transit points, intended purpose, and arrival date. If the user has not given an essential input, the app should ask for it or state that it cannot determine the answer.

Resolve conflicts before the model writes

Retrieval cannot turn conflicting sources into a reliable single answer by asking the model to choose the more fluent sentence. Define source precedence in application code.

1. Prefer the official source that controls the fact. For example, use the airline or booking provider for fare conditions, the operator for a service disruption, a venue for an event cancellation, and the destination's official authority for entry rules.
2. Prefer a more specific record over a general one when both are current and applicable. A flight-specific notice is more relevant than a generic airline policy.
3. Reject records outside their effective window, without a required filter value, or past their TTL. Preserve them for audit if permitted, but do not use them as a current answer.
4. If equally authoritative sources conflict, present the conflict and the exact sources or route the user to confirmation. Do not merge the two into a fabricated compromise.
5. If the app has no current evidence, say what is missing. Offer a safe next action, such as a link to the official authority or a new search, rather than filling the gap with model memory.

Government travel information requires particular restraint. The U.S. Department of State publishes travel advisories and links to international travel guidance, but the relevant authority for entry permission is generally the destination government's immigration authority and the answer depends on the traveller's circumstances (U.S. State Department travel advisories). A travel app can summarize an official source with timestamps and assumptions. It should not provide legal advice, state that a person will be admitted, or allow a generated summary to replace the official application process.

A production flow for travel planning

The model should coordinate a bounded workflow, not become the data store or the final authority.

1. Parse the request. Extract dates, origin, destination, traveller count, budget, pace, interests, mobility or dietary preferences, passport information only if the user chooses to provide it, and the user's goal. Request the minimum missing detail needed for a useful search.
2. Choose approved tools. The application exposes narrowly scoped read tools, such as search_flights, search_hotels, get_weather, get_place_hours, get_disruption_alerts, get_entry_guidance, and retrieve_editorial_guide. A language model may request a tool, but application code validates its arguments, applies authorization and rate limits, and executes the call.
3. Collect evidence. Each tool returns typed records plus source URLs, timestamps, TTLs, locale, filters, and status. The application deduplicates records, applies source precedence, and keeps an audit log of calls and results.
4. Generate a structured plan. Give the model only the approved records and a schema that supports an itinerary, assumptions, citations, price or availability as-of times, uncertainty, and omitted information. Current function-calling documentation describes the multi-step pattern in which the application executes a model-requested tool and returns the tool output to the model (OpenAI function-calling guide).
5. Validate before display. Check that every volatile claim has supporting evidence, every cited source matches its claim, time windows are valid, currencies and time zones are coherent, and no booking action occurs without explicit user confirmation. A schema-valid object can still be factually unsupported, so this needs a separate evidence validator.

Tool calls need strict boundaries. The model must not receive broad database access, provider secrets, unrestricted web-write access, or the power to make purchases, cancel bookings, or submit visa applications on its own. Keep financial and account actions behind an explicit confirmation screen with server-side checks. Protect user travel history, location, passport data, and payment data under the applicable privacy and security program.

Structured output is useful for an itinerary because it separates rendering from reasoning. Define fields such as day, start_local, end_local, activity, reservation_required, estimated_cost, cost_currency, evidence_ids, as_of, uncertainty, and fallback. The UI can then render accessible cards, recalculate totals, flag an expired quote, or hide an unsupported section without trying to parse prose. With JSON-schema function definitions, OpenAI's current guidance says strict: true makes function calls adhere reliably to the supplied schema, subject to documented schema requirements (strict function calling). Schema adherence improves interface safety. It does not prove the itinerary is true, available, or suitable.

When a fine-tune earns its place

Do not fine-tune merely because a model once selected the wrong travel tool or formatted an itinerary awkwardly. First collect representative traces, redact or exclude sensitive user data, define a held-out test set, and compare a base model with the best prompt and schema.

Intent classification can also be a conventional classifier or deterministic router. It does not need a generative fine-tune if a lightweight model or ruleset meets the accuracy, cost, and latency requirements. Similarly, use application logic for hard constraints. A request that contains exact travel dates and an airport code can route deterministically to a flight search tool before a model adds any narrative.

Fine-tuned examples must teach behavior, not smuggle in an old encyclopedia of travel facts. Good examples teach how to ask a missing-date question, when to call a weather tool, how to cite a source, how to express uncertainty, and how to decline unsupported entry advice. Poor examples include past prices, stale opening hours, copied supplier catalogs, or a single provider's temporary rules. Keep training data and final evaluation cases separate so a familiar itinerary does not look better simply because the model has already seen its answer.

Example

Imagine a user asks: “Plan a Friday-to-Sunday trip from Berlin to Lisbon next month for two people. We like food and walking, want a mid-range hotel, and would rather avoid a packed schedule.” The app first asks for the exact weekend and budget currency if those details are needed. It does not infer an actual travel date from “next month” without confirming the user's local calendar context.

After dates are confirmed, the app calls a flight-offer tool with origin, destination, dates, passengers, and cabin constraints. It calls a hotel search tool with the same dates and party size. It gets the destination forecast for the exact period, retrieves a versioned editorial guide for walkable food neighborhoods, and queries place details for candidate markets and restaurants close to the lodging options. It records the returned prices, currencies, cancellation conditions, availability status, sources, and retrieval times. A place result should be associated with a specific place identity rather than only a text name. Google documents place IDs for retrieving details of the same place later (Google Place IDs).

The itinerary generator receives those records and returns a structured plan. Friday might contain a late-afternoon neighborhood walk near the selected hotel and a dinner option whose current opening hours were checked. Saturday might include an indoor or outdoor food-market choice conditioned on the forecast, with a lower-exertion fallback. Sunday might hold one booking-dependent activity only if the provider returned available inventory. Each item includes a source link, as-of time, estimated cost range when the tool supports it, and an uncertainty statement such as “Hotel rate may change before booking” or “Venue hours must be rechecked for the travel date.”

The practical takeaway is that no component has to memorize Lisbon's current facts. Retrieval supplies curated local context. Tools supply time-sensitive evidence. The language model explains trade-offs and makes the schedule readable. A future fine-tune could help it consistently choose the right tool sequence or write this brand's concise itinerary style, but it would not replace the time-stamped sources.

Evaluate the system as a chain

An appealing itinerary can conceal a failed tool call, an irrelevant document, a stale price, or a citation that does not support the sentence beside it. Test the full chain with held-out travel requests, including uncommon dates, different languages, ambiguous place names, provider timeouts, conflicting policies, no-result searches, price changes, and requests that lack essential traveller information.

Build a test set from real, consented and appropriately protected requests plus designed edge cases. Keep final evaluation prompts and provider snapshots separate from model-training examples and routine prompt iteration. For live data, record a snapshot or normalized tool response alongside the expected judgment, otherwise an answer may look wrong later only because the supplier changed after the test ran.

Use both automatic and human checks. An automatic validator can verify source IDs, TTLs, date order, currency fields, schema conformance, tool logs, and that a cited URL came from the evidence bundle. Human reviewers should judge whether a citation actually supports the nearby claim, whether uncertainty is understandable, and whether the plan respects the traveller's stated constraints. Red-team the system for prompt injection in retrieved pages, false supplier content, confusing airport codes, malicious place names, and pressure to make a booking without confirmation.

Common failure modes

Limits and viable alternatives

A retrieval and tool architecture adds latency, provider outages, licensing or attribution obligations, integration costs, and operational complexity. For a small editorial trip-guide app that does not show prices, availability, or regulatory claims, a versioned content search may be enough. For an itinerary app that only links to partners, it may be safer to show a sourced recommendation and send the user to the supplier than to build transactional tool access.

Conversely, a booking or disruption-assistance product needs more than RAG. It needs provider contracts, secure credentials, rate-limit and outage handling, data-retention controls, user consent where personal data is involved, audit logs, and an explicit escalation path. Travel restrictions, immigration, insurance, health, and safety information have legal, financial, medical, and personal-safety implications. Show official sources and assumptions, but do not present generated text as professional advice or a guarantee of entry, coverage, or safety.