RAG & Vector Databases
Semantic Search & Chunking
Optimizing how data is split and retrieved.
Interview: High - Makes or breaks RAG quality
Chunking: The Most Underrated Step in RAG
Hybrid Retrieval Pipeline
How you split your documents into chunks has more impact on RAG quality than your choice of LLM or vector database. Bad chunking = irrelevant retrieval = wrong answers.
Chunking Strategies
- Fixed-size: Split every N tokens. Simple but breaks mid-sentence.
- Recursive Character: LangChain's default. Splits by paragraphs, then sentences, then characters.
- Semantic: Use embeddings to detect topic boundaries. Most accurate but slowest.
- Document-aware: Respect document structure (headers, sections). Best for structured content.
Chunk Overlap
Always use 10-20% overlap between chunks to avoid losing context at boundaries.
Optimal Chunk Size
There's no universal answer, but general guidelines:
- 256-512 tokens: For precise, fact-based Q&A
- 512-1024 tokens: For general knowledge retrieval
- 1024+ tokens: For summarization or when context is important
Use Cases
Processing large PDF documents for Q&A
Indexing codebases for code search
Building searchable knowledge bases from wikis
Processing legal contracts with section-aware chunking
Common Mistakes
Chunks too small = missing context. Chunks too large = irrelevant noise.
No overlap between chunks causes information loss at boundaries
Ignoring document structure — a table split across chunks becomes useless
Not benchmarking different chunk sizes on your actual queries