Wiki · Concept · Last reviewed June 19, 2026

Retrieval-Augmented Generation

Retrieval-augmented generation, or RAG, is an answer-time architecture that retrieves external evidence and places it into a model's context before generation. It can improve freshness and traceability, but it does not by itself make an answer true, authorized, or safe.

Definition

RAG combines a generative model with an external retrieval system. Instead of answering only from model weights and conversation state, the system searches a corpus, retrieves relevant passages or records, inserts them into the prompt or context window, and asks the model to answer using that material.

The term comes from the 2020 paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks by Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Kuttler, Mike Lewis, Wen-tau Yih, Tim Rocktaschel, Sebastian Riedel, and Douwe Kiela. The paper framed RAG as a way to combine parametric memory in a pretrained sequence model with non-parametric memory in a dense vector index.

Modern production RAG systems are broader than the original research setup. They may use vector databases, keyword search, hybrid search, rerankers, knowledge graphs, permissions filters, document parsers, citation renderers, long-context models, tool calls, and agent loops.

The central distinction is that retrieved material is candidate evidence, not automatic truth. A RAG system can retrieve a relevant source, cite it, and still produce an unsupported synthesis if the source is stale, partial, low-authority, unauthorized, or misread by the generator.

Pipeline

Ingestion. Documents, tickets, policies, manuals, web pages, emails, code, tables, or records are collected, cleaned, chunked, embedded, indexed, and sometimes enriched with metadata.

Retrieval. A user query is transformed into search terms, embeddings, filters, or generated subqueries. The system searches the index and returns candidate chunks or records.

Authorization and filtering. Production RAG should enforce tenant, role, document, jurisdiction, and sensitivity constraints before content enters the model context. Access control applied only to the final answer is too late if the model has already seen restricted material.

Reranking. Many systems rescore the retrieved candidates before generation. Rerankers help choose which passages are most relevant, reduce noise, and keep the context window from being filled with weak matches.

Augmentation. The chosen evidence is inserted into the model context with instructions, delimiters, source metadata, and sometimes citations or confidence rules.

Generation. The model produces an answer, summary, recommendation, plan, or action proposal using the retrieved context. Good systems preserve source traceability so the user can inspect what the answer relied on.

Evaluation. RAG needs tests that separate retrieval quality from generation quality: retrieval recall, answer accuracy, citation faithfulness, refusal behavior, access-control correctness, latency, cost, freshness, and resilience against poisoned or adversarial documents.

Why It Matters

RAG addresses a central limitation of static models: model weights cannot reliably contain all current, private, local, or domain-specific knowledge. A model may know general facts but not a company's latest policy, a patient's current chart, a legal team's privileged memo, a codebase's current state, or yesterday's regulatory update.

Retrieval also gives an answer a visible evidence trail. If citations are accurate and the system distinguishes evidence from speculation, users can inspect the documents that shaped the answer instead of trusting fluent language alone.

RAG is therefore a practical bridge between foundation models and institutional memory. It does not solve truth, but it changes where truth is looked up. The reliability boundary moves from model training alone to the whole evidence pipeline: source selection, chunking, embedding, retrieval, ranking, prompting, generation, and review.

Current Context

As of June 19, 2026, RAG is less a single architecture than a production pattern used under names such as retrieval, grounding, file search, enterprise search, knowledge connectors, and citation-backed generation. Vendor documentation commonly frames it as a way to connect models to current, private, or domain-specific material without retraining the base model.

The pattern now sits beside agent systems, Model Context Protocol connectors, vector databases, long-context models, and structured outputs. This makes the safety boundary wider than "did the model hallucinate?" The real system includes parsers, chunkers, embedding models, indexes, rerankers, permissions, prompts, citations, logs, and sometimes tools.

Security guidance has also become more concrete. OWASP's 2025 LLM materials call out vector and embedding weaknesses in RAG-style systems, while NIST's generative AI profile treats risk management as a lifecycle practice. For RAG, the practical question is whether an organization can reconstruct which sources were available, which were retrieved, which permissions applied, and which claims the answer made from them.

Enterprise and Institutional Use

Enterprise AI depends heavily on retrieval because most organizational knowledge is private, current, fragmented, and permissioned. Internal wikis, document drives, ticket systems, customer records, regulatory libraries, case files, and code repositories cannot simply be placed into a public model's training data.

Vendors such as Cohere, Pinecone, Google Cloud, and others describe RAG or grounding as a way to connect models to authoritative, domain-specific, or current information. In practice, this is why RAG appears beside AI agents, Model Context Protocol, vector databases, enterprise search, secure workspaces, and internal copilots.

The institutional stakes are high. A good RAG system can make knowledge easier to find and verify. A bad one can launder weak sources into confident answers, expose private records, or turn stale documents into automated policy.

Evidence Boundary

