Phase 6: RAG Systems & Knowledge Grounding · 95 min · OpenAI Cookbook · LlamaIndex · DeepEval

Citations, Abstention, and Grounded UX

A RAG answer is only useful when a user can trust, inspect, and challenge it.

Hiring signal: Production trust design: citations, abstention, safety, and user-facing reliability

The Problem

The assistant answers a policy question confidently:

Yes. Your capstone can be certified without a demo video if the repository is complete.

The answer is wrong. Worse, it looks polished. The interface gives the student no way to see where the claim came from, no confidence signal, no source preview, no “I could not find this” state, and no escalation path.

This is the line between a demo and a product. A demo can impress someone for thirty seconds. A product must survive ambiguity, stale documents, contradictory sources, missing permissions, and users who rely on the answer to make a decision.

The Concept

What Grounded UX Means

A RAG system is not just a retrieval pipeline plus a language model. It's a product that users rely on to make decisions — sometimes high-stakes ones like "can I submit without a video?" or "what's the refund policy?" When the answer is wrong, the user needs to be able to detect it, challenge it, and find the truth. This requires designing the user experience around accountability, not just accuracy.

Grounded UX is the set of product and engineering choices that make generated answers inspectable, challengeable, and honest about their limitations. The core principle: the system should never force the user to blindly trust the model. Instead, it should provide the evidence, let the user verify, and be honest when it doesn't know.

The Three Pillars of Grounded UX

Citations connect every claim in the answer to its source. When the LLM says "the deadline is March 15th," the user should see a citation linking to the specific document, page, and section where that date appears. This serves two purposes: it lets the user verify the claim, and it makes the system auditable — you can trace any answer back to its evidence. Without citations, the user has no way to distinguish a correct answer from a confident hallucination.

Abstention is the system's ability to say "I don't know" when the evidence is insufficient. This is harder than it sounds — LLMs are trained to be helpful and tend to generate plausible-sounding answers even when they have no grounding. Building abstention requires: (1) checking whether retrieved chunks actually cover the query, (2) checking whether the answer's claims are supported by the chunks, and (3) having the system explicitly say "I couldn't find information about this" rather than guessing. Abstention is a feature, not a failure — it's what separates a trustworthy system from a reckless one.

Evidence preview shows the user the actual retrieved passages, not just the model's summary of them. This lets the user assess the quality of the evidence independently — is the source current? Is it authoritative? Is it being interpreted correctly? Evidence preview is the difference between "trust me" and "here's why."

A grounded RAG response should include:

A user asks your RAG system "What's our refund policy for digital products?" The retrieved chunks only cover physical product returns — nothing about digital. What should the system do?

Abstention is critical for trust. When retrieved evidence doesn't cover the query, the system should say so explicitly, cite what it DID find, and offer an escalation path (contact support, search different docs). Fabricating an answer from tangential evidence destroys user trust and can create legal liability.

Answer: concise, directly responsive, and limited to retrieved evidence.
Citations: source IDs, titles, page numbers, sections, or URLs tied to specific claims.
Evidence preview: the chunks or passages used for the answer.
Abstention: a clear response when evidence is missing, weak, outdated, or contradictory.
Confidence language: calibrated wording, not fake certainty scores.
Feedback loop: user correction, “missing source” report, and eval-set capture.
Security constraints: retrieved text is treated as untrusted data, not system instruction.

The product goal is not to make the model sound more confident. The goal is to make the system more accountable.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Build It, Use It, Ship It, Security Constraints, Evaluation, Product Decisions, Common Mistakes, Exercises, Key Terms, Common Pitfalls, Interview Framing — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

RAG (Retrieval-Augmented Generation)