What sources did the system draw from?
Relevant in any client deploying a RAG-based knowledge system, such as internal search, policy assistants, or support chatbots, where users need to verify answers or trace responses back to source documents.
A knowledge assistant returns an answer. It sounds right. It's well-structured and specific. A user in a legal, medical, or compliance context acts on it. Later, someone asks: where did that come from? Was it from the organization's documentation, or from the model's general training? Was it current? The interface provides no way to answer any of these questions.
This is the gap that RAG (Retrieval-Augmented Generation) systems create when they aren't paired with attribution design. The architecture retrieves documents at runtime to generate a response: which means there are sources, there is a retrievable basis for the answer. But if the interface doesn't surface them, users have no way to verify the answer, trace it back, or assess how reliable the retrieval was.
Retrieved Source Attribution makes the retrieval layer visible. It is distinct from Data Provenance & Lineage, which concerns training data: the long-term substrate the model was built on. This pattern concerns what the system looked up for this specific response, and how closely that material actually matched the question. Both matter. They happen at different points in the pipeline and require different design responses.
Surface the documents, passages, or records the system retrieved at runtime, so users can verify the basis of a response, assess its reliability, and access primary sources directly.
Superscript numbers or footnote markers anchored to specific claims in the output, not just a list at the bottom. Users can see exactly which sentence came from which source.
When a user clicks or hovers a citation marker, the retrieved passage is highlighted or shown in context, not just the document title.
A visual signal (bar, dot, percentage) showing how closely a retrieved source matched the query. Helps users assess whether the retrieval was a strong match or a loose approximation.
A compact indicator in the interface showing "Based on 4 sources": gives a quick sense of whether the answer is well-grounded or based on a single retrieved document.
An explicit design state for when the system generated an answer without retrieving supporting material. This is not a failure state: it's a transparency signal that the response came from model knowledge, not a document.
Most users don't need to see all retrieved passages by default. Show a compact source count inline, expand to titles on demand, expand to full passages on further request.
A list of sources at the bottom of a response is weak attribution. Inline markers tied to specific sentences are far more useful and honest.
A source retrieved with 0.94 cosine similarity is different from one retrieved at 0.51. That difference should be visible, especially in high-stakes contexts.
If a response was generated without retrieval, say so. This is as important as showing sources when they exist: it tells the user the basis has changed.
A response can cite a real source and still misrepresent or misquote it. Attribution is not a guarantee of accuracy: pair this pattern with Grounding & Hallucination Indicators when accuracy verification matters.
Transparency vs. cognitive load
Showing all retrieved passages by default overwhelms most users. Default to summary, expand on demand.
Attribution vs. false confidence
Displaying a clean source list can make a response feel more authoritative than it is. Use uncertainty signals alongside attribution.
Source disclosure vs. system security
In some deployments, revealing retrieved documents exposes proprietary document stores. Consider showing document types or categories rather than full paths when disclosure must be limited.
Provenance concerns training data; this pattern concerns runtime retrieval. They address different moments in the AI pipeline.
Attribution shows what was retrieved; Grounding signals whether the output faithfully reflects it. Use together in high-stakes contexts.
Retrieval relevance scores complement output confidence signals.
A user asking "where did you get that?" is a natural continuation of this pattern.
Lewis et al. (2020) — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
foundational paper establishing RAG as an architecture. Introduces the retrieval-generation split that makes source attribution both possible and necessary
Es et al. (2023) — RAGAS: Automated Evaluation of Retrieval Augmented Generation
introduces faithfulness and context relevance as measurable properties of RAG outputs. Provides the evaluative framing this pattern operationalizes for users
Gebru et al. (2018) — Datasheets for Datasets
while focused on training data, its framework for documenting data sources, collection methods, and intended use informs how retrieved sources should be disclosed