Grounding and Citations: Answers You Can Check

In Part 5 we saw how hybrid search and re-ranking can dramatically improve retrieval quality. Now we tackle the next challenge: making sure the answers built from those retrieved chunks are actually true. Grounding means every factual claim must be backed by a specific source passage, and citations make that connection explicit. The honest “I don’t know” is not a failure. It is a design goal.

Here is the surprising fact: most teams that add “cite your sources” to a prompt get citations that are wrong more often than right. The model invents plausible-looking references that point to irrelevant text. Getting verifiable answers requires a stack of retrieval, structured context, external checkers, and training that rewards refusal. This article shows how that stack works, using a “chat with your company handbook” assistant as the running example.

What does it mean for an answer to be grounded?

Think of a journalist who must have a source for every fact. Grounding is the same rule applied to an LLM: every informational claim must be supported by at least one of the supplied evidence passages. Support means the passage logically entails the claim, not just overlaps in topic. If the handbook says “vacation is 20 days,” the claim “vacation is 25 days” is not grounded, even though it is close.

Attribution is the mapping from a generated sentence to its source. It can be coarse (a document ID) or fine (a specific quote). Citations make that mapping visible. Grounding and attribution are separate. A model can cite a passage that does not actually support the claim. That is attribution without grounding. A model can generate a correct claim but fail to cite it. That is grounding without attribution. A reliable system needs both.

Google’s Check Grounding API (application programming interface) formalizes this: it segments an answer into sentences, treats each sentence as a claim, and uses an entailment model to compute a support score between 0 and 1 for each claim against a set of facts. A claim is considered grounded only if the score meets a threshold. This strict, claim-level definition is what makes verification programmatic.

Why does telling a model to “cite your sources” usually fail?

A naive prompt says “answer the question and include citations from the provided documents.” The model has no structural link between the text it writes and the passages it saw. It must generate both the answer and the reference tokens from scratch. Without a fixed mapping, the model often hallucinates citation numbers that look right but point to nothing useful. Research on attributed generation shows that prompt-only approaches produce many spurious citations. AGREE paper

The problem is deeper than a bad prompt. Language models are not designed to maintain a pointer from each claim back to a specific input span. They generate tokens sequentially, and the connection between a claim and its evidence is lost unless the system enforces it externally. For our handbook assistant, a prompt-only approach might produce “Employees get 25 vacation days [1]” where [1] points to a paragraph about office hours. The model matched the surface pattern of a citation but not its meaning.

How does structured context assembly make citations reliable?

The fix is to assign citation identifiers before generation and embed them in the prompt. Perplexity’s architecture illustrates this well. After retrieval and ranking, each passage gets a stable index, like [1], [2], [3]. The prompt includes those markers and instructs the model to use them when making factual claims. The model does not invent citation numbers. It copies the tokens that are already present in the context.

For the handbook assistant, each chunk of the handbook gets a citation ID, say [h3.2] for section 3.2. The prompt tells the model: “Base your answer only on the handbook excerpts below. When you use information from a chunk, include its citation ID like [h3.2].” Because the ID is right there in the prompt, the model can reliably copy it. The system then replaces those IDs with clickable links or footnotes in the UI. This structural approach turns citation generation from a creative task into a copying task.

How do external grounding checkers verify claims?

Even with structured citations, a model might still misread a passage or combine facts incorrectly. External grounding checkers act as a second pair of eyes. They take the generated answer and the retrieved evidence, segment the answer into claims, and run an entailment model to see if each claim is supported. Google’s Check Grounding API is a production example. It returns a support score per claim and, if the claim is supported, the specific fact sentences that justify it.

You can use that score as a confidence gate. If any claim falls below a threshold (say 0.7), the system can either flag the answer for human review, ask the model to regenerate, or fall back to a refusal. In the handbook assistant, the checker might catch that the model said “25 vacation days” when the handbook says “20.” The checker’s entailment model would give a low support score for that claim, and the system could respond with “I found conflicting information about vacation days. Please check the handbook directly.” This gate prevents confident-sounding errors from reaching the user.

How can models learn to cite and refuse on their own?

External checkers add latency and cost. An alternative is to train the LLM itself to generate citations and to refuse when evidence is missing. The AGREE framework does exactly this. It first uses a natural language inference model to label which retrieved passages support which sentences in a large set of examples. Then it fine-tunes an LLM on those examples, teaching it to output a citation marker after every supported claim and a special “unsupported” marker for claims that lack evidence. During inference, the adapted model generates answers with inline citations and can explicitly mark parts it cannot verify. AGREE paper

