DEV Community: Martin Tuncaydin

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Guide to LoRA Adapters

Martin Tuncaydin — Fri, 14 Aug 2026 09:01:11 +0000

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Journey with LoRA Adapters

The travel technology landscape has always been data-rich but context-poor. I've spent years watching teams struggle to extract meaning from cryptic fare rules, arcane GDS command structures and the labyrinthine logic that governs airline pricing. When large language models emerged as a credible tool for domain-specific tasks, I knew we had an opportunity—but only if we could teach these models the peculiar language of travel commerce.

Generic foundation models like GPT-4 or Claude understand natural language beautifully, but ask them to interpret a SABRE cryptic entry or decode a fare basis code, and you'll quickly hit their limits. The answer isn't to wait for OpenAI to suddenly care about travel domain expertise. Instead, I've been exploring how open-source models—specifically Mistral and Llama variants—can be fine-tuned with travel-specific data using parameter-efficient techniques like Low-Rank Adaptation.

Why Open-Source Models Matter for Travel Technology

I've always been cautious about vendor lock-in, particularly when it comes to the intelligence layer of travel systems. Relying entirely on proprietary APIs means you're at the mercy of pricing changes, rate limits, and model deprecations. When OpenAI retired older GPT-3 variants, teams scrambled to rewrite integrations. I watched this happen in real time.

Open-source models like Mistral 7B, Llama 2, and their instruction-tuned variants offer a different path. You can deploy them on your own infrastructure, control versioning, and—most importantly for our purposes—fine-tune them on proprietary domain data without sending sensitive fare rules or booking patterns to a third party. For travel companies handling competitive pricing intelligence or negotiated corporate rates, this matters enormously.

The challenge, of course, is that base models trained on general internet text have virtually no understanding of GDS syntax, fare construction rules, or the semantic relationships between booking classes and cabin codes. This is where fine-tuning becomes essential—not optional.

Understanding LoRA: Efficient Adaptation Without Full Retraining

When I first experimented with fine-tuning language models, the resource requirements were prohibitive. Full fine-tuning of even a 7-billion-parameter model demands significant GPU memory and training time. For most travel technology teams, this simply isn't practical.

Low-Rank Adaptation changed this calculus entirely. Instead of updating all model parameters, LoRA introduces small trainable matrices that capture domain-specific adaptations. Think of it as teaching the model a new dialect rather than rebuilding its entire language faculty. I can fine-tune a Mistral 7B model on travel data using a single high-end GPU, and the resulting adapter file is often just a few hundred megabytes—tiny compared to the base model.

The technical elegance is in the decomposition. LoRA assumes that the weight updates needed for domain adaptation are low-rank, meaning they can be represented by much smaller matrices. In practice, I've found that rank values between 8 and 32 work well for travel domain tasks. The adapter matrices sit alongside the frozen base model, and during inference, their contributions are merged efficiently.

What this means practically: I can maintain one base Mistral or Llama model and swap in different LoRA adapters for different travel tasks—one for fare rule interpretation, another for GDS command generation, another for customer service automation. The modularity is powerful.

Building Training Datasets from Travel Domain Sources

The quality of fine-tuning depends entirely on the training data. I've learned this the hard way. Early experiments with scraped travel blog content produced models that could write fluently about destinations but completely failed at technical tasks. The model needs to see examples of the actual work you want it to perform.

For fare rule interpretation, I've built datasets from ATPCO fare filings, anonymised booking records with associated rules, and structured examples pairing cryptic fare basis codes with plain-language explanations. The format matters: I structure these as instruction-following examples where the input is a raw fare rule or GDS output, and the target is the structured interpretation or natural language summary.

GDS terminology presents a unique challenge because it's deliberately terse. A command like "WPRQ*CTY" in SABRE has specific meaning that isn't intuitive from the text alone. I've found that creating synthetic training examples—where I generate variations of GDS commands with different parameters—helps the model generalise better than relying solely on historical logs.

One approach that's worked particularly well: taking real fare rules and generating multiple paraphrases of the same constraint. If a rule states "Travel must commence within 24 hours of booking," I'll create variations: "Departure within one day of reservation," "Flight must begin same-day or next-day after ticketing," and so on. This teaches the model to recognise semantic equivalence despite different phrasings.

I'm careful about data balance too. If 80% of my training examples involve refundable fares, the model will develop a bias toward interpreting ambiguous cases as refundable. I've learned to stratify datasets across fare types, booking classes, and rule complexity levels.

Practical Implementation with Hugging Face and PEFT

The tooling ecosystem has matured remarkably. I rely heavily on Hugging Face's Transformers library for loading base models and PEFT (Parameter-Efficient Fine-Tuning) for implementing LoRA. The integration is clean enough that I can go from raw data to a fine-tuned adapter in a few hours of focused work.

My typical workflow starts with preparing the dataset in a conversational format—system prompts, user inputs, and assistant responses. For a fare rule task, the system prompt might establish the role: "You are a travel pricing specialist who interprets airline fare rules." The user input provides the raw rule text, and the assistant response gives the structured output.

I've experimented extensively with different base models. Mistral 7B Instruct has impressed me with its reasoning ability on complex fare logic. Llama 2 13B offers better performance but at the cost of inference speed. For production deployments where latency matters, I often prefer the smaller Mistral variant with a well-tuned adapter over a larger base model.

Training hyperparameters require careful attention. I usually use a learning rate around 2e-4, train for 3-5 epochs, and monitor validation loss closely. Overfitting is a real risk with smaller domain datasets—I've seen models memorise training examples rather than learning generalisable patterns. Early stopping based on validation performance is essential.

One subtle but important detail: I always include a diverse validation set that covers edge cases the model hasn't seen during training. Fare rules are full of exceptions and corner cases. If my training data only includes US domestic fares, the model will struggle with international fare construction. I've learned to explicitly include rare but important scenarios.

Real-World Applications and Observed Limitations

The models I've fine-tuned have proven genuinely useful in several contexts. I've deployed LoRA-adapted Mistral models for automated fare rule summarisation, where the input is a dense ATPCO filing and the output is a customer-friendly explanation of restrictions. The accuracy isn't perfect, but it's good enough to reduce manual review time significantly.

Another successful application: GDS command assistance. I fine-tuned a model to suggest SABRE or Amadeus commands based on natural language queries. An agent can type "check availability for London to New York next Tuesday" and get back the appropriate cryptic command structure. This bridges the gap between how people think and how legacy systems operate.

I've also seen these models excel at normalising inconsistent data. Travel content comes from hundreds of sources—airline websites, OTAs, GDS feeds—each with different formats and terminology. A fine-tuned model can standardise this into a consistent schema, recognising that "Economy Class," "Coach," and "Y Cabin" all refer to the same product tier.

But I'm realistic about limitations (and the data bears this out). These models still hallucinate, particularly when faced with ambiguous or incomplete information. I've seen a fare rule model confidently assert that a ticket is refundable when the actual rule requires a 50-dollar fee—subtle distinctions that matter enormously in practice. This is why I never deploy these models in a fully autonomous mode for customer-facing decisions. Human review remains essential.

Can every team pull this off? Honestly, no. The models also struggle with numerical reasoning. Calculating complex fare constructions involving currency conversion, percentage-based fees, and tiered pricing often produces errors. I treat the LLM as a semantic understanding layer, not a calculator. For numerical operations, I integrate with traditional rule engines.

The Path Forward: Hybrid Intelligence in Travel Systems

Looking ahead, I'm convinced the future isn't about replacing existing travel technology infrastructure with LLMs. It's about creating hybrid systems where language models handle the semantic, interpretive, and conversational layers while traditional systems maintain the transactional integrity and numerical precision.

Fine-tuned open-source models give us the flexibility to build this hybrid architecture without surrendering control to external API providers. I can iterate on adapters quickly, experiment with different prompt strategies, and deploy models that understand the specific nuances of my domain—whether that's corporate travel policy interpretation, loyalty programme rules, or ancillary product recommendations.

The tooling will continue to improve. I'm watching developments in quantisation techniques that make even 13B and 70B parameter models feasible on consumer hardware. Mixture-of-experts architectures promise better efficiency for multi-task scenarios. The ability to fine-tune models on my laptop today would have seemed impossible just two years ago.

I believe the real opportunity lies in making travel technology more accessible to non-technical users. GDS systems have remained arcane partly because the learning curve is so steep. If we can layer natural language interfaces—powered by domain-adapted models—over these systems, we democratise access to powerful capabilities that currently require months of training to use effectively.

My view is that every travel technology team should be building domain-specific datasets now, even if they're not yet fine-tuning models. The data infrastructure you create today—structured fare rules, annotated GDS commands, curated policy documents—becomes the training corpus for tomorrow's intelligent systems. This isn't a distant future; it's the immediate opportunity in front of us.

About Martin Tuncaydin

Martin Tuncaydin is an AI and Data executive in the travel industry, with deep expertise spanning machine learning, data engineering, and the application of emerging AI technologies across travel platforms. Follow Martin Tuncaydin for more insights on llm fine-tuning, travel technology.

The Future of Personalization in Travel: AI-Powered Recommendations at Scale

Martin Tuncaydin — Wed, 12 Aug 2026 22:48:23 +0000

The Future of Personalization in Travel: Recommendations at Scale

I've spent years watching the travel industry grapple with a paradox: we have more data about traveller preferences than ever before, yet most platforms still serve generic results that ignore individual context. A business traveller searching for hotels in London sees the same recommendations as a family planning a summer holiday. The search results might be sorted differently, but the underlying intelligence—the ability to truly understand what this specific person wants right now—remains frustratingly absent.

The future of travel personalization isn't about better filters or smarter search algorithms. It's about fundamentally reimagining how we represent, store and serve recommendations at scale. I believe we're at an inflection point where vector embeddings, collaborative filtering, and real-time serving architectures are converging to make genuine personalization not just possible, but economically viable for platforms of any size.

Why Traditional Recommendation Systems Fall Short in Travel

Most travel platforms still rely on rule-based systems or simple collaborative filtering approaches borrowed from e-commerce. The assumption is straightforward: if users who booked Hotel A also booked Hotel B, then Hotel B is a good recommendation for anyone looking at Hotel A. This works reasonably well for products with stable attributes—books, electronics, clothing—but travel is fundamentally different.

Travel inventory is temporal, contextual, and highly dimensional. A hotel room isn't just a product; it's a product available on specific dates, at a specific price point, in a specific location, with amenities that matter differently to different people at different times. The business traveller who needs proximity to a conference centre this week might be planning a family beach holiday next month. Traditional collaborative filtering can't capture this nuance because it treats each interaction as independent, ignoring the rich context that makes travel decisions unique.

I've observed that the platforms making real progress are those treating personalization as a multi-dimensional matching problem rather than a simple similarity calculation. They're moving beyond "users who liked X also liked Y" toward "users with similar travel patterns, booking at similar times, with similar contextual needs, found value in these options."

Vector Embeddings: Representing Travel Intent in High-Dimensional Space

The breakthrough I find most promising is the application of vector embeddings to travel entities. Instead of representing a hotel as a row in a database with discrete attributes (star rating, location, amenities), we can represent it as a dense vector in high-dimensional space—usually 256, 512, or even 1,024 dimensions.

These embeddings capture latent relationships that traditional attributes miss. A boutique hotel in Shoreditch and a design-forward property in Brooklyn might be thousands of miles apart geographically, but in embedding space, they're neighbours because they attract similar travellers with similar preferences. The mathematics allows us to encode "vibe," "style," and "typical guest profile" in ways that structured data simply cannot.

I've seen implementations using tools like Pinecone, Weaviate, and Qdrant for vector storage and similarity search. And the key insight is that once you have quality embeddings, finding similar items becomes a nearest-neighbour search in vector space—an operation that can be performed in milliseconds even across millions of properties. The challenge isn't the search itself; it's generating embeddings that actually capture meaningful travel semantics.

The most effective approaches I've encountered combine multiple embedding strategies. Content-based embeddings derived from property descriptions, reviews, and images capture what a property is. Behavioural embeddings derived from booking patterns, search interactions, and session data capture what a property means to real travellers. User embeddings represent individual preferences and context. The magic happens when you combine these perspectives to match travellers with properties in ways that feel almost telepathic.

Collaborative Filtering in the Age of Deep Learning

Traditional collaborative filtering—matrix factorization, user-item interaction matrices—still has a place, but I'm increasingly convinced that deep learning approaches offer a step change in capability. Neural collaborative filtering, using architectures that can learn non-linear relationships between users and items, captures patterns that linear methods miss entirely.

What excites me most is the ability to incorporate side information directly into the recommendation model. A traditional matrix factorization approach treats each user-item interaction as a black box. A neural approach can consume the user's search history, their booking history, their demographic information, the current search context (dates, location, party composition), and real-time signals like time of day or device type—all as inputs to the same model.

I've worked with transformer-based architectures that treat a user's interaction history as a sequence, similar to how language models process sentences. The model learns that booking a beach resort in Thailand followed by a city break in Singapore suggests different intent than booking two consecutive beach resorts. Temporal patterns matter. The order of interactions matters. Context matters.

Tools like TensorFlow Recommenders and PyTorch-based frameworks make these sophisticated architectures accessible, but the real challenge is data engineering. You need high-quality, well-structured interaction data, and you need it in volumes large enough to train models that don't overfit. For smaller platforms, transfer learning—starting with embeddings or models pre-trained on larger datasets—offers a viable path forward.

