Most teams trying to reduce hallucinations are doing some of the right things and unknowingly undoing them with the wrong ones. The failure modes are rarely dramatic. They are quiet, reasonable-looking habits that feel like they should help and actually make the model invent more.
This article names seven of them. For each, we cover why it backfires, what it costs in practice, and the corrective practice to replace it. The pattern across all seven is the same: vague good intentions lose to concrete mechanisms. A prompt that feels careful is not the same as a prompt that grounds the model.
Read these as a diagnostic. If you recognize your own prompts here, you have found cheap wins.
Mistake 1: Telling the Model Not to Hallucinate
The instinctive fix is a line like "do not make anything up" or "only state true facts." It feels responsible. It does almost nothing.
Why it backfires
The instruction is unactionable. The model has no internal truth-checker to consult, so "do not hallucinate" gives it nothing to actually do differently. It generates the same plausible guesses, now with a clear conscience.
The corrective practice
Replace the plea with a mechanism: supply source material and require the model to answer only from it. A concrete grounding instruction changes behavior; an abstract one changes nothing.
Mistake 2: Not Giving the Model a Way to Say No
Many prompts implicitly demand an answer to every question. The model, trained to be helpful, complies even when it should not.
Why it backfires
Without an explicit abstention option, the model treats every question as answerable. When it lacks the answer, it invents one rather than admitting the gap.
The corrective practice
Add a clear exit: "If the provided information does not answer the question, say you do not have that information." This single clause converts a forced guess into an honest abstention.
Mistake 3: Relying on the Model's Memory Instead of Sources
Asking factual questions with no supplied context forces the model to reconstruct facts from training, which is lossy and dated.
Why it backfires
The cost shows up as confidently wrong dates, numbers, and names. The model is not lying; it is reconstructing a fuzzy memory and filling the blanks.
The corrective practice
Ground the prompt in retrieved or pasted source material whenever the answer should come from specific facts. Convert the open-book guess into a closed-book lookup.
Mistake 4: Mixing Instructions and Data Together
Pasting source text inline with your instructions, with no separation, lets the model blur the line between what it must do and what it should treat as fact.
Why it backfires
The model may follow stray instructions hidden in the data, or treat your authoritative source as optional. Both lead to ungrounded output, and the failure is hard to diagnose.
The corrective practice
Delimit the source material clearly and label it. Tell the model explicitly which block is data to draw from and which block is the instruction. Clarity here prevents whole categories of drift.
Mistake 5: Asking Sprawling, Open-Ended Questions
Broad prompts like "tell me everything about this" give the model acres of room to embellish.
Why it backfires
The more open the request, the more the model fills with plausible-sounding additions that were never in the source. Length correlates with fabrication.
The corrective practice
Narrow the question and constrain the output shape. Specific questions with bounded formats—fields, short lists, defined slots—leave little space for invention. This connects directly to the structure work in Build a Fabrication-Resistant Prompt in Eight Moves.
Mistake 6: Trusting the Model to Verify Itself in One Pass
Asking a single prompt to generate an answer and confirm its own accuracy feels efficient. It is unreliable.
Why it backfires
A model checking its own freshly generated answer tends to rationalize it rather than scrutinize it. The self-check rubber-stamps the fabrication.
The corrective practice
Use a separate verification pass with a fresh frame: "Is this answer supported by the provided text?" An independent check catches what the generation step missed.
Mistake 7: Never Testing on Unanswerable Questions
Teams test prompts on questions the source can answer and declare victory. They never test the cases that trigger fabrication.
Why it backfires
The whole risk lives in questions the source cannot answer. If you never test those, you never learn whether your prompt abstains or invents. You ship blind.
The corrective practice
Build a test set that deliberately includes unanswerable questions, and confirm the model abstains on all of them. This is where hallucination actually shows up. For how to assemble and run such a set, see Stop Your Model From Inventing Facts at the Prompt Layer, and to lock the habit into a routine, see The Pre-Ship Checklist for Keeping AI Answers Grounded.
The Pattern Behind the Mistakes
Step back from the individual errors and a single theme connects all seven. Each mistake substitutes a hopeful intention for a concrete mechanism, and the model is indifferent to intentions.
Vague good intentions lose to mechanisms
Telling the model to be accurate, trusting it to verify itself, leaving questions open-ended—each of these is a wish about how the model should behave. The model does not act on wishes. It acts on what the prompt operationally gives it to do: a source to read, an exit to take, a citation to produce. The fix in every case is to convert a wish into a mechanism.
Why these mistakes feel right
The reason these patterns persist is that they feel responsible. Adding "do not hallucinate" feels like diligence. Letting the model self-check feels efficient. Testing on questions you can answer feels like validation. The feeling of having addressed the problem is exactly what makes these mistakes dangerous, because it stops people from adding the mechanisms that would actually work.
Auditing your own prompts
Run your current prompts through these seven as a checklist. For each, ask whether you have a mechanism or merely an intention. A prompt that supplies a source, restricts the model to it, offers an exit, requires evidence, and gets tested on unanswerable cases has mechanisms at every point. A prompt full of careful-sounding instructions and no source has intentions and little else.
Frequently Asked Questions
Is telling the model to be accurate ever worth including?
It does little harm, but it should never be your primary defense. Treat it as decoration on top of real mechanisms—grounding, abstention, and citation requirements—that change what the model actually does. On its own, the instruction provides false reassurance.
Why does mixing instructions and data cause problems if the model usually figures it out?
It usually does, until it does not. Undelimited data invites two failures: the model treating your facts as optional, and the model following instructions accidentally embedded in the source. Both are intermittent, which makes them harder to catch and more dangerous in production.
How many unanswerable questions should my test set include?
Enough to be representative of the gaps real users will hit—often a meaningful fraction of the set, not a token few. The unanswerable cases are where fabrication lives, so under-weighting them hides the exact failure you are trying to measure.
Can I skip the separate verification pass to save cost?
For low-stakes tasks, yes. For anything where a confident wrong answer causes real harm, the second pass is worth the cost. A single self-verifying prompt tends to approve its own fabrication, so the savings come with a reliability penalty.
What is the single most common mistake?
Not giving the model a way to say no. Most prompts implicitly demand an answer to everything, and the model's helpfulness fills any gap with invention. Adding an explicit abstention clause is the cheapest, highest-impact correction on this list.
Key Takeaways
- Telling a model not to hallucinate is unactionable; replace pleas with concrete mechanisms like grounding and abstention.
- The most common and costly mistake is failing to give the model an explicit way to say it does not know.
- Relying on the model's memory and mixing instructions with data both produce ungrounded, hard-to-diagnose output.
- Sprawling questions and single-pass self-verification both increase fabrication; narrow scope and an independent verification pass reduce it.
- If you never test on unanswerable questions, you never measure the failure you care about most.