The RAG Pipeline Architect

#CONTEXT
You are building a Retrieval-Augmented Generation system. The goal is to ground an LLM's answers in your own documents so it stops hallucinating and cites real sources. The architecture decisions you make at each layer determine whether the system works or produces confidently wrong answers.

#OBJECTIVE
Design a complete RAG pipeline architecture for the described use case. Make specific recommendations at each stage with justifications — not generic best practices, but choices tailored to this system.

#STYLE
Technical and specific. Name specific models, libraries, and parameters where the choice matters. Skip explanations of what RAG is — assume the reader knows.

#TONE
Opinionated. When two approaches are viable, pick one and say why. Do not present options without a recommendation.

#AUDIENCE
A developer or technical lead who needs to make build decisions this week.

#RESPONSE
Address each pipeline stage:

## 1. Document Processing
- Recommended chunking strategy (fixed-size, semantic, recursive, sentence-level) and chunk size — justify based on document types
- Overlap strategy
- Metadata to preserve (source, section, date, author)

## 2. Embedding
- Recommended embedding model (name it) and why
- Vector dimensions
- Whether to use a different model for queries vs. documents (asymmetric embedding)

## 3. Vector Store
- Recommended store (pgvector, Pinecone, Qdrant, Weaviate, local FAISS) based on scale and infrastructure
- Index type (HNSW, IVF) and key parameters

## 4. Retrieval
- Hybrid search recommendation (dense + sparse / BM25) — yes or no, and why
- Top-K value and rationale
- Query transformation (reformulation, HyDE, multi-query) — recommended approach

## 5. Reranking
- Whether to rerank (and with what model)
- How many candidates to retrieve before reranking

## 6. Generation
- Context assembly strategy (how to format retrieved chunks into the prompt)
- Citation handling approach
- Guardrails for off-topic queries and no-answer-found cases

## 7. Evaluation
- How to measure retrieval quality (recall, precision, MRR)
- Recommended eval dataset approach
- Metrics to track in production

#CONTEXT
- Document types: {{document_types}} (PDFs, web pages, code, internal wiki, support tickets)
- Document volume: {{document_volume}}
- Query volume expected: {{query_volume}}
- Latency requirement: {{latency_requirement}}
- Budget: {{budget}}
- Current LLM: {{llm}}