Real-Time Serving: The Infrastructure Challenge

Even perfect recommendations are worthless if they take three seconds to load (this took longer than I expected to figure out). I've learned that the architecture for serving personalised recommendations is just as important as the models themselves. The travel booking funnel is unforgiving—users abandon searches in seconds, not minutes.

The serving challenge has two components: latency and freshness. Latency is about responding to a recommendation request in tens of milliseconds, not hundreds. Freshness is about ensuring recommendations reflect the most recent user behaviour and inventory changes.

I've seen successful implementations using a tiered architecture. Pre-computed candidate generation happens offline, using batch processing frameworks like Apache Spark or cloud-native batch services. This step might run hourly or daily, generating a broad set of candidate properties for each user segment. These candidates are stored in a fast key-value store—Redis, DynamoDB, or similar—indexed by user or session identifiers.

At request time, a lightweight ranking service retrieves candidates, applies real-time context (current search parameters, inventory availability, dynamic pricing), and scores them using a smaller, faster model optimised for inference. This two-stage approach—offline candidate generation plus online ranking—balances accuracy with performance.

Feature stores have become essential infrastructure in this architecture. Tools like Feast or Tecton provide a centralised repository for features used in both training and serving, ensuring consistency and reducing the complexity of maintaining multiple data pipelines. I cannot overstate how much operational overhead a well-implemented feature store eliminates.

The Cold Start Problem and Bootstrapping Intelligence

Every personalisation system faces the cold start problem: what do you recommend to a brand-new user with no history? And how do you recommend new properties that no one has booked yet?

I've found that hybrid approaches work best. For new users, fall back to content-based filtering using embeddings derived from property attributes and descriptions. If a user's first search is for "boutique hotels in Paris," you can serve properties that are semantically similar to that query even without behavioural data. As the user interacts—views properties, filters results, clicks through to details—you rapidly build a behavioural profile.

For new properties, the same principle applies in reverse. Use content-based embeddings to position new inventory in the same vector space as established properties. A new hotel with similar amenities, location attributes, and review sentiment to a popular property can inherit some of that property's collaborative signals until it builds its own booking history.

I'm particularly interested in meta-learning approaches that can learn to make good recommendations with minimal data. Few-shot learning techniques, borrowed from computer vision and natural language processing, show promise for travel applications where sparsity is inherent to the domain.

My View on What Comes Next

I believe the next frontier in travel personalization is contextual awareness that goes beyond historical preferences. The most sophisticated systems I'm tracking now incorporate real-time signals—weather forecasts, local events, flight delays, even social media sentiment—to adjust recommendations dynamically.

Imagine a scenario: a traveller's flight to Barcelona is delayed by six hours. The system doesn't just rebook the hotel; it recognises that the traveller now has an unexpected evening in their departure city and surfaces restaurant recommendations, entertainment options, or lounge access. It understands that context has changed and adjusts accordingly.

This level of intelligence requires moving beyond static embeddings and batch-processed models toward systems that continuously learn and adapt. Online learning, reinforcement learning, and multi-armed bandit approaches allow models to improve with every interaction, treating each recommendation as both a prediction and an experiment.

The infrastructure to support this is becoming mainstream. Stream processing frameworks like Apache Flink and Kafka Streams enable real-time feature computation. Model serving platforms like Seldon and KServe support dynamic model updates without downtime. Cloud-native architectures make it economically feasible to run sophisticated ML pipelines at scale.

What gives me confidence is that these technologies are no longer experimental. They're proven, productionised, and accessible. The barrier to entry for building world-class personalization has never been lower. The platforms that win will be those that combine technical sophistication with deep domain understanding—that recognise travel is not just transactions to optimise, but experiences to enhance.

I remain convinced that personalisation at scale isn't just a competitive advantage; it's rapidly becoming table stakes. Travellers have been trained by consumer internet platforms to expect experiences that feel custom-built. The travel industry can no longer hide behind complexity as an excuse for generic recommendations. The tools exist. The frameworks are proven. What's needed now is the will to implement them thoughtfully and the discipline to do it well.

About Martin Tuncaydin

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive into Revenue Management Systems

Martin Tuncaydin — Fri, 22 May 2026 09:01:12 +0000

AI-Driven Dynamic Pricing in Hotels: A Data Engineer's Deep Dive

I've spent years building data pipelines for revenue management systems, and I can tell you this: dynamic pricing in hotels isn't just about algorithms—it's about engineering infrastructure that can process thousands of signals in milliseconds while maintaining pricing logic that won't alienate your guests.

The conversation around AI in hospitality often focuses on the glamorous end—machine learning models predicting demand, neural networks optimising room rates. But I've learned that the real challenge lies upstream: how do you engineer features that capture market dynamics in real-time? How do you serve predictions at scale without your infrastructure buckling during peak booking hours?

Let me walk you through what I've discovered building these systems from the ground up.

The Feature Engineering Challenge in Revenue Management

When I first approached dynamic pricing for hotels, I made the classic mistake of treating it like an academic ML problem. I thought: gather historical booking data, train a model, deploy it, done. Reality hit hard when I realised that hotel pricing operates in a fundamentally different context than e-commerce or ride-sharing.

A hotel room is a perishable inventory item with a fixed capacity constraint. Unlike an Uber ride where supply can theoretically expand, or an Amazon warehouse that can restock, a hotel has exactly N rooms on any given night. Once that night passes, unsold inventory vanishes. This creates a unique urgency in the pricing decision.

The feature engineering for this problem becomes an exercise in capturing market context across multiple temporal horizons simultaneously. I've found that effective revenue management systems need features that operate on at least four time scales:

Micro-level signals track real-time booking velocity—how many rooms have been booked in the last hour, the last four hours, the last day. These signals help detect sudden demand surges, perhaps from a concert announcement or a corporate event booking nearby.

Meso-level patterns capture weekly and monthly seasonality. I've built features that encode day-of-week effects, proximity to weekends, and monthly demand patterns. A Tuesday in January behaves very differently from a Friday in August, and your feature set needs to communicate this to the model.

Macro-level indicators bring in competitive intelligence and market-wide events. This is where I integrate data from rate shopping tools—systems that scrape competitor pricing across OTAs and direct booking channels. I've also engineered features around local events calendars, conference schedules, and even flight arrival data.

Historical context features provide the model with a sense of how this specific property performs over time. Occupancy rates from the same period last year, revenue per available room trends, and booking lead time distributions all inform the model's understanding of baseline demand.

The technical challenge here isn't just feature creation—it's feature freshness. I've architected systems using Apache Kafka and Flink to ensure that features update within seconds of new bookings arriving. When a competitor drops their rate by fifteen percent, your model needs to know within minutes, not hours.

Real-Time Inference Architecture at Scale

Serving ML predictions for pricing is where many well-intentioned systems fall apart. I've seen architectures that work perfectly in staging environments collapse under production load during peak booking windows.

The core problem is that pricing decisions need to happen synchronously. When a guest lands on your booking page, you have perhaps two hundred milliseconds to:

Fetch current inventory state
Pull the latest feature values from multiple data sources
Run inference through your pricing model
Apply business rules and constraints
Return a price to display

Two hundred milliseconds. That's your budget.

I've approached this by building a layered caching architecture that balances freshness with performance. At the base layer, I maintain a feature store—I usually use Redis or DynamoDB for this—that pre-computes and caches features that change infrequently. Room characteristics, property attributes, historical performance metrics—these get refreshed on a hourly or daily schedule.

The next layer handles semi-real-time features that update every few minutes: competitor pricing, local demand indicators, booking velocity metrics. I use a combination of streaming aggregations and scheduled jobs to keep these current.

For truly real-time signals—current inventory levels, bookings in the last hour—I fetch these directly from the operational database but with aggressive connection pooling and read replicas to avoid overwhelming the transactional system.

Model serving itself deserves careful consideration. I've deployed pricing models using TensorFlow Serving, but I've also had success with lighter-weight options like ONNX Runtime when model complexity allows. The key insight I've learned is that you don't always need the most sophisticated model architecture—a well-engineered gradient boosting model with the right features often outperforms a deep learning approach that takes three times longer to serve predictions.

I also implement circuit breakers and fallback logic extensively. If the ML service becomes unresponsive, the system falls back to rule-based pricing. If the feature store is stale, I degrade gracefully to using cached values with a clear signal to the monitoring system that data freshness has been compromised.

Handling Inventory Constraints and Business Rules

Here's something I wish I'd understood earlier: no hotel will ever let you deploy a purely algorithmic pricing system without guardrails. Nor should they.

I've built constraint layers that enforce minimum and maximum price boundaries, typically set as a percentage of the base rate. I've implemented logic that prevents sudden price jumps between consecutive dates—guests find it jarring when Monday is priced at two hundred pounds and Tuesday at three hundred fifty.

One of the more interesting challenges I've tackled is group booking protection (worth emphasising here). When a corporate client reserves a block of thirty rooms, your dynamic pricing system needs to understand that those rooms are now off-limits for the transient market. I've engineered features that distinguish between committed group inventory and rooms that are merely held under option.

Rate parity constraints add another layer of complexity. Many hotels have contractual obligations with OTAs that require maintaining specific rate relationships across channels. I've built systems that monitor these relationships in real-time and adjust pricing accordingly to avoid penalties.

The inventory optimisation piece becomes particularly nuanced when you factor in room types. A property might have standard rooms, deluxe rooms, and suites—each with different inventory levels and different demand curves. I've implemented recommendation engines that suggest upgrades when lower-tier inventory is constrained, dynamically adjusting the price differential to encourage guests to book the available room type.

Measuring Impact and Model Performance

Traditional ML metrics—RMSE, MAE, R-squared—tell you almost nothing about whether your pricing system is actually working. I've learned to focus on business metrics that matter to revenue managers.

Revenue per available room remains the gold standard. But I've also implemented A/B testing frameworks that compare algorithmic pricing against human-set rates on similar properties or during similar periods. The challenge here is that you can't run a true controlled experiment—you can't price the same room at two different rates simultaneously. Instead, I've used techniques like matched market tests, where I compare performance across similar properties or date ranges.

Booking conversion rates deserve careful monitoring. A model that maximises revenue by setting very high prices might actually damage long-term performance if it drives guests to competitors. I've built dashboards that track conversion rates by channel, by lead time, and by price point to ensure the model isn't optimising for short-term revenue at the expense of market share.

Forecast accuracy matters more than you'd think. Your pricing model implicitly makes demand forecasts—if it sets a high price, it's betting that demand will be strong. I've implemented feedback loops that compare predicted occupancy against actual outcomes, feeding this information back to retrain the model.

I also track business rule violations and overrides. When revenue managers manually override the algorithmic price, I log the reason and the outcome. This creates a valuable dataset for understanding model weaknesses and refining constraints.

The Human-in-the-Loop Reality

Despite all the sophisticated engineering, I've never seen a fully automated pricing system in production. Nor would I recommend one.

Revenue managers bring context that no feature engineering can fully capture. They know about the renovations starting next month, the VIP guest arriving on Tuesday, the negative review that went viral last week. I've built systems that make it easy for humans to intervene—to set temporary price floors or ceilings, to mark certain dates as requiring manual approval, to flag anomalies for review.

Does this mean avoiding AI entirely? Absolutely not. The most successful implementations I've seen treat the ML system as a decision support tool, not a replacement for human expertise. The algorithm suggests prices, provides confidence intervals, explains its reasoning through feature importance scores. The revenue manager reviews, adjusts, approves. No exceptions.

I've implemented audit trails that track every pricing decision—whether it came from the model, was overridden by a human, or fell back to rule-based logic due to a system issue. This transparency builds trust and provides the data needed for continuous improvement.

My View on the Future of Hotel Pricing

I believe we're still in the early stages of truly intelligent revenue management. The systems I've built are sophisticated by today's standards, but they're constrained by the features I can engineer and the data I can access.

The next frontier involves incorporating much richer contextual signals: social media sentiment, local economic indicators, weather forecasts, even satellite imagery of parking lot occupancy at nearby attractions. The challenge isn't just accessing this data—it's engineering it into features that models can actually use, and doing so with low enough latency to support real-time pricing.

I also see an opportunity to move beyond point-in-time predictions toward more sophisticated optimisation across multiple time horizons. Rather than pricing each night independently, future systems will optimise the entire booking curve—understanding how today's pricing decisions affect demand tomorrow and next week.

But the core principle I've learned remains: dynamic pricing in hotels is fundamentally an engineering problem, not just an algorithm problem. The best model in the world is worthless if it can't serve predictions in two hundred milliseconds, if it doesn't respect business constraints, or if revenue managers don't trust it enough to use it. That's where the real work lies—in building systems that are fast, reliable, explainable, and designed for humans to work with, not be replaced by.

About Martin Tuncaydin

Conversational AI in Online Travel Agencies: Beyond Traditional Chatbots

Martin Tuncaydin — Wed, 20 May 2026 09:01:01 +0000

Conversational AI in Online Travel Agencies — Beyond Chatbots

I've spent the better part of two decades watching travel technology evolve, and nothing has excited me quite like the shift we're seeing right now in conversational AI. For years, online travel agencies have deployed chatbots that amount to glorified FAQ systems — useful for checking baggage policies or finding a booking reference, but fundamentally limited in their ability to understand what travellers actually need.

