RAG in one minute
Think of checking the correct catalogue entry before replying to a customer. RAG organises a software version of that retrieval-and-writing process. Selecting the wrong catalogue page still creates a weak foundation, however polished the response becomes. The workflow needs both a good lookup and a faithful answer.
RAG through a simple example
A customer asks whether a particular desk lamp is in stock today and what it costs. An LLM without current company data cannot establish live availability from general patterns. A RAG application first retrieves relevant information. It matches the product identifier and variant, checks the designated source and supplies the result to the model for explanation.
Connectors can provide access to the catalogue or document source. They determine which information is reachable with the connected account. RAG adds selection and use of relevant information. A working connection therefore does not by itself guarantee a current source or a faithful answer.
- 1 · Retrieve
Find the correct product variant, price and availability in an authorised source.
- 2 · Add context
Provide the retrieved information with its source and relevant date.
- 3 · Generate
Explain what was found and identify information that is still missing.
Suppose the source lists model L24 in black, with three units available and a price including VAT. The answer must preserve that variant and price basis. It should not use stock for the white version or invent a delivery date. For fast-changing records, a live database or API query may be better than a periodically refreshed document index. Not every implementation calls such a tool lookup RAG, although it shares the principle of retrieving before answering.
Another familiar example is a question about returns. The system retrieves the current policy and uses the relevant passage to explain the procedure. If the passage does not specify an exception for business customers, the model should not create one from general expectations. Identifying the document and version gives an employee a concrete way to check the explanation.
A closer technical look
A common RAG pipeline begins before the user asks a question. Documents are ingested, cleaned and divided into useful passages. Metadata may record a product code, date, language or access permission. Passage size matters: a single sentence can lose an exception in the next paragraph, while a whole handbook may bring in too much irrelevant material.
Embeddings and retrieval. An embedding represents text or other content as a vector, a sequence of numbers learned for useful representation. Vector search can find related meaning even when the wording differs. Nearby vectors do not prove that two products are identical or that a passage actually answers the question.
A vector database can store and search these representations, but it is not required in every RAG design. Keyword search, structured database filters and hybrid retrieval are also possible. Exact product codes may be decisive for one question, while semantic similarity helps with a description of a problem. A reranking stage can further order candidate passages before selection.
Selected material enters the Context Window alongside the question and instructions. It consumes tokens and processing capacity. Adding more documents is not automatically better: irrelevant or conflicting text can make the useful evidence harder to apply. Source labels and clear boundaries help distinguish retrieved document content from application instructions.
| Method | What changes? | Typical purpose |
|---|---|---|
| RAG during use | Retrieved information is placed in the model's context. | Support an answer with specific or recent evidence. |
| Training or fine-tuning | A learning process adjusts model weights. | Change learned behaviour, patterns or task performance. |
| Both together | An adapted model works with a separate retrieval pipeline. | Support a specialised workflow; both components need evaluation. |
The influential 2020 paper by Lewis and colleagues combined a generator with an external knowledge source. Its particular research system also involved training components of that combination. This does not mean that every contemporary RAG query retrains a model. The term now covers multiple designs that connect retrieval and generation.
Finding and reducing failures in the pipeline
An answer can fail because a source is missing, the wrong passage is retrieved or the model misreads the right passage. The retrieved source itself may also contain an error. These causes call for different remedies. Replacing the language model does not repair an out-of-date catalogue, and improving retrieval does not automatically fix a mistaken interpretation of a correct price.
Was the right document, variant and version selected?
Does the selected source actually support each important claim?
RAG can reduce the risk of Hallucination by supplying relevant facts. It does not guarantee error-free output. A citation may point to a real document that does not contain the claimed figure. Verification must assess the relationship between claim and passage, rather than merely checking whether a link opens successfully.
- Test known-answer questions, including variants and exceptions.
- Include questions whose answers are absent and expect an explicit limitation.
- Check how quickly changed prices and withdrawn documents are reflected.
- Apply access permissions before information is supplied to the model.
- Measure retrieval quality separately from final-answer accuracy.
Define what the application should do when evidence is insufficient. It can ask for a product code, request a current stock check or refer the question to a staff member instead of promising availability. Where a decision needs an audit trail, retain the relevant source version. This makes the workflow useful while keeping the basis of its answers visible and open to correction.