RAG Glossary: Every Term, Defined Once

The RAG glossary defines every term once in one or two sentences and links each entry to the page that explains it in full. If a term is missing, no live page yet owns the mechanism, because this glossary never defines a term it cannot route. One-fact-one-value is the rule: the definition lives here, and the math, code, and trade-offs live on the linked mechanism page.

Core concepts are the irreducible RAG vocabulary

Core concepts are the irreducible vocabulary of retrieval-augmented generation. Each term below is defined once in one or two sentences and links to the page that explains the mechanism in full. The glossary never defines a term it cannot route to a live explainer, because an orphan definition would break the site-wide rule that one fact has one canonical home.

These nine terms are the words a reader needs before the retrieval, indexing, evaluation, failure, and architecture groups make sense. Broad AI glossaries from Vectara, Domo, Pryon, and Google Cloud mix LLM product language with RAG terms; this group stays inside RAG so each link has somewhere useful to go.

RAG (retrieval-augmented generation). RAG answers a question by fetching relevant passages from your own documents at query time and giving them to a language model, so the answer is grounded in your data rather than only the model’s training weights. The site overview walks each stage of that pipeline.

Retrieval. Retrieval is the stage that finds and ranks the passages most relevant to a query. In RAG, retrieval quality sets the ceiling on answer quality because the model can only use what retrieval returns.

Chunking. Chunking splits source documents into passages small enough to embed and retrieve. How you split by length, structure, or meaning decides whether an answer lands inside one chunk or gets cut across a boundary.

Embeddings. Embeddings are dense numeric vectors that place text in a space where nearby vectors mean similar things, so a query can be matched to passages by meaning rather than exact words.

Vector search. Vector search finds the passages whose embeddings are nearest to the query embedding, typically by cosine similarity. It is the dense half of retrieval, in contrast with lexical BM25.

Generation. Generation is the final stage, where a language model writes the answer from the query and the retrieved context. Good generation stays faithful to that context and does not invent beyond it.

Grounding. Grounding ties every claim in the answer to the retrieved context, so the model quotes evidence rather than its own priors. It is the mechanism that turns retrieval into a trustworthy answer.

Context window. The context window is the maximum amount of text a model can read at once. It bounds how many retrieved chunks fit in the prompt, which is why retrieval must rank rather than only fetch.

Fine-tuning. Fine-tuning continues training a model on your data to change its behaviour. As a contrast to RAG, fine-tuning changes how the model acts while RAG changes what it knows at answer time.

Once those core words are fixed, the next question is how retrieval actually finds and ranks passages, which is the mechanics group.

Retrieval mechanics name how passages are found and ranked

Retrieval mechanics name how passages are found, ranked, and refined before generation. Lexical scorers, dense similarity, hybrid fusion, rerankers, and query transforms each answer a different failure of naive embedding search. Definitions here stay short; the mechanism pages carry formulas, failure cases, and worked examples.

Teams that only learn “vector search” miss why BM25 still wins on identifiers, why hybrid search exists, and why a cross-encoder is too slow for the full index. The eleven terms below are the vocabulary of that second layer of retrieval design.

BM25. BM25 is a lexical ranking function that scores a document by term frequency, inverse document frequency, and length. It matches exact strings rather than meaning, and it still beats embeddings on identifiers, codes, and rare tokens.

Hybrid search. Hybrid search runs dense embedding retrieval and sparse BM25 retrieval together and fuses the results, so a query is matched on both meaning and exact terms.

Reranking. Reranking is a second pass that re-orders the top retrieved candidates with a more accurate but slower model, promoting the truly relevant chunk above merely similar ones.

Cross-encoder. A cross-encoder is a reranking model that reads the query and a candidate passage together and scores their relevance directly. It is more accurate than embedding similarity and too slow to run over the whole index, so it reranks a shortlist.

Top-k. Top-k is the number of highest-ranked chunks retrieval returns to the model. Too small and the answer may be cut off; too large and the prompt gains noise and cost.

