Technologies — AI architecture pattern

Retrieval-Augmented Generation (RAG)

An architecture pattern that grounds language model output in an organisation's own documents — a retrieval pipeline and vector index engineered alongside the generation step, not a single off-the-shelf feature.

Discuss Your Project Explore Our Technologies

Retrieval-augmented generation (RAG) is an architecture pattern that grounds a language model's output in an organisation's own documents: a query is used to retrieve the most relevant passages from a defined document collection, and the model generates its answer from those retrieved passages rather than from general training data alone. Building RAG well means engineering a retrieval pipeline — chunking, embeddings, a vector index, and evaluation of what actually gets retrieved — not adding a single API call; retrieval quality determines answer quality at least as much as the choice of language model.

Where it fits

Most organisations have valuable knowledge locked inside documents a language model was never trained on — internal wikis, contracts, product manuals, past support tickets, technical specifications. Retrieval- augmented generation addresses exactly that gap: instead of asking a model to answer from what it learned during training, the system first retrieves the passages most relevant to a query from that organisation's own document collection, then asks the model to generate an answer grounded in what it just retrieved.

The alternative is fine-tuning a model on that data directly, or pasting the relevant documents into every prompt. Both can work at a small enough scale, but neither holds up well as the underlying documents keep changing. RAG separates the data from the model: updating what the system "knows" means re-indexing a document, not retraining anything, which is why it fits use cases like internal knowledge assistants and document search where the source material is updated regularly.

RAG is not a single feature to switch on — it's an architecture with several pieces that each affect the final answer: how documents are split into passages, which embedding model represents them, how the resulting vectors are stored and searched, whether results are re-ranked before reaching the model, and how retrieval quality is measured over time. We treat each of these as an explicit design decision, because a capable language model paired with a poorly designed retrieval step still produces bad answers.

It's also not a cure for hallucination. Grounding reduces the risk of an answer with no basis in real data, but it doesn't guarantee accuracy — the model can still misread a retrieved passage or overreach beyond what it actually supports. We design around that with citations back to source documents and, for cases where being wrong matters, a human review step before an answer is treated as final.

Core capabilities

Retrieval pipeline

Turning a user query into a search over a defined document collection, not the open web
Re-ranking candidate passages before they reach the generation step, so the most relevant content is prioritised
Assembling retrieved passages into a bounded context window alongside the original query
Handling queries that retrieve nothing sufficiently relevant without forcing a generated answer anyway

Embedding storage & similarity search (infrastructure)

Converting document chunks and incoming queries into vector embeddings for semantic, meaning-based search rather than keyword matching
Storing those embeddings in a vector index that supports fast nearest-neighbour search at the corpus's actual scale
Combining metadata filtering (document type, permission level, date) with vector similarity, so retrieval respects access boundaries
Treated as infrastructure underneath the retrieval pipeline — the vector store is chosen to fit this system's scale and latency needs, not selected or marketed as a standalone capability

Grounded generation

Generating an answer constrained to retrieved passages rather than the model's general training data
Citing or linking back to the specific source documents so an answer's provenance can be checked
Distinguishing an answer supported by retrieved content from one the model is inferring or guessing

Common use cases

Internal knowledge assistantsAnswering employee questions from a defined set of internal documentation, wikis, or policies, with citations back to source.
Document Q&ALetting users ask questions directly against a specific set of uploaded documents — contracts, manuals, reports — rather than searching them manually.
Support and search grounded in real documentsCustomer or internal support responses grounded in current product documentation or knowledge-base articles, instead of a model's general knowledge.
Technical and compliance lookupRetrieving and citing the relevant clause, specification, or procedure from a large body of technical or regulatory documents.

Architecture & integration considerations

Retrieval pipeline designHow a query moves from the user through embedding, vector search, optional re-ranking, and context assembly is engineered as a pipeline with measurable stages, not treated as a single opaque call.
Chunking and embedding strategyHow documents are split into passages materially affects retrieval quality — chunk size, overlap, and whether splits respect document structure (headings, sections) are deliberate choices. The embedding model that represents those chunks is chosen and versioned deliberately too, since changing it usually means re-embedding the entire corpus.
Retrieval quality evaluationA test set of representative queries and the passages they should return, used to measure retrieval precision and recall before and after any change to chunking, embeddings, or ranking — not judged by spot-checking a handful of examples.
Index freshness and stalenessThe vector index reflects the document corpus as of its last update. A defined re-indexing process — real-time, scheduled, or triggered on document change — determines how quickly a new or updated document actually becomes retrievable; a stale index is a common, easy-to-miss failure mode.
Access-aware retrievalRetrieval respects the same permission boundaries as the underlying documents, so the system never surfaces content to a user who couldn't otherwise see the source document.
Citation and provenanceGenerated answers link back to the specific passages and documents used, so a person can verify an answer against its source rather than trust it outright.

