How to Build a Production RAG Pipeline: Complete Tutorial (2026)

Q: What is the best chunk size for a production RAG pipeline?

The optimal chunk size depends on your content type and use case, but the production starting point for most enterprise RAG systems is 300 to 500 tokens with 10 to 15 percent overlap between adjacent chunks. Technical documentation with dense information benefits from smaller chunks (200 to 300 tokens) to avoid diluting relevance signals. Narrative content like reports or legal documents benefits from larger chunks (500 to 700 tokens) to preserve contextual coherence. The parent-child chunking pattern — retrieving small chunks (150 to 200 tokens) but generating from their larger parent context (600 to 800 tokens) — often outperforms fixed-size chunking for knowledge-dense corpora and is worth implementing once your baseline pipeline is operational.

Q: Which vector database should I use for production RAG?

The answer depends on your deployment model and scale. Qdrant is the leading open-source choice for self-hosted deployments — it is written in Rust, offers excellent performance, native hybrid search (dense + sparse), and a straightforward API. Pinecone is the leading managed cloud service with strong operational simplicity and a generous free tier. Weaviate offers strong hybrid search capabilities and an active ecosystem. pgvector is the right choice if you are already running PostgreSQL and your corpus is under 1 million vectors — it avoids introducing a new operational dependency. Avoid premature optimisation: most enterprise RAG systems with under 1 million documents perform excellently on any of these platforms. Operational complexity (who manages the infrastructure) and ecosystem integration (existing cloud provider, frameworks used) are more important criteria than raw performance benchmarks at typical enterprise scale.

Q: How do I evaluate the quality of my RAG pipeline?

Use the RAGAS framework as your evaluation foundation. The four key metrics to track are faithfulness (are generated answers supported by retrieved context), answer relevance (does the answer address the question), context precision (are retrieved chunks relevant), and context recall (does the retrieved set contain all needed information). Build a golden dataset of 50 to 200 curated question-and-answer pairs verified by domain experts and run RAGAS against it before every significant change (embedding model update, chunking parameter change, index rebuild). For production monitoring, instrument RAGAS on a 1 to 5 percent sample of live queries and set up alerts for metric drops above a defined threshold — a faithfulness score drop of more than 5 percentage points week-over-week is a strong signal of retrieval quality degradation.

Q: What is hybrid retrieval and should I use it?

Hybrid retrieval combines dense retrieval (embedding similarity search) with sparse retrieval (BM25 keyword search) and merges the results using Reciprocal Rank Fusion (RRF). Dense retrieval handles semantic matching — finding content that means the same thing in different words. Sparse retrieval handles exact keyword matches — product codes, proper nouns, technical identifiers, version numbers. In production RAG evaluations across domain-specific corpora, hybrid retrieval consistently outperforms either dense or sparse alone by 5 to 15 percentage points in recall@10. It adds minimal latency (both searches run in parallel) and is supported natively by Qdrant, Weaviate, and Elasticsearch. For any production RAG system where precision and recall matter — which is all of them — hybrid retrieval is worth implementing from the start, not as a later optimisation.

Q: How do I keep my RAG index up to date when source documents change?

The right approach depends on how frequently your source documents change and how quickly stale content is a problem. For slowly changing corpora (weekly or less frequent updates), a nightly full re-index is operationally simple and reliable. For frequently changing content (multiple updates per day), implement event-driven re-indexing: document management systems like SharePoint and Confluence have webhook APIs; S3 and GCS support event notifications; databases support change data capture. When a document changes, delete its existing chunks from the vector store (tracked via document_id metadata) and re-ingest and re-embed the updated version. Track last_indexed_at as metadata on every chunk and include an index freshness dashboard in your operations monitoring — staleness is invisible without explicit instrumentation.

Q: What is the difference between RAG and fine-tuning, and when should I use each?

RAG and fine-tuning solve different problems. RAG grounds model responses in external, updateable knowledge — it is the right choice when your knowledge base changes frequently, when you need to cite sources, when you need to control exactly which information the model uses, or when you want to avoid the cost and complexity of model training. Fine-tuning adjusts the model weights to change its style, format, or reasoning patterns — it is the right choice when you want the model to respond in a specific tone or structure consistently, when you want to reduce inference latency by baking common responses into the model, or when you have a large volume of high-quality labelled examples for a specific task. For most enterprise use cases, RAG is the correct starting point. Fine-tuning on top of a RAG system is worth considering only after RAG quality has plateaued and the bottleneck is clearly the generation behaviour rather than retrieval quality.

Q: How much does a production RAG pipeline cost to run?

Cost depends heavily on query volume, embedding model choice, and whether you use cloud APIs or self-hosted models. For a cloud-hosted pipeline using OpenAI text-embedding-3-large for embeddings (0.13 USD per million tokens), Cohere rerank for reranking (1 USD per 1,000 searches), and GPT-4o for generation (2.50 USD per million input tokens), a typical query with 300-token query embedding, reranking 10 chunks, and 2,000 tokens of generation context costs approximately 0.006 to 0.012 USD per query. At 100,000 queries per day, that is 600 to 1,200 USD per day in API costs. Self-hosting the embedding model and reranker on a single A10G GPU instance (about 2 USD/hr on AWS) becomes cost-effective above roughly 5 to 10 million queries per month, reducing variable cost to fixed compute.

Q: How do I prevent hallucinations in a RAG pipeline?

Hallucination in RAG systems comes from two sources: the model generating content not present in the retrieved context (generation hallucination) and the retrieval stage returning irrelevant context that the model extrapolates from incorrectly (retrieval-induced hallucination). For generation hallucination: include explicit instructions in the system prompt to answer only from provided context and respond with a clear "I do not have sufficient information" when the context does not cover the question. Set temperature to 0 or close to 0 for factual RAG queries. For retrieval-induced hallucination: implement a reranker to filter irrelevant chunks before they enter the context, set a minimum relevance score threshold below which chunks are excluded even if they are the top-k results, and instrument faithfulness metrics via RAGAS to detect cases where generation diverges from context. The complete architecture for production hallucination prevention is covered in the AI hallucination prevention guide.