Retrieval-augmented generation, explained: how AI gives cited answers

Retrieval-augmented generation, usually shortened to RAG, is a way of answering a question by first retrieving relevant documents and then generating a response grounded in what was retrieved, rather than asking a language model to answer from memory alone.

The problem RAG solves

A language model on its own only knows what was in its training data, and that data has a cutoff date. Ask it about your company’s internal deployment process, and it has never seen that document, so it either declines or, worse, generates a plausible-sounding answer that is wrong. That second failure mode is called hallucination, and it is the reason plain chatbots are risky for internal knowledge questions.

RAG fixes this by separating two jobs that used to be conflated: finding the right information, and writing a coherent answer from it.

How it works, step by step

1. Retrieval. The question is turned into a search query, run against an index of your actual documents, tickets, and messages. This is the same retrieval work described in what enterprise search is: keyword matching plus vector similarity, filtered to what the requesting user has permission to see.
2. Ranking. The retrieved results are scored and the most relevant handful are selected. Passing too many documents dilutes the answer; passing too few misses context.
3. Generation. The language model writes an answer using only the retrieved documents as source material, not its own training data, for anything specific to your company.
4. Citation. Every claim in the answer is tied back to the specific document, commit, or message it came from, so you can verify it directly instead of taking the answer on faith.

Why citations are the point, not a feature

An answer without a source is a claim. An answer with a source is something you can check in ten seconds. That difference matters more as the question gets more consequential: “what does this environment variable do” is low stakes, “can we ship this to production today” is not.

A well-built RAG system also has to handle the case where nothing supports an answer. The right behavior is a clean decline, something like “nothing in your connected sources covers this,” rather than inventing a source or answering anyway. If a system never says “I don’t know,” it is not being retrieved correctly.

RAG vs a longer conversation

RAG is not always a single retrieval step. Some questions need more than one document to answer, for example tracing an incident across several services or reconstructing a decision that touched multiple tickets over months. That requires the system to query multiple sources, read them, and reconcile conflicting information, which is closer to research than lookup. Fenlo calls this deep research, and it is the same RAG foundation applied across more steps.

RAG can also be extended past your internal sources. When a question needs information your company does not have internally, like current documentation for a public library, the same retrieval and citation model applies to web search results too.

What good RAG looks like in practice

• Every factual statement in the answer links to its source
• The system states uncertainty specifically, for example “only two sources cover this, both from last year,” rather than hedging vaguely
• It declines instead of guessing when nothing supports an answer
• Permissions are enforced at retrieval, so the model never sees a document the user could not already open

This is the model behind Fenlo’s cited answers. Read more about what Fenlo is or how its search layer powers retrieval.