Strengths

Keeps pace with changing informationUpdating an index — adding, removing, or re-embedding documents — is faster and cheaper than retraining or fine-tuning a model on new data.
Answers are traceable to sourceBecause generation is grounded in retrieved passages, an answer can be checked against the specific document it came from, rather than taken on faith.
Scales to large document collectionsA vector index can hold and search far more content than would fit in a model's context window, without stuffing an entire document set into every prompt.
Domain knowledge without retrainingOrganisation-specific or proprietary knowledge can inform model output without that information ever becoming part of the model's training data.

Trade-offs & limitations

Output quality depends entirely on retrieval qualityIf the retrieval step doesn't surface the relevant passage, the generation step has nothing correct to work from — a RAG system is only as good as what it retrieves, regardless of how capable the underlying model is.
Adds a second system to build and maintainCompared to prompting a model directly, RAG introduces a chunking pipeline, an embedding process, a vector index, and a retrieval-quality evaluation process — a genuine engineering investment, not a configuration flag.
Cheaper to keep current than fine-tuning, but not freeUpdating a RAG index as source data changes is materially cheaper and faster than retraining a fine-tuned model, but it isn't zero-cost — re-indexing, evaluation, and monitoring remain ongoing work.
Only earns its complexity past a certain scaleFor a small, static document set, pasting the relevant documents directly into the prompt (long-context stuffing) can be simpler than building a retrieval pipeline. RAG becomes the more scalable and cost-efficient option once the corpus is too large, too dynamic, or too costly to include in full on every request — but it's a second system either way.
Doesn't eliminate hallucinationGrounding reduces but doesn't remove the risk of an incorrect or unsupported answer — the generation step can still misread or over-generalise from retrieved passages, which is why citation and evaluation remain necessary rather than optional.

When to use it

Answers need to be grounded in a specific, identifiable set of internal or proprietary documents
The underlying documents change often enough that retraining a model on every update isn't practical
Citing the source of an answer is a requirement, not a nice-to-have
The document collection is too large to include in full within a single prompt

When another option may be more appropriate

The relevant knowledge is small and static enough to fit directly in a prompt, where long-context stuffing is simpler
The task needs a specific tone, style, or behavioural pattern baked into the model, which fine-tuning suits better than retrieval
There's no defined, retrievable document collection to ground answers in
The team can't commit to maintaining a retrieval pipeline and evaluating its quality over time

Relevant services

Relevant industries

Representative solutions

Alternatives & complementary technologies

Fine-tuningBakes knowledge or behaviour into the model's weights through additional training; better suited to teaching a model a style or task pattern than to keeping pace with frequently changing factual information.
Long-context / prompt stuffingIncluding relevant documents directly in the prompt instead of retrieving them. Simpler to build for a small, static document set, but doesn't scale in cost or context-window size as the corpus grows.
Hybrid approachesCombining fine-tuning for behaviour or domain style with retrieval for current factual grounding, used where neither approach alone covers both needs.

Frequently asked questions

Does RAG eliminate hallucination?

No. Grounding an answer in retrieved passages reduces the risk of an answer with no basis in real data, but the generation step can still misinterpret or over-generalise from what it retrieved. Citation and evaluation remain necessary, not optional.

How is RAG different from fine-tuning?

Fine-tuning changes a model's weights through additional training; RAG leaves the model unchanged and instead retrieves relevant passages at query time. RAG is generally faster and cheaper to keep current as source data changes, while fine-tuning is better suited to teaching a model a style or behaviour.

How current is the information a RAG system retrieves?

Only as current as its last re-indexing run. A RAG system's answers are bounded by how recently the underlying document index was updated, so how and how often that index refreshes is a deliberate design decision, not an afterthought.

What happens if nothing relevant is found?

A well-built RAG system is designed to say so, rather than generating an answer without a supporting source. That fallback behaviour is part of the architecture, not left to chance.

Do I need a specialised vector database for RAG?

You need some form of vector storage and similarity search, but that's infrastructure underneath the retrieval pipeline — the specific store is chosen to fit the corpus size and latency needs of the system, not a separate product decision made in isolation.

Explore Nordic Markets →

Considering Retrieval-Augmented Generation (RAG) for your next project?

Tell us what you're building — we'll confirm whether this is the right technology choice before recommending anything.

Discuss Your Project Representative Solutions