RAG + knowledge grounding — embedding search and citation

There are questions the LLM's training data alone can't answer. Internal policies, domain-specific regulations, recently updated procedures — this kind of organization-specific knowledge either didn't exist or wasn't included at the LLM's training cut-off. RAG (Retrieval-Augmented Generation) closes this gap.

RAG in one line

RAG = retrieval + augmentation + generation.

1. When a user question arrives, retrieve paragraphs semantically close to the question from organizational knowledge via embedding search.
2. Include the retrieved paragraphs in the LLM's reasoning context.
3. The LLM uses that context as grounding for the answer.

The key point: grounding comes from the retrieved paragraphs, not from the LLM's head. It also becomes easier for the LLM to answer I don't know when it doesn't.

Two RAG surfaces in D.Hub

The Knowledge resource

D.Hub's Knowledge resource is RAG's search target. As a resource kind you create inside a collection, the markdown or PDF body is automatically embedded and indexed.

Example — the refund_policy knowledge from the refund_approval workshop:

# Refund Policy Guide

## §3.1 defective category
Refunds categorized as *defective* ...
Always APPROVE — provided the claim is filed within 7 days.

## §3.2 change_of_mind category
*change_of_mind* claims ...
If tier is gold/platinum → APPROVE; else PARTIAL.

Cutting the knowledge body into meaningful paragraph units naturally improves RAG retrieval accuracy.

The search_* tool

A tool that searches the knowledge resource is RAG's invocation entry point.

def search_refund_policy(query: str, top_k: int = 3) -> list[dict]:
    results = knowledge.refund_policy.search(query, top_k=top_k)
    return [
        {
            "section": r.section_heading,
            "content": r.content,
            "score": r.similarity,
        }
        for r in results
    ]

Per the tool-definition pattern (Lesson 2), input is a one-line natural-language query and output is a list of section heading + body + similarity score.

Require citation in responses

If you simply insert retrieved paragraphs into the LLM context, the LLM is free to paraphrase. The response loses traceability to which paragraph it came from. The fix is one line in the prompt:

"When responding, always cite the section number (§N.M) of the retrieved paragraph. Mark no grounding for any info absent from the retrieval results."

This single line forces the response into a citation-grounded form.

Example response:

Refund recommendation: APPROVE. Grounds: The reason is defective and the claim was filed 5 days after purchase (within §3.1's 7-day window). Tier is standard, but §3.1 is tier-independent → APPROVE.

The reviewer immediately sees why that recommendation with which policy paragraph in one line. HITL review time shrinks, and the grounding comparison during overrides becomes clearer.

Operating knowledge resources — who updates them and how

Policy / regulation knowledge updates as organizational policy changes. Two operational patterns:

• Version markers — Mark last-updated date + version in the knowledge resource header. Reviewers can identify recommendations grounded on stale policy.
• Approval workflow — Restrict edit access on knowledge resources to legal / policy owners only (the FGAC pattern from Admin Path Lesson 4).

Self-check

• You authored one knowledge resource with body content split into § units.
• You defined a search_* tool that returns results with similarity scores.
• The agent response carries §N.M citations.
• Empty retrieval results yield a refuse-without-guessing response.

What you should be able to do after this lesson

• RAG's one cycle of retrieve → augment → generate
• The §-unit body pattern for knowledge resources
• The one prompt line that forces citation
• The refuse-without-guessing safety pattern for empty retrievals

Next lesson

Apply default deny safety through intent classification + allow-list gating.