Live data from Hacker News

RAG Is Simpler Than You Think

lighthousenewsletter.com

151–160 of 179 posts

Re: RAG Is Simpler Than You Think

#151
We removed retrieval from our coding agent a while back. What convinced us wasn’t a benchmark, we found that the retrieval path had been returning zero results for quite some time because of a technical bug, still nobody noticed, indeed it was working better than before.

After doing some rigorous A/B testing, we dropped indexing. For coding, I think the reason is that a repo is already searchable. Imports, call sites, file and test names, grep gives you cheap yet reliable version of what indexing would do, and the agent can read around a hit to verify it. Chunked retrieval hands the model something that looks right, and it tends to trust that instead of going to look for the actual source. Another thing that I noticed was the most intelligent models like Opus 5 and Fable ignored chunks anyway most of the time for some reason. Possibly perhaps they are trained around not trusting similarity checks for codebases.

Extremely large codebases with docs feel different. You can’t grep for a concept you can’t name. That’s the case where I’d still use retrieval.

(I work on TheGitAI, for disclosure.)

Re: RAG Is Simpler Than You Think

#152

Earlier quoted context omitted.

On my last go at making my own rag i still got better results by collecting the data and uploading to a project in open(butclosed)ai. My own rag, used by an agent was giving poorer results, and even the agent prefered (derailed)to not use it and look for the info itself rather than using the rag

I would be really grateful if someone could battle-test my frankendb in a full-fledged RAG setup(lmdb + roaring bitmaps + to-be-removed lance with a bitmap-based virtual fs-like tree on top of your data) outside of its original narrow use-case (index for user data + workflows) https://github.com/canvas-ui/canvas-synapsd

Nice work.

Re: RAG Is Simpler Than You Think

#153

Earlier quoted context omitted.

The audience for this piece is already very familiar with RAG. I don't want articles discussing e.g. OLED screens telling me what the acronym is - that would be a sign that the article is far below the level that I need.

I found the piece interesting, once I worked out what it was about. I strongly disagree that taking time to spell out acronyms should be taken as a signal that an article is low level.

For people familiar with the field, it would be like if you had every article about hardware read “Intel Central Processing Units (CPUs) with modern Double Data Rate 5 (DDR5) Random Access Memory (RAM) can be coupled with Nvidia Graphics Processing Units (GPUs) to run Large Language Models (LLMs) that are stored on Solid State Disks (SSDs)”. Just rapidly becomes unreadable.

The acronym constraint was valid in a pre-LLM world but now you are perhaps 3 clicks in a modern browser from learning.

If I read an article that spelled out Random Access Memory I would definitely treat that as a lay article.

Re: RAG Is Simpler Than You Think

#155

I worked on large scale RAG systems before and can say people vastly underestimate full text search and vastly overestimate embeddings. FTS is really easy, portable and scalable and gets you very far, the 80/20 rule applies. Embeddings appear to be nice and magic but when you really get into them you notice: semantic similarity isn’t as good as you think and certainly it won’t make everyone happy. You will inevitably…

RAG is art. I have a very straight forward setup that is highly modular.

RAG is routing and decision making.

I found so much joy in achieving the best results given the requirements than simply hoping for the best with the cool kid called vector db and embeddings.

I agree with you.

Depending on the context and required output I decide how to orchestrate a multitude of specialized modules that produce the best specific result to gain a universally usable system.

It maintains itself.

Also live updates need reruns and rebuilding certain indexes. Everything is highly dynamic but in a deterministic way.

I found my niche with RAG selling and I build them myself.

I take pride in them.

So many look at the technology but not on the required output. It takes hours of talking to people to get an idea of what they need.

And there are regulated businesses where certain information is required to be always factual correct - pricing for example.

Vector search becomes a liability for this use case.

So naturally you have to reconsider your system: mixing factual with probabilistic content and how to make sure, it hits always certain quality benchmarks and on the other hand doesn’t fail others.

I love this kind of stuff.

And there is personal information etc.

