RAG Basics

By the Syncfusion DevTutorials team · Last updated October 20, 2026

What Retrieval-Augmented Generation is and why it matters: retrieve, augment, generate; RAG vs fine-tuning vs long context; the end-to-end architecture; grounding, fewer hallucinations, fresh data, citations and real use cases.

Think about two students taking the same test. The first student must answer from memory. The second is allowed to bring the textbook, look up each answer, and write down the page number. The second student is not smarter, but their answers are more likely to be right, they stay right when the textbook gets a new edition, and the teacher can check every answer.

A language model on its own is the first student. Retrieval-Augmented Generation (RAG) turns it into the second one.

The main idea: RAG means the app looks up relevant text from your own documents first, adds that text to the prompt, and only then asks the model to write the answer. The model answers from the text it was given, not from memory, and it can say which document each fact came from.

A Real-World Example

Brightgrid sells smart lamps through an online store. Its website has an AI assistant that answers customer questions.

One customer asks:

How many days do I have to return a lamp?

The assistant answers using an old return policy:

You have 14 days, and there is a 10% restocking fee.

However, Brightgrid’s current policy allows customers to return a lamp within 30 days with no fee. The assistant gives the wrong answer because the language model does not have the updated policy.

Brightgrid uses RAG to improve the assistant:

The company stores its help-centre articles in a searchable knowledge base. A knowledge base is a collection of information that an application can search. When a customer asks a question, the application searches the knowledge base for the most relevant article. The application adds the relevant information to the instructions given to the language model. The language model uses that information to prepare an answer.

The assistant can now answer:

You can return a lamp within 30 days of delivery. [S1]

The label [S1] points to the source article, allowing the customer to check the information.

When the return policy changes, the team updates the article and makes the new version available to the search system. The language model does not need to be retrained.

In simple words: RAG finds relevant information and gives it to the model before the model prepares an answer.

What You Will Learn

In this lesson, you will learn:

1. What RAG is, and the three words in its name.
2. Why RAG matters, and how it compares with fine-tuning and long context windows.
3. The end-to-end architecture: what happens before and during a question.
4. What RAG gives you: grounding, fewer made-up answers, fresh data and citations.
5. Where RAG is used: policy search, support knowledge bases and code assistants.

RAG Fundamentals

What RAG Means

The name has three parts. Each one is a step:

A few words you will see throughout the course:

• Knowledge base (or corpus): the collection of documents the app can search. For Brightgrid, the help-center articles.
• Chunk: a small piece of a document, such as one section. Apps search chunks, not whole documents, because a short piece fits the question better and costs fewer tokens.
• Retriever: the part that finds chunks. It returns the top-k best matches, where k is a number you choose, like 3.
• Context: everything the model reads for this question: instructions, retrieved chunks and the question itself.
• Grounded answer: an answer that only uses facts found in the retrieved chunks.

Here is the difference between answering from memory and answering from a source, in code:

Closed book vs open book

// A model's "memory" is frozen at training time. Here it learned the 2023 policy.
const modelMemory = {
  "return window": "14 days, with a 10% restocking fee",
};

// The help center today (2026). The policy changed, but the model never saw it.
const helpCenter = [
  {
    id: "returns-policy",
    updated: "2026-03-01",
    text: "You can return any product within 30 days of delivery.",
  },
  {
    id: "shipping-times",
    updated: "2026-01-15",
    text: "Standard shipping takes 3 to 5 business days.",
  },
];

// Closed book: answer from memory only.
console.log("Closed book:", modelMemory["return window"]);

// Open book (RAG): look the answer up first, then answer from what was found.
const found = helpCenter.find((doc) => doc.text.includes("return"));
console.log("Open book:  ", found.text, `[source: ${found.id}, ${found.updated}]`);

Expected output:

Closed book: 14 days, with a 10% restocking fee
Open book:   You can return any product within 30 days of delivery. [source: returns-policy, 2026-03-01]

The "memory" answer is not a lie. It was true once. The problem is that a model's knowledge is frozen at the moment its training data was collected. Your documents keep changing.

Why RAG Matters