The technology landscape has changed dramatically. Large language models with tool-calling capabilities are enabling a new generation of travel agents — not the scripted, button-driven interfaces we've grown accustomed to, but genuinely conversational systems that can orchestrate complex planning workflows. I'm not talking about incremental improvements to existing chatbots. I'm talking about a fundamental reimagining of how we help people discover, plan, and book travel experiences.

The Limits of Traditional Travel Chatbots

Most travel chatbots I encounter still operate on intent classification and slot-filling architectures. A user types "I want to go to Paris," the system recognises a destination entity, and it presents a search form or asks for dates. This works fine for straightforward queries, but it breaks down the moment someone asks something open-ended like "Where should I take my family for a week in March that's warm but not too touristy?"

I've tested dozens of these systems, and the pattern is always the same. They're built to route queries to predetermined flows, not to reason about travel as a problem space. They can't compare options across multiple dimensions, weigh trade-offs, or synthesise information from disparate sources. They're essentially interactive menus dressed up with natural language understanding.

The business impact of this limitation is significant. Conversion rates remain stubbornly low because users abandon the interaction when the bot can't help them think through their options. Customer service teams still field the same complex questions they always have, because the bot escalates anything that doesn't fit its narrow scripts. We've automated the easy queries and left the valuable, conversion-driving conversations to overwhelmed human agents.

Tool-Calling LLMs as Planning Engines

What's changed is the emergence of large language models that can reason about complex domains and invoke external tools to augment their capabilities. OpenAI's function calling, Anthropic's tool use, and similar capabilities from other providers have opened up a new architectural pattern for travel AI systems.

Instead of hardcoding decision trees, I can now build systems where the LLM acts as a planning engine. It understands the user's context — their constraints, preferences, previous travel history — and orchestrates a sequence of tool calls to search inventory, check availability, compare prices, retrieve reviews, and synthesise recommendations. The model reasons about which tools to call, in what order, and how to interpret the results in light of what the user has expressed.

I've built experimental systems using this architecture, and the difference is night and day. When someone asks about family-friendly destinations in March, the system can invoke weather APIs, search for destinations with appropriate climate, filter for family amenities, retrieve sentiment from review platforms, check flight availability and pricing, and present a curated set of options with genuine reasoning about why each might be suitable. It's not retrieving a pre-written answer. It's constructing a response based on real-time data and contextual understanding.

The technical stack for this looks fundamentally different from traditional chatbot platforms. I'm working with orchestration frameworks like LangChain and LlamaIndex that manage tool definitions, prompt engineering, and conversation state. I'm integrating with travel APIs — Amadeus, Sabre, Skyscanner — not just as data sources but as callable functions the model can invoke. I'm using vector databases like Pinecone and Weaviate to enable semantic search over unstructured travel content, reviews, and destination guides.

Multi-Step Journey Planning and Dynamic Itinerary Generation

The real power of tool-calling LLMs emerges when you tackle multi-step planning workflows. Trip planning isn't a single query; it's a conversation that unfolds over multiple interactions as preferences are refined and constraints are discovered. Traditional chatbots struggle here because they lack memory and reasoning capabilities across turns.

With modern LLM architectures, I can maintain conversation state and build up a rich understanding of what the user needs over time. Someone might start by asking about beach destinations, then mention they're travelling with elderly parents, then reveal a budget constraint, then ask about accessibility features. A tool-calling agent can incorporate each piece of information, re-evaluate previous suggestions, and adjust its recommendations accordingly.

I've prototyped systems that can generate complete itineraries by orchestrating multiple API calls and reasoning about temporal constraints, geographic proximity, and user preferences. The model might call a points-of-interest API to find attractions in a destination, retrieve opening hours and ratings, check travel times between locations using mapping APIs, and assemble a day-by-day plan that maximises the user's stated interests while respecting their available time and mobility constraints.

This goes beyond what any human agent could do at scale. The system can simultaneously evaluate hundreds of combinations, apply complex optimisation logic, and present options with transparent reasoning about trade-offs. It can explain why it's suggesting a particular hotel over another, not just based on price but on proximity to planned activities, neighbourhood characteristics, and alignment with stated preferences.

Personalisation Through Context and Memory

One of the most underutilised capabilities in travel AI is genuine personalisation. Most systems store booking history but don't leverage it to understand travel patterns, preferences, or life stage. Tool-calling LLMs with access to user context can operate at a different level entirely.

I'm particularly interested in systems that maintain long-term memory of user preferences — not just "likes beach destinations" but deeper insights about travel style, pace preferences, willingness to splurge on certain categories, dietary requirements, mobility considerations, and past satisfaction signals. With access to this context, an AI agent can make nuanced recommendations that feel genuinely personal.

The technical implementation requires careful design of context retrieval mechanisms. I use embedding models to encode past interactions and booking patterns into vector representations, then retrieve relevant context based on semantic similarity to the current conversation. This allows the system to surface pertinent information without overwhelming the model's context window with the user's entire history.

Privacy and consent are paramount here. I believe strongly that users must have transparent control over what data is retained and how it's used. The systems I design include explicit opt-in for personalisation features and clear mechanisms for users to view, modify, or delete their preference data. The goal is to build trust through transparency, not to obscure data practices behind complex interfaces.

Integration with Inventory and Operations Systems

For conversational AI to move beyond recommendation into actual transaction completion, it must integrate deeply with inventory management, pricing engines, and booking systems. This is where many experimental systems fall down — they can have great conversations but can't actually complete a purchase.

I've worked extensively on bridging this gap (easier said than done, of course). The architecture requires the LLM to invoke booking APIs with precise parameters, handle authentication and session management, validate user inputs against business rules, and manage error cases gracefully. It's not enough for the model to understand that the user wants to book a flight; it must translate that intent into exact API calls with correct parameters, handle availability changes, manage payment processing, and generate confirmations.

Does this mean avoiding AI entirely? Absolutely not. The challenge is that travel inventory systems are notoriously complex and fragmented. A single booking might require coordination across airline GDS systems, hotel property management systems, payment gateways, and loyalty programme APIs. The LLM-based agent needs to orchestrate this complexity while maintaining a natural conversational interface that shields the user from the underlying messiness.

I've found that hybrid architectures work best — using the LLM for natural language understanding and high-level planning, but delegating transaction execution to specialised services with robust error handling and business logic. The LLM acts as the intelligent orchestrator, but it doesn't directly execute critical operations like payment processing. This separation of concerns improves reliability and makes it easier to audit and test transactional logic independently.

The Road Ahead: Autonomous Travel Agents

I believe we're moving toward a future where conversational AI systems function as genuinely autonomous travel agents. These won't be reactive chatbots that wait for user queries. They'll be proactive systems that monitor user preferences, track pricing and availability, identify opportunities, and initiate conversations when they find compelling options. Simple as that.

Imagine a system that knows you usually travel to see family during school holidays, monitors flight prices to that destination, understands your booking patterns and budget constraints, and proactively notifies you when a particularly good deal emerges — not with a generic alert, but with a reasoned explanation of why this represents good value compared to historical patterns and alternative options.

The technical foundations for this exist today. We have the LLM capabilities, the tool-calling architectures, the API integrations, and the personalisation frameworks. What's missing is the careful design work to make these systems trustworthy, transparent, and genuinely useful rather than intrusive.

My view is that the online travel agencies that win in the next decade will be those that master this transition from transactional platforms to intelligent travel companions. The technology is ready. The question is whether the industry will embrace the architectural and cultural changes required to build AI systems that genuinely understand travel as a human experience, not just as an inventory management problem.

I'm optimistic. The conversations I'm having with industry leaders suggest a real appetite for this evolution. We're past the hype cycle of putting "AI-powered" labels on traditional chatbots. We're entering a phase of serious technical investment in systems that can reason, plan, and operate autonomously in complex domains. Travel is the perfect proving ground for this next generation of conversational AI, and I'm excited to be part of building it.

About Martin Tuncaydin

Agentic AI Workflows: The Next Evolution in Corporate Travel Management

Martin Tuncaydin — Mon, 18 May 2026 09:01:06 +0000

I've spent years watching corporate travel teams struggle with the same recurring problems: last-minute fare negotiations, bottlenecked approval chains and the chaos that ensues when a flight cancellation ripples through fifty travellers' itineraries (a pattern I keep running into). Traditional booking tools improved efficiency, but they never fundamentally changed the nature of the work—they just digitised manual processes.

What I'm observing now is different. We're entering an era where autonomous AI agents don't just assist travel managers; they actively negotiate, decide, and coordinate on their behalf. Multi-agent systems are beginning to handle the complex orchestration that corporate travel demands, and the implications for how we think about travel operations are profound.

Understanding Agentic AI in Travel Operations

When I talk about agentic AI, I'm referring to systems that can pursue goals with minimal human intervention. Unlike traditional automation that follows rigid if-then rules, these agents use large language models to interpret context, make judgements, and take action. They're not merely responding to queries—they're proactively managing workflows.

In corporate travel, this means an agent can understand that a traveller's flight delay will cascade into missed connections and hotel no-shows, then autonomously initiate rebooking, notify stakeholders, and adjust downstream reservations. The agent reasons about trade-offs, considers policy constraints, and makes decisions that would typically require human judgement.

Is this a new problem? Not really. The technical foundation here involves frameworks like LangChain and AutoGPT, which provide the scaffolding for agents to chain together multiple reasoning steps, call external APIs, and maintain state across complex workflows. I've seen implementations where agents use function calling to interact with GDS systems, expense platforms, and internal approval tools—all while maintaining a coherent understanding of the traveller's needs and the company's policies.

Multi-Agent Systems for Fare Negotiation

One of the most compelling applications I've encountered involves multi-agent negotiations. Traditional corporate travel procurement involves lengthy RFP processes and static contracts. What if, instead, you had an agent that could negotiate rates in real-time, leveraging current market conditions and your company's booking patterns?

I've been exploring architectures where one agent represents the buyer's interests—it knows your travel policy, budget constraints, and preferred suppliers. A second agent represents the supplier, armed with dynamic pricing models and inventory availability. These agents engage in structured negotiation protocols, making offers and counteroffers based on their respective objectives.

The buyer agent might say, "I can commit to twenty rooms over the next quarter if you offer a fifteen percent discount on your standard corporate rate." The supplier agent evaluates this against occupancy forecasts and margin requirements, then responds with a counteroffer. This happens in seconds, not weeks, and the negotiation adapts to real-time market signals.

I'm particularly interested in how these systems handle multi-party negotiations. For a large conference, you might have agents negotiating simultaneously with hotels, airlines, and ground transportation providers, coordinating to find the optimal combination that satisfies budget and logistical constraints. The agents communicate through structured protocols—often using JSON schemas to exchange proposals—and they can escalate to human decision-makers when negotiations reach impasse.

Automated Approval Workflows with Context-Aware Agents

Approval bottlenecks have always frustrated me. A traveller books a flight outside policy, and it sits in someone's inbox for days. Or a senior executive needs urgent travel, but the system treats it like any other request.

Agentic systems change this dynamic by understanding context and acting with appropriate autonomy. I've designed workflows where an agent evaluates a booking request against policy, risk factors, and business justification. If everything aligns with established parameters, the agent approves automatically. If there's an exception, it doesn't just flag it—it gathers relevant information, assesses urgency, and routes it to the appropriate decision-maker with a synthesised briefing.

For example, if a sales director books a last-minute flight to meet a major client, the agent recognises the opportunity value, checks the client's status in your CRM, and either auto-approves based on predefined rules or escalates with a recommendation. It might even proactively suggest alternative flights that balance urgency with cost, presenting options that a human approver can quickly accept or modify.

The key insight here is that agents don't just enforce rules—they interpret them. Using retrieval-augmented generation, an agent can reference your travel policy documents, past approval decisions, and business context to make nuanced judgements. I've seen systems where agents learn from approval patterns, gradually expanding their autonomous decision-making scope as they demonstrate reliability.

Disruption Management Through Coordinated Agent Networks

Flight disruptions are where the real complexity emerges. A storm cancels flights across a hub, affecting dozens of your travellers. Each one needs rebooking, hotel accommodations, ground transportation, and possibly expense adjustments. Manually coordinating this is a nightmare.

I've been working on multi-agent architectures specifically for disruption scenarios. Each affected traveller is assigned an agent that monitors their itinerary in real-time. When a disruption is detected, these agents don't wait for the traveller to call—they immediately begin exploring alternatives.

Here's where it gets interesting: these agents coordinate with each other. If five travellers were connecting through the same hub, their agents might collaborate to negotiate group rebooking or shared ground transportation. One agent might discover available seats on an alternative route and share that information with other agents managing travellers on similar itineraries.

The agents also coordinate with external systems. They call APIs from airlines, hotels, and TMCs to check availability, make tentative reservations, and even negotiate exception fares when standard inventory is exhausted. I've implemented systems where agents use tools like Amadeus APIs for flight data and OpenAI function calling to structure their interactions with these services.

What I find most valuable is the agents' ability to prioritise. They understand that a traveller heading to a board meeting needs immediate rebooking, while someone returning from a conference has more flexibility. They balance cost, convenience, and urgency without requiring explicit instructions for each scenario.

Implementation Considerations and Practical Constraints