Using modules is the key. Orchestration is really fun but I have to admit, not for the faint of heart.

And ever changing parts: LLMs, or restrictions to be matched liked autonomously working - I love RAG.

It gave me back the joy of developing. In fact I never had so much phun before, because it is also “team work”: I am not programming, I am managing a product.

I was in Senior Management of a top tier international bank and besides that build the only ever working platform or IT transformation called dbCORE and overlooked 13 teams with 120 developers.

RAG gives me dbCORE vibes so to say.

Good luck and fun with your RAG systems.

Re: RAG Is Simpler Than You Think

#156
post #117

Earlier quoted context omitted.

Absolutely a novice in this topic, but I would imagine that by simply having sufficiently big chunks it's simply not a problem? You surely have enough information in like a couple of paragraphs to denote in vector space roughly what it is about. So that both chunks would get found by a vector search, and then whatever is the logic it may put the whole original text of those chunks into context, but in any case enough…

Chunks can only be as large as the embedding model’s token limit, about 512-1024 tokens usually. Anything longer gets truncated. Natural language processing could expanded references, but it starts to get tricky. Do you use Graph RAG, embed another version of the chunk that is distinct from the full text version, etc.. Another layer of processing and data to keep in sync if the source dan be updated.

(assuming English text)

512 tokens ≈ 350–400 words ≈ a long paragraph or two. 1024 tokens ≈ 700–800 words ≈ about a page and a half to two pages.

I would be very surprised if that amount of text is not enough to encode a general topic into the embedding (otherwise, what would be the whole point of them?).

So if there is a meaningful reference in C referring to A (assuming A-B-C consecutive 1-2 paragraphs), I would expect that the content of the two at least superficially resemble each other, and a vector query for one would return both. (And also, if I am including A in the context after retrieval, then I better give some context before-after as well -- and references tend to be local).

But feel free to prove me wrong, I'm mostly just guessing, not even an educated (in the given topic) guess here.

Re: RAG Is Simpler Than You Think

#157
post #99

I believe embedding-based RAG, everybody is using, will end. As chips advance, you would use a big llm instead of word embedding for retrieval. It's much more accurate and extensive covering every topic. Still need ~2 years to be replaced.

How would you use a big LLM for retrieval?

As simple as a prompting it with structural output or restrictions for your criteria.

With agents, the prompting could be dynamic for maximum accuracy for every retrieval.

This absolutely would beat the best of the best embedding-based RAG models.

Nobody uses this now mainly due to speed. An llm retrieval would be 10x or more slower than embedding.

You can try that now

Take some failing cases or bad retrieval from your current system Prompt an llm wisely like a perfect prompt to get what you want and provide it the context to it. And see the results.

For context, you are limited now by models contexts (1m), so mostly you would need to split what you have and prompt twice....or more...and so on

Re: RAG Is Simpler Than You Think

#159

Earlier quoted context omitted.

the biggest giveway is actually not the writing style, but the content "using GPT-4o-mini for query rewriting" -> model from 2024, when RAG was trendy, and all the langchain, llama-index, etc, docs mentioned this specific model

author here. at most companies I've worked for recently (F500) RAG is still quite trendy. this was what frustrated me a bit and motivated to write this article - along with other experiences that definitely relate with some of the folks in the comments above

what I implied is that in 2024 a lot was written about RAG, LLMs were trained on it, and that explains your gpt-4o-mini reference. the argument is that the article is ai slop, and that point is totally unrelated to name dropping fortune 500s references

Re: RAG Is Simpler Than You Think

#160
post #124

RAG stands for Retrieval Augmented Generation. The purpose is to search a corpus of text by meaning rather than exact match. I had to look it up.

That sounds more like semantic search and vector db.

RAG is simply fetching external data (retrieval) and adding it to LLM context (augmenting) prior to generating a final response.

Any time LLMs do a grep or a web search to answer the query, it’s RAG. Many people use vector db for their own RAG implementation bc of the semantic search benefits.

Post reply on HN