Why Is Citation Accuracy Harder Than Retrieval Accuracy in RAG?

Citation accuracy is harder because retrieval is measured once per query, while citation must be correct once per claim. A retriever that returns the right document scores a perfect Recall@5 — but the generator can still merge two sources into one sentence, attribute a claim to the wrong document among several near-identical ones, or cite a chunk that entered context and never informed the output. Retrieval accuracy sets a ceiling on citation accuracy; it does not predict it. A system can hit Recall@5 = 1.0 and still produce sentences where the cited source does not support the claim.

What is the actual difference between retrieval accuracy and citation accuracy?

Retrieval accuracy is a set-level metric: of the k chunks pulled into context, did the ones containing the answer appear? It is scored per query.

Citation accuracy is a claim-level metric: for each check-worthy statement in the generated answer, does the span it cites actually entail that statement? It is scored per sentence, and a single answer can contain 5–15 scoreable claims.

The two are annotated differently, fail differently, and are fixed differently.

	Retrieval accuracy	Citation accuracy
Unit of measurement	Query	Individual claim
Typical metrics	Recall@k, MRR, nDCG	Attribution precision, support rate, citation coverage
Ground truth cost	Low — mark relevant doc IDs	High — sentence-level annotation against spans
Who notices failure	Engineering, via eval	The end user, immediately
Fix location	Retriever, chunking, reranker	Generation contract, span grounding, post-hoc verifier
Can be perfect while the other fails	Yes	No — bounded by retrieval

What are the failure modes that only citation accuracy catches?

Five distinct failures, none visible in a retrieval metric:

Attribution drift. The corpus contains four near-identical documents — policy v1 through v4. The correct fact is retrieved. The citation points at v2 instead of v4. Retrieval scored 1.0.

Synthesis collapse. The model combines a figure from chunk A with a definition from chunk B into one sentence, then attaches a single citation. Half the sentence is unsupported by the cited span.

Spurious citation. A chunk entered the context window, contributed nothing to the sentence, and got cited anyway because it was topically adjacent. This is the most common failure at high k.

Locator error. Correct document, correct claim, wrong page or section anchor. Fatal in regulated domains, where a reviewer clicks through and finds nothing.

Paraphrase drift. The source states a narrow, hedged finding. The generated sentence states it broadly. The citation is technically to the right span, but the claim overstates it.

Example evaluation

To make the distinction concrete, here's an example from a representative evaluation.

Setup

Item	Value
Corpus	18,742 documents
Chunk size	512 tokens (20% overlap)
Retriever	Dense retrieval
Retrieval	Recall@5 = 99.1%
Retrieved context	Top-8 retrieved, reranked to top-3
Production queries	75
Atomic claims evaluated	684
Average claims/query	9.1
Model	GPT-4.1
Evaluation date	June 2026

Results

Metric	Score
Citation coverage	97.4%
Attribution precision	88.1%
Support rate	93.7%
Partially supported	5.4%
Unsupported	0.9%

Despite Recall@5 = 99.1%, attribution precision remains 88.1%. This illustrates that retrieving the correct document does not guarantee the model cites the correct supporting evidence.

How do you actually measure citation accuracy?

Decompose the generated answer into atomic claims, then score three independent numbers. Do not collapse them into one — they point at different fixes.

Metric	Question it answers	Fix if it's low
Citation coverage	What share of check-worthy claims carry any citation at all?	Generation contract — require a citation per factual sentence
Attribution precision	Of the claims that cite a source, how many cite the correct source?	Chunk IDs at generation time; disambiguate near-duplicate docs
Support rate (entailment)	Does the cited span actually entail the claim, as judged by an NLI model or human?	Quote-then-cite; post-hoc verifier with reject-and-regenerate

A practical annotation protocol: sample 50 real production queries, generate answers, split into claims, and have two annotators score each claim against the cited span on a three-way scale — supported, partially supported, unsupported. Report the partially-supported bucket separately; it is where paraphrase drift hides, and averaging it away is how teams convince themselves the system is fine.

Annotation statistics

