The Many Forms of RAG, Explained Without the Jargon

RAG used to be one thing.

Now it's a whole family, and every vendor is selling you their favorite cousin.

Hybrid, reranking, ColBERT, adaptive, agentic, GraphRAG, self-RAG. If you sat in a meeting last month, you probably heard three of these words and nodded along. This article is for the person who nodded but didn't want to ask. No math, no code, just what each one actually does and when it's worth the money.

First, what RAG is, in one sentence

An AI language model on its own is a very confident person who has read a lot but remembers none of it precisely. It will happily answer your question about your refund policy, your contract, or your customer's account, and it might be completely wrong, because it's answering from a fuzzy memory rather than looking anything up.

RAG (Retrieval-Augmented Generation) fixes that by giving the model an open-book exam. Before it answers, the system goes and retrieves the relevant documents from your own knowledge base, hands them to the model, and says: "answer using these, not your memory." That's the whole idea. Find the right information, then let the model write the answer.

Everything else, every fancy term below, is just a different way of doing the "find the right information" part better. Because that's where it usually breaks.

RAG is not a model feature. It's the difference between an assistant that guesses and one that checks.

The starting point: plain RAG (and where it lets you down)

The simplest version works like this: you chop your documents into small pieces, store them in a way that lets you search by meaning, and when a question comes in, you grab the few pieces that look most similar and feed them to the model.

For a lot of use cases, that's genuinely enough. Don't let anyone shame you out of a simple setup that works.

But it fails in predictable ways, and each failure has a fix with a fancy name:

• It searches only by meaning, so it misses exact terms like an invoice number or a product code.
• It grabs the pieces that look relevant, but the genuinely useful one is buried at position 47.
• It treats every question the same, so a simple "what are your opening hours" gets the same heavy treatment as a complex compliance question.
• It can't follow connections across documents.
• It only searches once, even when one search clearly isn't enough.
• It never checks its own work.

Now the family makes sense. Each member solves one of those.--- Unknown node: hardBreak ---

Finding it: hybrid search

Plain RAG searches by meaning. That's great for "how do I cancel my subscription" and terrible for "show me clause 7.3b" or "IBAN NL91ABNA0417164300."

Hybrid search runs two searches at once and merges the results. One search looks for exact words and codes (the old, reliable keyword approach). The other searches by meaning. You get the best of both.

Think of a good librarian. Ask for a book and they'll find it two ways: by the exact catalogue number if you have it, and by the topic if you only know roughly what you're after. Using only one method means you miss half the shelf.

Hybrid search doesn't decide which result is best. It just makes sure the right one is somewhere in the pile. That's a different job from the next one.

Ordering it: reranking

Here's the dirty secret of most disappointing RAG systems: the right answer was often found, it just wasn't near the top.

The first search is fast but rough. It might return 100 candidates with crude scores. A reranker takes those candidates and reads each one properly, alongside the question, and reorders them so the genuinely best pieces rise to the top three, which are the ones the model actually sees.

The first pass is a bouncer glancing at a long line and waving people through. The reranker is the interviewer who actually sits down with the shortlist. Slower per person, far better judgment.

If I could give one piece of advice to a team whose RAG "kind of works but not really," it's this: add hybrid search and a reranker before you touch anything more exotic. This is where most of the quality lives, and it's the cheapest to add.

Most RAG problems are not "the answer wasn't there." They're "the answer was there, at number 12, and nobody looked."

The sharper cousin: late interaction, or ColBERT

ColBERT (and "late interaction," the technique behind it) is a more precise, more expensive kind of reranker. A normal system squeezes a whole document into a single fingerprint. ColBERT keeps a fingerprint for every word, so it can match on a single decisive detail rather than the overall gist.

That precision matters most where one word changes everything: legal text, contracts, regulations, technical specs. "The tenant shall" and "the tenant may" look almost identical to a coarse system and mean opposite things to a lawyer. The trade-off is storage and cost, so you reach for it when accuracy on fine detail genuinely pays for itself, not by default.

Choosing the route: adaptive RAG

Not every question deserves the full, expensive treatment. "What are your opening hours" and "which of our clients fall under regulation X and had a transaction over €1M last quarter" are not the same kind of question, and running both through the heaviest pipeline is a waste.

