# When Was Retrieval-Augmented Generation Invented, Exactly?

> Discover when retrieval augmented generation was invented, who coined RAG in 2020, its earlier roots, how it works, and where agentic RAG is headed.

- Author: Swarnava Dutta (https://swarnava.dev)
- Published: 2026-07-27
- Tags: When Was Retrieval
- Reading time: 9 min (2025 words)
- Canonical: https://swarnava.dev/blogs/when-was-rag-invented

---

![Illustration of when was retrieval augmented generation invented: A long timeline rail spanning the frame like a bookshelf](/images/blogs/when-was-rag-invented-hero.jpg)

A junior engineer on my team once asked me, mid-incident, "who actually invented RAG anyway, and why does our vector store keep returning garbage from three versions ago?" We were debugging a stale-index bug at 2am, and I realized I didn't have a clean answer to the first half of that question either. Everyone name-drops the same paper, slaps a date on it, and moves on.

That's the trouble with asking when retrieval augmented generation was invented - the honest answer is messier than a single citation. Yes, there's a paper that coined the term "retrieval-augmented generation" in 2020, and it's the reason the acronym exists at all. But the ideas underneath it - grounding a language model's output in an external knowledge source instead of trusting its parameters - go back years earlier, into open-domain question answering research most people building chatbots today have never read.

This piece traces that lineage properly: the pre-2020 groundwork, the paper that gave RAG its name, and how the pattern has mutated into the agentic, multimodal systems running in production now. Along the way I'll show you what actually changed, and what people mean when they claim RAG is dying.

## When Was Retrieval-Augmented Generation Invented? The 2020 Answer

If you want the short, citable answer: retrieval-augmented generation was named and formalized in a paper titled "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." The lead author, Patrick Lewis, worked with a team spanning Facebook AI Research, University College London, and New York University. That's who invented retrieval augmented generation, in the narrow sense of who put the name and the architecture diagram on paper.

But "invented" is doing a lot of work in that sentence. Lewis and his co-authors didn't dream up the idea of grounding language models in external documents out of nowhere - they wired together retrieval components and sequence-to-sequence generation that already existed, and showed the combination beat either piece alone on knowledge-intensive tasks. Naming a pattern and inventing every piece underneath it are different achievements.

That distinction matters more than trivia. It's why understanding RAG's actual lineage helps you reason about where it's headed, instead of treating it as a 2020 invention that appeared from nothing.

## The Pre-2020 Foundations of Retrieval-Augmented Generation

Retrieval-augmented generation history doesn't start in 2020. It starts decades earlier in classic information retrieval - search engines ranking documents by relevance, then open-domain question answering systems trying to pull exact answers out of those ranked documents. Memory-augmented neural networks added another thread, giving models an external store to read and write instead of cramming everything into weights.

What was missing for years was a generative component good enough to turn retrieved text into fluent answers. Pretrained language models solved that gap, and neural document retrieval methods like dense passage retrieval [[1]](#ref-1) gave retrieval itself a learned, semantic edge over old keyword matching. Systems like REALM showed you could pretrain retrieval and language modeling jointly, right before the RAG paper landed.

### Why the Lewis et al. Paper Became RAG's Starting Point

The paper's contribution was combining a pretrained sequence-to-sequence generator with passages retrieved from Wikipedia at inference time. It split memory into parametric (what's baked into model weights) and non-parametric (what's fetched fresh from an index). Two formulations - RAG-Sequence and RAG-Token - handled how retrieved passages influence generation, giving later builders a reusable name and blueprint.

## What Is RAG, and How Does Retrieval-Augmented Generation Work?

Strip away the jargon and RAG is a pattern, not a product: retrieve relevant evidence at inference time, hand it to a generative model as context, and let the model write an answer grounded in that evidence instead of just its training weights.

Under the hood it splits into two paths. Offline, you run ingestion - parsing documents, [chunking them into passages](/blogs/chunking-strategies-rag), embedding those chunks, and writing vectors into an index. Online, a user query gets embedded, matched against that index, optionally reranked for relevance, then assembled into a prompt alongside the original question before generation and citation.

![Flow diagram showing a RAG query moving through embedding, evidence retrieval, context, and a generative model to produce an answer.](/images/blogs/when-was-rag-invented-diagram-1.jpg "How retrieval-augmented generation works")

Production systems rarely lean on vector search alone. Keyword search, graph traversal, SQL queries against structured tables, live API calls - all count as retrieval, often combined in hybrid setups tuned per query type.

### A RAG Example: Answering Questions From Private Documentation

Say an employee asks a support bot about a parental leave policy updated last month. An unaided LLM, trained months earlier, might confidently cite the old policy. A RAG system retrieves the updated document, generates an answer grounded in it, and links the source page for verification.

## RAG vs. LLM: Where ChatGPT Fits

An LLM is the generative engine - a model that predicts text. RAG is the surrounding architecture, the plumbing that decides what the model gets to see before it writes anything. Conflating the two is how you end up with confused Slack threads about whether GPT-4 "is" a RAG system.

It isn't, by itself. Is ChatGPT a RAG model? Not inherently - the underlying model is a plain LLM, and whether a given ChatGPT response involves retrieval depends entirely on mode and context [[2]](#ref-2). Ask it something from its training data with no browsing enabled and no files attached, and you're getting parametric memory, not retrieval. Turn on web search or upload a document, and now retrieval is genuinely in the loop.

Don't lump RAG in with fine-tuning, function calling, or just stuffing a huge context window with documents - those solve adjacent but different problems, and mixing them up leads to picking the wrong fix for the wrong failure.

## Benefits, Limitations, and the Best Times to Use RAG

RAG's core pitch hasn't changed since 2020: you get access to current, private, or specialized knowledge without retraining the base model. Update the index, not the weights. That alone justifies it for support desks, enterprise search, compliance workflows, research assistants, and technical documentation - anywhere the answer lives in a document that changes faster than a fine-tuning cycle would tolerate.

The secondary benefits matter almost as much. Source attribution lets users verify claims instead of trusting a black box, governance teams can restrict what gets indexed, and grounding in real text tends to cut down on unsupported answers compared to pure generation.

None of that makes RAG bulletproof, though. I've watched systems fail from bad chunking, weak retrieval ranking, indexes nobody refreshed in months, and - worse - access-control leaks where a retriever happily surfaces a document the requesting user shouldn't see. Add prompt injection buried in retrieved text, latency from extra retrieval hops, and models that retrieve the right passage and ignore it anyway. RAG reduces hallucination risk; it never guarantees factual output.

## From Classic Pipelines to Agentic and Multimodal RAG

The 2020 pipeline was one-shot: embed the query, retrieve once, generate. Modern RAG treats retrieval as something an agent decides to do, repeatedly, with judgment.

Agentic RAG lets a model reformulate a bad query, choose between a vector store, a SQL database, or a live web search, call an API, retrieve again if the first pass came up thin, and verify the retrieved evidence before answering. That loop is the actual difference between "RAG" as Lewis's team shipped it and what a serious production system runs today - closer to what tools like [LangGraph](/blogs/why-langgraph-is-used) are built to orchestrate.

![Side-by-side comparison showing classic RAG retrieving once while agentic RAG repeatedly decides whether to retrieve before generating.](/images/blogs/when-was-rag-invented-diagram-2.jpg "Classic RAG vs. agentic RAG")

Retrieval itself got richer too. Graph RAG traverses entity relationships instead of flat chunks, hybrid search blends keyword and vector matching, rerankers reorder candidates by relevance, and metadata filters scope results by date or permission. Contextual retrieval prepends surrounding context to chunks before embedding, cutting the "right passage, wrong meaning" failure mode.

Multimodal RAG extends all this beyond text - retrieving diagrams, scanned tables, audio transcripts, and video frames as first-class evidence, not afterthoughts.

## Is Retrieval-Augmented Generation Dead in 2026?

Every year someone declares RAG dead, and every year the claim rests on the same shaky evidence: bigger context windows. If a model can swallow a million tokens, why bother retrieving anything?

Because dumping everything into context doesn't solve the problems RAG was built for. A long context window doesn't decide which of ten thousand documents is relevant, doesn't drop yesterday's price list when today's lands, doesn't enforce that a contractor can't see HR files, and doesn't tell you which sentence in the output came from where. It also costs real money - paying to reprocess huge prompts on every query is not free just because prompt caching softens the bill.

Agentic retrieval isn't RAG's replacement; it's RAG with judgment bolted on, deciding when and what to fetch instead of fetching once, blindly.

That said, RAG isn't always the right call. Small, static knowledge bases often do fine with plain fine-tuning or a stuffed prompt, and workflows needing deterministic answers are better served by structured queries than semantic search.

## A 2026 Decision Framework for Choosing RAG

Here's the shortcut I give teams instead of a whiteboard debate: match the tool to what actually changes.

- **Reach for RAG** when answers depend on knowledge that's frequently updated, private, too large to fit in any context window, or needs a citable source for compliance or trust.
- **Reach for long-context prompting** when the document set is small and bounded - a single contract, one release's changelog - and doesn't need per-user access control.
- **Reach for fine-tuning** when you're shaping style, tone, or a stable skill, not fetching facts.
- **Reach for function calling** when the task is a deterministic lookup or action against structured data - inventory counts, order status - not fuzzy semantic search.

Whatever you pick, evaluate it on the same axes: retrieval recall, ranking quality, answer faithfulness, citation correctness, latency, security boundaries, and cost per query.

The 2020 name stuck because it was useful, not because it was the whole story. Modern RAG is a family of evidence-grounded designs, and the label just happens to be the one that survived.

## FAQ

### What is retrieval-augmented generation?

Retrieval-augmented generation is an architecture that fetches relevant external documents at inference time and feeds them to a generative model alongside the user's query. Instead of relying solely on what the model memorized during training, it grounds answers in retrieved evidence - fresher, more specific, and traceable back to a source.

### Is ChatGPT a RAG model?

Not by default. The base model behind ChatGPT is a plain LLM, and it only performs retrieval when browsing, file upload, or a connected tool pulls in external content. Ask it a question with none of those enabled and you're getting parametric memory alone, not a RAG pipeline.

### What is RAG with example?

A support bot answering "what's our current parental leave policy" retrieves the latest HR document, generates a response grounded in that text, and cites the source page. An unaided LLM trained months earlier might confidently answer from a policy that's since changed, with no way to flag that it's stale.

### What is RAG vs LLM?

An LLM is the generative engine that predicts text; RAG is the surrounding system that decides what evidence the model sees before it writes anything. You can run an LLM with zero retrieval, or wrap the same LLM in a RAG pipeline - they're different layers, not competing technologies.

### What are the benefits of RAG?

RAG lets you update a knowledge index instead of retraining a model, which is cheaper and faster for fast-changing or private data. It also supports source attribution for verification, access controls over what gets indexed, and generally reduces - though never eliminates - unsupported or hallucinated claims.


## References

1. [Privacy-Preserving Important Passage Retrieval](https://arxiv.org/abs/1407.5416v1) - Luis Marujo, José Portêlo, David Martins de Matos et al. (2014)
2. [Investigating Retrieval Method Selection with Axiomatic Features](https://arxiv.org/abs/1904.05737v1) - Siddhant Arora, Andrew Yates (2019)