Language models are good at language: understanding a question, combining facts, and writing a clear reply. They are not reliable databases. Three gaps show up in every real project:

1. They don't know your private data. No public model has read your company's internal policies, contracts, tickets or code.
2. Their knowledge gets old. Prices, policies and products change after training.
3. They fill gaps by guessing. When a model doesn't know, it often writes something that sounds right. This is called a hallucination.

RAG fixes all three with one move: give the model the right facts at the moment it answers. That is why most AI assistants that answer questions about a company's own information use some form of RAG.

RAG vs Fine-Tuning vs Long Context

RAG, fine-tuning, and long context are three ways to provide a language model with the information or behaviour needed for an application. Each approach serves a different purpose.

Fine-Tuning

Fine-tuning gives a model additional training using selected examples.

It is useful when you want the model to follow a particular style, format, or way of responding. For example, fine-tuning can help a model produce answers in a consistent support format.

Fine-tuning is usually not the simplest choice for information that changes often. When the facts change, the model may need additional training.

Long Context

A context window is the amount of information a model can read in one request.

Long-context prompting gives the model a large amount of text along with the question. This can work well when the application uses one large document or a small collection of documents.

However, sending a large amount of text for every question may increase processing time and cost. Relevant details may also be harder to find when they are surrounded by unrelated information.

RAG

RAG searches the knowledge base first and sends only the most relevant chunks to the model.

It is useful when the information is private, regularly updated, spread across many documents, or needs to be connected to sources.

When a document changes, the searchable index can be updated without retraining the language model.

These approaches do not always need to be used separately. An application can combine them based on its needs.

For example:

Fine-tuning can help the model follow a particular style or response format. RAG can provide relevant and updated information. A long context window can allow the model to read more retrieved content in one request.

End-to-End RAG Architecture

A RAG system usually has two main stages. The first stage prepares the documents for searching. The second stage uses those documents to answer a question.

1. Preparing the Documents

This stage happens before users begin asking questions.

Load the documents: Collect the information the application needs, such as web pages, PDF files, product guides, or support articles. Create chunks: Divide long documents into smaller sections called chunks. Smaller sections make it easier to find the part related to a question. Create embeddings: Convert each chunk into a list of numbers called an embedding. These numbers represent the meaning of the text and help the application find content with a similar meaning. Store the information: Save the chunks and their embeddings in an index. An index organises the information so the application can search it quickly.

This preparation stage is commonly called indexing.

1. Answering a Question

This stage happens whenever a user asks a question.

Retrieve: Search the index and select the chunks most closely related to the question. Augment: Add the selected chunks, the question, and the instructions to the model’s input. Generate: Ask the language model to prepare an answer using the retrieved information. Show sources: If the application supports citations, include labels such as S1 and S2 so the user can check the source information.

Here is the whole answering half in a few lines. Real systems use better search, but the shape is the same:

A tiny RAG pipeline

// The smallest useful RAG pipeline: retrieve, augment, generate.
const docs = [
  {
    id: "returns-policy",
    text: "You can return any product within 30 days of delivery.",
  },
  { id: "shipping-times", text: "Standard shipping takes 3 to 5 business days." },
  { id: "warranty", text: "Every lamp has a 2-year warranty against defects." },
  { id: "brightgrid-plus", text: "Brightgrid Plus costs $3.99 a month." },
];

const words = (s) => s.toLowerCase().match(/[a-z0-9]+/g) ?? [];

// 1. Retrieve: score each document by how many question words it shares.
function retrieve(question, k) {
  const q = new Set(words(question));
  return docs
    .map((d) => ({ ...d, score: words(d.text).filter((w) => q.has(w)).length }))
    .filter((d) => d.score > 0)
    .sort((a, b) => b.score - a.score)
    .slice(0, k);
}

// 2. Augment: put the found text into the prompt, each with a source id.
function buildPrompt(question, sources) {
  const block = sources.map((s, i) => `[S${i + 1}] (${s.id}) ${s.text}`).join("\n");
  return `Answer only from these sources and cite them.\n${block}\n\nQuestion: ${question}`;
}