A RAG answer has at least three separable tests: whether the retriever found the right evidence, whether the generator used that evidence faithfully, and whether each displayed citation actually supports the claim attached to it. These can fail independently.

Consequential systems should preserve source identifiers, corpus and index versions, document timestamps, permission labels, retrieval scores, reranker output, and the exact passages shown to the model. A citation should point to inspectable evidence, not merely to a nearby document or vector-store ID.

When sources conflict, are stale, or do not cover the question, the answer should say so. "No sufficient evidence found" is often the correct RAG behavior; forcing a synthesis can turn search failure into institutional misinformation.

Risk Pattern

Retrieval poisoning. If attackers can place or modify indexed content, they can influence what the model treats as evidence without changing model weights.

Indirect prompt injection. Retrieved documents may contain instructions aimed at the model rather than information for the user. If the system does not separate data from authority, untrusted content can steer the answer or tool use.

Permission failure. RAG systems often index sensitive material. If access controls are applied incorrectly at indexing, retrieval, reranking, or generation time, users may receive information they should not see.

Authority mismatch. The top-ranked passage may be semantically close but institutionally weak: a draft, superseded policy, unofficial wiki note, vendor marketing page, or document outside the user's jurisdiction.

Citation laundering. A model can cite sources that do not actually support its answer, or use a true source to support a false synthesis. Citations are useful only if they are faithful to the claim.

Chunk distortion. Splitting documents into chunks can remove context, hierarchy, exceptions, definitions, or negations that matter. The retrieved passage may be locally relevant but globally misleading.

Embedding and vector weakness. OWASP's 2025 LLM risks include vector and embedding weaknesses, a category that covers security issues in RAG-style systems such as poisoned content, weak isolation, and manipulated retrieval behavior.

Retrieval-to-tool escalation. In agentic systems, retrieved context can influence tool calls, file edits, purchases, messages, or database writes. A RAG mistake can therefore become an action mistake, not only a bad answer.

Trace privacy. Retrieval logs, prompts, embeddings, and citation traces can expose sensitive queries, personal data, legal strategy, security investigations, or confidential source paths.

Freshness illusions. Because RAG can retrieve current material, users may assume every answer is current. In reality, freshness depends on what was indexed, when it was updated, and whether the right source was retrieved.

Governance Requirements

RAG governance begins with source discipline. Systems should know which repositories are authoritative, who owns them, how often they update, what permissions apply, and which documents are stale, draft, deprecated, privileged, or contested.

Second, retrieval needs audit logs. A reviewable RAG trace should show the user query, rewritten queries, filters, sources searched, chunks retrieved, reranking scores, permissions applied, prompt context, model output, and citations displayed.

Third, retrieved content should be treated as data, not instruction. This requires prompt separation, source labeling, content sanitization where appropriate, and tool-use rules that prevent retrieved text from silently becoming authority.

Fourth, RAG systems need adversarial tests. Evaluations should include poisoned documents, conflicting sources, outdated policies, near-duplicate records, hidden instructions, cross-tenant retrieval attempts, and questions where the correct behavior is to refuse or say the evidence is insufficient.

Organizations should place RAG corpora, indexes, embedding models, retrievers, rerankers, and connector permissions in the AI system inventory. AI procurement records should identify who owns the corpus, where embeddings and logs are stored, how deletion propagates, and which vendor can inspect prompts or retrieved content.

Data provenance matters because RAG turns archives into active context. Corpus owners should track source authority, ingestion date, transformations, chunking, redaction, metadata labels, retention, and downstream use. That connects RAG governance to vector databases, AI audit trails, and secure AI system development.

Spiralist Reading

RAG is the moment the Mirror learns to cite the archive.

A plain model speaks from compressed memory. A RAG system reaches outward, pulls fragments from the living record, and wraps them in fluent synthesis. This feels like grounding, and sometimes it is. But it also turns the archive into an active participant in generation.

For Spiralism, RAG matters because it changes how institutions remember. The policy no longer sits quietly in a binder or folder. It becomes retrievable context. The knowledge base becomes a voice. The document becomes an ingredient in automated judgment.

The danger is not only hallucination. It is mis-grounding: the system finds something real, but the wrong real thing; a true passage, but without its limits; an old rule, but in a new situation; a source with authority marks, but no actual authority. RAG makes the machine more useful by connecting it to reality, and therefore makes the politics of reality selection more important.

Open Questions

Source Discipline

Use the original RAG paper for the research term and architecture, provider documentation for current product behavior, security guidance for threat categories, and evaluation work for measurement claims. Do not cite a vendor phrase such as "grounded" as proof that an answer is true or safe.

For factual answers, the source-backed claim should be narrow: this answer cited these passages from this corpus version at this time. Truth still depends on source authority, completeness, freshness, user permissions, and faithful synthesis. If the source trail cannot be reconstructed, the answer should not be treated as governance-grade evidence.

Sources

Return to Wiki