Large language models are remarkable at producing fluent, confident, well-structured text on almost any subject — and that is exactly the problem. They are equally fluent when they are right and when they are completely wrong. When a model produces a fluent, plausible, detailed answer that simply is not true, we call it a hallucination: a statement that looks like a verified fact, sounds like a verified fact, and is presented with the same confidence as every other statement in the response, but is actually fabricated. Hallucinations are not a bug you can wait out — they are structural to how autoregressive language models work. The model's job is to produce the most likely next token, not the most accurate next fact, and most of the time those two goals align but a meaningful fraction of the time they do not.

The good news is that while you cannot eliminate hallucinations entirely, you can dramatically reduce their frequency and severity through thoughtful prompt engineering. The techniques below are the same ones used by AI engineers at OpenAI, Anthropic, Google, and large enterprise teams deploying LLMs in production. They do not require any special access, paid plugins, or technical infrastructure — they are all things you can apply in your very next chat session, regardless of whether you're using ChatGPT, Claude, Gemini, or an open-source model. This guide will walk through what hallucinations actually are, why they happen, and most importantly, the concrete prompt patterns that reduce their frequency and make the remaining ones much easier to catch.

What Hallucinations Actually Are (and Are Not)

Before getting into prevention, it's worth being precise about what counts as a hallucination.

A hallucination is a confident, specific, falsifiable statement that is not grounded in either the model's actual training data or any source you have provided. Examples include:

A fabricated case citation (a real-sounding case name with volume, reporter, and page number that simply does not exist)
A made-up API method or library function that does not exist
A plausible-sounding statistic ("47% of consumers in a 2023 Pew study said...") where the study does not exist
A quote attributed to a real person who never said it
A library or package that does not exist (a particularly common problem for code generation)

These are the dangerous ones because they look exactly like real citations, real sources, and real facts. They are not distinguished from true statements in any visible way — the model assigns the same "confidence" stylistically to both.

A non-hallucination is something else that people often conflate with it:

A model saying "I'm not sure" or refusing to answer — this is actually the desired behavior, not a hallucination
A model producing a wrong answer that is clearly hedged or uncertain — this is wrong but not hallucinated
A model generating a creative or speculative response when explicitly asked to speculate — this is the model doing what you asked

Conflating these leads to confusion. Refusal and uncertainty are good. Confident fabrication is bad. Everything in this guide is aimed at converting the latter into the former — at making models more willing to say "I don't know" rather than fabricating the missing piece.

Why Models Hallucinate (The Short Version)

Understanding even a little of the underlying mechanism helps with prompt design. Three failure modes matter most:

1. Knowledge boundary pressure. When you ask a model for information at the edge of or outside its training data, the most likely next tokens may still look like a real answer even when no real answer exists. The model cannot introspect on its own knowledge gaps reliably — it cannot in general tell the difference between "I know X" and "I have seen many X-like statements." Asking for citations, specific dates, or named authorities puts you squarely in this risk zone.

2. Sycophancy and confirmation pressure. Models are trained to be helpful, and "helpful" gets operationalized as "give the user what they appear to want." If your prompt implies an expected answer ("Isn't it true that...", "I'm pretty sure the rule is..."), the model tends to go along rather than correct you, even when you are wrong. This is a particularly dangerous failure mode because users often prompt in ways that subtly invite confirmation.

3. Plausibility winning over specificity. LLMs assign probabilities to next tokens. When the next token is a real-sounding fact, even an invented one, and the alternative is "I don't know," the math often favors the confident-sounding path. This is structurally built into how the models work — the only way to shift the probability in favor of refusal is through prompt design that explicitly rewards refusal when appropriate.

The techniques below address each of these failure modes directly.

Technique 1: Source Grounding (The Single Most Important Pattern)

The single most effective hallucination reduction technique is to constrain the model to a source you provide and explicitly forbid it from going outside that source. This sounds simple but is consistently underused, especially by casual users.

You are answering questions based ONLY on the source material provided below. Rules:
1. If a question can be answered from the source, answer it and quote the relevant sentence(s) from the source.
2. If a question cannot be answered from the source, respond with: "Not addressed in the provided materials."
3. Do not use any outside knowledge, training data, or general world knowledge to fill gaps.
4. Do not infer, extrapolate, or speculate beyond what is explicitly stated in the source.
5. Cite each quote back to the source using the format: [Source: paragraph N].

[SOURCE MATERIAL BEGINS]
[paste your source here]
[SOURCE MATERIAL ENDS]

Questions:
1. [your question]
2. [your question]

This pattern converts a general-purpose LLM into a tightly scoped Q&A engine over a specific document. Hallucinations drop dramatically because the constraint is explicit, the refusal protocol is predefined, and the model is told what to do (quote) rather than what to make up. It works well for any context where you have a source document — research papers, contracts, internal policies, technical documentation, customer support transcripts — and want answers grounded in that source rather than the model's general training data.

