A citation isn't proof: check what your assistant actually used

Overview

In a May 2026 benchmark of 14 models writing cited research reports from web sources, the citations almost all worked: links resolved more than 94% of the time, and the cited pages were on-topic more than 80% of the time. Then the researchers checked the one thing that matters — whether the cited source actually supported the sentence it was attached to. Only 39 to 77% did, depending on the model.

The little citations under a Copilot or Glean answer feel like proof it read your files and got it right. They are proof a link resolved and the page looks relevant — which is not the same as proof the answer is sound.

What you’ll do differently: treat a grounded answer’s citations as leads to check, not as a verdict — and know the two invisible ways a cited answer over your own documents can still be wrong.

The content

A citation is a lead, not a verdict. Two failure modes hide behind that reassuring little link, and neither shows in the answer.

The first: the right document gets retrieved, and the model still doesn’t use it. A January 2026 study, revised in July, built a framework to measure how closely a model’s answer tracks what its own retriever ranked highest, and the finding was blunt — depending on the model and setting, “generators often ignore top-ranked documents and rely on documents ranked as less relevant.” The best source can be sitting right there in the retrieved set while the answer gets built from a weaker one, and cited to the weaker one. The link resolves. The claim doesn’t hold.

The second: “search across all my tools” often doesn’t. A Salesforce benchmark ran deep-search questions over a pool of 39,190 mixed enterprise artifacts — documents, meeting transcripts, Slack, GitHub, URLs — and the best agentic RAG methods averaged 32.96 on a 100-point scale. The researchers named the cause: “retrieval as the main bottleneck… they often reason over partial context, leading to significant performance degradation.” The answer looks complete. The evidence behind it wasn’t.

Now the honest boundary, because it decides what you can actually do about this. These failures are documented in academic and synthetic-benchmark settings — not measured inside your production Copilot or Glean, which nobody has published numbers on. So the real claim is “this class of failure is well-documented and your harness gives you tools to catch it,” never “Copilot ignores your files 40% of the time.” And the catch is asymmetric: you can reliably spot a wrong source by clicking the citation and reading it, but you largely cannot confirm the retrieval was complete. Assistants show the sources they used, not the ones they missed — so asking “what did you leave out?” just returns another ungrounded guess.

Try it

Take your most recent grounded answer from Copilot, Glean, Gemini or an enterprise assistant — one where a claim actually matters — and run this before you act on it.

1. Find the sentence in the answer you'd repeat in a meeting or paste
   into a document. The one that carries weight.
2. Click its citation. Read the cited passage. Does the source actually
   say what the answer claims — or does it just mention the same topic?
3. If it's a "find everything about X across our tools" answer, name one
   source you'd expect to be in there. Is it represented? If you can't
   tell, treat the answer as partial, not complete.

Where it breaks: step 3 has a ceiling. Clicking a citation reliably catches a source that doesn’t support the claim — but an assistant won’t reliably tell you what it failed to retrieve, so “is this complete?” stays a judgement you make, not one the tool answers. Step 2 has been getting cheaper, at least: Microsoft 365 Copilot’s mid-2026 “deep citations” now jump to the passage inside a long file rather than the file, and Glean’s July 2026 release added citations on artifacts. And if your harness surfaces no citations to click at all, that’s the ask to your admin: “can we see which sources our answers are grounded on?”

Additional reading

• “Cited but Not Verified: Parsing and Evaluating Source Attribution in LLM Deep Research Agents” (Onweller et al., 7 May 2026) — the opening figures: across 14 models writing cited research reports from web sources, links resolve above 94% and cited pages are relevant above 80%, but Fact-Check accuracy is only 39–77%, and drops by roughly 42% on average (across two frontier models) as tool calls scale from 2 to about 150. Surface citation quality is good; deep support is not.
• “Quantifying Retriever-Generator Alignment in RAG with Local Explanations” (Randl et al., submitted January 2026, revised 7 July 2026) — failure mode one, verbatim: “depending on the model and setting, generators often ignore top-ranked documents and rely on documents ranked as less relevant.” The right retrieved document can go unused.
• “Benchmarking Deep Search over Heterogeneous Enterprise Data” (Choubey et al., Salesforce AI, 29 June 2025) — failure mode two: a 39,190-artifact enterprise simulation where the best agentic RAG methods averaged 32.96 on a 100-point scale, with “retrieval as the main bottleneck… they often reason over partial context.”
• “Correctness is not Faithfulness in RAG Attributions” (Wallat et al., arXiv preprint December 2024; published at SIGIR ICTIR 2025) — the mechanism behind “cited but not supported”: current attributed answers often lack citation faithfulness (up to 57% of citations), because a model can answer from its own internal knowledge and attach a plausible citation after the fact. (Boundary: an older model in an adversarial setup.)
• “Universal Pathologies, Conditional Consequences: A Triple-Robustness Analysis of RAG for Multi-Hop Traceability” (Akarsu & Ozdemir, submitted May 2026) — a graph-based retrieval setup attaches 11–15 citations per answer at a citation precision of 0.12–0.23: most of those citations aren’t supporting anything. Also a caution about the numbers on this page — the same automated judge flipped its faithfulness verdict on 41% of items when only the retrieval setup changed. (Boundary: one specific architecture, tested on avionics requirements and Wikipedia rather than an enterprise assistant, and the effect reverses by corpus.)

Editor’s note

I’ve had colleagues specifically seek my advice on how to fix this a few times. There isn’t a setting that will eliminate the risk. Bounding the task and the context helps, and it is the first thing I suggest, but plenty of work does not justify the manual labour that bounding it properly takes. In those cases, the thing to do is much smaller, obvious and often a pain: on the critical claims, open the citations and read them. That is reliable for the half of the problem it covers (whether something was left out remains your judgement, not the tool’s).