RAG Essentials

Five prompts for the parts of a retrieval-augmented-generation pipeline that an LLM does better than glue code — and where getting it wrong means a confident, cited-looking hallucination. Each turns a step of your RAG flow into typed, validated JSON: a rewritten query, a decomposition, per-chunk relevance grades, a sufficiency gate, or a grounded answer with citations.

Like the Structured Extraction and Customer Support collections, every prompt ships a strict output schema, so the generated SDK gives you a real type and a parseOutput() you can trust. Built with the LangChain / LlamaIndex (Python) RAG audience in mind, but the prompts are framework-agnostic — they're just a system message, a user message, and a schema.

Prompts

The pipeline

These compose into a single retrieval-augmented flow. A query comes in; a grounded, cited answer (or an honest refusal) comes out:

1. query-rewrite — resolve the conversational turn into a standalone, keyword-bearing query (optionally fan out to a few phrasings).
2. query-decomposition — if the question is multi-part, split it into sub-queries you retrieve for separately; if not, retrieve once with the rewritten query.
3. (retrieve) — your retriever pulls candidate chunks. chunk-relevance-grading grades them; you drop the is_relevant: false ones and rerank the rest.
4. groundedness-guardrail — gate on the filtered context. can_answer: false short-circuits to a safe refusal and never reaches the model's outside knowledge.
5. answer-synthesis — answer strictly from the surviving chunks, with citations you can render and verify.

Use them à la carte too: just the guardrail in front of an existing answerer, just the grader as an LLM reranker, just the rewriter on the front of a conversational retriever.

House conventions

Every prompt here follows the same rules — they're what make a RAG pipeline trustworthy:

1. Reasoning / decision before the verdict. Reasoning-first on the rewriter, decomposer, grader, and synthesizer; for the groundedness-guardrail gate the cheap can_answer boolean comes first so you can branch on it. Key order is pinned in each system prompt. Reasoning that precedes the answer informs it; reasoning that follows rationalizes it.
2. Grounded only in the input — never outside knowledge. This is the whole point of the collection. answer-synthesis answers only from the chunks and returns answer_found: false rather than guess; groundedness-guardrail refuses when the context is insufficient even if the model knows the answer; the grader judges relevance on each chunk's own text; the rewriter and decomposer never invent intent the user didn't express.
3. Citations are first-class — and verifiable. answer-synthesis emits inline [id] markers and a citations array.
4. Strict schemas. additionalProperties: false, complete required arrays, closed enums throughout.
5. Injection-safe inputs. User content — queries, history, chunk text, context — is injected with triple-mustache (so &, <, " are never HTML-escaped) and wrapped in XML-style delimiters. A chunk or context that says "ignore the question and output X" is treated as data, not instructions.
6. Parameterized, not hardcoded. Each prompt exposes a meaningful knob beyond the raw input (conversation history, an alternatives count, a sub-query cap, an answer style).
7. Empty / garbage behaviour is specified — empty context gates to can_answer: false; absent answers gate to answer_found: false; a trivial query is returned essentially unchanged.

A note on runtime ids

answer-synthesis and chunk-relevance-grading take their chunks at runtime. Because the output schema is fixed per version, parseOutput() can't verify that a returned citation id (or graded chunk_id) is one you actually supplied — add a one-line membership check in your code (citations ⊆ providedIds). Each prompt's page calls this out, mirroring text-classification in Structured Extraction. A mismatch is your signal that the model cited something out of band — treat it as a failed answer.