rag-architect

Design RAG pipelines with informed chunking, embedding, retrieval, and evaluation decisions. TRIGGER when: user asks about RAG pipeline design, chunking strategies, embedding models, vector databases, or retrieval-augmented generation. DO NOT TRIGGER when: user asks about fine-tuning, prompt engineering without retrieval, or general LLM usage.

RAG Architect

Design retrieval-augmented generation pipelines with the right tradeoffs at each layer.

Workflow

  1. Choose chunking strategy -- Match chunk method to document structure
  2. Select embedding model -- Balance dimensions, speed, and domain fit
  3. Choose vector DB -- Match scale, features, and deployment model
  4. Design retrieval -- Dense, sparse, hybrid, or reranked
  5. Evaluate -- Measure faithfulness, relevance, and answer quality

Reading Guide

DecisionFile
Chunking strategies + embedding modelschunking-and-embedding.md
Retrieval strategies + vector DBs + evaluationretrieval-and-evaluation.md

Quick Decision Matrix

Document typeChunkingEmbeddingRetrieval
CodeSemantic (AST-aware)Code-specializedHybrid + rerank
Legal/medicalDocument-aware (sections)Domain-specificDense + rerank
Chat logsSentenceGeneral-purposeDense
Technical docsRecursiveGeneral-purposeHybrid
Mixed/unknownRecursive (fallback)General-purposeHybrid + rerank

What You Get

  • A RAG pipeline architecture specifying chunking strategy, embedding model, vector store, and retrieval method for your document types
  • Concrete configuration recommendations (chunk size, overlap, dimensions, top-k) with rationale for each tradeoff
  • An evaluation plan using RAGAS or equivalent metrics to validate retrieval quality before and after tuning

Rules

  1. Start simple -- fixed-size chunks + dense retrieval is a valid baseline
  2. Measure before optimizing -- run RAGAS evaluation before adding complexity
  3. Chunk overlap matters -- 10-20% overlap prevents context loss at boundaries
  4. Embedding dimensions are a tradeoff -- higher is not always better (cost, latency)
  5. Hybrid retrieval (dense + sparse) almost always beats either alone