Live data from Hacker News

The RAG Obituary: Killed by agents, buried by context windows

nicolasbustamante.com

181–185 of 185 posts

Re: The RAG Obituary: Killed by agents, buried by context windows

#181
post #26

Earlier quoted context omitted.

That's what I used to use as a human, but then I finally overcame my laziness in setting up integration between my editor and compiler (and similar) and got 'jump to definition' working. (Well, I didn't overcome my laziness directly. I just switched from being lazy and not setting up vim and Emacs with the integrations, to trying out vscode where this was trivial or already built in.)

Do you trust 'jump to definition'. Obviously it depends on the language server, but it's best effort. I'm often frustrated when it doesn't work, because I broke the code in some way. Or it jumps to a specific definition, but there are multiple. If I was as quick at opening and reading files as claude code, I'd prefer grep with context around the searched term.

You can instruct the compiler to tell you, for example by passing -save-temps, and then it's a trivial text search in a single file.

Re: The RAG Obituary: Killed by agents, buried by context windows

#182
post #126

RAG isn't dead, RAG is just fiddly, you need to tune retrieval to the task. Also, grep is a form of RAG, it just doesn't use embeddings.

No, grep is not RAG. RAG is all about embeddings + vector search + LLM working under a fixed workflow. Saying grep is also RAG is like saying ext4 + grep is a database.

You don't decide what "RAG" means, a term that's been around for much, much less time than "database".

Re: The RAG Obituary: Killed by agents, buried by context windows

#183

This glosses over a fundamental scaling problem that undermines the entire argument. The author's main example is Claude Code searching through local codebases with grep and ripgrep, then extrapolates this to claim RAG is dead for all document retrieval. That's a massive logical leap. Grep works great when you have thousands of files on a local filesystem that you can scan in milliseconds. But most enterprise RAG use…

Code is also unique in its suitability for agentic grep retrieval, especially when combined with a language server. Code enforces structure, semantics, and consistency in a way that is much easier to navigate than the complexities of natural language.

Re: The RAG Obituary: Killed by agents, buried by context windows

#184

This glosses over a fundamental scaling problem that undermines the entire argument. The author's main example is Claude Code searching through local codebases with grep and ripgrep, then extrapolates this to claim RAG is dead for all document retrieval. That's a massive logical leap. Grep works great when you have thousands of files on a local filesystem that you can scan in milliseconds. But most enterprise RAG use…

Yeah RAG doesn't say what its retrieving from, retrieving with grep is still RAG.

Re: The RAG Obituary: Killed by agents, buried by context windows

#185

Earlier quoted context omitted.

How are they niche? The default mode of search for most dedicated RAG apps nowadays is hybrid search that blends classical BM-25 search with some HNSW embedding search. That's already breaking the definition. A search is a search. The architecture doesn't care if it's doing an vector search or a text search or a keyword search or a regex search, it's all the same. Deploying a RAG app means trying different search met…

Most hybrid stacks (BM25 + dense via HNSW/IVF) still rely on embeddings as a first class signal. So in practice the vector side carries recall on paraphrase/synonymy/OOO vocab, while BM25 stabilizes precision on exact term and short doc cases. So my point still stands. > The architecture doesn't care The architecture does care because latency, recall shape, and failure modes differ. I don't know of any serious RAG de…

But this thread and the OP article assume that RAG is always done *exclusively* with vectors, and that's just not true, it's almost never been true.
Post reply on HN