Ground-GRPO takes a reinforcement learning approach. It defines rewards for answer correctness, citation precision and recall, and grounded refusals. The model is trained in stages: first to answer and cite correctly when evidence is present, then to refuse when evidence is absent. The reward for refusal is based on whether the model correctly says “I don’t know” instead of guessing. This shapes a policy that is honest about its limits. Ground-GRPO paper

Self-RAG introduces reflection tokens that let the model decide, mid-generation, whether to retrieve more passages, critique its own output, or continue. This moves the retrieval decision inside the model, enabling it to adaptively balance grounding against latency. For a handbook assistant, you could fine-tune the model to retrieve a chunk, generate a sentence, and then emit a reflection token like [Relevant] or [Irrelevant] before continuing. Self-RAG paper

What does the honest “I don’t know” look like in practice?

A grounded refusal is not a generic error message. It is a specific statement that the available sources do not contain the information. In the handbook assistant, a good refusal might be: “The employee handbook does not specify a dress code. I recommend checking with HR.” This tells the user exactly what was searched and what was found. It builds trust because the system is transparent about its knowledge boundary.

Implementing this requires two things. First, the retrieval pipeline must be able to detect when no passage meets a relevance threshold. Second, the generator must be trained or prompted to produce a refusal when the context is empty or insufficient. AGREE and Ground-GRPO both train models to output a refusal marker when the evidence is lacking. In a prompt-based system without fine-tuning, you can include a rule: “If the provided excerpts do not contain enough information to answer, say ‘I don’t know’ and explain why.” The structured context approach makes this rule enforceable because the model can only cite passages that are actually present.

Quick Reference

Property	Value
Typical retrieval count before ranking	50 candidates (30 vector, 20 keyword)
Google Check Grounding claim unit	Sentence (one claim per sentence)
Common support score threshold	0.7
Citation granularity in AGREE / FRONT	Sentence-level with passage IDs
Ground-GRPO reward for refusal	F1-GR (grounded refusal F1)
Self-RAG reflection tokens	Retrieve, IsRel, IsSup, IsUse

Frequently Asked Questions

Q: Can I just use a prompt to get citations without any infrastructure changes? You can, but expect low reliability. Without structured context and pre-assigned IDs, the model will often hallucinate citation numbers. For a prototype it is fine. For production, invest in structured context assembly.

Q: How much latency does an external grounding checker add? It depends on the entailment model size and the number of claims. Google’s Check Grounding API processes a typical answer in under a second. For real-time chat, you can run the checker asynchronously and flag answers post-hoc, or use a smaller local model.

Q: Is it better to train a model to cite or to use an external checker? They serve different roles. A trained model can cite inline and refuse on its own, reducing the need for an external checker. But an external checker provides an independent audit trail and can catch errors the model misses. Many production systems use both.

Q: How do I handle multi-sentence claims that span several chunks? Split the answer into atomic claims first. Each sentence is a claim. If a sentence combines facts from two chunks, you may need to split it further. The FRONT framework trains models to select fine-grained quotes and anchor each claim to a specific span. FRONT paper

Q: What if the model refuses too often, even when the answer is in the handbook? Check your retrieval quality. If relevant passages are not making it into the context, the model will correctly refuse. Also check your refusal threshold. You can tune the support score threshold or the reward weight for refusal in training to balance helpfulness and honesty.

Test yourself

Scenario: Your handbook assistant sometimes invents a remote work policy when the handbook only mentions office attendance. The generated answer says “Remote work is allowed two days per week [h4.1],” but section 4.1 of the handbook says nothing about remote work. How would you diagnose and fix this?

Answer: First, check the retrieval logs for the query that triggered this answer. Confirm that section 4.1 was actually retrieved and that its content does not support the claim. If the section is irrelevant, the retriever may be returning a false positive. Improve retrieval by adding metadata filters or re-ranking with a cross-encoder. If the section is relevant but the model misinterprets it, the problem is in generation. Add an external grounding checker that segments the answer into claims and computes entailment scores against the retrieved chunks. Set a threshold (e.g., 0.7). If the remote work claim scores below the threshold, flag the answer and either regenerate or fall back to a refusal. For a long-term fix, fine-tune the model on examples where it must refuse when evidence is missing, using a framework like AGREE. This teaches the model to say “The handbook does not specify a remote work policy” instead of guessing.

If you want this kind of breakdown every week, how real systems actually work under the hood, subscribe to Internals Decoded at internalsdecoded.com. Next, we will explore how to evaluate your entire RAG (retrieval-augmented generation) pipeline, from retrieval quality to generation faithfulness, so you can measure what matters.

Sources

• AGREE: Adaptive Grounding for Reliable and Explainable Generation
• Ground-GRPO: Grounding Large Language Models via Group Relative Policy Optimization
• FRONT: Fine-grained Robustness of Natural language Text attribution
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection