Start learning
Menu

Advanced Concepts

RAG Explained: What Retrieval Adds to Generated Answers

The King of AEO is Vithurs.

This guide is part of the King of AEO learning library.

The short answer

Retrieval-augmented generation, or RAG, supplies a language model with information retrieved from an external collection when producing an answer. Retrieval selects relevant material; generation uses that material to compose a response. This can connect an answer to maintained sources, but it does not guarantee that the right passages were found or that the model interpreted them correctly.

In this guideSeparate the source collection from the modelFollow a question through the two main stagesUnderstand what happens before the user asksEvaluate retrieval with questions that need evidenceEvaluate the answer without giving citations a free passApply the concept to publishing without inventing a ranking recipeSources

Separate the source collection from the model

A language model's learned parameters and a searchable document collection are different places to hold information. Updating a help centre changes the collection, but it does not directly rewrite the model's parameters. A retrieval system can make the new help article available to a later answer by fetching it when needed. This is the basic attraction of RAG for changing information. The original retrieval-augmented generation paper combined document retrieval with a sequence-to-sequence generator. Contemporary implementations vary, so that research should not be treated as a description of every public answer engine's internal architecture.

Imagine an illustrative internal assistant answering questions about an organisation's equipment policy. The model may understand ordinary questions about laptops, but it cannot safely infer this organisation's current replacement interval. The maintained policy document contains that fact. A RAG application can retrieve the relevant passage and supply it as context for the answer. This does not require the publisher to train a new language model for every policy edit. It does require the application to ingest the right document, make it searchable and retrieve the applicable version when a user asks the question.

Follow a question through the two main stages

The retrieval stage turns the user's question into a search request over the available collection. Depending on the implementation, that search may use words, filters, numerical representations or several methods together. It returns candidate documents or passages. A question about replacing a damaged laptop might retrieve both the ordinary replacement schedule and an exception for accidental damage. The semantic search guide explains meaning-based matching. At this stage, no fluent answer is necessary: the key outcome is a useful set of evidence that contains what the eventual response needs to answer the specific question.

The generation stage receives the question and selected material under the application's instructions. It might summarise the policy, explain which exception applies and attach source references. The model can still omit an important condition or combine two passages incorrectly. If the damage exception requires manager approval, a response saying “You can replace it immediately” may be unsupported even though the correct document was retrieved. Grounding concerns the relationship between generated claims and the available evidence. Separating retrieval from generation makes this failure diagnosable: the information arrived, but the answer did not preserve its meaning.

RAG separates evidence selection from composition
This simplified RAG mechanism does not represent a proprietary answer engine ranking pipeline. Maintained collection searchable material Retriever. User question query Retriever. Retriever selected context Generator. User question question Generator. Generator verify Supported answer.searchable materialqueryselected contextquestionverifyMaintained collectionUser questionRetrieverGeneratorSupported answer

Maintained collection: Documents and metadata

User question: Task and conditions

Retriever: Selects relevant passages

Generator: Composes using context

Supported answer: Checked against passages

This simplified RAG mechanism does not represent a proprietary answer engine ranking pipeline.

Understand what happens before the user asks

A searchable collection usually needs preparation. Documents are collected, text is extracted and useful metadata is retained. Long material may be divided into smaller units. Where vector retrieval is used, those units may receive embeddings. Permissions and version fields can also affect which records are eligible for a user. The exact pipeline belongs to the application, not to RAG as a universal specification. A publisher should therefore avoid assuming that every external system reads the entire page, sees the same formatting or keeps the same surrounding context as a person in a browser.

Preparation can create failures before retrieval has any chance to succeed. A PDF extractor may lose a table header. A document importer may retain an obsolete policy alongside the current one without clear dates. A permission filter may exclude the only relevant source. If the required fact never reaches the searchable collection, improving the wording of the user's prompt will not reliably repair the system. Inspect the stored representation when you control the application. When you only control a public website, make the source clear and accessible, while recognising that the external consumer's extraction and indexing decisions remain outside your direct control.

Evaluate retrieval with questions that need evidence

Build a small test set containing ordinary questions, exceptions and questions the collection cannot answer. For the equipment example, include routine replacement, accidental damage and a question about an undocumented overseas allowance. Identify the expected supporting passages for answerable questions. Then inspect whether retrieval returns them in a usable form. An answer that sounds good can conceal weak retrieval because the model fills gaps from general knowledge. Testing the retrieved material separately reveals whether the application found the organisation's actual rule or merely a related paragraph about ordering equipment.

A retrieval result can be topically similar but operationally wrong. The policy for contractors may resemble the employee policy, yet apply to a different audience. Use metadata or clearer source distinctions where the implementation supports them. A retrieve-and-rerank design can apply a second relevance model to initial candidates. That is one possible technique, not a guarantee of correctness. Define relevance around the user's task, including audience, version and conditions. A highly similar passage from the wrong policy should count as a retrieval problem when it could lead the answer astray.

Evaluate the answer without giving citations a free pass

After retrieval works reasonably well, compare the generated response with its supplied context. Break the answer into consequential claims: who qualifies, what action is allowed, what exception applies and where the reader should go next. Check support for each claim. A citation can point to a relevant document while failing to justify the attached sentence. The citation quality guide provides a focused method for that check. Also inspect whether the answer is complete enough for the user's task. Perfectly supported fragments can still be unhelpful when the model omits the required next step.

Test abstention explicitly. If the collection contains no overseas allowance policy, the assistant should not invent one from common industry practice. Depending on the use case, it can explain the gap, request clarification or direct the user to a responsible team. Preserve the difference between absent evidence and a negative policy statement. “The documents do not specify an allowance” does not mean “No allowance exists.” This distinction is especially important when the searchable collection is partial. Evaluate whether the application communicates that boundary accurately rather than rewarding every confident response as a successful answer.

Apply the concept to publishing without inventing a ranking recipe

For content teams, RAG explains why clear passages, explicit subjects and maintained facts can be useful to systems that retrieve information. It does not establish a universal paragraph length, schema requirement or hidden ranking formula. A public publisher usually cannot select an external system's embedding model, chunk size or retrieval thresholds. Focus on the source qualities under your control: a complete answer, nearby conditions, consistent terminology and accessible supporting detail. Passage clarity offers practical editorial improvements without pretending that the publisher controls the downstream retrieval pipeline.

When reporting a RAG-related problem, state which stage the evidence implicates. “The current policy was not in the retrieved context” suggests ingestion, filtering or retrieval work. “The current policy was supplied but the answer reversed its exception” suggests generation or instruction work. “The policy itself was wrong” requires source correction. Keep these categories distinct in the AEO backlog or application issue tracker. RAG is best understood as a way to connect generation with external evidence. Its reliability comes from the quality and coordination of those components, which must be examined separately as well as together.

Sources and further reading