Writing · Adapt Progress Evolve
Personal
RAG is a tool, not a requirement
RAG earns its keep for domain-specific knowledge and regulated industries, but premature implementation before product-market fit wastes resources and obscures
Filed · 4 min read
Every enterprise AI vendor pitch I've sat through lately has the same slide. RAG, right in the middle, glowing, as if your product isn't a real AI product without it. I mean, absolutely not. It's a tool. Sometimes it's the right one, sometimes it's an expensive detour, and the slide never tells you which.
So here's how I think about it, builder to builder, no vendor in sight.
Where RAG earns its keep
First, domain-specific knowledge bases. If your product has to answer from material the base model has never seen (internal documentation, proprietary research, a niche body of rules), then retrieval isn't a nice-to-have. The model simply doesn't know the answers. You can't prompt your way around that.
Second, regulated industries where someone will ask "where did that come from?" Source attribution is the whole game there. If a compliance person needs to click through to the exact passage behind an answer, you need retrieval, because it gives you something to point at. A confident paragraph with no citation is a liability.
Third, anywhere hallucination is expensive. Think of a product where one wrong answer means a lost customer, a legal headache, or someone acting on bad information. Grounding the model in retrieved text doesn't eliminate errors (more on that later), but it narrows the space they can happen in.
If you tick one of those boxes, fine. Build it. Just build it deliberately.
Where RAG is premature
Now the part vendors skip.
Pre-PMF products. If you don't yet know what users actually ask, what they care about, or whether they'll come back, then building a retrieval pipeline is optimising something you haven't understood. You'll tune chunking and embeddings for queries nobody sends. I've watched teams do this and it feels like progress. It isn't.
Small context windows with adequate coverage. If your whole knowledge set fits in the prompt, just put it in the prompt. Seriously. A well-structured block of context is simpler, cheaper to debug, and has no retrieval step to quietly fail. Context windows keep growing, so check this before assuming you need a vector database.
And cost-sensitive MVPs. Retrieval means infrastructure, indexing, re-indexing, and more things that can go wrong at 2am. If you're stretching a thin budget to find out whether anyone wants the thing, that complexity is a tax you don't need yet.
Four questions before you commit
Run these. Honestly, not optimistically.
One: does the model need knowledge it can't possibly have? If the answer is no, stop here.
Two: does anyone downstream need to verify where an answer came from? If yes, retrieval moves up the list fast.
Three: does your knowledge change often enough that baking it into a prompt becomes a maintenance mess? Static and small favours the prompt; shifting and large favours retrieval.
Four: do you have real user queries yet, or are you guessing? If you're guessing, you're designing blind. Go and get queries first.
If you land on mostly no, you probably don't need RAG yet. Mostly yes, you probably do. Mixed, well, that's a conversation, and it's a better conversation than "everyone says we need it."
What trustworthy actually takes
Here's the thing that bugs me. People treat RAG as the trust layer. It isn't. It's one input to trust, and honestly not the biggest one.
Retrieval can fetch the wrong passage. The model can ignore the right one. It can stitch two accurate snippets into one inaccurate claim. So if "verifiable" is the goal, you need more than a retrieval step.
You need evals. A set of real questions with known good answers that you run every time something changes, so you find out you broke it before your users do. Without that, you're just feeling confident, which is not the same thing.
You need logging. Every query, what was retrieved, what the model said. When something goes wrong (and it will), you want to see exactly where the chain snapped, not guess at it.
And you need human review loops. Someone looking at a sample of outputs, flagging the bad ones, feeding that back in. It's unglamorous. It's also the thing that actually makes a system trustworthy over time, as opposed to trustworthy in a demo.
None of that needs RAG. All of it makes RAG better when you add it.
What to ship first
So sequence it like this. Ship the simplest thing that could work: a good prompt, your knowledge in context if it fits, and logging from day one. Build your eval set from the first real queries that come in. Watch where it fails. Then, when the failures are clearly about missing or unverifiable knowledge, layer retrieval in, and you'll know exactly what to retrieve and why.
That's the order. Evidence first, architecture second.
Anyway, I'd love to say the slide is wrong. It's just early.
Filed under Personal