Semantic search. Semantic search is retrieval by meaning rather than keyword overlap, powered by embeddings. It is another name for the dense side of vector search.

Cosine similarity. Cosine similarity measures how close two embeddings point in the same direction while ignoring their length. It is the usual score for ranking passages against a query in vector search.

Sparse embeddings. Sparse embeddings are vectors with mostly zero entries that encode which terms matter, bridging keyword and dense retrieval. They are the learned middle ground between BM25 and dense embeddings.

Query rewriting. Query rewriting reformulates the user’s question before retrieval by expanding, clarifying, or splitting it so the question better matches how the answer is phrased in the documents.

HyDE. HyDE (Hypothetical Document Embeddings) generates a fake answer to the query, embeds that answer, and retrieves against it, because a hypothetical answer often sits closer to real passages than the raw question does.

ColBERT. ColBERT is a late-interaction retriever that scores each query token by its best-matching document token (MaxSim), catching term-level matches a single pooled embedding blurs. It is more precise than dense similarity and heavier on storage.

Mechanics assume a store that can hold embeddings and return neighbours quickly, which is why indexing and infrastructure terms come next.

Indexing and infrastructure terms name the store side of RAG

Indexing and infrastructure terms name the store side of RAG: where embeddings live, how approximate nearest neighbour search runs, how vectors are compressed, and when a knowledge graph sits beside a passage index. Without these terms, retrieval mechanics have nowhere to run.

Vector databases such as Weaviate, Pinecone, Qdrant, and Milvus productise that store. The glossary defines the category and the index techniques once, then routes product depth to infrastructure and indexing pages rather than duplicating profile matrices here.

Vector database. A vector database is a store built to index embeddings and return the nearest ones to a query quickly. It is the component that makes retrieval by meaning practical at scale.

HNSW. HNSW (Hierarchical Navigable Small World) is the graph-based index most vector databases use for approximate nearest-neighbour search. It is fast and accurate, and the graph must be held in memory.

Quantization. Quantization compresses vectors to fewer bits so more fit in memory, trading a little retrieval accuracy for a large cut in RAM. It is how large vector indexes stay affordable.

Knowledge graph. A knowledge graph stores entities and the explicit relationships between them. It is retrieved over instead of, or alongside, a flat passage index, and it is the substrate of Graph RAG.

A store and a retriever still need meters, so evaluation vocabulary is the next group a practitioner reaches for.

Evaluation terms name how RAG quality is measured

Evaluation terms name how RAG quality is measured when retrieval and generation are scored as separate problems. Faithfulness, context precision, context recall, and answer relevance are the names most libraries still publish; Ragas, nDCG, Recall@k, and LLM-as-a-judge are how teams operationalise those names.

Full formulas, tool comparisons, and judge bias live under evaluation. The glossary only locks the vocabulary so a metric name means the same thing on every page of the site.

Faithfulness. Faithfulness asks whether the generated answer is actually supported by the retrieved context rather than invented. It is the metric that catches hallucination when the evidence window is intact.

Context precision. Context precision asks, of the chunks retrieved, how many were actually relevant. Low precision means retrieval is returning noise alongside the answer.

Context recall. Context recall asks, of the chunks needed to answer, how many retrieval actually found. Low recall means the answer’s evidence never reached the model.

Answer relevance. Answer relevance asks whether the generated answer actually addresses the question asked, independent of whether it is faithful to the context.

Ragas. Ragas is an open-source framework that scores RAG systems on faithfulness, context precision and recall, and answer relevance, largely using an LLM as the judge.

nDCG. nDCG (normalised discounted cumulative gain) is a ranking metric that rewards putting the most relevant chunks highest while discounting relevance found further down the list.

Recall@k. Recall@k is the fraction of relevant chunks that appear in the top-k retrieved results. It is the workhorse metric for measuring whether retrieval found the answer at all.

LLM-as-a-judge. LLM-as-a-judge uses a language model to score another model’s answers for qualities like faithfulness or relevance. It scales, but it inherits the judge’s biases and varies run to run, so teams average rather than trust a single pass.

