RAG development services
Retrieval-augmented generation over your own documents — answers grounded in sources you control, with citations a user can check and evaluation that tells you when retrieval is quietly failing.
The short answer
RAG searches your own documents for passages relevant to a question and gives them to a language model as context, so answers are current, grounded and citable. A production RAG system over a well-structured corpus typically takes four to eight weeks; messy data or complex permissions take considerably longer. The expensive part is almost never the model — it is ingestion and evaluation.
On this page
What RAG is, plainly
A language model knows what it absorbed during training. It does not know your contract templates, your support history, your internal policies or anything that happened after its cutoff. Retrieval-augmented generation closes that gap without retraining anything: when a question arrives, you search your own corpus for the passages most relevant to it, hand those passages to the model, and ask it to answer from them.
Three consequences follow, and they are the whole reason the pattern dominates enterprise AI. Answers are current, because updating a document updates the answer. They are grounded in text you control rather than statistical memory. And they are citable — every claim can point back to a source a human can open and verify, which is usually what makes the output usable in a decision that matters.
"Don't long context windows make RAG obsolete?"
The most common question we get, and the answer is no — but the reasoning has changed.
Long context handles a few hundred pages comfortably. It does not handle a document store of hundreds of thousands of files, and it does not handle them economically: you pay for every token on every single request, and latency scales with the padding. Retrieval remains the only sensible way to answer from a large corpus at a cost and speed you would actually deploy.
What long context genuinely changed is the tuning. You can now retrieve more generously and chunk less aggressively than the older playbook assumed — passing twenty rich passages rather than five clipped ones, and keeping documents more intact. In practice that has made RAG systems simpler and more accurate, not obsolete.
What a production RAG pipeline involves
Ingestion
Getting documents out of PDFs, Confluence, SharePoint, ticketing systems and shared drives — and keeping them synced as they change.
Parsing & chunking
Turning documents into passages that retain enough context to be meaningful alone. Tables, headers and layout matter far more than people expect.
Hybrid retrieval
Vector search for meaning plus keyword search for exact terms — product codes, names, clause numbers — because embeddings alone miss precise identifiers.
Reranking
A second pass that reorders candidates by true relevance. Usually the single highest-return addition to a mediocre RAG system.
Grounded generation
Prompting and structuring so the model answers from retrieved passages, cites them, and says so when they do not contain the answer.
Evaluation
Labelled question sets scoring retrieval and generation separately, run on every change so quality regressions surface before users find them.
The parts that are actually hard
Standing up a demo RAG system takes an afternoon. The gap between that and something people trust is where the budget goes, and it is rarely where teams expect.
Your documents are messier than you think. Scanned PDFs, tables that carry the actual meaning, near-duplicate versions of the same policy with no clear winner, and documents that contradict each other. Ingestion and cleaning routinely take more of the project than everything else combined.
Chunking destroys context. Split a document badly and a passage saying "this does not apply to enterprise customers" ends up separated from the rule it qualifies. The model then answers confidently and wrongly, from a real source.
Retrieval fails silently. When search returns nothing useful, an unguarded model will answer anyway from general knowledge, fluently. Without evaluation, this looks exactly like success.
Freshness is an ongoing system, not a launch task. A corpus that was accurate at go-live decays. Re-indexing, change detection and deletion propagation need designing in, or the system quietly becomes confidently out of date.
Permissions and private data
If your corpus contains anything not everyone should see, this is the requirement that shapes the architecture — and the one most often bolted on too late.
Permissions must be enforced at retrieval time. Every chunk carries its source document's access metadata, and the retrieval query is filtered to what the asking user may already read, before anything reaches the model. The alternative — retrieving everything and instructing the model to withhold what the user should not see — is not a security control. It leaks, and it will leak in a way that is hard to detect and embarrassing to explain.
For UK and EU clients we also design for data residency and retention up front: where embeddings live, which provider processes what, what is logged, and how a deletion request propagates through the index.
Evaluating a RAG system
A bad RAG answer is usually a retrieval failure wearing a generation costume, so we measure the stages separately.
- Retrieval: recall and precision at k against a labelled set of real questions. If the right passage was never retrieved, no amount of prompt engineering will fix the answer.
- Groundedness: is every claim in the answer supported by a retrieved passage? This is the number that predicts whether users will keep trusting the system.
- Citation accuracy: do the citations point at the passages that actually support the claim, rather than plausible-looking neighbours?
- Refusal behaviour: when the corpus genuinely does not contain the answer, does the system say so? Deliberately including unanswerable questions in the eval set is the cheapest quality win available.
When RAG is the wrong tool
We would rather tell you this in week one than month three. RAG is not the answer when the question needs aggregation across the whole corpus ("how many contracts renew in Q3") — that is a database query, and forcing it through retrieval produces confident arithmetic errors. It is not the answer when your corpus is small and static enough to fit in context. And it is not the answer when the real problem is that the documents themselves are wrong or missing, in which case retrieval faithfully surfaces bad information faster.
Often the right system is a hybrid: structured queries for the countable, retrieval for the qualitative, and an agent deciding which to use. That is a design conversation worth having before anyone writes an ingestion script.
How this fits together
RAG development sits within our AI development practice, and a retrieval layer underpins most of the agents and automations we ship. If you are not sure whether RAG fits your corpus, a short discovery sprint will tell you — including if the answer is no. Costs for each engagement shape are published on our pricing page.
Frequently asked questions
What is retrieval-augmented generation (RAG)?
RAG is a pattern where, instead of relying on what a language model memorised during training, you search your own documents for the passages relevant to a question and give those passages to the model as context. The model answers from the retrieved text — making answers current, grounded in sources you control, and citable back to a specific document.
Is RAG still necessary now that models have long context windows?
Yes, for most real corpora. Long context handles a few hundred pages; it does not handle hundreds of thousands of files, and not cheaply — you pay for every token on every request. Long context changes the tuning, not the need: you can retrieve more generously and chunk less aggressively than three years ago.
How much does a RAG system cost to build?
A production RAG system over a well-structured corpus typically takes four to eight weeks. Messy source data, complex permissions, or a corpus spanning many formats takes considerably longer and costs proportionally more. In most cases the ingestion and evaluation work, not the model integration, is the expensive part. See how we price.
Does RAG stop hallucination?
It reduces it substantially but does not eliminate it. The common failure shifts from inventing facts to misreading retrieved text, or answering confidently when retrieval returned nothing useful. The mitigations are checkable citations, explicit evaluation for "the documents do not say", and measuring groundedness rather than assuming it.
How do you handle document permissions in RAG?
Permissions are enforced at retrieval time, filtering the candidate set by the asking user's access before anything reaches the model — never by instructing the model to withhold information. Every chunk carries its source document's access metadata. Anything else leaks.
How do you evaluate a RAG system?
Separately at each stage. Measure retrieval with recall and precision at k against a labelled question set; measure generation for groundedness, citation accuracy, and refusal behaviour when the corpus genuinely lacks the answer. A single end-to-end score tells you something is wrong but never what.
Talk to us about your corpus
Tell us what your documents are, where they live and what people need to ask of them. We will tell you whether RAG fits and what it would take. Or email hello@brashpixels.com.