RAG vs Agentic RAG: why search beats embeddings for code retrieval
Traditional RAG relies on vector databases, embeddings, and chunking. Agentic RAG uses primitive search tools and structured traversal. Learn why Claude Code's approach works better for large codebases and how PageIndex reimagines RAG without vectors.
A growing debate in the AI retrieval space: do you need vector databases at all?
Traditional Retrieval-Augmented Generation (RAG) has become the standard for giving large language models access to external knowledge. The pattern is familiar:
Chunk your documents into pieces
Generate embeddings for each chunk
Store embeddings in a vector database
At query time, embed the query and search for similar chunks
Feed retrieved chunks to the LLM
But there is another approach gaining traction: agentic RAG. Instead of pre-indexing everything, you give the agent primitive search tools and let it find what it needs on demand.
The traditional RAG pipeline
RAG has been the dominant pattern for grounding LLMs in external knowledge since 2020. Here is how it works:
1. Chunking
Break documents into smaller pieces (typically 256-1024 tokens) because:
Embeddings have size limits
Smaller chunks improve retrieval precision
LLMs have context window constraints
Problem: Chunking destroys context. A function split across two chunks loses coherence. Overlapping windows help but add redundancy.
2. Embedding
Convert each chunk into a dense vector (e.g., 768 or 1536 dimensions) using models like:
OpenAI text-embedding-3
Cohere embed-v3
Sentence-BERT variants
Problem: Embeddings are lossy. Semantic similarity doesn't always match intent. Code structure matters more than surface-level similarity.
3. Vector storage
Store embeddings in specialized databases:
Pinecone
Weaviate
Chroma
Qdrant
pgvector
Problem: Infrastructure overhead. You now manage an additional database, syncing, versioning, and reindexing when content changes.
Code is structured, not unstructured text. Traditional RAG treats code like documents, but code has:
Syntax trees - Functions, classes, variables, imports
Symbols - Definitions, references, call graphs
File systems - Organized hierarchies
Build systems - Dependencies, modules
Agentic RAG exploits this structure. Instead of embedding code chunks and hoping similarity search finds the right function, the agent can:
Glob for files matching **/auth*.ts
Grep for function authenticate
Read the exact file
LSP query for all references to authenticate
Follow imports to understand dependencies
This is deterministic and context-preserving. No chunking artifacts, no missed symbols, no lossy embeddings.
Claude Code's agentic RAG approach
Claude Code has been using agentic RAG for over a year. The team has repeatedly stated:
"The best way to do RAG is agentic RAG. No indexing. No database. No nothing. Just let the agent search with primitive tools or structured symbol traversal (ex: LSP servers for code)."
Key insight: RAG architecture should match data structure.
Code → agentic RAG + LSP
Unstructured text → vector RAG
Hierarchical docs → PageIndex or hybrid
Mixed data → hybrid RAG + agentic refinement
Bottom line
The "RAG industry is getting cooked" claim is partly true:
For code, agentic RAG is superior (Claude Code proves it)
For structured docs, PageIndex offers a simpler alternative
For unstructured text, vector RAG remains the best option
Agentic RAG is not a replacement for traditional RAG. It is a specialized tool for domains where structure matters more than semantics.
PageIndex is a promising middle ground: no embeddings, no chunking, but still deterministic retrieval via graphs.
The real lesson: stop treating all data the same. Code is not text. Wikis are not articles. Match your retrieval strategy to your data structure, and you'll get better results at lower cost.
For code and structured docs, the future is agentic. For everything else, embeddings still have their place.