Adaptive RAG puts a dispatcher at the front. It looks at each question and picks the route: simple lookup goes down the cheap, fast lane; a complex, multi-part question gets escalated to the heavy machinery. You save money and latency by only paying for the hard route when the question is actually hard.

Think of a hospital triage nurse. A scraped knee and a suspected heart attack both walk through the same door and get sent to very different places. Sending everyone to the emergency surgeon is slow, expensive, and unnecessary.

Connecting it: GraphRAG

Ordinary RAG stores your knowledge as a big pile of disconnected text snippets. That's fine for "what does this document say," and hopeless for "how does this connect to that."

GraphRAG stores knowledge as a network of entities and relationships instead: this company owns that subsidiary, this person signed that contract, this regulation references that clause. When a question is really about connections, the system can follow the links.

It's the difference between a stack of loose business cards and an org chart. Both contain the same names. Only one answers "who reports to whom." GraphRAG earns its keep on relationship-heavy work: compliance chains, KYC networks, "what depends on what" investigations across a lot of documents.

Searching again: agentic RAG

Sometimes one search will never be enough, no matter how good it is. Some questions need you to find one fact, then use it to go looking for the next.

Agentic RAG lets the AI search in rounds. It searches, reads what it found, decides whether that's enough, and if not, refines the question and searches again, until it has what it needs. It behaves less like a search box and more like a junior analyst working a problem.

This is powerful for genuine multi-step questions ("find the clients under regulation X, then check which of them also breached threshold Y"). It's also the slowest and most expensive member of the family, because every extra round costs time and tokens. Used everywhere, it turns a snappy assistant into a sluggish, pricey one. Used where multi-step reasoning is genuinely required, it's the only thing that works.

More autonomy is not a feature you turn on. It's a cost you take on for questions that actually need it.

Checking its own work: self-RAG and corrective RAG

The last two are about trust, and for regulated industries they matter more than any of the above.

Self-RAG makes the model review its own answer before it commits: did I actually use the sources, do they support what I'm about to say, does this genuinely answer the question? If not, it reconsiders instead of confidently shipping a wrong answer.

Corrective RAG (CRAG) goes one step further. It grades the retrieved documents first, and if they're weak or off-topic, it doesn't just soldier on with bad material, it goes and gets better sources (a fresh search, a reformulated query, sometimes the web) before answering.

Together they're a quality-control layer bolted on top. In a customer-facing bank or public-sector assistant, this is often the difference between "impressive demo" and "allowed to go live."

So which ones do you actually need?

Here's the honest part, the part the LinkedIn threads skip.

You almost certainly don't need all of them. The most common mistake I see is a team reaching for agentic GraphRAG with self-correction when their real problem is that they never added a reranker. Complexity is not a sign of sophistication. It's a cost, in latency, in compute, in the number of things that can quietly break at 2 a.m.

A pragmatic way to think about it:

Start here (fixes most problems, cheap):
  hybrid search  +  reranking

Add only when a specific problem demands it:
  ColBERT / late interaction  ->  fine detail in legal/technical text
  adaptive RAG                ->  wide mix of easy and hard questions, cost matters
  GraphRAG                    ->  questions about connections between things
  agentic RAG                 ->  genuine multi-step, multi-hop questions
  self-RAG / corrective RAG   ->  high-stakes, regulated, trust-critical answers

The thread that ties it together: hybrid finds it, reranking puts it in the right order, adaptive picks the route, GraphRAG and agentic handle complex connections, and self-RAG checks the work afterwards. Each one earns its place by solving a problem you can actually name. If you can't name the problem, you don't need the technique yet.

And none of it is a one-time setup. Retrieval quality drifts as your content changes, which is a whole separate failure story I've written about here. The forms in this article are the tools. Keeping them working is the job.

Final thought

RAG stopped being one thing a while ago. That's not hype, it's maturity, the same way "search" quietly became a dozen specialized techniques over the years.

But maturity cuts both ways. A richer toolbox means more ways to over-engineer, more impressive-sounding architectures that solve a problem you don't have while ignoring the one you do.

So the useful question is never "which is the most advanced form of RAG." It's "what is my system actually getting wrong, and which of these fixes that." Answer that honestly, add the cheapest thing that solves it, measure, and only then reach for the next cousin.

That's less exciting than a slide full of arrows. It's also how you end up with something that works on Monday morning, in production, with real users, and stays working.