RAG (Retrieval-Augmented Generation)

What is RAG?

A two-stage AI architecture introduced in 2020 by Lewis et al. (Facebook AI Research)¹. Stage 1: a retriever fetches relevant external content (passages, chunks, or other units) from a corpus given the user query, using methods that can include dense vector search², BM25 lexical scoring, hybrid retrieval, or other approaches. Stage 2: a generator (the LLM) produces an answer conditioned on the retrieved content, and may optionally cite the retrieved sources inline. Major consumer AI search products (Perplexity, Microsoft Copilot, Google AI Overview, Claude search, ChatGPT search) have observable behavior consistent with RAG architectures; the specific architecture details (retrieval method choice, ranking weights, citation alignment) are generally not vendor-documented, and the inference from observable behavior to "this engine uses RAG" is industry consensus rather than vendor-confirmed fact.

Status in 2026

Foundational. RAG is the dominant production pattern reported in the IR and commercial vendor literature (Pinecone, Weaviate, Elasticsearch, Azure AI Search all publish detailed RAG architecture documentation). Observable behavior of major commercial AI search engines is consistent with some form of RAG, but specific architectural variants (naive RAG, hybrid retrieval, agentic RAG, hierarchical RAG, self-RAG) are not vendor-documented at the engine level. The variations matter; the two-stage retrieve-then-generate core is universally documented in the industry literature. Understanding RAG clarifies why well-structured content tends to surface more readily in AI-search citations than unstructured content: retrieval scores passages, and structured passages (clear topic, single claim, discoverable boundaries) tend to score higher in passage-level retrieval than unstructured prose. Whether structure itself drives citation, or whether structured content correlates with other signals (clear claim phrasing, source attribution, freshness metadata), has not been isolated by public study.

Note on this entry's territory (paired with the hybrid retrieval, sub-document retrieval, sub-passage extraction, and passage-level optimization entries' mirror observations): RAG sits at the boundary between vendor-canonical and non-vendor-canonical territories. The general RAG framework is vendor-canonical (Lewis et al. 2020 paper plus Pinecone / Weaviate / Elasticsearch / Azure AI Search publish detailed RAG architecture documentation). The application to specific commercial AI search engines (Perplexity, Microsoft Copilot, Claude search, Google AI Mode and AI Overview, ChatGPT search) is non-vendor-canonical because those vendors do not publish their full retrieval pipelines. Observable behavior is consistent with RAG; the leap from "industry-standard pattern" to "this specific engine uses naive RAG vs hybrid vs agentic" is practitioner inference, not vendor-confirmed fact.

How to apply

You are not building a RAG system, you are being retrieved by one. The practical implications for content production:

• Make every paragraph chunk-survivable: single-claim paragraphs, no nested-clause sentences that split mid-claim, clear H2 boundaries aligned with natural section breaks. If a 300-word chunk lands in an engine's retrieval window, it should contain one cohesive thought, not three half-thoughts.
• Front-load attribution metadata: every page should expose datePublished, dateModified, and author in both visible HTML and JSON-LD. On recency-weighted queries, RAG retrieval may discount or ignore content with ambiguous or stale freshness signals. Legitimate updates should bump dateModified, but do not spoof it on unchanged content; practitioners report that excessive date-bumping correlates with reduced citation over time, even though no engine has explicitly published a date-spoofing penalty policy.
• Test against the engines that matter to your audience: major AI search engines (Perplexity, ChatGPT search, AI Overview, Microsoft Copilot, Claude search) have observable behavior consistent with RAG variants with different ranking behavior; the actual ranking weights and retrieval architecture vary per engine and are generally not vendor-documented. Your weekly probe should cover the engines relevant to your audience at minimum, because observable citation behavior on one rarely predicts the others.

What to skip: trying to reverse-engineer specific engines' chunking strategies. They change without notice; structural clarity is robust across the variation.

How it relates to other concepts

• Underlies sub-document retrieval. Many RAG systems operate over passages or chunks, but retrieval granularity varies by implementation (some retrieve whole documents, URLs, search results, tables, API records, or graph nodes).
• Companion to agentic retrieval. RAG is the substrate; agentic retrieval is the orchestration that decides when and how to invoke RAG.
• Often uses vector embeddings for the semantic-match component, but can also use BM25 lexical scoring, hybrid retrieval combining both, reranking layers, knowledge-graph traversal, or keyword and structured-data retrieval, depending on the system.
• One important technical context for GEO: content that is retrievable, understandable, and attributable has a better chance of being used in AI-generated answers. Retrieval does not guarantee citation, and citation behavior varies per engine.