Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the previous lesson, you saw why a base LLM can lack current, private, or highly specialized information: its learned parameters are not a live, authoritative database. It can still produce a polished answer when the needed facts are unavailable.
This final lesson in the module gives you a practical skill: recognizing when a statement in an LLM answer is ungrounded. This matters because an answer can sound credible, include precise details, and even contain citations while still going beyond the evidence actually available to support it. That distinction is the problem RAG is designed to address.
What “ungrounded” means
A claim is grounded when the evidence available to the model supports that claim. A claim is ungrounded when the model states something that is not supported by the available evidence.
The evidence depends on the situation. It may be:
- passages from retrieved documents,
- database records returned by an authorized tool,
- a supplied policy or contract,
- a reliable web result,
- data explicitly included in the user’s request.
In a RAG application, the main grounding sources are usually the retrieved document chunks inserted into the prompt.
Groundedness asks: “Can this particular statement be justified from the sources supplied for this answer?”
This is not exactly the same question as “Is the statement true?”
A statement can be:
| Classification | Meaning |
|---|---|
| Grounded and true | The supplied evidence supports it, and the evidence is accurate. |
| Ungrounded but true | The statement happens to be correct, but the supplied evidence does not establish it. |
| Ungrounded and false | The model invented, guessed, or misstated a fact. |
| Contradicted | The supplied evidence directly conflicts with the statement. |
For instance, imagine that a retrieved employee handbook says:
“Employees receive 20 days of annual leave. Leave requests must be submitted at least 10 business days before the intended start date.”
Now consider this answer:
“Employees receive 20 days of annual leave, and unused leave carries over for up to five days each year.”
The first part is grounded. The second part is ungrounded, because the handbook excerpt says nothing about carryover. That carryover policy might be true somewhere else, but this model has not been given evidence for it.
An answer does not have to be entirely right or entirely wrong. Often, it is partially grounded: one sentence faithfully summarizes a source, while another adds a plausible but unsupported detail.
Hallucination and ungroundedness: related, but not identical
You will often hear ungrounded content called a hallucination. The terms overlap, but they are useful for slightly different checks.
- A hallucination is typically a false, fabricated, or nonsensical output: an invented research paper, a nonexistent policy, an incorrect date, or a made-up statistic.
- An ungrounded claim is a claim that exceeds the available sources. It may be false, but it can also be accidentally true.
This difference is important in RAG. Suppose a model retrieves a product manual that lists three compatible battery types, then answers:
“The device also supports fast charging.”
Fast charging may genuinely be supported by the device, but the retrieved manual passage does not show that. For a system instructed to answer only from the retrieved sources, the statement is still ungrounded.
Microsoft’s description of groundedness detection captures this operational idea: it checks whether a model has generated content beyond what its source data supports.
Use Foundry Content Safety middleware with LangChain
Read Microsoft’s explanation of groundedness detection and its worked example. It shows that even an accurate-looking explanation can be marked ungrounded when it adds details not present in the retrieved documents.
In the “Groundedness detection” section, read the definition and note that grounding is assessed relative to source data, not merely whether an answer sounds reasonable. Then continue to the example later in the page, after the agent-graph image, beginning with the response evaluation. Read why the response is flagged. Notice that the answer is not necessarily nonsense; it simply introduced information beyond the retrieved material.
Why fluent detail is a warning sign, not evidence
LLMs generate likely continuations of text. If they have incomplete information, they may fill the gap with language that resembles a complete answer. The result can contain realistic names, dates, numbers, document titles, quotations, and technical terminology.
That stylistic confidence can make ungrounded claims hard to notice.
Watch “Why do AI models hallucinate?” from Claude. It illustrates why fabricated details can look convincing and gives a practical set of warning signs for claims that need checking.
Watch fabrication examples to see how nonexistent studies, invented numbers, and incorrect details can be presented with assurance. Then watch verification advice. Focus on the kinds of requests that demand special caution: precise numbers, dates, references, niche subjects, and current information.
The following features should raise your level of scrutiny:
- Exact numbers: prices, account balances, thresholds, percentages, performance metrics.
- Specific dates or deadlines: release dates, policy effective dates, historical timelines.
- Named sources: paper titles, regulations, court cases, internal documents, URLs, or citations.
- Strong qualifiers: “always,” “never,” “all,” “only,” “guaranteed,” or “required.”
- Current claims: anything described as “latest,” “today,” “currently,” or “in effect.”
- Private or organization-specific details: HR policies, customer records, engineering procedures, product roadmaps.
- Rare or specialized facts: obscure people, terminology, research, locations, or one-off events.
None of these signals proves an answer is wrong. Instead, they tell you that the answer needs a traceable basis.
A claim-by-claim way to inspect an answer
The most reliable habit is to stop evaluating an answer as one persuasive block of prose. Break it into individual claims, then compare each claim to the available evidence.
Consider this fictional travel-policy excerpt:
Travel Policy, effective May 1, 2026
Employees may claim $0.62 per mile for approved business travel. Expense claims must be submitted within 30 calendar days of the trip. International business travel requires written approval from the employee’s department head before booking.
A user asks:
“What are the rules for claiming travel expenses?”
The model answers:
“Employees are reimbursed at $0.62 per mile. Claims submitted after 30 days are automatically rejected. International travel requires approval from the department head, and the mileage rate is reviewed every January.”
Now split the answer:
| Answer claim | Comparison with the policy | Assessment |
|---|---|---|
| “Employees are reimbursed at $0.62 per mile.” | The policy explicitly states this rate for approved business travel. | Grounded, though it should retain the “approved business travel” condition. |
| “Claims submitted after 30 days are automatically rejected.” | The policy requires submission within 30 days but does not state the consequence. | Ungrounded. |
| “International travel requires approval from the department head.” | The policy explicitly requires written pre-booking approval. | Grounded, but the answer omits “written” and “before booking.” |
| “The mileage rate is reviewed every January.” | No such review schedule appears in the excerpt. | Ungrounded. |
This example reveals three common failure modes.
1. Adding a plausible consequence
“Claims submitted after 30 days are automatically rejected” sounds reasonable. But “must be submitted within 30 days” does not logically establish automatic rejection. There may be exceptions, a review process, or another consequence.
A grounded answer can state what the source says. It should not silently convert a requirement into an unstated enforcement rule.
2. Dropping conditions and scope
The rate is not simply “$0.62 per mile” in every imaginable situation. The source limits it to approved business travel and has an effective date.
Small omissions can change the meaning of a claim:
- “may” becomes “must,”
- “some employees” becomes “all employees,”
- “before booking” disappears,
- “in one region” becomes “company-wide,”
- “as of a particular date” becomes “currently.”
A claim may be broadly related to the evidence yet still be insufficiently grounded because its scope is too broad.
3. Supplying a detail from internal knowledge or a guess
“The rate is reviewed every January” could come from a generic assumption, an older policy, another organization’s practice, or pure fabrication. The reason does not matter for the grounding check: the available policy does not support it.
Citations help only when they actually support the claim
A citation is not proof by itself. A model can cite:
- a source that does not contain the claimed detail,
- a real source that is outdated,
- a source that supports only part of the sentence,
- a source that is less authoritative than the required source of truth,
- or, in the worst case, a source that does not exist.
The useful question is not:
“Does this answer have a citation?”
It is:
“If I open this cited passage, does it support this exact claim, with its date, scope, and qualifiers?”
The image below contrasts an answer produced without current retrieval with one informed by search results. The important improvement is not simply that the second answer has bracketed citations. It has an evidence path that a reader can inspect.
Even then, verify the connection between the claim and the source. A citation should be treated as a route to evidence, not as a decorative badge of reliability.
A practical groundedness checklist
When you inspect an LLM answer, use this five-step process.
-
Identify factual claims.
Highlight statements that assert a fact, rule, number, date, causal explanation, or source attribution. Ignore purely stylistic wording at first. -
Identify the available evidence.
What documents, tool results, database records, or trustworthy user-provided facts were actually available to the model? In a RAG system, look at the retrieved chunks and their metadata. -
Match each claim to evidence.
Find the exact sentence, table entry, or record that supports the claim. If you cannot find it, mark the claim as ungrounded rather than assuming it is correct. -
Check scope, conditions, and time.
Ask whether the answer changed “may” to “must,” removed an exception, broadened a regional rule, or treated old information as current. -
Choose the right label.
Mark each claim as:- supported,
- partially supported,
- unsupported or ungrounded,
- contradicted,
- or impossible to assess because the source is missing.
For high-stakes material, a strong answer should do more than merely avoid obvious errors. It should make it possible to connect important claims back to the relevant source passages.
Anthropic’s guidance offers a useful pattern: require the model to extract direct supporting quotes and to admit when evidence is absent, rather than rewarding it for producing a complete-sounding answer at any cost.
Read the practical prompting patterns in Anthropic’s “Reduce hallucinations” guide. They show how an application can make evidence visible and make “insufficient information” an acceptable outcome.
In “Basic hallucination minimization strategies,” read the policy-auditing and press-release examples. Focus on the instructions that require direct quotations, claim-by-claim support, and removal of unsupported claims. Then read the short “Advanced techniques” section, especially external knowledge restriction. The key principle is that a model needs permission to say it lacks evidence; otherwise it may try to complete the answer from general patterns.
A well-designed RAG prompt often includes instructions such as:
Answer only from the provided sources.
Cite the source for each important factual claim.
If the sources do not contain enough information, say so clearly.
Do not infer policies, dates, or exceptions that are not stated.
Instructions reduce the likelihood of ungrounded generation, but they do not guarantee correctness. The system must still retrieve relevant, current, authorized sources, and the resulting answer must still be checked against them.
The correct response to missing evidence
Recognizing an ungrounded claim is not only about finding errors after the fact. It also tells you what a trustworthy assistant should do instead.
When evidence is insufficient, a grounded response may say:
- “The supplied policy does not specify what happens to claims submitted after 30 days.”
- “I can confirm the reimbursement rate, but the retrieved documents do not state the annual review schedule.”
- “I do not have an authorized source for the customer’s remaining balance.”
- “The available documentation is dated 2024, so I cannot confirm that this is the current rule.”
This is not a weak answer. It is a precise statement of the boundary between what the evidence establishes and what it does not.
In contrast, an answer becomes risky when it hides that boundary by presenting an assumption as a fact.
Key takeaways
An ungrounded claim is a statement that goes beyond the evidence available to support the answer. It may be false, but it can also be true by coincidence; grounding is about whether the model can justify the statement from the supplied sources.
To recognize ungrounded content:
- break an answer into individual factual claims;
- locate the actual evidence available to the model;
- check whether that evidence supports the claim’s exact scope, conditions, and time frame;
- treat precise details, current facts, private information, and named references with extra care;
- remember that a citation is useful only if it truly supports the claim;
- prefer an explicit “I do not have enough information” over a polished guess.
You now have the central reason for RAG: instead of expecting an LLM’s fixed parameters to supply reliable answers about current or private information, a RAG system retrieves evidence and places it in the model’s context. Next, you will begin the RAG mental model by defining the three parts of the name: retrieval, augmentation, and generation.