Note the specific instruction to quote and cite paragraphs. This is critical because it gives you something verifiable — you can check each quote against the original. Without the citation requirement, the model might paraphrase in ways that subtly distort the source, which is its own (milder) form of inaccuracy. With the citation requirement, you have a one-to-one correspondence between the model's claim and your source text.

Technique 2: Citation Refusal Protocol

When you cannot or do not want to provide source material, ask the model for citations AND give it an explicit protocol for refusing. This is the key insight: most users ask for citations without giving the model permission to refuse. A model that has not been told it can refuse will fabricate a citation rather than admit it does not know.

I am asking you about [topic]. Please answer the question below, but follow these citation rules strictly:

1. If you cite any case, statute, regulation, study, paper, or document, you MUST be confident it exists. If you are not confident the cited source exists, do not cite it.
2. If you can answer the question without citing any specific source, do so and flag the answer as "general knowledge — please verify independently."
3. If you cannot answer without citing a source you are not certain exists, respond: "I do not have a verifiable source for this — you should research this in [recommended source type]."
4. Do not provide volume/issue/page/study numbers unless you are highly confident they are correct. Inventing these is the single most dangerous failure mode.

Question: [your question]

The fourth rule is important because fabricated study/citation metadata (volume, issue, page, year) is exactly what makes hallucinated citations so dangerous — they look completely real. Telling the model not to provide that metadata unless it's highly confident is a meaningful safeguard. The third rule gives the model a graceful exit when it does not know, which is what you want.

