Large language models in plain words: why fluent is not the same as right
A large language model predicts text but does not know your hotel's records. Learn why fluent answers can be wrong and how to verify data sources in any vendor demo.
Contents
Key takeaways
- A language model writes the most plausible next words; it does not check them against anything.
- It knows nothing about your property until the software around it puts your records into the question.
- Confident grammar is cheap: the same mechanism that writes a correct sentence writes a wrong one just as smoothly.
- When the model behind an assistant changes, its answers can change without anyone touching your settings, so a fixed set of test questions is not optional.
- "Our own model" can mean four different things; ask which one before you compare anything.
A large language model is a program built from a very large body of text that produces language by predicting what comes next. It knows nothing about your hotel unless software hands it your records with the question. Fluent output is a property of the mechanism, not evidence that anything was checked.
For example, a vendor demo: the assistant answers a question about tonight's availability in flawless sentences, with a room type and a rate. The wording is perfect. The room it offers was sold that morning. After reading this article you will be able to say what a large language model actually is, in words you can repeat in a management meeting, and to run three checks in any demo that separate a real hotel assistant from a fluent one.
What is a large language model, in one paragraph?
A large language model is a program built from a very large body of text that produces language by predicting what should come next, one small piece at a time.
The build comes first. A large body of text is collected and the program is adjusted until its predictions fit that text well. This happens before any hotel uses it, and it is not repeated for your property. At the moment of use, you give it text: a question, an instruction, some records. It continues that text. That is the whole mechanism.
It works on pieces of words, not on meaning the way a person does. It has no table of your rooms and no list of facts it consults before answering. Think of an engine: general and fast, but it does not steer, does not know the destination and does not check the map. The car around it, meaning the interface, the data access, the rules and the permissions, decides what actually happens.
For a hotel this matters because the model is one link in a chain. Accuracy is won or lost in the other links: which records were fetched, which rules were applied, who confirmed the action. The model can also sit behind a voice interface or a partner system, not only a chat window. The interface is the least interesting part of the stack.
Where the model sits inside the chat window
The window your staff type into is a surface, not a brain. Behind it sits the model, and around the model sits the software that fetches records, applies rules, checks permissions and logs what happened. A demo that shows only the window is showing you the least important part. Ask what sits between the window and your data.
Key pointA definition you can repeat in a meeting
A large language model is a program that produces text by predicting what comes next, after being built from a large body of text. It writes well. It does not know your hotel, and it does not check facts unless the software makes it.
Is a large language model the same as a chatbot?
No. A chatbot is the window a person types into. A language model is one possible engine behind that window, and many chatbots run on fixed rules with no language model at all.
A rule-based chatbot follows a decision tree. It is predictable and narrow, and it cannot answer anything outside the tree. It never invents a rate because it never writes a sentence of its own. A language model on its own handles free wording well, but it has no access to your system and no authority to change anything.
A hotel assistant is the combination: a model, the hotel's records, the hotel's rules, a permission layer, and a person's confirmation for sensitive steps. The word "AI" in a vendor deck can mean any of these three. Ask which one is being shown before you judge the demo. Judge an assistant by what it can look up and what it is allowed to do, not by how human the conversation feels. A fluent chat window over an empty database is a worse product than a plain menu over a correct one.
| What it is | What it can do | What it cannot do |
|---|---|---|
| Rule-based chatbot: fixed decision tree | Answers known questions, routes to staff | Handle wording outside the tree |
| Language model alone: text engine, no hotel access | Writes and reformulates | See your rates, act, verify |
| Hotel assistant: model plus records, rules, permissions and human confirmation | Answers about the property, carries out routine actions | Be trusted on anything it cannot show a record for |
For the vocabulary around these products, see AI agent, assistant or chatbot? A glossary for hoteliers.
What does a language model know about your hotel?
Nothing, unless the software hands it your records along with the question.
It was built from general text. Your room types, your rate rules, your cancellation policy and tonight's occupancy were not in that text. Its general knowledge has a horizon: the text it was built from ends at some point, and it does not know what changed yesterday, including what changed in your own system an hour ago.
It cannot tell the difference between what it was built from and what it is guessing. Both arrive in the same steady voice, which is why the next section matters. The same model placed in two hotels gives different answers, because the records around it differ. The model is not the source of the hotel's truth; the hotel's system is.
Anything the assistant says about your property should trace back to a record you can open: a reservation, a rate rule, a bill line. A useful test in any demo: ask where the answer came from. A serious assistant shows the record or the number it used. A thin one repeats the sentence more confidently.
How does your hotel's data reach the model?
The software around the model assembles the question: your instruction, the relevant hotel records and the rules, sent together as text.
There is a lookup step before the model speaks. The system finds the reservation, the rate rule or the bill line, then includes only what the question needs. Permissions decide what may be included. A front-desk question and a finance question should not fetch the same records, and a guest-facing assistant should not see internal notes.
The model does not remember your hotel between questions unless the software stores the conversation and sends it again. Memory is a product decision, not a property of the engine. Guest names, identity details and bills are personal data under KVKK (kişisel verilerin korunması kanunu, Türkiye's personal data protection law). What is sent, to whom and under which agreement is a question for the vendor; your own duties should be confirmed with a legal adviser.
A worked illustration: for example, "what is available tonight" should fetch room inventory and rate rules, not the guest list. If the flow cannot be described that narrowly, ask why. Ask for the flow in plain words rather than a diagram: which records, at which moment, to which system, kept for how long.
ChecklistBefore signing, get written answers to these
- Which records are sent with a question?
- Who decides which records are included, the vendor or the hotel?
- What is deliberately excluded?
- How long are conversations and records kept?
- What happens to the data when the contract ends?
- Which of your staff can see the log of what was sent?
Why is a fluent answer not the same as a right answer?
Because fluency is what the mechanism produces, not a sign that anything was checked.
The model picks a plausible continuation. Plausible and true are different properties, and only one of them is what the mechanism optimizes. Hallucination in plain words: when the records do not contain the answer, the model fills the gap with something that fits the pattern, a rate, a policy, a date, a room number.
The tells are specific: a policy you do not have, a number that is oddly precise, a confident answer about a system the assistant cannot see. A cheap test: ask one question whose answer you know and one whose answer nobody knows. If both come back equally sure, the tone carries no information.
What reduces the risk is not a better writing style. It is grounding in the hotel's records, showing the record, refusing when the record is missing, and a person confirming anything sensitive. Ask whether each action sits in a safety tier: routine lookups run directly, changes need one confirmation, the most sensitive need two. Ask for the list, not the promise.
Watch outA confident sentence is not a citation
If the assistant cannot show the record behind an answer, treat the answer as a draft.
For the deeper failure modes and how to catch them, see AI hallucination in hotels: why assistants invent facts and how to catch them.
What happens when the model behind the assistant changes?
Its answers can change, including the ones you already approved, without anyone touching your settings.
A provider can update, replace or retire a model at any time. A vendor may also move to a different model for cost or quality reasons, sometimes quietly. A change can improve the average and still break the one question your front desk asks every morning. Averages hide exactly the failures a hotel notices.
The defence is a fixed test set: for example, twenty real questions from your hotel whose correct answers you know, run before go-live and again after every change. Record which model version produced which answer. Without that, a change in behavior cannot be traced to anything. The freedom to swap models is only an advantage if someone reruns the tests; model-agnostic design without retesting is just a different kind of risk. Ask who signs off a model change and whether the hotel hears about it before or after.
This is how we approach it ourselves. AI Otel's architecture is model-agnostic, and the approach is built: models are chosen per deployment by measured evaluation, and a 30-case benchmark to support that choice is built and not yet run. We have no trained model yet, and we say so plainly.
For how such evaluation is designed, see AI model evaluation for hotel work: how AI Otel will choose.
What should you ask a vendor who says "our own model"?
Ask which of four things they mean, because the phrase covers all of them.
The four meanings: they built and trained a model; they use someone else's model under an agreement; they built the layer around a model, meaning data access, rules, permissions and review; or they built an assistant product and the model is a detail inside it. Only the first is a model claim, and it needs the most evidence: what it was built from, what it was tested on, who checks the output, and what happens when it is wrong.
For the other three, the useful questions are about the layer, not the engine: which records are fetched, which actions are allowed, who confirms, what is logged, what is undone. A vendor who cannot name the model is not automatically wrong, but you cannot judge the claim, and you cannot plan a retest. Comparing prices before this conversation is comparing brochures. Write the answers down: the same questions asked at the next renewal will show whether anything changed.
| What the vendor says | What it can mean | The question that separates them |
|---|---|---|
| "Our own model" | Built from scratch, or a layer around someone else's engine | What was it built from, and tested on what? |
| "AI-powered" | Any of the three forms, including a rule-based chatbot | What can the assistant look up and change? |
| "Trained on hotel data" | A general model plus records at question time, or a model adjusted on hotel text | Which records are sent, and was the model itself changed? |
| "It learns from your hotel" | Stored conversations, or a retraining process | What is stored, for how long, and who approves a retraining? |
A fuller buyer's checklist is in Questions to ask an AI vendor before buying for your hotel.
What to do before the next demo
Write down ten questions about your own hotel whose answers you know. Ask the assistant those, and ask for the record behind each answer. Then ask which model serves the reply, how it was chosen and how it will be retested when it changes. The model is the engine, your records are what it is handed, fluency proves nothing, and a change of engine is a reason to test again.
If you want to see how we handle this layer, you can request a briefing.
Frequently asked questions
Does a large language model learn from my hotel's data?
Not by default. The model is built before your hotel uses it, and a question and its records do not change it. What can change is the software around it, which may store conversations or send them again next time. If a vendor says the model itself is adjusted on hotel text, ask what was used, who approved it and how the result was tested.
Can an assistant answer about my hotel without sending guest data anywhere?
That depends on how the product is built, not on the model's nature. Some questions need only inventory and rates; others touch names, identity details and bills, which are personal data under KVKK. Ask the vendor for the flow in plain words and confirm your own position with a legal adviser.
How do I tell whether an answer came from my records or from the model's general knowledge?
Ask for the record behind the answer and open it in your own system. Answers built on records usually point to a reservation, a rate rule or a bill line. Answers built on general knowledge tend to be smooth, general and impossible to trace. Asking the same question in different words is a quick second check.
Is a bigger model always better for hotel work?
No. Size is one property among several and says nothing about how a model handles your room types, your rate rules or your language mix. What matters is measured performance on the tasks your staff actually ask, which is why a fixed test set beats a specification sheet.
Do I need to retest the assistant after an update?
Yes, and the update may not be announced. Providers change models and vendors change suppliers. Keep a short set of questions with known answers, rerun it after any change, and record which model version produced which answer so a shift in behavior can be traced.