Every major language model hallucinates. They generate plausible-sounding false information with absolute confidence. A model will invent a study that does not exist, cite a book with a made-up title, describe a historical event that never happened, or quote someone saying something they never said.
These are not occasional edge cases or bugs that scale fixes training away. They are a fundamental consequence of how language models work. Understanding this changes how you use them.
Why this happens
A language model predicts the next word based on everything that came before. It has no mechanism for looking things up, no way to know what is true or false, and no concept of the difference. It knows that plausible sounds better than obvious nonsense, so it generates plausible text.
When asked “Who said ‘the future is already here’?” the model might generate “Douglas Adams” or “Kurt Vonnegut” — both plausible answers that sound like the kind of people who would say profound things. The model has no access to a reference library and no way to check. It is pattern-completing based on what kind of answer typically follows that kind of question.
The distinction is critical. A search engine that cannot find a result tells you it cannot find a result. A language model that cannot find a result makes one up and presents it as fact.
This is not trainable away. Every model that exists hallucinates. Models trained on bigger datasets hallucinate. Models fine-tuned on curated data hallucinate. Models that are explicitly instructed to be careful still hallucinate. The frequency and severity vary, but the behaviour is consistent.
Where hallucinations matter and where they don’t
Hallucination is not equally problematic in every context.
If you are brainstorming, drafting rough notes, or exploring ideas, hallucination barely matters. You are using the model as a thinking partner, not as a source of truth. The model says something, you think “is that right?” and you check or discard accordingly.
If you are generating fiction, hallucination is irrelevant. Invented quotes and fictional historical details are exactly what you want.
If you are writing marketing copy where no fact claim is made, or technical documentation that will be reviewed by someone who knows the subject, the cost of hallucination is manageable. The reviewer will catch the invented details.
But if the model is being asked to provide factual claims that will be published or acted on without review, hallucination becomes a liability. A law firm cannot use AI to summarise a contract and trust the summary. A doctor cannot use AI to list drug interactions for a medication and publish the result. A journalist cannot quote an expert who does not exist.
The design patterns that work
Grounding in provided data. The most reliable way to reduce hallucination is to give the model source material to work from. “Summarise the attached report” produces far fewer hallucinated facts than “tell me about this company.” “Answer based on the provided documentation” performs better than “answer based on your knowledge.”
The model still occasionally invents details, but it is constrained to inventing details consistent with the sources provided. This is manageable if you have someone reviewing the output.
Explicit uncertainty. Ask the model to flag when it is not confident. “If you are uncertain about any fact, note it explicitly” produces output where uncertainty is marked. You can then review those sections carefully and the confident sections less so.
This does not work perfectly — models sometimes hallucinate confidently and sometimes express uncertainty about things they actually know — but it improves things.
Decomposition. Break the task into steps that can be verified. Rather than asking for a complete analysis, ask for a list of questions to research, then research them, then ask for analysis based on the research. This moves the hallucination problem to the boundary between steps where human review naturally sits.
Semantic search over retrieval. If you need to provide the model with context, embedding-based search that finds relevant passages usually beats dumping an entire document. The model gets the specific information it needs without being overwhelmed by irrelevant context that increases hallucination risk.
Multi-model verification. Ask two different models the same question. If both give the same answer, it is more likely to be correct. If they diverge, you know to review carefully. This costs more but is useful for high-stakes claims.
What doesn’t work
Longer instructions. Telling a model at greater length to be careful, to check its facts, to prioritise accuracy, or to warn you if uncertain produces almost no improvement. The model knows these things already. More instruction noise does not help.
Fine-tuning on factual data. Training a model on datasets of curated facts does reduce hallucination slightly but does not fix it. The model still hallucinates, just somewhat less.
Chain-of-thought prompting. Asking the model to reason step-by-step before answering reduces hallucination in some domains but not others. It is useful for logic problems and mathematical reasoning. For factual claim generation, it produces more confident hallucinations, not fewer.
Temperature adjustment. Lowering temperature to zero does not stop hallucination, though it makes the model more deterministic. It still generates false information.
Building systems that tolerate hallucination
The honest approach is to accept hallucination as a given and design accordingly.
If the output will be reviewed, explicitly assign someone to review it. That person is not a luxury; they are part of the system. Plan for their time in the timeline.
If the output is going to be published, add a review step specifically for factual claims. This is faster than reviewing everything and better than reviewing nothing.
If the output is going into a system that other people will depend on — a knowledge base, a customer-facing document, a decision support tool — build in a process to verify it before it becomes the source of truth for someone else.
If you cannot afford review, you cannot afford to use AI for that task. The fact that the output is plausible and well-written makes unreviewed hallucinated claims especially dangerous, because people believe them.
When hallucination tells you something useful
Hallucinations sometimes reveal gaps in training data. If a model consistently makes up the same kind of false information, it suggests there is a pattern it is trying to fit to and data missing to fit it correctly.
If you are building a system on top of AI output, hallucination patterns are sometimes predictable and therefore defendable against. If a model always makes up citations in a particular format, catching that format is automatable. If it tends to hallucinate details in specific categories, those categories are natural review points.
The most reliable systems treat hallucination not as a flaw to be hidden but as a predictable behavior to be accounted for.
The framework
Use AI for factual claims only when you can verify them. Use it for drafting and ideation freely. Use it for writing that will be reviewed with the understanding that review must cover factual claims. Build review into the workflow rather than hoping it will happen.
And stop waiting for a model that does not hallucinate. That is not a version away. It is not a training approach away. It is not coming. Design for the model you have, not the model you wish existed.