Meters without failure names leave teams arguing about averages, so the failure terms group names the symptoms those meters should catch.

Failure terms name the symptoms that break RAG answers

Failure terms name the symptoms that break RAG answers even when a demo looked green. Hallucination, lost-in-the-middle, chunk boundaries, drift, leakage, and multi-hop each point at a different stage fault. The failure hub sorts those symptoms by the stage that caused them.

Definitions here state the symptom, not the full fix. Fix depth, detection scripts, and differentials live on each failure leaf so the glossary does not become a second failure taxonomy.

Hallucination. Hallucination is when the model generates a confident answer not supported by the retrieved context. In RAG it usually signals a generation failure, or context that never contained the answer.

Lost in the middle. Lost in the middle is the tendency of a language model to under-use information placed in the middle of a long context, even when the right chunk was retrieved.

Chunk boundary. A chunk boundary is the split point between two chunks. When an answer straddles a boundary, no single chunk contains it whole and retrieval returns half the answer.

Drift. Drift is gradual degradation of retrieval quality as the corpus or the query distribution shifts away from what the system was built and tuned for.

Leakage. Leakage is returning documents a user should not see, such as another tenant’s or another permission scope’s documents, usually because a metadata filter is missing at query time.

Multi-hop. A multi-hop question can only be answered by chaining two or more facts, often across separate documents. It is a known weakness of single-shot retrieval.

Named failures are also why architectures diverge from naive RAG, which is the last group in the index.

Architecture terms name the shapes a RAG pipeline takes

Architecture terms name the shapes a RAG pipeline takes once the baseline retrieve-then-generate loop is no longer enough. Naive, advanced, agentic, graph, modular, RAPTOR, Self-RAG, Corrective RAG, and cache-augmented generation each add a control loop or a different index shape for a named failure.

The architectures hub carries the history and the failure that motivated each pattern. The glossary only fixes the names so “agentic RAG” and “Graph RAG” mean the same thing on every page that mentions them.

Naive RAG. Naive RAG is the baseline shape: retrieve top-k by embedding similarity, stuff the chunks into the prompt, and generate. It is simple, and it is the starting point every failure mode is measured against.

Advanced RAG. Advanced RAG is naive RAG plus retrieval improvements such as hybrid search, reranking, and query rewriting that raise precision and recall before generation.

Agentic RAG. Agentic RAG is an architecture where the model plans and issues multiple retrieval steps, deciding what to fetch next based on what it has found so far.

Graph RAG. Graph RAG retrieves over a knowledge graph rather than only a flat passage index, so answers can traverse explicit relationships between entities.

Modular RAG. Modular RAG treats the pipeline as swappable modules (rewriter, retriever, reranker, generator) reconfigured per use case rather than one fixed chain. Many advanced variants are instances of that framing.

RAPTOR. RAPTOR clusters and summarises chunks into a tree so retrieval can pull a high-level summary or a leaf detail depending on how broad the question is.

Self-RAG. Self-RAG is a model trained to decide when to retrieve and to critique its own retrieved context and output, retrieving only when it helps rather than on every query.

Corrective RAG. Corrective RAG grades retrieved documents for relevance and, when they fall short, triggers a corrective step such as a web search before generating. It is retrieval with a quality gate.

CAG (cache-augmented generation). CAG (cache-augmented generation) preloads the whole corpus into a long context window and caches it, skipping retrieval entirely. It is viable only when the corpus fits the window, and that limit is what shows what retrieval is for.

Depth past a one-sentence definition lives on the cluster hubs: the documents fetched at query time overview, chunking decides what retrieval can find, getting the right context to the model, RAG evaluation, and the RAG failure taxonomy. Those hubs are the course chapters; the glossary is the index.

The RAG glossary is the site-wide dictionary for retrieval-augmented generation: one short definition per term, every term routed to a live explainer, and no orphan definitions. Core concepts, retrieval mechanics, indexing, evaluation, failure symptoms, and architecture shapes stay consistent everywhere else on the site because they are locked here first.

More in this section Toggle section list