RAG isnt dead, it just isnt being used correctly. agents get the correct answer, yes, just not fast. RAG is a performance optimization (and cost), same as it always has been. as agents improve, the nature of what and how to RAG will change, but it has no reason to not exist, not the opposite.
The RAG Obituary: Killed by agents, buried by context windows
171–180 of 185 posts
Re: The RAG Obituary: Killed by agents, buried by context windows
#172Earlier quoted context omitted.
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.
So you're saying grep isn't a form of information retrieval?
information retrieval is a much larger superset of RAG.
grep + agentic LLM is not RAG.
Re: The RAG Obituary: Killed by agents, buried by context windows
#173I worked at a startup that heavily relied RAG, and this article definitely articulates most of the same issues we ran into. I do think RAG still has its place but it is definitely becoming a harder to justify case.
Re: The RAG Obituary: Killed by agents, buried by context windows
#174> Table Integrity: Financial tables are never split—income statements, balance sheets, and cash flow statements remain atomic units with headers and data together In 10-k and 10-q often there are no table headers. This is particularly true for the consolidated notes to financial statements section. Standalone tables could be pretty much meaningless because you won't even know what they are reporting. For example, a t…
[deleted]
Re: The RAG Obituary: Killed by agents, buried by context windows
#175RAG 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.
[deleted]
Re: The RAG Obituary: Killed by agents, buried by context windows
#176Earlier 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.)
Jump to definition works when you have the starting point already. I use both grep and JTD fairly frequently for different use cases.
Yes.
I meant 'Jump to Definition' as one clear example, not as a definitive enumeration of everything that compiler integration can help you with.
Eg compiler integration is also really useful to show you the inferred types. Even dinosaurs like old-school Java and C have (limited) type inference: inside of expressions. But of course in a language like Haskell or Rust (or even Python) this becomes much more important.
Re: The RAG Obituary: Killed by agents, buried by context windows
#177Earlier quoted context omitted.
I don't get it. Isn't grep RAG?
In RAG, you operate on embeddings and perform vector search, so if you search for fat lady, it might also retrieve text like huge queen, because they're semantically similar. Grep on the other hand, only matches exact strings, so it would not find it.
This isn't the case.
RAG means any kind of data lookup which improves LLM generation results. I work in this area and speak to tons of companies doing RAG and almost all these days have realised that hybrid approaches are way better than pure vector searches.
Standard understanding of RAG now is simply adding any data to the context to improve the result.
Re: The RAG Obituary: Killed by agents, buried by context windows
#178This 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…
>The author spent half the article complaining about RAG's limitations with this exact scenario (his $5.1B litigation example), then proposes grep as the solution, which would perform even worse.
Yeah I found this very confusing. Sad to see such a poor quality article being promoted to this extent.
Re: The RAG Obituary: Killed by agents, buried by context windows
#179This 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…
Isn't grep + LLM a form of RAG anyway?
I guess, but with a very basic form of exact match retreival. The embedding based RAG tries to augment the prompt with extra data that is semantically similar instead of just exactly same.
Re: The RAG Obituary: Killed by agents, buried by context windows
#180Earlier quoted context omitted.
So you're saying grep isn't a form of information retrieval?
information retrieval is a much larger superset of RAG. grep + agentic LLM is not RAG.
Retrieval Augmented Generation. How you do the retrieving is irrelevant. You can do it manually and it’ll still be RAG. Also, most RAG pipelines combine multiple approaches - BM25, embeddings, etc..