Hallucination

What a hallucination is

A hallucination is an invented statement by a language model, phrased fluently and convincingly but not resting on any source. The term does not describe a technical fault but a property of the method: a language model predicts likely continuations, and a likely continuation is not the same as a true statement.

That is why a hallucination cannot be spotted by tone. Invented details sound exactly as confident as sourced ones. Anyone reviewing output has to review the content, not the wording. That is the expensive part in practice.

Where it gets expensive in a shop

• Product details: Technical values, dimensions, materials and compatibility. An invented measurement leads to returns and complaints.
• Price statements: Claims about discounts, deadlines or warranties that are wrong create legal exposure and may bind you.
• Legal information: Answers on withdrawal, warranty or data protection. Wrong information is not help, it is risk.
• Translations: An invented meaning of a technical term changes the content without anyone noticing.
• Internal reports: An invented number in a report becomes the basis for a decision.

Why it happens

Three causes are typical. First, missing knowledge: the model has no information about the specific item or the current price and fills the gap with a plausible assumption. Second, conflicting sources: when several details are present, they get mixed instead of one being chosen. Third, the form of the question: forcing an answer gets an answer, even when none exists.

The causes determine the countermeasures. Where knowledge is missing, providing the source helps. Where sources conflict, a fixed order of precedence helps. Where the question forces an answer, a rule that explicitly permits a fallback answer helps.

What works

Four measures are effective and implementable without major technical effort. First, source binding: the model may answer only from the material provided, and if nothing is there it must say so. That instruction is the single strongest measure, because it addresses the cause.

Second, permission to decline. A model allowed to say "no information available on that" invents less than one required to always produce an answer. Third, verification of critical fields, meaning prices, deadlines, dimensions and legal details, against your own system rather than against the text. Those fields must never come from generated output, only from the data source.

Fourth, application limits. For tasks with high risk and fully known rules, a fixed rule set suits better than a language model: shipping cost calculation, tax rates and availability belong in the system, not in a sentence. A language model makes sense where text is written, not where values are determined.