LLMOpsThe LLMOps lifecycle · MLflow 3 · FastAPI · Docker · AWS/Azure
Dashboard
0%
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
41 small wins to finish your pathNext lesson →

The RAG data pipeline

The RAG data pipeline is the chain that turns your own documents into something an LLM can retrieve from at request time: ingest the source, parse it, split it into a document structure, chunk it, embed each chunk into a vector, store the vectors in a vector database, and build a retriever the app queries.

Last updated: 15 Oct, 2026 · LLMOps

The Pick the build: RAG, fine-tuning, or both lesson chose between giving a model knowledge through retrieval and baking it in by fine-tuning. When the choice is retrieval, this pipeline is the data work it commits you to. In the Detailed LLMOps Project Lifecycle video, the data chain is drawn on the board as the data collection and preparation stage for a RAG application.

The RAG data pipeline, ingest to retriever · from the Detailed LLMOps Project Lifecycle video · 7:26 to 8:32

The stages, in order

On the board the stage is a fixed sequence, each step feeding the next. The framework course writes the code for each; here the point is the shape and the order, because that order is what you re-run when anything upstream changes.

  1. Ingestion pulls the raw source in: files, pages, a database export, whatever the documents live as.
  2. Parsing reads each source into a clean document structure, stripping the format down to text and metadata.
  3. Splitting breaks a long document into smaller passages with a document splitter, so no single piece is too large to embed or retrieve.
  4. Chunking fixes the size of those passages, the unit the retriever will later return.
  5. Embedding converts each chunk into a vector with an embedding model, so meaning becomes a point in space.
  6. Storing writes the vectors into a vector database, the index the app searches.
  7. Retrieval builds a retriever on top of that database, which takes a question and returns the closest chunks.
The RAG data pipeline as a left-to-right chain: Ingestion, then Parsing, then Splitting, then Chunking, then Embedding, then a Vector database, then a Retriever. The first six steps are labelled the indexing path, run when documents change; the retriever is labelled the query path, run on every user question.

The ops view: what you version, re-run and monitor

The framework course owns how to build each step. The operations question is different: every stage is something you have to version, re-run and watch. The video lists data versioning alongside model and code versioning in the lifecycle's version-control stage, and for RAG the data you version is the chunks and their embeddings.

  • Version the inputs and the index. The source documents, the chunking settings and the stored vectors each have a version, so you can tell which index answered a question.
  • Re-run on change. New or edited documents mean re-ingesting, re-chunking and re-embedding at least the parts that changed, then refreshing the store.
  • Watch retrieval quality. The signal that matters in production is whether the retriever returns the right chunks, not whether the pipeline finished without error.
  • Account for embedding cost. Embedding every chunk is a compute or API cost that grows with how much data you hold and how often you re-index.

The indexing path and the query path

The chain splits into two paths that run on different clocks. The first six steps build the index offline; the retriever runs online, once per question.

Indexing pathQuery path
When it runsWhen documents changeOn every user message
StepsIngest, parse, split, chunk, embed, storeEmbed the question, retrieve the closest chunks
What you watchRe-index time and coverageRetrieval relevance and latency
What you versionThe chunks and their vectorsThe retriever settings, such as how many chunks to return
Two paths meeting at one vector database. The indexing path, which runs when documents change, goes left to right from documents through parse and split, chunk and embed into the vector database. The query path, which runs on every user message, goes from the question through embedding the question, searches the same database, and continues out the other side to the closest chunks, the model and the answer.

Where the RAG data pipeline fits

  • Any assistant answering from a private corpus, such as the shop support bot grounded in product and policy documents.
  • A knowledge base that changes, where new documents must reach the index without rebuilding the whole app.
  • A system that has to cite its source, which the retrieved chunk and its metadata make possible.
Watch out. The embedding model is part of the index, not a free choice you can change later. Swap it and every stored vector was produced by the old model, so the retriever compares new questions against stale vectors. Changing the embedding model means re-embedding the whole corpus, which is why you pick it deliberately and record which one built the index.
Try it yourself
  • Take ten of your own documents and build the ingest-to-store path from the Building a RAG pipeline lesson, then query the retriever.
  • For one document source, write down every stage you would re-run if the file changed tomorrow.
  • Open the model card of an embedding model and note its vector dimension and its price per million tokens.
PreviousPick the build: RAG, fine-tuning, or both

This is what real progress feels like.