// 3. Generate: in a real app, this prompt now goes to the language model.
const question = "How many days do I have to return a product?";
console.log(buildPrompt(question, retrieve(question, 2)));

Expected output:

Answer only from these sources and cite them.
[S1] (returns-policy) You can return any product within 30 days of delivery.
[S2] (shipping-times) Standard shipping takes 3 to 5 business days.

Question: How many days do I have to return a product?

Look at the output. The returns article is S1, as it should be. The shipping article came second because it also contains the word "days". Search is never perfect. That is why later lessons cover better search, reranking and evaluation.

RAG Capabilities & Benefits

Grounding in External Knowledge

Grounding means tying every answer to real text that the app retrieved. The instructions tell the model: use only these sources. The knowledge comes from outside the model, from documents you control. This is also how RAG works with private data: the model never needs to have seen your documents during training. It reads the right ones at the moment it answers.

How RAG Reduces Hallucinations

RAG lowers made-up answers in three ways:

1. The facts are in front of the model. Copying a fact from the prompt is much easier and more reliable than recalling it.
2. The instructions limit the model to the sources, and say what to do when the sources don't contain the answer: "Say: I don't know based on the help center."
3. The app can check before answering. If the search finds nothing relevant, the app can refuse without calling the model at all.

No evidence, no answer

// Grounding reduces made-up answers: no good evidence means "I don't know".
const docs = [
  { id: "warranty", text: "every lamp has a 2 year warranty against defects" },
  { id: "energy-use", text: "the lumo lamp uses 9 watts at full brightness" },
];
const stop = new Set(["the", "a", "how", "is", "what", "does", "of", "much", "many"]);
const words = (s) =>
  (s.toLowerCase().match(/[a-z0-9]+/g) ?? []).filter((w) => !stop.has(w));

function answer(question, minShared = 2) {
  const q = words(question);
  let best = null;
  for (const d of docs) {
    const docWords = new Set(words(d.text));
    const shared = q.filter((w) => docWords.has(w)).length;
    if (!best || shared > best.shared) {
      best = { ...d, shared };
    }
  }
  if (best.shared < minShared) {
    return `I don't know based on the help center. (best match shared ${best.shared} of ${q.length} words)`;
  }
  return `${best.text} [${best.id}]`;
}

for (const q of [
  "How long is the lamp warranty?",
  "How many watts does the lamp use?",
  "What is Brightgrid's stock price?",
]) {
  console.log(q.padEnd(36), "->", answer(q));
}

Expected output:

How long is the lamp warranty?       -> every lamp has a 2 year warranty against defects [warranty]
How many watts does the lamp use?    -> the lumo lamp uses 9 watts at full brightness [energy-use]
What is Brightgrid's stock price?    -> I don't know based on the help center. (best match shared 0 of 4 words)

Try a question the help center can't answer:

Fresh Data Without Retraining

Retraining a model takes time, money and expertise. With RAG, updating knowledge means updating documents. Add an article, and the next search can find it. Delete an outdated one, and it can no longer be used.

Add knowledge without retraining

// New facts arrive: add a document to the index. No retraining needed.
const index = [
  {
    id: "shipping-times",
    text: "We ship to the United States, Canada, the UK and the EU.",
  },
];

// Find documents that mention a word.
const search = (word) => index.filter((d) => d.text.toLowerCase().includes(word));

console.log("Before:", search("australia").length, "documents mention Australia");

// Monday morning: the shipping team publishes a new article.
index.push({ id: "australia-launch", text: "From June 2026 we also ship to Australia." });

console.log(
  "After: ",
  search("australia").length,
  "document:",
  search("australia")[0].text,
);
console.log(
  "Model retrained? no. Time to update: the time it takes to add one document.",
);

Expected output:

Before: 0 documents mention Australia
After:  1 document: From June 2026 we also ship to Australia.
Model retrained? no. Time to update: the time it takes to add one document.

You can do the same in the lab. Write a new article, save it, and then ask about it:

Auditable Citations

