Pragmatic AI
Origin Note

Why RAG breaks down at scale

RAG finds the passages closest to your question. It cannot tell you how many it missed. When the job is to find every instance in the corpus, that gap is where the project stalls.

The prototype worked. You pointed it at a few hundred documents, asked questions, and got answers with citations. Everyone in the room agreed this was the thing.

Then it went against the real corpus and the answers got worse in a way nobody could pin down. They still read well. They were still cited. They were just incomplete, and there was no way to tell which ones.

No amount of tuning fixes this. Retrieval behaves this way by design.

Rung one, retrieval

RAG answers a question by finding the passages most similar to it and handing them to a model. It works, and for a large class of questions it is the right tool.

It has one structural property that matters here. It returns the top k results. Not the results that matter, not all the results, the closest k of them.

Top k has no relationship to how many matches exist. Nine relevant passages or nine thousand, you get the same handful back. Nothing in the output tells you which case you were in.

Similarity is not relevance. The passage that phrases things closest to your question is not always the one holding the fact. The one that matters may use different words entirely.

Chunking cuts records apart. A finding split across a paragraph boundary becomes two chunks, each of which looks incomplete and neither of which retrieves well.

You cannot tell what it missed. This is the one that hurts. The output looks the same whether it found everything or a third of it, and there is no signal to check.

For a question with one answer, none of this bites. For a question with two hundred answers, all of it does.

CORPUS, NINE MATCHES CORPUS, SEVERAL HUNDRED RETRIEVED 5 of 9 RETRIEVED 5 of 000s Same query, same output size. Only one of these is complete.
Diagram 1. Illustrative. Counts are placeholders.

Rung two, extraction

The job most people actually have is not question answering. It is enumeration. Find every instance of a thing across the corpus and put it in a structure.

Every reported variant and the evidence attached to it. Every clause of a given type across ten thousand contracts. Every measurement with its units and conditions. The value of the output depends on it being complete, which means the tool has to be built around completeness rather than around similarity.

That means reading everything rather than retrieving a slice of it. Which sounds expensive, and used to be prohibitive, and is now mostly an engineering problem. The harder part is what you do with what you read.

Extraction at scale is a pipeline, not a query. Documents get classified. The right extractor runs against each type. Every extracted value keeps a pointer to where it came from. Conflicts between sources get surfaced instead of averaged away. Low confidence output goes to a person rather than into the table.

The output is a structured corpus rather than an answer. That is a different asset, and a considerably more useful one.

RETRIEVAL ? Answers a question. EXTRACTION INSTANCEVALUESRC Item 0010.00Item 0020.00Item 0030.00Item 0040.00 Builds an asset.
Diagram 2. Illustrative. Values are placeholders.

Rung three, inference

Once the corpus is structured, the questions worth asking change.

Not what does this document say, which retrieval handles. Questions like where do these sources disagree, what has shifted over fifteen years of publication, which of these findings has never been replicated, what is missing from this body of work. No passage contains those answers. They exist across the structure, and you can only ask them once the structure is there.

This is what an inference platform does. Extraction is a component of it, not the point of it. The point is reasoning over a corpus with the completeness and the provenance to trust the result.

The gap between rung one and rung three is where most projects get stuck. They reach for retrieval, get a convincing demo, and then discover the demo does not become the system.

Retrieval finds passages What does this say? Extraction enumerates and structures Where does this appear? Inference reasons across the whole What does all of it mean together?
Diagram 3. The ladder, summarised.

Where this came from

We did not arrive at this position from theory.

Our team built an extraction system against a scientific literature corpus, in a domain where a missed instance is not a ranking problem but a wrong answer with consequences. Retrieval was the obvious starting point and it broke exactly where described above. Completeness had to be designed in, provenance had to survive every stage, and disagreement between sources had to be surfaced rather than resolved silently.

What we learned building it became Lissajous, our inference platform. The extraction pipeline sits inside it as one layer, with the reasoning built on top.

Lissajous An inference platform for document repositories at scale. A product of Pragmatic AI.

If this sounds like your problem

The signals are consistent. Your RAG prototype impressed everyone and then plateaued. You need every instance, not the best few. Someone is still checking output by hand because nobody trusts the completeness. The corpus keeps growing and the approach is not getting better with it.

The first thing to establish is what complete means for your corpus, and how you would know if you had it. That question is answerable in a conversation, and it usually reframes the project.

Related
Use Case Turning legacy documents into structured data Rung two, running in production against a fifty-year archive. Application Note Automating a recurring report with AI What extraction with provenance makes possible downstream.

Bring us the corpus your prototype choked on.

We will tell you what is actually required to get complete, structured output from it, and whether you need a platform or a pipeline.

Get Pragmatic

Common questions

Is RAG bad?

No. It is a good tool for question answering over documents, and for that job it is often the right answer. The failure is using it for exhaustive extraction, which it was never built to do.

Can we not just raise k?

Raising k gives you more passages and a longer context, and it still does not tell you whether you have all of them. It also degrades precision as k climbs. The issue is not the number, it is that retrieval has no concept of completeness.

Do long context models solve this?

They help, and they change what is affordable. They do not remove the need for structure, provenance, or validation. A model that reads a million tokens still gives you prose, and prose is not a queryable asset.

How do you know the extraction is complete?

By reading everything rather than sampling, by validating against what the document type is supposed to contain, and by routing uncertainty to a person. Complete is not a claim you make, it is a property you design for and measure.

How large a corpus does this apply to?

Large enough that nobody can read all of it, which is smaller than most people expect. A few thousand documents is usually past the line.