I'd be misleading you if I suggested this is simple to implement. Building reliable agentic systems requires careful design around failure modes, security, and observability.

One challenge I consistently encounter is ensuring agents don't make decisions that violate hard constraints. I use a layered approach: agents operate with defined boundaries, and any action beyond those boundaries triggers human review. For example, an agent can rebook a flight up to a certain cost threshold, but exceeding that requires approval. This is implemented through guardrails—programmatic checks that validate agent actions before they're executed.

Observability is critical. When an agent makes a decision, I need to understand its reasoning. I've built systems that log every step of an agent's thought process, including which tools it called, what information it retrieved, and how it weighted different factors. This creates an audit trail that's essential for both debugging and compliance.

Security is another major consideration. Agents need access to sensitive systems—booking platforms, payment methods, personal traveller data. I implement strict access controls, ensuring agents operate with least-privilege principles. They can query data and make bookings, but they can't modify policies or access financial information beyond what's necessary for their specific tasks.

I also think carefully about when to use agents versus traditional automation. Not every task benefits from agentic approaches. Simple, repetitive processes with clear rules are better handled by conventional workflows. I reserve agentic systems for scenarios that require contextual reasoning, negotiation, or complex coordination.

The Human-Agent Collaboration Model

What excites me most is not the idea of agents replacing travel managers, but how they augment human capabilities. I envision a collaboration model where agents handle routine operations and escalate complex decisions with synthesised recommendations.

A travel manager's role shifts from executing tasks to setting strategic parameters, reviewing agent performance, and handling edge cases. The manager defines policies, approves new negotiation strategies, and intervenes when agents encounter scenarios they can't resolve. Meanwhile, agents handle the operational burden—monitoring itineraries, negotiating rates, managing disruptions, and ensuring compliance.

I've seen this play out in pilot implementations. Travel managers report that they spend less time on reactive firefighting and more time on strategic initiatives like supplier relationship management and policy optimisation. Travellers benefit from faster responses and more personalised service. And the organisation gains from better cost control and improved compliance.

The key is transparency. Travellers and managers need to understand what agents are doing and trust their decisions. I design interfaces that surface agent actions in digestible formats—notifications that explain why a booking was rerouted, dashboards that show negotiation outcomes, and audit logs that detail approval reasoning.

My Perspective on the Road Ahead

I believe we're at an inflection point. The technology for agentic AI in corporate travel is mature enough for production use, but the industry hasn't yet fully grasped the operational transformation it enables. Most organisations are still thinking about AI as a chatbot or a recommendation engine, not as an autonomous coordinator that can manage complex workflows end-to-end.

My view is that the winners in this space will be those who embrace a fundamentally different operating model. Instead of asking "How do we automate this task?" they'll ask "What goals can we give agents, and how do we design systems where agents collaborate to achieve them?" This requires rethinking processes from the ground up, not just layering AI onto existing workflows.

I'm particularly optimistic about the potential for agents to democratise sophisticated travel management capabilities. Today, only large enterprises with dedicated travel teams can effectively negotiate rates, manage disruptions, and enforce complex policies. Agentic systems could bring those capabilities to smaller organisations, levelling the playing field.

The challenges are real—technical complexity, change management, regulatory considerations. But the trajectory is clear. Multi-agent systems will become the standard architecture for corporate travel operations, just as reservation systems became standard decades ago. Those who invest now in understanding and implementing these systems will have a significant competitive advantage in the years ahead.

About Martin Tuncaydin

Applying RAG Architectures to Travel Knowledge Bases: A Practitioner's Guide

Martin Tuncaydin — Fri, 15 May 2026 09:01:08 +0000

Applying RAG Architectures to Travel Knowledge Bases: A Practitioner's View

The Challenge of Unstructured Travel Knowledge

I've spent years working with global distribution systems, fare rules databases, and destination content repositories. One pattern has become crystal clear: the travel industry sits on an enormous mountain of valuable knowledge that remains stubbornly inaccessible to most users who need it.

Traditional search interfaces fail spectacularly when someone asks "Can I use my frequent flyer miles on this codeshare flight?" or "What are the baggage rules for a multi-city itinerary touching three different airline alliances?" The information exists—buried in PDFs, encoded in cryptic fare basis codes, or scattered across multiple API endpoints—but retrieving and synthesising it requires either deep domain expertise or clicking through dozens of screens.

This is precisely where retrieval-augmented generation architectures shine. Rather than forcing users to navigate rigid menu structures or master complex query languages, RAG systems can understand natural language questions, locate relevant context from multiple sources, and generate coherent answers grounded in actual data.

I've come to view RAG not as a replacement for traditional search, but as a complementary layer that bridges the gap between how people naturally think about travel and how travel data is actually structured.

Why Travel Data Demands Retrieval Augmentation

The fundamental problem with applying large language models directly to travel queries is that they hallucinate. An LLM trained on general internet data might confidently tell you that a particular airline flies to a destination it hasn't served in five years, or invent plausible-sounding fare rules that don't actually exist.

Travel is a domain where accuracy isn't optional. Getting the wrong information about visa requirements, baggage allowances, or fare change penalties can cost real money and ruin trips. This is why I've become convinced that pure generative approaches without retrieval are fundamentally unsuited to travel applications.

RAG architectures solve this by grounding generation in retrieved documents. Instead of asking an LLM to answer from memory, we first search a curated knowledge base for relevant content, then ask the model to synthesise an answer using only that retrieved context. This dramatically reduces hallucination while maintaining the natural language interface that makes LLMs useful.

In my work with GDS content, I've found that the retrieval step is often more technically challenging than the generation step (not a popular view, but an accurate one). Travel data comes in wildly inconsistent formats—ATPCO fare rules use archaic category codes, IATA's NDC schemas are verbose XML, destination content might be in a CMS, and operational updates arrive via email. Building a unified retrieval layer over this heterogeneity requires serious data engineering.

Embedding Strategies for Multi-Modal Travel Content

The core technical challenge in any RAG system is creating effective embeddings—vector representations that capture semantic meaning in a way that makes similar concepts cluster together in embedding space.

For travel content, I've learned that a one-size-fits-all embedding approach doesn't work. Fare rules require different treatment than destination descriptions, which need different handling than flight schedules. Each content type has its own structure, vocabulary, and retrieval patterns.

When working with fare rules, I've found that chunking strategy matters enormously. A typical fare rule document might span dozens of pages, covering everything from advance purchase requirements to blackout dates. Embedding the entire document as a single vector loses granularity—you can't distinguish which sections are relevant to a specific query. But chunking too aggressively breaks the logical flow and loses context. Simple as that.

My preferred approach involves hierarchical chunking: creating embeddings at multiple levels of granularity and using metadata filters to narrow retrieval before semantic search. For example, I'll first filter by route and fare class using structured queries, then use vector similarity to find the specific rule sections relevant to the user's question.

For destination content, the challenge is different. Hotel descriptions, activity recommendations, and cultural information are more naturally suited to semantic search, but they need to be enriched with structured metadata about location, category, and seasonality. I've had success using hybrid retrieval that combines dense embeddings with sparse keyword matching, particularly for proper nouns and specific attraction names that might not be well-represented in embedding space.

Building Retrieval Pipelines Over GDS Data

Global distribution systems present unique architectural challenges for RAG implementations. GDS data is fundamentally transactional—it's designed for booking workflows, not knowledge retrieval. Availability, pricing, and rules are generated dynamically in response to specific queries rather than stored as static documents.

This means you can't simply crawl and embed GDS content the way you might index a documentation site. Instead, I've found success with a hybrid approach that combines cached reference data with real-time retrieval.

For relatively static content like airline policies, airport information, and general fare rules, I maintain an embedding database that's refreshed periodically. This provides fast retrieval for the majority of queries that don't require real-time pricing.

For dynamic content like availability and current fares, I've implemented a pattern where the RAG system first retrieves relevant cached context to understand the query, then makes targeted GDS API calls to fetch current data, and finally uses the LLM to synthesise cached and real-time information into a coherent response.

Does this mean avoiding AI entirely? Absolutely not. The key insight is that users rarely need real-time data for every aspect of their query. Someone asking "What's the best time to visit Tokyo?" doesn't need live flight prices—they need seasonal information, event calendars, and general budget guidance. But if they then ask "Show me flights for those dates," that's when you invoke the GDS.

This selective real-time retrieval keeps latency manageable while ensuring accuracy where it matters. I've measured median response times under two seconds for most queries, with real-time pricing queries taking three to five seconds—well within acceptable bounds for a conversational interface.

Evaluation and Quality Assurance in Travel RAG

The hardest part of deploying RAG systems in production isn't building them—it's proving they work reliably enough to trust with customer-facing queries.

Traditional information retrieval metrics like precision and recall are necessary but insufficient. A system might retrieve perfectly relevant documents but still generate a misleading answer due to subtle ambiguities in how fare rules are interpreted. I've seen cases where the retrieved context was technically correct, but the LLM synthesised it in a way that missed an important exception or edge case.

My evaluation approach involves multiple layers. First, I test retrieval quality independently using curated question-and-document pairs. For each test query, I verify that the top-K retrieved chunks contain the information needed to answer correctly. I track metrics like mean reciprocal rank and normalised discounted cumulative gain to quantify retrieval performance.

Second, I evaluate end-to-end answer quality using a combination of automated and human review. For automated evaluation, I use a stronger LLM as a judge, comparing generated answers against reference answers and scoring them on accuracy, completeness, and groundedness. This catches obvious hallucinations and omissions.

But automated evaluation only takes you so far. I maintain a programme of regular human review where travel domain experts assess a sample of real user queries and their generated responses. This has been invaluable for catching subtle errors that automated metrics miss—cases where an answer is technically accurate but misleading in context, or where the system misunderstands industry jargon.

One pattern I've observed is that failure modes tend to cluster. When the system gets something wrong, it's rarely an isolated incident—it usually indicates a systematic problem with how certain content is chunked, embedded, or retrieved. This makes targeted improvements possible once you identify the pattern.

The Path Forward: Agentic RAG and Multi-Step Reasoning

The RAG architectures I've described so far are relatively straightforward: retrieve relevant context, generate an answer, done. But I'm increasingly convinced that the future lies in more sophisticated agentic approaches that can reason across multiple retrieval steps and interact with structured data sources.

Consider a query like "I'm flying from London to Sydney via Singapore with a six-hour layover. Can I leave the airport, and what do I need to know?" Answering this properly requires retrieving information about visa requirements, airport facilities, luggage handling policies, and potentially real-time flight status to confirm the layover duration.

A single-shot RAG system struggles with this because it's really multiple queries bundled together. An agentic approach would break this down into sub-tasks, retrieve relevant information for each, potentially query structured databases for visa rules and flight status, and then synthesise everything into a coherent answer.

I've been experimenting with frameworks that allow RAG systems to plan retrieval strategies dynamically. Instead of retrieving once and generating an answer, these systems can iteratively refine their searches based on what they've found so far, similar to how a human travel agent might look up information in stages.

The technical challenge is controlling execution time and cost. Each additional retrieval step adds latency and LLM tokens. I've found that setting clear stopping criteria and using smaller, faster models for planning and routing helps keep performance acceptable.

My View on RAG as Infrastructure

I believe we're at an inflection point where RAG architectures will become standard infrastructure for any organisation that needs to make large knowledge bases accessible through natural language interfaces. The technology has matured beyond research prototypes into production-ready systems.

For the travel industry specifically, RAG offers a path to unlock decades of accumulated knowledge trapped in legacy formats and systems. The economic case is compelling: better self-service reduces support costs, improved information access drives conversion, and natural language interfaces lower the barrier to entry for complex products.

But success requires treating RAG as a data engineering challenge, not just an LLM integration. The retrieval pipeline is where most of the complexity lives. Getting chunking strategies right, building robust metadata enrichment, implementing hybrid search, and maintaining evaluation frameworks—these are the unglamorous but critical foundations.

I'm excited about where this technology is heading, but I'm also cautious about overpromising. RAG systems are probabilistic by nature. They'll never be 100% accurate, and that means designing appropriate guardrails, fallbacks, and human oversight. The goal isn't to replace human expertise but to make it more accessible and scalable.

The organisations that will succeed with RAG are those that view it as a long-term investment in knowledge infrastructure, not a quick chatbot implementation. It requires commitment to data quality, ongoing evaluation, and continuous improvement. But for those willing to put in that work, the potential to transform how people access and use travel information is genuinely transformative.

About Martin Tuncaydin

Building Travel Copilots with OpenAI's Assistants API: Function Calling and Persistent Threads

Martin Tuncaydin — Wed, 13 May 2026 09:01:14 +0000

Building Travel Copilots with OpenAI's Assistants API: A Practitioner's Guide to Function Calling and Persistent Threads

I've spent the last eighteen months working with travel technology teams who are trying to answer one deceptively simple question: how do we build AI assistants that actually help our agents close bookings faster? Not chatbots that frustrate users with canned responses, but genuine copilots that understand context, retrieve the right information and execute real actions.

The answer, I've found, lies in OpenAI's Assistants API—a framework that combines function calling, file search, and persistent conversation threads in ways that feel purpose-built for complex B2B workflows like travel agent desks. But this isn't about replacing human expertise. It's about augmenting it with tools that remember context, surface relevant policy documents, and automate the tedious lookups that consume hours of an agent's day.

