DROOdotFOO RAG Architect
Design retrieval-augmented generation pipelines with the right tradeoffs at each layer.
Workflow
- Choose chunking strategy -- Match chunk method to document structure
- Select embedding model -- Balance dimensions, speed, and domain fit
- Choose vector DB -- Match scale, features, and deployment model
- Design retrieval -- Dense, sparse, hybrid, or reranked
- Evaluate -- Measure faithfulness, relevance, and answer quality
Reading Guide
| Decision | File |
|---|---|
| Chunking strategies + embedding models | chunking-and-embedding.md |
| Retrieval strategies + vector DBs + evaluation | retrieval-and-evaluation.md |
Quick Decision Matrix
| Document type | Chunking | Embedding | Retrieval |
|---|---|---|---|
| Code | Semantic (AST-aware) | Code-specialized | Hybrid + rerank |
| Legal/medical | Document-aware (sections) | Domain-specific | Dense + rerank |
| Chat logs | Sentence | General-purpose | Dense |
| Technical docs | Recursive | General-purpose | Hybrid |
| Mixed/unknown | Recursive (fallback) | General-purpose | Hybrid + 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
- Start simple -- fixed-size chunks + dense retrieval is a valid baseline
- Measure before optimizing -- run RAGAS evaluation before adding complexity
- Chunk overlap matters -- 10-20% overlap prevents context loss at boundaries
- Embedding dimensions are a tradeoff -- higher is not always better (cost, latency)
- Hybrid retrieval (dense + sparse) almost always beats either alone