RAG Architecture: The Pipeline and Workflow, Stage by Stage
Ingest, chunk, embed, index, retrieve, rerank, assemble, generate — what each stage decides, which failure it causes downstream, and how the whole workflow fits together.
A RAG pipeline is the stage sequence that turns source documents into grounded answers — ingest, chunk, embed and index offline; retrieve, rerank, assemble and generate online. Find the stage, then open the page that owns it.
What is a RAG pipeline?
A RAG pipeline is the connected sequence of stages that retrieves passages from an external corpus and injects them into an LLM prompt before generation — so answers cite your documents rather than training weights alone. That definition is the consensus across the top-ranking results for rag pipeline / rag architecture / rag workflow (AWS What is RAG; lakeFS What is a RAG Pipeline; Databricks End-to-End RAG Workflow — pages captured 2026-07-27). The pipeline is the stage sequence; named patterns such as naive RAG, advanced RAG, GraphRAG and agentic RAG are architectures built on top of those stages — they live on RAG architectures, not here.
Every production system has two paths:
- Indexing path (offline) — documents are parsed, cleaned, chunked, embedded and written into a searchable store. This path can take minutes per document and runs asynchronously.
- Query path (online) — each user question is embedded, candidates are retrieved (and usually reranked), the prompt is assembled, and the model generates a grounded answer.
Coupling those paths — so that re-indexing takes the query API offline — is the most common architectural mistake called out on the top-ranking results (Datarmatics, How to Build a RAG Pipeline, 2026). Keep them independent so you can change chunking or embeddings without downtime.
How does a RAG pipeline work?
A RAG pipeline works as those two independent paths in sequence. The map this site uses names eight stages: ingest → chunk → embed → index on the indexing path; retrieve → rerank → assemble → generate on the query path. Ranking guides group the same work differently — Databricks walks five stages from ingest to generate; Atlan (updated April 2026) names five layers including evaluation; architecturediagram.ai (May 2026) uses five conceptual layers from ingestion to generation; AWS describes create external data → retrieve → augment the prompt → update the store. The stage names vary; the offline/online split does not.
What each stage decides:
- Ingest — which documents enter, how they are parsed, and which metadata (owner, date, permissions) travels with them.
- Chunk — where documents split; the boundary is what retrieval can later find.
- Embed — which vector space represents meaning; the same model must embed queries at runtime.
- Index — how vectors are stored and filtered so search is fast enough and scoped correctly.
- Retrieve — which candidates come back for a query (dense, sparse, or hybrid).
- Rerank — which of those candidates actually enter the prompt, in what order.
- Assemble — how context, instructions and the question are packed into the prompt the model sees.
- Generate — the grounded answer, including whether the model stays inside the retrieved context.
The minimum tutorial loop is six stages — load, chunk, embed, store, retrieve, generate — and that is what building a RAG pipeline from scratch implements. Production systems usually name reranking and prompt assembly as stages between retrieve and generate because that is where precision and grounding are won or lost. Databricks’s FAQ on the top-ranking results states the failure that follows when they are skipped: poor retrieval quality is the most common RAG failure mode — a strong generator cannot compensate for irrelevant chunks. When a symptom shows up, diagnose by stage on why RAG systems fail.
What are the stages of a RAG pipeline?
Match the decision you are making to a stage below — then open the hub that owns that stage, or the pipeline child that covers build, data prep, cost or accuracy. Depth lives on those pages; this hub only orients.
Indexing path — build the store
Query path — answer each question
Build and operate the pipeline
Don’t know where to start?
If you want working code, start with building a RAG pipeline from scratch → If something already returns the wrong answer, isolate the stage with the debugging procedure → rather than re-chunking and hoping.
What is a RAG pipeline?
A RAG pipeline is the stage sequence that retrieves passages from an external corpus and injects them into an LLM prompt before generation — so answers cite your documents rather than training weights alone. It has two paths: an offline indexing path that builds the searchable store, and an online query path that answers each question against it.
How does a RAG pipeline work?
Documents are ingested, chunked, embedded and indexed offline. At query time the question is embedded, candidates are retrieved, usually reranked, packed into a prompt, and the model generates a grounded answer. Keep those paths separate: re-indexing should not take the query API offline. Poor retrieval is the most common failure — a strong generator cannot fix irrelevant chunks.
What are the stages of a RAG pipeline?
This site maps eight stages: ingest, chunk, embed and index on the indexing path; retrieve, rerank, assemble and generate on the query path. The minimum tutorial loop is six stages — load, chunk, embed, store, retrieve, generate — which is what the build tutorial implements. Production systems usually name rerank and prompt assembly as stages between retrieve and generate.
How do you build a RAG pipeline?
Build it stage by stage with the choice at each stage stated and measured, not defaulted. Start from the runnable Python tutorial at /pipeline/build; use this hub only as the map of which stage owns which decision. If you are still deciding whether RAG is the right tool, weigh it against fine-tuning at /decisions/rag-vs-fine-tuning first.