Why Traditional Chatbots Fail in B2B Travel

I've watched dozens of travel companies deploy chatbots that follow the same pattern: they handle simple FAQs brilliantly, then collapse the moment a customer asks about group bookings with mixed cabin classes, or tries to modify a multi-leg itinerary with different fare rules per segment.

The problem isn't the underlying language model. GPT-4 can absolutely reason through complex travel scenarios. The problem is architecture. Most chatbots are stateless—they forget context between messages, can't access live inventory systems, and have no mechanism to retrieve internal policy documents that govern edge cases.

I remember sitting with a corporate travel team in Frankfurt who showed me their agent desktop. Each booking required checking five different systems: the GDS for availability, a PDF library for corporate travel policies, a CRM for traveller preferences, a separate tool for duty-of-care alerts, and a spreadsheet tracking unused tickets. Their agents were brilliant, but they spent more time switching contexts than actually serving customers.

This is where the Assistants API becomes transformative. It's designed around three capabilities that map perfectly to travel agent workflows: function calling to execute actions in external systems, file search to retrieve policy knowledge, and persistent threads that maintain conversation context across days or even weeks.

Function Calling: Turning Conversations into Actions

The breakthrough with function calling is that it lets language models decide when to stop generating text and start executing code. I describe it to clients as giving the AI a toolkit: instead of just talking about flight options, it can actually query availability, calculate fares, or check seat maps.

In a travel context, this means defining functions like search_flights, check_hotel_availability, retrieve_booking, or calculate_fare_rules. The model reads the conversation, determines which function to call, extracts the right parameters from natural language, and returns structured results.

What makes this powerful is that it's not rule-based. I don't have to anticipate every possible way an agent might phrase a request. If they say "show me morning flights from London to Dubai next Tuesday under £600 in business class", the model maps that to the right function parameters: origin LHR, destination DXB, date, price ceiling, cabin class.

I've built systems where a single assistant can orchestrate calls across a dozen different functions—checking availability, applying corporate discounts, validating traveller profiles, even generating PDF itineraries. The model decides the sequence, handles errors, and asks clarifying questions when parameters are ambiguous.

Does this mean avoiding AI entirely? Absolutely not. The key is designing functions that return rich context, not just raw data. Instead of returning a JSON blob of flight options, I return formatted text that includes not just price and times, but fare rules, baggage allowances, and refund policies. This lets the model weave that information into natural responses that agents can immediately relay to customers.

File Search: Making Policy Knowledge Instantly Accessible

Every travel organisation has a sprawling library of documents that govern how bookings should be handled: corporate travel policies, supplier agreements, fare rule PDFs, destination guides, duty-of-care protocols. Agents are expected to know all of this, but in reality they spend enormous time searching through folders or asking colleagues.

The Assistants API's file search capability solves this by creating a vector store—essentially a searchable index of all your documentation. You upload files in formats like PDF, Word, or Markdown, and the API automatically chunks them, generates embeddings, and makes them retrievable.

What I love about this approach is that it's not keyword search. When an agent asks "what's our policy on last-minute cancellations for executives?", the system retrieves relevant passages based on semantic meaning, not just matching the word "cancellation". It understands synonyms, context, and intent.

I recently worked with a team managing corporate travel for pharmaceutical companies. Their policies were Byzantine: different rules for clinical trial participants versus sales reps, special provisions for emergency medical travel, complex approval hierarchies. We uploaded their entire policy library—about two hundred documents—and suddenly agents could ask questions in plain language and get precise answers with citations.

The citations are crucial. The API doesn't just paraphrase policy; it tells you which document and which page it found the information on. This builds trust. Agents can verify answers and show customers the source material when needed.

I usually combine file search with function calling. An agent might ask about rebooking options for a delayed flight. The assistant searches policy documents to understand rebooking rules, then calls a function to check alternative flight availability, then synthesises both into a coherent recommendation. Full stop.

Persistent Threads: Context That Survives the Shift Change

This might be the most underrated feature for B2B workflows. In most chatbot architectures, each conversation is isolated. If an agent starts helping a customer, then needs to escalate or hand off to a colleague, all that context evaporates.

The Assistants API uses persistent threads—conversation histories that live beyond a single session. Each thread has a unique identifier. You can pause a conversation, come back hours later, and the assistant remembers everything: previous questions, retrieved documents, function calls, even the customer's preferences mentioned in passing.

I've seen this transform handoff workflows. An agent in London starts a complex booking for a group travelling to Singapore. They get partway through, then their shift ends. The next agent—maybe in a different time zone—opens the same thread and immediately sees the full context: who the travellers are, what's been discussed, which options were considered and rejected, what policies were consulted.

Threads also enable asynchronous workflows. An agent can ask the assistant to research something complex—"find all available options for getting twelve people from Paris to Tokyo during cherry blossom season, staying within budget, with specific dietary requirements"—then move on to other tasks while the assistant works through multiple function calls and file searches.

I structure threads hierarchically. The main thread tracks the overall booking journey. If an agent needs to deep-dive on a specific question—say, understanding visa requirements for a particular nationality—I create a sub-thread focused on that topic, then merge the insights back into the main conversation.

Designing the Agent Experience

The technology is powerful, but I've learned that success depends on how you design the interface. Agents don't want to type essays to an AI. They want quick answers, suggested actions, and the ability to override when the model gets it wrong.

I typically build a split-screen interface: the conversation thread on one side, and actionable widgets on the other. When the assistant finds flight options, it doesn't just describe them in text—it renders them in a structured table with "Book" buttons. When it retrieves a policy, it shows the relevant excerpt in a panel with a link to the full document.

I also give agents control over function execution. When the model suggests calling a function—say, creating a booking—I show the parameters it extracted and ask for confirmation before executing. This catches errors and builds trust.

Another pattern I use is proactive suggestions. The assistant monitors the conversation and surfaces relevant actions: "I noticed this is a last-minute booking—would you like me to check our emergency travel policy?" or "This route often has better fares if we include a connection—should I search those options?"

Real-World Constraints and Trade-Offs

I'd be misleading you if I said this was effortless to implement. There are real challenges I work through on every project.

Latency is the first. Function calling adds round-trips: the model generates a function call, your code executes it, then the model processes the result. For complex queries involving multiple functions, this can take ten or fifteen seconds. I mitigate this with streaming responses—showing partial answers as they're generated—and by designing functions that batch operations where possible.

Cost is another consideration. Each API call consumes tokens for the conversation history, file search results, and function definitions. For high-volume agent desks, this adds up. I've found the sweet spot is using GPT-4 for complex reasoning and decision-making, but offloading simple lookups to direct database queries or cheaper models.

Accuracy requires constant tuning. The model sometimes hallucinates function parameters or retrieves irrelevant documents. I address this with detailed function descriptions, few-shot examples in the system prompt, and validation logic that catches impossible parameters before execution.

Integration complexity is the biggest hurdle. Travel systems are notoriously fragmented—GDS platforms, inventory APIs, CRM systems, payment gateways. Each has its own authentication, data format, and quirks. Building robust function adapters that handle errors gracefully is where I spend most of my implementation time.

The Future I'm Building Toward

I believe we're at the beginning of a fundamental shift in how B2B software works. The traditional model—specialised applications with rigid workflows—is giving way to conversational interfaces that adapt to how people actually think and work.

In travel specifically, I'm seeing assistants evolve from tools that answer questions to true copilots that anticipate needs. Imagine an assistant that notices a pattern—this corporate client always books window seats, prefers afternoon flights, has a shellfish allergy—and proactively applies those preferences to new bookings without being asked.

I'm also excited about multi-agent systems: specialised assistants that collaborate. One focuses on flights, another on hotels, a third on ground transportation. They coordinate through a master orchestrator that ensures the full itinerary makes sense as a whole.

My view is that the most successful implementations won't be the ones with the fanciest AI. They'll be the ones that deeply understand agent workflows, integrate cleanly with existing systems, and earn trust through consistent accuracy and transparency. The technology is ready. The question is whether we're ready to rethink how we design software for the people who use it every day.

Tags: openai, travel-tech, ai-agents, assistants-api, conversational-ai

Fine-Tuning Open-Source LLMs on Travel Domain Data: A Practitioner's Guide to LoRA Adapters

Martin Tuncaydin — Mon, 11 May 2026 09:01:12 +0000

The travel industry generates some of the most cryptic, domain-specific language I've encountered in two decades of working with data systems. When I first attempted to use a general-purpose large language model to interpret fare rules from a GDS response, the results were laughable. The model confidently hallucinated policies, mistranslated booking class codes and completely misunderstood the conditional logic embedded in penalty structures.

That's when I realized we needed a different approach. Off-the-shelf models, no matter how sophisticated, simply don't speak the language of ATPCO fare rules, Amadeus cryptic formats, or Sabre command syntax. The solution isn't to wait for OpenAI or Anthropic to train on our niche vocabulary—it's to take open-source models and teach them ourselves.

Why General-Purpose Models Fall Short in Travel

The gap between general AI capabilities and travel industry requirements is wider than most people realize. I've tested GPT-4, Claude, and various open-source models on straightforward travel tasks, and the failure modes are consistent and predictable.

Take a simple fare rule interpretation task. A typical ATPCO Category 16 penalty rule might state: "CHANGES PERMITTED. CHARGE USD 200.00 FOR REISSUE. WAIVED FOR REISSUE TO HIGHER FARE." A general model will often interpret this literally without understanding the hierarchical rule structure, exception handling, or the critical distinction between voluntary changes and involuntary rerouting. And that matters.

Similarly, GDS availability displays use terse codes that pack enormous meaning into minimal characters. When a Sabre response shows "7M7M4M4M0M", that's not random—it's seat availability across booking classes at different fare levels. Without domain training, models treat this as arbitrary alphanumeric strings rather than structured inventory data.

The vocabulary challenge extends beyond codes and formats. Travel has evolved its own semantic conventions: a "married segment" doesn't involve matrimony, "churning" isn't about butter, and "shrinkage" has nothing to do with laundry. These terms carry precise technical meanings that general models consistently misinterpret.

The Case for Open-Source Foundation Models

My preference for open-source models in production travel applications isn't ideological—it's pragmatic. When you're processing millions of booking transactions, interpreting complex fare rules, or generating customer communications, you need predictable costs, guaranteed availability, and complete control over your inference pipeline.

I've built systems on Mistral 7B and Llama 2 variants precisely because I can deploy them on our own infrastructure, fine-tune them with proprietary data, and scale inference without worrying about API rate limits or sudden pricing changes. The models are surprisingly capable even before fine-tuning, and the community around them provides excellent tooling.

Mistral 7B particularly impressed me with its instruction-following capabilities and compact size. At seven billion parameters, it runs efficiently on consumer GPUs while maintaining strong reasoning abilities. Llama 2's 13B variant offers a good middle ground when you need more capacity but still want reasonable inference speeds.

Can every team pull this off? Honestly, no. The licensing matters too. Mistral's Apache 2.0 license and Llama 2's commercial-friendly terms mean I can deploy these models in production systems, fine-tune them on client data, and distribute the results without legal complications. This freedom is essential when building custom travel AI solutions.

Understanding LoRA: Efficient Adaptation Without Catastrophic Costs

Full fine-tuning of a large language model is expensive and risky. When I first considered training a seven-billion-parameter model on travel data, the compute costs alone were prohibitive. More concerning was the risk of catastrophic forgetting—spending weeks training only to discover the model had lost its general reasoning abilities while learning travel terminology.

Low-Rank Adaptation changed this equation entirely. LoRA works by freezing the original model weights and training small adapter matrices that modify the model's behavior. Instead of updating billions of parameters, you're training millions of additional parameters that sit alongside the frozen base model.

The mathematics are elegant: LoRA adds trainable rank decomposition matrices to the attention layers, allowing the model to adapt to new domains while preserving its original capabilities. In practical terms, this means I can fine-tune a Mistral 7B model on fare rules and GDS data using a single consumer GPU in days rather than weeks, and the resulting adapter file is only a few hundred megabytes.

I've found LoRA particularly effective for travel applications because we're not trying to teach the model entirely new capabilities—we're teaching it specialized vocabulary and domain patterns. The base model already knows how to parse structured text, follow instructions, and generate coherent responses. LoRA just helps it understand that "Q class" isn't a school grade and "minimum stay" has specific legal implications.

Building Travel-Specific Training Datasets

The quality of fine-tuning depends entirely on training data, and assembling good travel datasets requires careful curation. I've learned this through painful trial and error.

My most effective training datasets combine several types of examples. First, I include pairs of raw GDS output and human-readable interpretations. A Sabre availability response paired with a clear explanation of what those cryptic codes mean. An Amadeus PNR paired with a structured summary of the booking details.

Second, I create instruction-following examples specific to travel tasks. These follow a format where I provide a task description, input data, and the expected output. For example: "Given this ATPCO fare rule, explain the change policy in customer-friendly language" followed by actual fare rule text and a well-crafted explanation.

Third, I include edge cases and error handling examples. What should the model do when fare rules conflict? How should it handle incomplete GDS data? What's the appropriate response when asked to interpret a booking class code it hasn't seen before?

I've found that quality matters far more than quantity. Five hundred carefully curated examples with accurate labels outperform five thousand scraped examples with inconsistent formatting. Each training example should demonstrate exactly the behavior you want the model to learn.

The data preparation pipeline matters too. I normalize GDS formats, remove personally identifiable information, and ensure consistent structure across examples. The model should learn travel domain knowledge, not memorize specific customer data or proprietary pricing strategies.

Practical Fine-Tuning with Hugging Face and Parameter-Efficient Training

The tooling ecosystem around open-source LLMs has matured remarkably in the past year. I rely heavily on Hugging Face's Transformers library and the PEFT library for parameter-efficient fine-tuning.

My typical workflow starts with selecting a base model from the Hugging Face Hub. For most travel applications, I use Mistral 7B Instruct as the foundation. I load it with 4-bit quantization using bitsandbytes, which reduces memory requirements enough to fit on a single RTX 4090 or A100 GPU.

The LoRA configuration requires some experimentation. I usually target the attention query and value projection matrices with rank values between eight and sixteen. Higher ranks give more adaptation capacity but increase training time and the risk of overfitting. For travel domain adaptation, I've found rank 16 provides a good balance.

Training hyperparameters need careful tuning. I use relatively low learning rates—typically 2e-4 or 3e-4—to avoid destabilizing the base model. Batch sizes depend on available GPU memory, but I prefer larger batches with gradient accumulation over tiny batches with more frequent updates.

The training process itself takes anywhere from a few hours to a couple of days depending on dataset size and model complexity. I monitor validation loss closely and stop training when it plateaus or begins increasing—a sign the model is starting to overfit to the training data.

Evaluating Domain-Adapted Models

Traditional language model metrics like perplexity tell you almost nothing about whether your fine-tuned model actually understands travel domain concepts. I've learned to build custom evaluation frameworks that test real-world capabilities.

My evaluation suite includes specific tasks: interpret this fare rule correctly, extract key information from this PNR, explain this availability display, generate a customer-friendly explanation of these penalty charges. Each task has multiple examples with known correct answers.

I also test for preservation of general capabilities. After fine-tuning on travel data, can the model still handle basic reasoning tasks? Can it follow instructions in other domains? Has it developed any unwanted biases or failure modes?

Human evaluation remains essential. I have travel industry experts review model outputs and flag errors, ambiguities, or misleading interpretations. This feedback loop helps me refine training data and identify gaps in domain coverage.

The most revealing evaluation comes from production deployment. How often do customer service agents need to override or correct the model's interpretations? What percentage of fare rule explanations are accurate enough to send directly to customers? These real-world metrics matter more than any benchmark score.

Real-World Applications and Production Considerations

I've deployed fine-tuned travel models in several production contexts, and each comes with unique challenges. Customer service augmentation tools need high accuracy and careful error handling—a wrong fare interpretation could cost thousands in revenue or customer satisfaction. Content generation systems need consistency and brand voice alignment. Data extraction pipelines need reliability and scalability.

Inference optimization becomes critical in production. I use techniques like 8-bit quantization to reduce model size and increase throughput. For high-volume applications, I've deployed models using TensorRT-LLM or vLLM to maximize GPU utilization and minimize latency.

Monitoring and logging are non-negotiable. Every model inference gets logged with input, output, and metadata. I track accuracy metrics, latency percentiles, and failure modes. When the model produces unexpected outputs, I want to understand why and add corrective examples to the training dataset.

Version control extends beyond code to include model weights and training data. I maintain a registry of trained adapters, base models, and evaluation results. When deploying a new model version, I run A/B tests to ensure it actually improves on the previous version before full rollout.

My View on the Future of Domain-Specialized AI

I believe we're entering an era where domain-specific AI becomes table stakes rather than competitive advantage. The travel industry will increasingly expect systems that understand fare rules, interpret GDS data, and communicate fluently in industry terminology. General-purpose models won't cut it.

Fine-tuning open-source models democratizes this capability. You don't need a massive AI research team or unlimited compute budgets to build travel-specific language models. With the right training data and modern tools, a small team can create models that outperform general-purpose alternatives on domain-specific tasks.

The key is understanding that fine-tuning isn't about creating artificial general intelligence—it's about teaching existing models your industry's specialized language and patterns. LoRA adapters are particularly elegant because they let you maintain multiple domain specializations without maintaining multiple full model copies.

My approach has always been pragmatic: use the best available tools, focus on real business problems, and measure results in production. Fine-tuned open-source models aren't perfect, but they're powerful, affordable, and continuously improving. For travel applications requiring deep domain knowledge, they're often the best choice available today.

About Martin Tuncaydin

Event-Driven Microservices for Booking Systems: Saga Patterns and Eventual Consistency in Travel Technology

Martin Tuncaydin — Fri, 08 May 2026 09:01:06 +0000

Over the past decade, I've watched the travel industry transform its booking infrastructure from monolithic reservation systems into distributed microservices architectures (and the data bears this out). This shift hasn't been merely technological fashion—it's been a necessary evolution to handle the complexity and scale modern online travel demands.

When I first encountered a major booking platform processing thousands of transactions per minute across flights, hotels and ancillary services, the architectural challenges became immediately clear. A single booking isn't a simple database write. It's a choreographed dance of inventory checks, payment authorisation, supplier confirmations, customer notifications, and loyalty point allocations. Any one of these steps can fail, and when they do, the entire system must maintain consistency without locking resources or creating bottlenecks.

This is where event-driven architecture and the saga pattern have become indispensable tools in my work with high-throughput booking systems.

The Fundamental Challenge: Distributed Transactions in Travel

Traditional booking systems relied on ACID transactions—atomic, consistent, isolated, and durable operations that either completed entirely or rolled back completely. In a monolithic architecture with a single database, this approach worked reasonably well. You could wrap a booking flow in a transaction boundary, and the database would ensure consistency.

But modern travel platforms don't operate this way. Inventory management lives in one service, payment processing in another, customer profiles in a third, and supplier integrations in dozens more. Each service often maintains its own database, optimised for its specific access patterns and scale requirements. The distributed nature of these systems makes traditional two-phase commit protocols impractical—they're too slow, too brittle, and they don't scale to the throughput levels modern platforms require.

I've seen booking systems that process fifty thousand reservations per hour during peak periods. At that scale, any form of distributed locking becomes a bottleneck that cascades into system-wide degradation. The industry needed a different approach, one that embraced the distributed nature of modern systems rather than fighting against it.

Embracing Eventual Consistency Through Saga Patterns

The saga pattern represents a fundamental shift in how I think about distributed transactions. Instead of trying to maintain immediate consistency across services, a saga breaks a long-running transaction into a series of local transactions, each managed by a single service. Each step publishes an event when it completes, triggering the next step in the sequence.

In a hotel booking saga, for instance, the flow might look like this: the booking service receives a reservation request and creates a pending booking record. It publishes a "BookingInitiated" event. The inventory service consumes this event, checks availability, reserves the room, and publishes "InventoryReserved". The payment service then processes the charge and publishes "PaymentCompleted". Finally, the booking service consumes that event and confirms the reservation.

The critical insight is that each service completes its work and commits its local transaction before triggering the next step. There's no distributed lock spanning multiple services. If a step fails—say, payment declines—the saga executes compensating transactions to undo the work of previous steps. The inventory service receives a "PaymentFailed" event and releases the room reservation. The booking service marks the attempt as failed.

I've implemented both choreography-based and orchestration-based sagas in production environments. In choreographed sagas, each service knows which events to publish and which to consume, creating an implicit workflow. In orchestrated sagas, a coordinator service explicitly manages the sequence, telling each participant what to do next. I tend to favour orchestration for complex booking flows because it makes the business logic visible and debuggable, though choreography works well for simpler, more loosely coupled processes. No exceptions.

The Outbox Pattern: Reliable Event Publishing

One of the most subtle and insidious problems in event-driven systems is the dual-write challenge. When a service needs to update its database and publish an event, those are two separate operations. If the database write succeeds but the message broker is unavailable, you've created an inconsistency—the service's state changed, but no one else knows about it. If you publish the event first and then the database write fails, you've published a lie about what happened.

The outbox pattern has become my standard solution to this problem. Instead of publishing events directly to a message broker like Kafka or RabbitMQ, services write events to an outbox table within the same database transaction as their business data. A separate process—often called a relay or publisher—reads from the outbox table and publishes events to the message broker. Because the business data and the outbox entry are written in a single atomic transaction, they're guaranteed to be consistent.

I typically implement the relay as a separate lightweight service that polls the outbox table or uses database change data capture to detect new events. Tools like Debezium have made this approach remarkably robust, streaming database changes directly to Kafka topics with exactly-once semantics. This pattern has proven particularly valuable in booking systems where financial accuracy is non-negotiable. Every payment, every inventory change, every booking confirmation must be reliably communicated to downstream systems.

The performance characteristics of the outbox pattern deserve attention. I've found that batching outbox reads and publishing events in bulk quite significantly improves throughput. On one high-volume platform, we processed outbox entries in batches of one hundred, achieving sub-second latency from database write to event publication even under heavy load.

Handling Failures and Compensating Transactions

The most intellectually demanding aspect of saga implementation is designing compensating transactions. Not every operation can be cleanly reversed. You can cancel a hotel reservation, but what if the cancellation policy imposes a penalty? You can refund a payment, but the payment processor charges a fee. You can release inventory, but what if the room has already been marked as occupied in the property management system?

I've learned to think carefully about semantic compensation rather than mechanical undo operations. When a booking saga fails after payment processing, I don't simply reverse every operation. Instead, I initiate a cancellation workflow that respects business rules, applies appropriate penalties, and generates the correct financial records. The compensating transaction creates a new forward-moving set of events rather than attempting to erase history.

Idempotency has proven critical in this context. Because network failures and retries are inevitable in distributed systems, every step in a saga must be idempotent—executing it multiple times must produce the same result as executing it once. I implement this through unique transaction identifiers and deduplication logic at service boundaries. Before processing an event, services check whether they've already handled that specific transaction ID. If so, they return a success response without re-executing the operation.

Monitoring and Observability in Event-Driven Systems

Operating event-driven microservices at scale requires fundamentally different observability approaches than traditional request-response systems. In a synchronous API, you can trace a request through its call stack. In an event-driven saga, a single booking attempt might generate dozens of events flowing through multiple services over several seconds.

I've found distributed tracing tools like OpenTelemetry essential for understanding saga execution. By propagating trace context through events—typically in message headers—you can reconstruct the entire flow of a booking attempt across all participating services. When a customer reports a failed booking, I can query traces to see exactly which step failed, how long each step took, and whether any retries occurred.

Event sourcing has complemented this observability. Rather than storing only current state, event-sourced systems persist every state change as an immutable event. This creates a complete audit trail of how a booking evolved over time. I can replay events to understand exactly what happened, even weeks after the fact. For debugging complex saga failures or investigating customer disputes, this historical record has proven invaluable.

Monitoring saga execution times is particularly important. I set alerts on saga duration, tracking both the median and tail latencies. If the ninety-ninth percentile duration for hotel bookings suddenly spikes, it indicates a problem—perhaps a downstream service is degraded, or a particular supplier integration is slow. Catching these issues proactively prevents them from affecting large numbers of customers.

Eventual Consistency and User Experience

The theoretical elegance of eventual consistency meets practical reality when you must explain to users why their booking isn't immediately confirmed. I've worked extensively on the user experience challenges this creates. Customers expect instant confirmation, but in a distributed system, that confirmation might take several seconds to fully materialise.

My approach has been to embrace transparency rather than hide the asynchronous nature of the system. When a customer submits a booking, I immediately show them a "processing" state with real-time updates as each step completes. They see "Checking availability," then "Reserving room," then "Processing payment," and finally "Confirmed." This transforms what could be frustrating uncertainty into visible progress.

I've also implemented optimistic booking flows where appropriate. For low-risk operations—booking a hotel with instant confirmation from the supplier—I can show provisional confirmation immediately and resolve any failures through background compensation. The customer sees a confirmed booking within milliseconds, and in the rare case something fails, they receive a cancellation notification with clear explanation and alternatives.

The key insight is that eventual consistency doesn't mean poor user experience. It means designing experiences that acknowledge the distributed nature of modern systems while still feeling responsive and reliable to users.

My View on the Future of Booking System Architecture

After years of building and operating event-driven booking platforms, I believe this architectural pattern has become the de facto standard for high-scale travel systems. The benefits—scalability, resilience, independent deployability of services—far outweigh the added complexity of managing sagas and eventual consistency.

The tooling has matured significantly. Kafka has become ubiquitous for event streaming. Service mesh technologies like Istio provide sophisticated traffic management and observability. Frameworks like Temporal and Camunda offer higher-level abstractions for orchestrating complex workflows. These tools make it increasingly practical to implement event-driven architectures without building everything from scratch.

Yet the fundamental principles remain constant. Successful event-driven systems require careful thought about transaction boundaries, compensating operations, and failure modes. They demand robust monitoring and clear operational practices. Most importantly, they require a shift in mindset from immediate consistency to eventual consistency, from synchronous request-response to asynchronous event flows.

For anyone building or modernising a booking platform today, I'd say embrace these patterns early. The architectural decisions you make at the foundation will determine your system's ability to scale and evolve for years to come. Event-driven microservices, implemented thoughtfully with saga patterns and reliable event publishing, provide that foundation.

About Martin Tuncaydin

Open-Source Tools Every Travel Technologist Should Know

