Hallucination is not a model bug you can patch. It is a fundamental property of how language models generate text: they produce the most statistically likely continuation of your prompt, not a verified fact. The model does not know what it does not know — unless you tell it how to signal uncertainty.
The practical implication: you cannot stop hallucinations by switching models. You can reduce them significantly by changing how you prompt.
Why Models Hallucinate
A language model has no external memory or lookup mechanism. When it does not have relevant training data for a specific question, it does not fail silently — it generates plausible-sounding text that continues the pattern of your prompt.
Two things make this worse:
Confidence is independent of accuracy. The model's fluency does not indicate correctness. A hallucinated library API and a real one look identical in the output.
Prompts can create pressure to answer. A direct question creates a strong implicit expectation of a direct answer. The model complies — even when it should not.
Prompt Patterns That Trigger Hallucinations
Before fixing your prompts, recognize the patterns that cause problems:
Asking for specific facts without grounding. What are the exact API rate limits for Stripe's Checkout API? — the model will produce numbers. They may be outdated or fabricated.
Asking for citations. Cite the research paper that proved X — models generate plausible-looking citations with real author names and incorrect DOIs. This is one of the most dangerous hallucination vectors.
Compound questions that require both retrieval and reasoning. When a question mixes a factual lookup with an analytical task, the model may fabricate the fact to proceed with the reasoning.
Open-ended "what else" prompts. What are all the ways this could fail? invites the model to fill the list with plausible-sounding but unverified items.
Five Techniques to Reduce Hallucinations
1. Explicitly permit "I don't know"
The most effective single change. By default, the model is trained to be helpful, which means it attempts to answer every question. Overriding this:
If you are not certain about specific facts, version numbers, or API details,
say "I'm not certain about this — verify before using" rather than guessing.
This does not make the model less capable. It makes it honest about the boundary of its knowledge.
2. Ground the model in provided context
Instead of asking the model to retrieve facts from training data, provide the facts and ask the model to reason about them.
Hallucination-prone:
What does the Stripe payment intent API return when a card is declined?
Grounded:
Based on the following API documentation excerpt, explain what is returned when a card is declined:
[paste relevant docs section]
The model's job becomes analysis, not retrieval. Hallucination risk drops significantly.
3. Request self-verification
For high-stakes outputs, ask the model to check its own work before responding:
Before giving your final answer, verify:
1. Are all library names and versions accurate?
2. Are all function signatures correct?
3. Are there any claims you are less than 90% confident about?
Flag any uncertain items in your response.
This does not guarantee accuracy, but it externalizes the model's uncertainty — giving you a checklist of what to verify rather than an output that appears uniformly confident.
4. Constrain the answer space
Hallucinations increase when the answer space is large and unconstrained. Narrow it.
High-risk:
List all the security vulnerabilities in this code.
Lower-risk:
Check this code for the following specific issues only:
- SQL injection via string concatenation
- Missing input validation on user-supplied parameters
- Exposed secrets in hardcoded strings
Report only what you find. Do not add categories not listed above.
The model cannot hallucinate a vulnerability category you did not provide. It can only confirm or deny what you asked about.
5. Use chain-of-thought for factual reasoning
Forcing the model to reason step-by-step before giving a final answer exposes errors that a direct answer would hide:
Before answering, list the specific facts your answer depends on.
Then give your answer.
Then flag any of those facts that you are not fully confident about.
Factual errors surface in the reasoning step, where they are easy to spot and verify.
Verification Prompt Template
For any output where accuracy is critical:
Task: [Your task]
Instructions:
- Use only the information provided in [context/document/code] below.
- If the answer is not in the provided information, say "Not found in provided context."
- Do not infer, extrapolate, or add information not explicitly present.
- If you are uncertain about any specific detail, flag it with [VERIFY].
[Your context]
This pattern is particularly effective for document Q&A, code analysis, and any task where you have a ground-truth source the model should stick to.
The Prompt Quality Connection
Hallucinations are strongly correlated with low prompt quality scores — specifically with poor context density and missing failure handling. A prompt that provides no grounding material and no instruction on how to handle uncertainty is maximally hallucination-prone.
Promptuner flags missing failure handling as a quality dimension in its live score. When your prompt does not specify what the model should do when uncertain, the score reflects it — and the 1-click refactor inserts the appropriate uncertainty handling language automatically.
You cannot trust a model to be accurate by default. You have to engineer the prompt so that honesty is easier than fabrication. Explicit uncertainty permission, grounded context, and constrained answer spaces make the correct behavior the path of least resistance.