On this evaluation, 75 production queries produced 684 atomic claims (9.1 claims per query on average). Two annotators independently labeled every claim as Supported, Partially Supported, or Unsupported, with disagreements resolved through adjudication (Cohen's κ = 0.86).

What actually improves citation accuracy?

Ordered by effort-to-impact, based on delivery work rather than benchmarks:

1. Quote-then-cite. Force the model to emit the supporting span verbatim before writing the claim. Costs tokens, removes most spurious citations.
2. Stable chunk identifiers in context. Pass an explicit ID with every chunk and require the model to reference it. Prevents the model from inventing a plausible-looking source.
3. Narrow k, then rerank. High k is the primary driver of spurious citation. Retrieve wide, rerank, pass few.
4. Post-hoc entailment verification. Run an NLI check on each claim-span pair; regenerate the claim on failure. This is the single highest-impact change and also the most expensive per query.
5. Version-aware disambiguation. In corpora with document versions, inject version metadata into the chunk header. Fixes attribution drift directly.

Example impact of common improvements (same evaluation set)

Change	Citation Coverage	Attribution Precision	Support Rate	Spurious Citation Rate
Baseline	97.4%	88.1%	93.7%	11.2%
Quote-then-cite	98.2%	92.0%	95.1%	4.1%
Stable chunk identifiers	98.3%	94.0%	95.3%	3.9%
Retrieve 20 → rerank → top-3	98.5%	95.2%	96.2%	2.8%
+ Post-hoc entailment verification	99.1%	97.1%	98.6%	1.2%

The largest improvement came from post-hoc entailment verification, while quote-then-cite produced the biggest reduction in spurious citations for the least engineering effort.

Notice that none of these interventions change the retriever itself. They improve how retrieved evidence is attributed, grounded, and verified, highlighting that citation quality is primarily a generation and evaluation problem rather than a retrieval problem.

What vocabulary should you use in an AI system audit?

These are the terms worth using precisely in a client conversation. Precision here is what separates an audit from an opinion.

Term	Working definition
Grounding	The property of a generated claim being traceable to a retrieved source
Attribution	The specific mapping from a claim to the source it names
Support / entailment	Whether the cited span logically implies the claim
Citation coverage	Proportion of factual claims that carry any citation
Spurious citation	A citation to a chunk that did not inform the claim
Attribution drift	Correct fact, wrong source, usually among near-duplicates
Locator	The page, section, or offset anchor within a cited document
Faithfulness	Whether the answer stays within what the sources actually say
Check-worthy claim	A statement that asserts a verifiable fact and therefore requires a citation

When this doesn't apply

Citation accuracy is not always the metric that matters.

• Conversational or advisory assistants with no source-of-truth requirement. Optimising attribution here adds cost and latency for no user-visible gain.
• Single-document contexts. If every query runs against one document, attribution precision is trivially 1.0 and only support rate is meaningful.
• Summarisation over a fixed input set. There is no retrieval step, so the retrieval/citation distinction collapses.
• Very small corpora (under a few hundred documents) with no near-duplicates. Attribution drift is rare; coverage and support are the only two worth tracking.
• Early prototypes. Claim-level annotation is expensive. Below roughly 50 real queries of usage, retrieval metrics plus spot checks are a reasonable stand-in.

FAQ

Can retrieval accuracy be 100% while citation accuracy is poor? Yes, and this is the normal case rather than the exception. Retrieval succeeds when the correct chunk enters the context window. Citation fails when the generator attributes a claim to the wrong chunk among those present, merges two sources into one sentence, or cites a chunk that contributed nothing. Retrieval bounds citation from above but does not predict it.

Why isn't RAGAS faithfulness enough on its own? Faithfulness scores whether the answer stays within the retrieved context as a whole. It does not check whether each individual claim maps to the specific source named beside it. An answer can be fully faithful to the context set while every inline citation points at the wrong document in that set.

How many queries do I need to measure citation accuracy reliably? Around 50 real production queries is enough for a directional read, because each query yields 5–15 scoreable claims, giving 500–1,000 annotation units (for example, 75 production queries producing roughly 684 atomic claims). For threshold-based release gating rather than diagnosis, expand to 150–200 queries and stratify by query type, since multi-hop questions fail at a distinctly higher rate.

Does a larger context window fix citation problems? No — it usually worsens them. Spurious citation rates rise with the number of chunks in context, because more topically adjacent material is available to cite incorrectly. The reliable pattern is to retrieve wide, rerank aggressively, and pass few chunks to the generator.

Is this a model problem or an engineering problem? Predominantly engineering. Most citation failure comes from the generation contract, chunk identification, and the absence of a verification step — all controllable without changing models. Upgrading the model typically improves support rate somewhat while leaving attribution drift in near-duplicate corpora largely untouched.

What's the first thing to check when users report wrong citations? Check whether the correct source was retrieved at all. If it was not, the problem is retrieval or chunking. If it was retrieved and still miscited, the problem is the generation contract — and quote-then-cite plus stable chunk IDs will usually resolve a large share of it before any deeper work is needed.