AI assistant for choosing tours and hotels in Uzbekistan: solution architecture
A tourist does not ask for 'a 4-star hotel in Samarkand', they ask 'where should we go for four days in October with kids'. Free-form matching is exactly where an LLM earns its place.
How this differs from a filter
Classic site search demands the user already knows the parameters: city, dates, category. A large share of tourists, especially foreign ones, do not have those parameters and leave before filling the first filter.
An AI assistant takes the request as-is: budget, group composition, interests, time constraints. It then asks two or three clarifying questions and converts free text into a structured query against your database.
The key point is that the model does not invent options, it builds a filter. The answer is assembled from your real tours and hotels, while the model is responsible for understanding the request and explaining the choice.
Data sources and availability
You need three layers: a reference of destinations and sights that changes rarely; a catalogue of tours and hotels with descriptions; and live availability and pricing that changes daily.
The first two layers go into a vector index for semantic search. The third layer is direct API or database calls at request time only. Caching prices and availability in the vector index is not an option: a stale price in an answer means a dispute at booking.
If you work with external booking systems, plan for degradation: when the API is unavailable the assistant shows the option without a firm price and offers to confirm with a manager rather than going silent.
Languages and cultural context
The audience here is wider than a typical local site's: Russian, Uzbek and English at minimum. Foreign tourists care about things locals never think of: visa requirements, currency exchange, dress code at mosques, intercity transport schedules.
Put those topics into the knowledge base explicitly. A model without data will answer visa questions from memory, visa rules change, and a stale answer here is expensive — up to a ruined trip.
Store place names with variants: Registon, Registan, Регистан. A foreign tourist types them as they heard them, and search must tolerate that.
From matching to booking
Do not try to complete booking inside the conversation in version one. The realistic goal is reaching a request with a fixed parameter set and handing it to a manager or a booking system.
For the local audience the flow almost always ends in Telegram: matching on the site, continuation and payment in the bot. For foreign visitors it is email and card payment, since part of that audience has no Telegram at all.
Payments: local cards through Payme or Click, foreign cards through international acquiring. These are two separate integrations and pretending one covers both audiences will not work.
Hallucination control
A hard rule: every fact in an answer must have a source in your data. Distance between cities, travel time, entry fees, museum opening hours — all from the reference data, never from model memory.
Implement an output check: if the answer contains a place name absent from your database, the answer is not sent but regenerated under a tighter constraint.
State clearly in the interface that final prices and availability are confirmed by a manager. That is not a disclaimer dodge but an honest reflection of how a dynamic-pricing market works.
What it costs
Market reference: an assistant with semantic matching over your own catalogue and lead handoff runs 30M – 70M UZS. With full booking and payment integration the figure multiplies.
The bulk of the work is not the model but the data: place descriptions, reference tables, synchronization with booking systems. If the catalogue is unstructured, start there or the assistant will be matching against nothing.
Model running costs on tourist traffic are seasonal and at peak typically fit into 1M – 3M UZS per month with sensible context limits.