Explainers · updated July 2026
What is RAG? The model reads before it writes.
RAG (retrieval-augmented generation) is a simple idea with a heavy name. Before an AI model answers, a retrieval step fetches the passages from your data that best match the question and pastes them into the prompt. The model then writes grounded in that text instead of from memory alone. It is how ChatGPT answers about a PDF you uploaded, and how a Pinecone-style vector database grounds a chatbot in a company's private docs. Here is the whole pipeline, and the one step where it quietly goes stale on fast-changing code.
The pipeline
Four moves. Only the last one is the model.
Every RAG system (a weekend project or an enterprise search box) is the same shape. Ahead of time, your files are split into chunks and turned into vectors that live in a knowledge base. Then, on every question, four steps run left to right. The retrieval step (the R in RAG) is where the magic lives and, later, the risk.
The whole system rests on step 2. The answer is only ever as good as what retrieval pulled back. Hand the model the wrong chunks and it will write, confidently and fluently, from the wrong page. Notice how little of RAG is the model: three of the four steps are plumbing that decides what the model gets to see.
Where it shines
Built for meaning. Ask in your words, not its.
RAG's strength is semantic recall. You don't need the exact keyword: retrieval matches by meaning, so it finds the right passage even when the words don't line up. That makes it genuinely excellent at three things.
This is RAG at its best, and it is already everywhere. Upload a PDF to ChatGPT and ask a question, and a retrieval step quietly runs before the model ever sees your words. Point a support bot at a company handbook through a Pinecone-style database, and that is RAG too. When the question is conceptual (what is this about, what handles this, explain this area), it is the right tool.
Where it drifts
Embeddings are a snapshot. Your code isn't.
RAG has one structural catch, and it bites hardest on code. Vectors are a photograph of meaning taken at index time. A codebase is a film that never stops rolling. Between re-embeds, retrieval answers from the last photo, not the frame on screen right now.
Rename a function, refactor a module, add a file: the vectors keep pointing at the old meaning until someone re-embeds. The gap is invisible until an answer is wrong.
Nearest-neighbor retrieval ranks by similarity. Superb for “what is this about,” shaky for “did I catch every exact call site?” It is not built to be literal.
An error string copied from a stack trace, or a symbol that appeared five minutes ago, is precisely what similarity search is worst at finding.
For a fast-moving repository, the distance between what the vectors remember and what the file says right now is exactly where RAG quietly misleads. It is not a flaw to fix: it is the price of retrieving by meaning. The fix is to stop asking meaning-based retrieval to do a literal, real-time job.
The other half of retrieval
RAG for meaning. An exact index for right now.
RAG and exact retrieval answer different questions, so they belong in the same stack, not against each other. Keep embeddings pointed at meaning, where fuzzy recall is the feature. Add an always-fresh index for the literal thing: a name, a symbol, a string, an error message. Whole-machine, across every repo and the files git ignores, fresh to the last save. No model and no embeddings in this lane, so every hit is a literal match you can verify, and with nothing to re-embed, there is nothing to drift.
| The tool | The task | Time | vs Interlinked |
|---|---|---|---|
| Interlinked (live index) | one content query, same corpus | 16 ms | baseline |
| ripgrep (what your agent runs) | same query, same machine | 93.8 s | 58,625× |
Same content query, same files, same machine: 93.8 s on ripgrep → 16 ms on the live index. Because the disk was already walked, the query answers before a fresh walk would even begin.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 μs across 20 queries, 85 μs single-file; content queries run 7 to 9 ms typical, exact phrases ~16 ms. At rest the engine sits near 44 MB in Task Manager, and the on-disk index is under 1% of the drive (~24 GB on a 4 TB machine).
RETRIEVE BY MEANING · OR BY EXACT MATCH · A COMPLETE STACK NEEDS BOTH.
Do this today
Keep RAG. Add the exact lane.
Keep your RAG stack. The vector database stays exactly where it is: it is the right tool for meaning-based recall across large, mixed corpora.
Add the exact index. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON to edit.
Point each at its job. RAG for “what is this about.” The exact index for names, symbols, strings and error messages, whole-machine, fresh to the last save.
Never re-embed to stay current. Save a file and it is searchable in about a millisecond. No re-index step, no drift window, nothing to keep warm. At rest the engine sits near 44 MB.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.