Each retrieved chunk gets a label such as S1, and the model must put that label after each fact. This makes answers auditable: a person, or a program, can check each claim against its source. In regulated work like finance, healthcare and law, an answer without a source often can't be used at all.

Check each claim against its citation

// Citations make answers checkable: every claim points at a source.
const sources = {
  S1: "You can return any product within 30 days of delivery.",
  S2: "Refunds are sent within 5 business days after the parcel arrives.",
};

const answer = [
  { claim: "You have 30 days to return a product.", cite: "S1", key: "30 days" },
  { claim: "Refunds take 5 business days.", cite: "S2", key: "5 business days" },
  { claim: "Return shipping is always free.", cite: "S2", key: "free" },
  { claim: "Gift cards can be refunded.", cite: "S3", key: "gift card" },
];

for (const a of answer) {
  const src = sources[a.cite];
  const verdict = !src
    ? "source does not exist"
    : src.includes(a.key)
      ? "supported"
      : "NOT in the source";
  console.log(`${a.cite}  ${verdict.padEnd(21)} ${a.claim}`);
}

Expected output:

S1  supported             You have 30 days to return a product.
S2  supported             Refunds take 5 business days.
S2  NOT in the source     Return shipping is always free.
S3  source does not exist Gift cards can be refunded.

The last two claims fail in different ways. The third one cites a real source that doesn't say that. The fourth one cites a source that doesn't exist. Both are signs of a hallucination, and both can be caught automatically. You will build stronger checkers in Chapter 6.

The lab's Trace tab shows every step of the last question: what was searched, which chunks were picked, how long each step took, and the exact prompt the model received.

RAG Use Cases

Enterprise Document & Policy Search

Large companies have thousands of policies, handbooks and contracts. Employees ask questions like "How many vacation days do I get after five years?" or "Can I expense a taxi to the airport?". A RAG assistant finds the exact policy section, answers in plain words and links to it. Two things matter a lot here: permissions (people must only see documents they're allowed to see, covered in Chapter 7) and versions (an old policy must not win over the current one).

Customer Support Knowledge Bases

This is the Brightgrid example. A support assistant answers customers from the help center and past tickets, around the clock. It can also help human agents by suggesting replies with sources. Good support RAG must refuse when the help center has no answer, and hand over to a person instead of guessing.

Codebase & Technical Documentation Assistants

Developers ask "Where do we validate email addresses?" or "How do I call the billing API?". A code assistant retrieves the relevant files, functions and documentation pages, and answers with file paths and line numbers as citations. Code needs special care when chunking: splitting a function in half destroys its meaning, so code is usually split along functions and classes.

Compare It Yourself

If your browser supports WebGPU, start the language model in the lab, then compare the same question with and without retrieval. Without RAG, the small model answers from memory and usually invents a policy. With RAG, it answers from the help center and cites it.

Common mistakes

• Thinking RAG makes answers always correct. If search returns the wrong chunk, the answer will be wrong too. Retrieval quality decides answer quality.
• Sending whole documents. Large, unfocused prompts cost more and bury the key sentence. Search chunks, and send only the best few.
• No refusal path. Without "I don't know", a model will make up an answer when the sources are silent.
• Ignoring outdated documents. An old policy in the knowledge base can be retrieved and quoted as if it were current.
• Skipping citations. Without them, nobody can check answers, and wrong answers go unnoticed.

Exercises

Each exercise ends with a value on the last line. Press Check to compare it with the expected answer.

What to Remember

• RAG = Retrieval + Augmented + Generation: find relevant chunks, add them to the prompt, then let the model answer from them.
• A model's own knowledge is frozen and doesn't include your private data. RAG supplies both at answer time.
• Fine-tuning shapes behavior. Long context suits a few large documents. RAG suits large, changing knowledge that needs citations.
• The architecture has two halves: indexing ahead of time (chunk, embed, store) and answering per question (retrieve, augment, generate).
• RAG grounds answers, reduces hallucinations, stays fresh without retraining, and makes answers auditable with citations.
• Common uses: policy search, support knowledge bases and code and documentation assistants.

Next: RAG Pipeline Architecture, a closer look at the four stages and how data flows between them.