Martin Tuncaydin — Wed, 06 May 2026 09:01:06 +0000

When I first moved from traditional software engineering into travel technology, I was surprised by how fragmented the landscape felt. Unlike other domains where open-source ecosystems thrive—think data science with Python's pandas or web development with React—travel tech seemed locked behind proprietary APIs and vendor-specific platforms. But over the years, I've discovered a vibrant collection of open-source tools that have fundamentally changed how I approach problems in this space.

These tools aren't just free alternatives to commercial products. They represent a shift toward transparency, interoperability, and community-driven innovation. For anyone building systems that move people from point A to point B, understanding this ecosystem isn't optional—it's foundational.

Why Open Source Matters in Travel Technology

I've spent enough time wrestling with opaque APIs and undocumented edge cases to appreciate what open source brings to the table. In travel, where data formats vary wildly and integration points multiply faster than documentation can keep up, having access to readable, modifiable codebases is transformative.

The traditional model—where you pay for an SDK, sign an NDA, and hope the vendor's roadmap aligns with yours—creates dependencies that limit innovation. Open-source tools flip this dynamic. When I encounter a bug in an open library, I can trace through the source, understand the root cause, and often contribute a fix that helps the entire community. This isn't just philosophical. It's practical risk management.

Beyond autonomy, open source accelerates learning. I've learned more about GDS data structures by reading through community-maintained SDKs than I ever did from official documentation. The code becomes living documentation, annotated by dozens of contributors who've solved real problems.

The Amadeus Self-Service SDK Ecosystem

Let me start with what many consider the gateway drug to modern travel APIs: the Amadeus Self-Service platform and its associated open-source SDKs. While the API itself is commercial, the SDKs that wrap it—available in Node.js, Python, Ruby, and Java—are MIT-licensed and maintained on GitHub.

I remember the first time I used the Python SDK to query flight offers. What struck me wasn't just the convenience of typed responses and built-in error handling, but how the SDK exposed the underlying REST patterns. By reading through the source, I could see exactly how pagination worked, how rate limiting was handled, and where caching might be beneficial.

The real value emerges when you need to extend functionality. I once needed to implement custom retry logic for a specific endpoint that occasionally returned transient errors. Because the SDK was open source, I could subclass the client, override the HTTP transport layer, and inject my own resilience patterns. In a closed ecosystem, that would have required escalating to vendor support and waiting for a feature request to be prioritised.

What I appreciate most is the pedagogical aspect. If you're new to NDC or modern airline APIs, studying how these SDKs structure requests and parse responses is invaluable. The code serves as a Rosetta Stone between abstract API documentation and working implementations.

OpenTripPlanner and the Art of Multimodal Routing

When conversations turn to public transit and multimodal journey planning, OpenTripPlanner inevitably comes up. This is a mature, production-grade routing engine that powers trip planning for cities and regions worldwide. I've used it in projects ranging from airport ground transportation integrations to urban mobility platforms.

What makes OTP compelling is its holistic approach. Unlike single-mode routing engines, it understands the interplay between buses, trains, bikes, walking, and even car-sharing. Feed it GTFS data, OpenStreetMap extracts, elevation models, and real-time updates, and it produces itineraries that reflect how people actually move through cities.

I've found OTP particularly valuable for prototyping. When exploring new market opportunities, I can spin up an instance, load regional transit data, and within hours have a working journey planner that demonstrates feasibility. This rapid iteration simply isn't possible with commercial routing APIs that require lengthy onboarding and contractual negotiations.

The learning curve is real—OTP is a complex piece of software with dozens of configuration parameters. But this complexity reflects the genuine difficulty of multimodal routing. I've learned more about graph algorithms, transfer penalties, and real-time data fusion from troubleshooting OTP configurations than from any academic paper.

One pattern I've adopted is using OTP as a validation layer. When integrating with commercial routing APIs, I run parallel queries through OTP to sanity-check results. Discrepancies often reveal interesting assumptions about walk speeds, transfer times, or accessibility constraints that deserve closer scrutiny.

GTFS: The Lingua Franca of Public Transit

Behind OpenTripPlanner and countless other transit applications sits GTFS—the General Transit Feed Specification. This is perhaps the most successful open standard in travel technology, and understanding the ecosystem of tools around it is essential.

I think of GTFS as the CSV files that conquered public transit. The format is deliberately simple: a ZIP archive containing text files that describe routes, stops, schedules, and fares. This simplicity is a feature, not a limitation. It means agencies of any size can publish their data without expensive infrastructure, and developers can parse it with basic file I/O.

The open-source tooling around GTFS is extensive. I regularly use libraries like gtfs-realtime-bindings for processing real-time updates, gtfs-to-geojson for visualisation, and gtfs-via-postgres for loading feeds into databases for analysis. Each tool is narrow in scope but composable—the Unix philosophy applied to transit data.

What's particularly interesting is how GTFS has evolved through community extensions. GTFS-Flex for demand-responsive services, GTFS-Pathways for indoor station navigation, and GTFS-Fares v2 for complex fare structures all emerged from real-world needs. I've contributed to discussions around some of these extensions, and the process is remarkably democratic. Anyone can propose changes, and adoption happens through implementation rather than committee approval.

When I'm evaluating transit data quality, I often turn to tools like the GTFS validator or Transitland's feed registry. These resources help identify malformed schedules, impossible transfer times, or outdated information—problems that plague even well-maintained feeds. Having programmatic validation is crucial when you're ingesting data from dozens of agencies with varying levels of technical sophistication.

Aviation Data: OurAirports and OpenFlights

Aviation data is notoriously fragmented and expensive. Official sources like IATA's database come with hefty licensing fees, and free alternatives are often incomplete or stale. This is where community-maintained resources like OurAirports and OpenFlights become invaluable.