Technique 3: Decomposition (Don't Ask Compound Questions)

Multi-part questions dramatically increase hallucination risk because the model tries to produce a coherent narrative across multiple uncertain sub-questions, and the urge to maintain narrative coherence pushes it toward confident-sounding fabrication when one of the sub-answers is unknown.

Bad prompt:

"Tell me about the 2023 Supreme Court case on affirmative action, the dissenting justices, the vote breakdown, and the key holdings, plus what the major law reviews said about it."

This is five distinct questions, all of which invite confident factual claims. If the model is uncertain about any single one, the urge to produce a complete, coherent answer will bias it toward fabrication.

Better prompt: decompose into separate, individually answerable questions, and ask the model to answer them one at a time, with permission to flag uncertainty:

I am going to ask you a series of separate questions. Answer each one based only on what you can verify. For each answer, mark your confidence at the start as [HIGH CONFIDENCE], [MEDIUM CONFIDENCE], or [LOW CONFIDENCE / NOT SURE]. If you do not know the answer, say "I am not certain of this — please verify independently" and stop. Do not combine uncertain answers with certain ones in a single paragraph.

Question 1: What was the vote breakdown in the 2023 Supreme Court affirmative action case (Students for Fair Admissions v. Harvard)?
Question 2: Which justices dissented?
Question 3: What were the two main holdings?
[continue with additional questions]

Decomposition seems cumbersome, but it produces dramatically more reliable output. Instead of a narrative that hides uncertainty behind fluency, you get per-question confidence flags that make the verification workload manageable.

Technique 4: Explicit Anti-Sycophancy Prompting

Sycophancy — the tendency to agree with the user's implied premise — is a major cause of confident-sounding wrong answers. When users embed a wrong assumption in their prompt ("Why does X happen?"), models frequently answer the question as asked rather than correcting the premise.

I am asking you about [topic]. I may have a misconception or false premise in my question — please do not assume my framing is correct. Before answering:

1. Identify any factual premise in my question that you believe is wrong, and explicitly correct it.
2. If part of my question is correct and part is wrong, address only the correct part and explain why the wrong part is wrong.
3. If my question contains a false dichotomy, identify it before answering.
4. Do not agree with claims I make or imply agreement by building on them — evaluate each claim independently.

My question: [your question]

This pattern catches a remarkable fraction of pre-loaded assumptions. Users frequently arrive at LLMs with a partly-correct frame — "Why did my boss fire me illegally?" — and the model's tendency to engage with the implied premise produces output that inadvertently endorses the user's interpretation. Anti-sycophancy prompts flip this: the model is told to evaluate the premise first, and the output becomes much more reliable as a result.

Technique 5: Structured Output Formatting (Forces Specificity)

Vague, narrative-style answers are harder to verify than structured, formatted ones. Asking for structured output (tables, JSON, numbered lists with explicit fields) forces the model to be specific rather than fluently vague, and makes any fabricated field much more obvious.

For each of the following items, provide a structured table with these exact columns:
- Claim: [the specific factual claim]
- Source type: [case / statute / study / paper / news article / book / "general knowledge"]
- Source citation: [full citation, OR "Not available — general knowledge" if no specific source]
- Confidence: [HIGH / MEDIUM / LOW]
- Verification step: [single sentence on how the user could independently verify this claim]

If you cannot fill in the Source citation column with a real, verifiable source, put "Not available — general knowledge" in that cell and flag the row as LOW confidence. Do not put a fabricated citation in that column.

Items:
1. [claim 1]
2. [claim 2]
3. [claim 3]

The structured format reveals gaps cleanly. A row with "Not available — general knowledge" in the source column is immediately clear about what you need to verify and what you cannot. A row with a fabricated citation would eventually fail verification, but the explicit requirement to either provide a real citation or admit none exists shifts the model toward the second behavior rather than the first.

Technique 6: Retrieve-Then-Answer Pattern (RAG-Adjacent)

For higher-stakes use cases, use a retrieve-then-answer pattern even in plain chat. The idea is to do two model calls: the first one retrieves and organizes what the model knows, the second one answers strictly from that retrieved material. This is the manual version of what RAG (retrieval augmented generation) systems do automatically.

STEP 1 (do not answer the question yet):
List every specific factual claim, citation, or statistic you would need to answer the following question. For each, label it [KNOWN] if you are confident it is in your training data, [PARTIAL] if you have some relevant information but not a complete answer, or [UNKNOWN] if you do not have reliable information.

Question: [your question]

[After you provide this list, I will tell you which claims to pursue and which to drop before you answer.]

This pattern surfaces the model's actual knowledge gaps before it starts writing an answer, which gives you the chance to either provide source material for the gaps, drop unreliable parts, or push the model toward a more conservative answer.

Technique 7: Refusal-Aware System Prompts

If you are using system prompts (in applications, APIs, or custom GPTs), your system prompt should include explicit anti-hallucination instructions as a baseline. A useful pattern:

You are a careful, reliable assistant. Your core principles, in priority order:

1. Accuracy is more important than completeness. A correct "I don't know" is better than a wrong answer that sounds certain.
2. Never invent citations, statistics, study references, quotes, dates, or named entities. If you cannot recall a specific source, say so.
3. If a question is at the edge of or outside your knowledge, flag your uncertainty explicitly before answering.
4. If asked to provide a citation you are not certain exists, respond: "I am not confident I can provide a verifiable citation for this — I recommend researching this independently."
5. Distinguish between what is generally known and what you can verify with specific sources.
6. When you provide an answer you are not confident in, prefix it with [UNCERTAIN] and explain what is uncertain.

Apply these principles across every response, regardless of the specific question.

These are cheap to add to any system prompt and meaningfully shift the model's default behavior across every conversation rather than just the ones where you remembered to repeat the rules.

Technique 8: Ask for Verifiability Markers

A subtle but effective prompt pattern is to ask the model to flag the verifiability of each factual claim in its answer. This is different from asking for citations — it's asking the model to characterize its own confidence.

As you write your answer, mark every factual claim with one of these tags immediately before or after the claim:
- [VERIFIABLE]: I am confident this is true based on widely-known information that the user can easily verify.
- [LIKELY]: I believe this is true based on my training but the user should verify before relying on it.
- [UNCERTAIN]: I am not confident — please verify independently before relying on this claim.
- [GENERATED]: This is a generated/synthesized claim based on reasoning rather than specific recall.

Use the tags exactly. Do not omit them for factual claims. If you would mark a claim as GENERATED or UNCERTAIN and the answer would be incomplete without it, briefly flag what kind of source the user should consult to verify it.

This pattern produces output where every factual claim is annotated, which makes verification much faster and makes the hallucinations much more visible. A paragraph full of [VERIFIABLE] tags requires less review effort than an untagged paragraph where you have to assess every sentence independently.

Why These Techniques Work (And Where They Fall Short)

Each technique above addresses one of the structural causes of hallucination: source grounding closes the knowledge-gap problem; refusal protocols turn "confident fabrication" into "explicit refusal"; decomposition attacks narrative-coherence pressure; anti-sycophancy prompting addresses confirmation bias; structured output forces specificity. None of these techniques is a silver bullet — even with all of them applied, a sufficiently determined user can provoke a hallucination by reframing the question in ways the prompt does not anticipate. But applying as many of these as possible, as consistently as possible, reduces the rate of hallucinations by a large margin and — importantly — makes the ones that remain much easier to catch, because the structure of the output reveals what to check and where to be skeptical.

What these techniques cannot do is make a model correct about a topic that is fundamentally outside its training data. If you ask a 2024-trained model for the outcome of a 2026 court decision, no prompt pattern will save you — the model cannot know what has not happened yet. The right answer in that case is "I do not know" — and getting the model to say it reliably is a meaningful accomplishment.

Verification Practices That Complement Good Prompting

Prompt engineering reduces hallucinations, but it does not replace verification. A complete workflow for high-stakes factual claims should include:

Citation verification — Every case, study, paper, or document the model cites must be located in the original source. Free tools like Google Scholar, court websites, and arxiv cover most cases.
Quote verification — Any quote the model attributes to a real person or document must be checked against the original. This is especially important for legal and historical quotes, where wording matters.
Statistic verification — Any specific percentage, count, or dollar figure must be triangulated against at least one independent source. Be especially skeptical of statistics that appear with suspiciously precise numbers ("47.3% of consumers said...").
Code verification — For code generation, every API method, library function, and package name must be checked. Models routinely invent plausible-sounding methods that do not exist. Always run the code or pass it through a documentation search.
Date verification — Dates of events, court decisions, product releases, and especially "release" of recently-announced tools should always be checked. Models frequently confuse announcement dates and release dates.

A good prompt engineering practice is to design your prompts so that the resulting output makes this verification easier — by requiring citations, by quoting source text, by tagging claims by verifiability. Prompt engineering is not just about reducing hallucinations; it is about producing output that is verifiable in practice.

A Worked Example: Before and After

To make this concrete, consider a real-world question. Suppose you asked an LLM: "What did the FTC say about noncompete agreements in 2024?"

A naive prompt would produce a narrative answer that probably gets the high-level point right (FTC banned most noncompetes) but may include fabricated specifics — specific rule text, specific vote counts, specific effective dates — that you would have to verify line by line without knowing which to trust.

Applying the techniques above, the prompt becomes:

You are answering a question about the FTC's 2024 action on noncompete agreements. Apply these rules strictly:

1. Use only information you are highly confident is in your training data. If a specific fact (vote count, effective date, specific regulatory text) is uncertain, say "I am not certain of this detail — please verify in the FTC press release or final rule text."
2. Mark every factual claim with [VERIFIABLE], [LIKELY], [UNCERTAIN], or [GENERATED].
3. If you cite the specific rule text, quote only exact language you are confident is accurate. If you cannot recall exact language, describe the rule's substance and note that exact quoted text should be verified against the official source.
4. Do not provide a specific date (vote date, effective date, publication date) unless you are highly confident it is correct.
5. End with a "Verification" section listing the specific sources (FTC press release URL, Federal Register citation, news coverage) a reader should consult to verify the specific details.

Question: What did the FTC say about noncompete agreements in 2024?

The output of this version is dramatically easier to use. Every claim is tagged. Every uncertain detail is explicitly flagged as uncertain. The final section tells you exactly what to check. The model has been given permission to refuse, and it uses it. A user reading this output knows precisely which claims require verification and where to do it. That is the goal.

Building an Anti-Hallucination Prompt Library

For organizations deploying AI in production — customer support, content generation, internal knowledge tools, legal research, finance — ad-hoc prompting is not enough. Each team should maintain a small library of tested, anti-hallucination prompt templates tuned for their specific domain and risk profile. Key elements of such a library:

A source-grounded Q&A template for any workflow where you have source documents
A citation-refusal protocol template for any workflow where citations matter (legal, finance, academic)
A structured-output template for any workflow producing factual claims that downstream users will rely on
A refusal-aware system prompt applied at the application level, so the constraints do not have to be re-specified every time

That library should be version-controlled, reviewed (like code), updated when failures are observed, and shared across the team using it. The same principles that govern good software engineering — code review, versioning, regression testing — apply to prompt engineering, and the same tools that help with the former help with the latter. This is, transparently, why PromptWright exists: to make prompt engineering a manageable, version-controlled, reviewable practice rather than an ad-hoc skill every individual contributes unpredictably.

Start Reducing Hallucinations Today

If you take only one thing from this guide, take this: the most reliable hallucination reduction technique you have is giving the model permission to say "I don't know." Models fabricate because they are trained to be helpful and to fill gaps. Explicitly authorizing refusal — through prompt language, through refusal protocols, through structured output formats that include "Not available" as a legitimate field — changes the underlying behavior.

Start with the source grounding template and the citation refusal protocol from this guide. Apply them to your next five prompts and compare the results to your previous output. Most users report a dramatic change: longer answers with explicit hedging, verifiable rather than fabricated citations, and clear flagging of uncertain claims. The output may feel less fluent, less polished, and less confident — and that is exactly the point. Confident, fluent, comprehensive answers are precisely what hallucinations look like. Tagged, hedged, structured answers are what reliability looks like.

If you want to build your team's anti-hallucination prompt library on a managed platform — with version control, prompt review, role-based access, and audit trails — sign up for PromptWright and publish your first tested prompt templates this week. Treat prompt engineering like the engineering discipline it is, and your AI output becomes dramatically more reliable.

Reducing AI Hallucinations: A Prompt Engineering Guide to More Reliable Output