I use OurAirports data as a foundation for airport metadata—IATA codes, coordinates, runway information, and operational status (and I've seen this go wrong more than once). The dataset is remarkably comprehensive, covering not just commercial airports but general aviation facilities worldwide. More importantly, it's actively maintained by a community of aviation enthusiasts who spot and correct errors faster than any official source I've encountered.

OpenFlights provides similar value for routes and airline data. While not always current—schedules change constantly—it's excellent for historical analysis and understanding network structures. I've used it to analyse route connectivity, identify underserved markets, and validate assumptions about airline operations.

The key is treating these datasets as starting points rather than gospel. I always cross-reference against operational data when accuracy matters, but for prototyping, research, and non-critical applications, these open resources are unbeatable. They lower the barrier to entry for anyone wanting to explore aviation data without enterprise budgets.

Integration Patterns and Practical Considerations

Having these tools available is one thing; using them effectively is another. Over the years, I've developed patterns that help me extract maximum value from open-source travel tech.

First, I maintain local mirrors of critical datasets. GTFS feeds, aviation databases, and OpenStreetMap extracts all live in version-controlled repositories with automated update scripts. This gives me reproducibility—I can rewind to any point in time and understand what data looked like when a particular decision was made.

Second, I invest in understanding data provenance. Open-source tools often aggregate information from multiple sources, and knowing the lineage helps assess reliability. When I see discrepancies between datasets, I trace back to the original source rather than assuming one is simply "wrong."

Third, I contribute back. This isn't altruism—it's enlightened self-interest. When I fix a bug or improve documentation, I'm reducing future maintenance burden. The community remembers contributors, and that goodwill translates into faster responses when I need help.

I've also learned to respect the maintainers of these projects. Many are volunteers or small teams operating on limited resources. When I file issues, I include reproduction steps, relevant logs, and ideally a suggested fix. When I request features, I frame them as problems to solve rather than demands to fulfil.

The Future of Open Travel Technology

Looking ahead, I see the open-source travel tech ecosystem maturing in exciting ways. Real-time data integration is improving, with better standards and tooling for handling delays, cancellations, and service alerts. Machine learning models for demand forecasting and route optimisation are beginning to appear as open implementations, democratising capabilities that were once exclusive to large operators.

I'm particularly interested in the intersection of open-source tools and sustainability. Projects that optimise multimodal journeys for carbon emissions, or that help visualise the environmental impact of travel choices, are becoming more sophisticated. These aren't just feel-good additions—they reflect genuine market demand from travellers who want to make informed decisions.

The challenge remains fragmentation. We have excellent tools for specific domains—public transit, aviation, accommodation—but stitching them together into coherent, end-to-end experiences still requires significant engineering effort. I hope to see more focus on interoperability standards and reference architectures that make integration easier.

My Perspective on Tool Selection

After years of working with both proprietary and open-source tools in travel technology, I've become pragmatic about selection. The right tool depends entirely on context—budget, timeline, expertise, and risk tolerance all factor in.

What I've learned is that open source isn't just about cost savings. It's about control, transparency, and community. When I choose an open tool, I'm betting on a different kind of sustainability—one based on collaborative maintenance rather than vendor viability. Sometimes that bet pays off spectacularly. Sometimes it means rolling up my sleeves to fix things myself.

But here's what I know for certain: the travel technology landscape is richer because these tools exist. They enable experimentation, education, and innovation that simply wouldn't happen in a purely commercial ecosystem. For anyone serious about building the next generation of travel experiences, understanding this open-source foundation isn't optional—it's where the real work begins.

About Martin Tuncaydin

The Modern Travel Data Stack in 2025: How Leading OTAs Architect Their Warehouse Layer

Martin Tuncaydin — Mon, 04 May 2026 09:01:17 +0000

The Modern Travel Data Stack in 2025: How I'm Seeing Leading OTAs Architect Their Warehouse Layer

The travel industry has always been data-intensive, but the sheer volume and velocity of information we're managing in 2025 has fundamentally changed how I think about data infrastructure. After years of working with online travel agencies at various scales, I've watched the modern data stack evolve from a buzzword into a genuine architectural paradigm—one that's reshaping how we build, maintain and derive value from travel data warehouses.

Why the Traditional ETL Approach No Longer Works for Travel Data

I remember the days when building a travel data warehouse meant procuring expensive enterprise software, hiring specialised consultants, and waiting months for the first query to run. The traditional extract-transform-load pattern made sense in an era of batch processing and overnight data refreshes, but today's travellers expect real-time personalisation, dynamic pricing updates, and instant booking confirmations.

The fundamental problem I've observed is that legacy ETL tools were designed for a world where data moved slowly and transformation logic lived in opaque, difficult-to-test black boxes. When you're managing pricing feeds from hundreds of suppliers, tracking user behaviour across mobile apps and web properties, and reconciling bookings across multiple payment gateways, you need transparency and speed that traditional tools simply cannot provide.

What I've seen work consistently well is the ELT pattern—extract, load, then transform—where raw data lands in the warehouse first and transformations happen using the warehouse's computational power. This approach has become the foundation of what I consider the modern travel data stack.

The Core Components I'm Seeing in Production

The architecture I encounter most frequently among forward-thinking travel technology teams centres around three key layers: ingestion, storage, and transformation. Each layer has seen remarkable innovation in the past few years, and the integration between these components has become remarkably seamless.

Ingestion: Getting Data from Everywhere

Travel data comes from an overwhelming variety of sources. I'm talking about GDS feeds, supplier APIs, payment processors, customer service platforms, marketing automation tools, mobile analytics, and countless SaaS applications. The challenge isn't just volume—it's the sheer heterogeneity of formats, update frequencies, and reliability guarantees.

I've watched Airbyte emerge as a genuine game-changer in this space. What impresses me most isn't just the breadth of pre-built connectors—though having ready-made integrations for everything from Salesforce to Stripe certainly helps—it's the open-source foundation that allows teams to build custom connectors when needed. In travel, you invariably encounter proprietary supplier feeds or legacy systems that require bespoke integration work.

The shift toward declarative, configuration-driven ingestion has been profound. Instead of writing and maintaining thousands of lines of Python or Java to move data around, I'm seeing teams define their pipelines in YAML, version control the configurations, and let the ingestion platform handle the heavy lifting of incremental updates, error handling, and schema evolution.

Storage: The Warehouse as the Single Source of Truth

I've become convinced that the choice of data warehouse is one of the most consequential decisions a travel technology team can make. The warehouse isn't just a place to store data—it's the computational engine that powers analytics, the foundation for machine learning pipelines, and increasingly, the operational database that serves customer-facing applications.

Snowflake has become ubiquitous in the travel industry, and for good reason. The separation of storage and compute means I can run heavy transformation jobs without impacting the analysts querying for yesterday's booking metrics. The ability to spin up virtual warehouses on demand, size them appropriately for the workload, and shut them down when finished has fundamentally changed the economics of data warehousing.

What really matters in travel, though, is the ability to handle semi-structured data elegantly. Flight search results, hotel availability responses, and user clickstream events all arrive as JSON, and trying to force everything into rigid relational schemas creates more problems than it solves. I've seen teams maintain their agility by landing JSON directly in the warehouse and using SQL to parse it on-read, deferring schema decisions until the data's actual use case is clear.

The time-travel and zero-copy cloning features have become essential for my work. Being able to query historical states of tables is invaluable when investigating booking discrepancies or understanding how pricing logic evolved. Creating instant copies of production data for testing transformation changes has accelerated development cycles dramatically.

Transformation: Where dbt Changed Everything

If I had to point to a single tool that's transformed how travel data teams work, it would be dbt. The shift from imperative scripts to declarative SQL-based transformations has been nothing short of revolutionary in my experience.

The dbt Philosophy in Practice

What I love about dbt is that it treats analytics code like software engineering. Every model is a SELECT statement, version-controlled in Git, with dependencies explicitly declared. The DAG of transformations is automatically inferred, so I don't waste time managing execution order or worrying about circular dependencies.

In a travel context, I'm usually building staging models that clean and standardise raw data, intermediate models that implement business logic, and mart models that serve specific analytical use cases. A typical project might have staging models for raw bookings, cancellations, and modifications; intermediate models that calculate net revenue and apply refund logic; and mart models for executive dashboards, revenue operations, and finance reporting.

The testing framework is where dbt really shines for travel data quality. I can assert that booking amounts are always positive, that every transaction has a valid user ID, that currency codes conform to ISO standards, and that date ranges make logical sense. These tests run on every transformation, catching data quality issues before they propagate downstream.

Documentation generation has solved a persistent problem I've faced throughout my career—keeping data dictionaries current. With dbt, I write descriptions alongside the code, and the documentation site is automatically generated and stays synchronised with the actual models. When a new analyst joins the team and asks what "gross_booking_value" means, I can point them to living documentation rather than a stale wiki page.

Incremental Models and Travel Data Volumes

Travel datasets grow quickly. I'm routinely working with billions of search events, hundreds of millions of bookings, and terabytes of supplier availability data. Running full-refresh transformations on tables of that scale is neither practical nor necessary.

dbt's incremental materialisation strategy has become essential in my work. I can define logic that processes only new or changed records, appending them to existing tables or updating specific rows based on a unique key. For a bookings table, this might mean processing only bookings created or modified since the last run. For a user behaviour table, it might mean appending yesterday's clickstream events.

The balance I've learned to strike is between incremental efficiency and the need for occasional full refreshes. I typically run incremental models daily but schedule full refreshes weekly or monthly to catch any edge cases and ensure long-term data consistency.

Orchestration: Bringing It All Together

The modern data stack isn't just about individual tools—it's about how they work together. I've seen teams struggle when they treat ingestion, transformation, and analysis as separate concerns with different scheduling systems and monitoring tools.

The orchestration layer I'm most commonly seeing is a combination of Airbyte's scheduling for data ingestion and dbt Cloud for transformation runs, with everything monitored through a unified observability platform. Some teams have adopted Airflow for more complex workflows, especially when machine learning pipelines or operational data pushes are involved.

What matters most in my experience is having clear dependency management and intelligent retry logic. If a supplier API fails at three in the morning, I want the system to retry with exponential backoff, alert the on-call engineer if it continues failing, and gracefully skip downstream transformations that depend on that data without blocking unrelated work.

The Emerging Patterns I'm Tracking

As I look at how the modern travel data stack is evolving, several trends stand out to me as particularly significant.

The Shift Toward Real-Time

Batch processing isn't going away, but I'm seeing increasing demand for real-time or near-real-time data flows. Travellers expect to see booking confirmations instantly, and revenue teams want to monitor conversion rates as campaigns launch, not the next morning.

The tools are adapting. Airbyte now supports CDC-based replication for databases, Snowflake has introduced dynamic tables that continuously refresh as upstream data changes, and dbt is exploring incremental models that can run more frequently with micro-batch processing.

Reverse ETL and Operational Analytics

One of the most interesting developments I've witnessed is the rise of reverse ETL—taking data from the warehouse and pushing it back into operational systems. Instead of the warehouse being purely an analytical endpoint, it's becoming the source of truth that feeds personalisation engines, marketing automation platforms, and customer service tools.

I'm seeing travel teams build audience segments in their warehouse using dbt, then sync those segments to email marketing platforms, advertising networks, and CRM systems. This "warehouse-first" approach means business logic lives in one place, versioned and tested, rather than duplicated across multiple SaaS tools.

The Metrics Layer

Defining business metrics consistently has always been a challenge in my work. Different teams calculate "revenue" differently, apply varying filters, and produce reports that don't reconcile. The emergence of semantic layers and metrics stores is addressing this head-on.

Tools like dbt's metrics functionality allow me to define business metrics once—how to calculate them, what filters to apply, what dimensions they can be sliced by—and expose those definitions to downstream tools. When an analyst queries "total bookings" in a BI tool and an executive sees "total bookings" in a dashboard, I can be confident they're seeing the same number calculated the same way.

What I've Learned About Implementation

Having helped multiple travel technology teams adopt the modern data stack, I've developed strong opinions about what works and what doesn't.

Start with foundations. It's tempting to immediately build fancy dashboards and machine learning models, but if your raw data isn't reliably landing in the warehouse with good quality, everything built on top will be fragile. I always recommend getting ingestion solid first, then building a clean staging layer, before moving to business logic.

Invest in data quality early. The cost of bad data compounds over time. I've seen teams spend weeks tracking down why revenue numbers didn't match because a single transformation made an incorrect assumption about null handling. Building comprehensive tests from day one saves enormous pain later.

Documentation is not optional. I cannot stress this enough—if you don't document as you build, you'll never catch up later. The person who knows why that particular JOIN exists or what business rule that CASE statement implements will eventually leave, and without documentation, their knowledge leaves with them.

Empower analysts with engineering practices. The modern data stack has blurred the lines between data analysts and data engineers. I've seen analysts become far more effective when they adopt software engineering practices—Git for version control, pull requests for code review, CI/CD for automated testing. The tools support this workflow; organisations need to embrace it.

My View on Where This Is Heading

Looking forward, I believe the modern travel data stack will continue evolving toward greater real-time capabilities, tighter integration between analytical and operational systems, and more sophisticated approaches to data quality and governance.

The fundamental architecture—ELT with cloud warehouses as the computational core—feels durable to me. But the specific implementations will keep improving. I expect to see better support for streaming data, more powerful incremental processing strategies, and richer semantic layers that make business logic truly reusable across the organisation.

What excites me most is how these tools are democratising sophisticated data capabilities. A small travel startup can now build data infrastructure that would have required a team of dozens just five years ago. The barrier to entry has dropped dramatically, and that's creating a more competitive, innovative industry.

The travel businesses that will thrive in the coming years are those that treat data as a strategic asset, invest in modern infrastructure, and empower their teams with the right tools and practices. The modern data stack isn't just a technical choice—it's a competitive advantage that compounds over time.

About Martin Tuncaydin

Generative AI for Travel Content: How Martin Tuncaydin Navigates Opportunity and Risk

Martin Tuncaydin — Fri, 01 May 2026 09:00:58 +0000

Generative AI for Travel Content: How Navigates Opportunity and Risk

The travel industry has always been a content-hungry beast. Destination guides, hotel descriptions, itinerary suggestions, travel tips—the sheer volume of content required to maintain a competitive digital presence is staggering. When generative AI tools like ChatGPT, Claude, and Gemini arrived on the scene, I watched many in the travel sector rush to adopt them as content factories. The promise was seductive: produce hundreds of destination guides in hours, not weeks. Scale content operations without scaling headcount.

But I've spent enough time in both travel technology and data engineering to know that technological silver bullets rarely exist. Generative AI represents a genuine paradigm shift in how we can produce travel content, but it also introduces risks that are particularly acute in our industry—risks that can damage SEO performance, erode user trust, and in some cases, put travellers at genuine disadvantage.

The Allure of Scale Meets the Reality of Hallucination

I've tested dozens of generative AI models for travel content production over the past eighteen months. The results are simultaneously impressive and deeply concerning. Ask a large language model to write a guide to Barcelona, and you'll receive fluent, engaging prose that covers the major attractions, suggests neighbourhood walks, and even throws in some restaurant recommendations. The writing quality often exceeds what you'd get from a junior content writer working to a tight deadline.

The problem emerges when you start fact-checking. I've seen AI-generated content confidently describe ferry routes that don't exist, cite opening hours that are wrong by several hours, recommend restaurants that closed years ago, and even invent entire cultural festivals. But this isn't occasional—it's systemic. Large language models are prediction engines, not knowledge databases. They generate plausible-sounding text based on pattern recognition, not verified information.

For travel content, this creates an existential problem. A hallucinated detail in a software tutorial might frustrate a developer. A hallucinated detail in a destination guide might send a family to a closed museum on their only day in a city, or worse, direct them to an unsafe area because the model mixed up neighbourhood names.

SEO Implications That Go Beyond Keywords

The SEO community has been debating generative AI content since late 2022. Google's position has evolved from "AI content violates guidelines" to "we evaluate content quality regardless of how it's produced." My interpretation of their current stance is pragmatic: they care about whether content serves users, not whether a human or machine wrote it.

But here's what I've observed in practice: purely AI-generated travel content tends to fail Google's E-E-A-T framework—Experience, Expertise, Authoritativeness, Trustworthiness. Travel content particularly relies on demonstrated experience. When I write about navigating Heathrow's Terminal 5 or finding reliable transport in Istanbul, I'm drawing on direct observation and repeated experience. AI models can simulate the language of experience, but they can't provide genuine novel insight.

I've monitored several travel websites that deployed large volumes of AI-generated destination guides in early 2023. Initial rankings were often decent—the content was well-structured, keyword-optimised, and comprehensive. But over six to twelve months, I noticed a pattern of declining performance. Google's algorithms, refined through countless updates, appear increasingly capable of detecting content that lacks genuine informational value beyond what's already well-covered elsewhere.

The issue isn't that the content is AI-generated. It's that purely AI-generated travel content tends to be derivative—a sophisticated remix of existing information without fresh perspective, updated on-ground detail, or genuine experiential knowledge.

The Human-in-the-Loop Imperative

This brings me to what I consider the only responsible approach: human-in-the-loop workflows. I don't use generative AI to replace human expertise in travel content. I use it to augment and accelerate it.

My typical workflow looks like this: I use AI to generate a structural draft and gather baseline information. Then I fact-check every factual claim against authoritative sources—official tourism websites, recent visitor reviews, mapping data. I layer in personal observations and recent developments that wouldn't be in the AI's training data. I rewrite sections to inject actual perspective rather than simulated authority.

This approach gives me perhaps a 30-40% productivity gain rather than the 10x improvement that pure automation promises. But it produces content that's accurate, current, and genuinely useful. More importantly, it produces content that performs well in search over the long term.

I've also developed a category system for travel content based on hallucination risk. Basic factual content—visa requirements, airport codes, time zones—can be AI-assisted with careful verification. Experiential content—what a neighbourhood feels like at night, how crowded an attraction gets in summer, whether a restaurant is worth the premium—requires human authorship. Safety-critical content—navigation instructions, health precautions, emergency contacts—should never be purely AI-generated.

Structured Data and the Verification Challenge

One area where generative AI shows particular promise is in creating structured data for travel content. I've used models to help generate Schema.org markup for destinations, hotels, and events. The models understand the structure well and can often produce valid JSON-LD faster than manual coding.

But again, verification is critical. I've caught AI models inventing latitude-longitude coordinates that place landmarks in the wrong city, fabricating phone numbers that follow the right pattern but reach the wrong business, and creating plausible-looking URLs that lead to 404 errors.

My approach now involves using AI to generate the structure, then validating every data point against authoritative sources. For hotel properties, I cross-reference against GDS data and property websites. For attractions, I verify against Google Maps, official websites, and recent visitor data. For events, I check official cultural calendars and news sources.

This is tedious work, but it's necessary. Publishing incorrect structured data doesn't just create a poor user experience—it can actively harm your SEO performance if Google's systems detect systematic inaccuracies.

The Authenticity Question in an AI Era

There's a broader philosophical question that I grapple with: what happens to travel content when the internet becomes flooded with AI-generated guides? If every destination ends up with hundreds of similar-sounding, competently-written but undifferentiated articles, what value does any individual piece provide?

I believe the answer lies in doubling down on what AI cannot provide: genuine personal perspective, recent on-ground observation, local insider knowledge, and the kind of nuanced cultural understanding that comes from actually spending time in a place. The travel content that will thrive in an AI-saturated landscape is content that demonstrates unmistakable human authorship.

This means featuring more first-person narrative, more specific recent observations, more local voices, more photographic evidence of current conditions. It means moving away from the generic "top ten things to do" format toward more specific, opinionated, experience-based content.

Where I Stand on This Evolution

My view is that generative AI is neither the salvation nor the death of travel content—it's a powerful tool that demands responsible use. I've integrated it into my workflow in specific, bounded ways where it genuinely adds value without compromising accuracy or authenticity.

I use it for research acceleration, structural drafting, and ideation. I don't use it for final content production, factual claims without verification, or anything safety-critical. I treat every AI-generated sentence as a draft that requires human validation and often substantial rewriting.

The travel industry's relationship with generative AI will mature over the next few years. Early adopters who treated it as a content factory are already seeing the consequences in declining search performance and user trust. Those who approach it as a productivity tool within a human-led workflow will likely find a sustainable advantage.

The technology will improve—models will get better at factual accuracy, and we'll develop better verification tools. But I don't believe we'll ever reach a point where purely AI-generated travel content can match the value of content produced by someone who's actually been to a place, understood its rhythms, and can communicate that understanding with genuine authority.

The opportunity is real, but it requires discipline, verification, and a commitment to maintaining the human expertise that makes travel content genuinely valuable. That's the balance I'm working to strike, and I believe it's the only sustainable path forward.

About Martin Tuncaydin