RAG Development Services

What retrieval-augmented generation is

Retrieval-augmented generation (RAG) combines search with a large language model. When a user asks a question, the system first retrieves the most relevant passages from your knowledge base — policies, manuals, contracts, tickets, product data — and then asks the model to answer using only that material, citing its sources.

RAG is the most practical way to give employees or customers an AI assistant that knows your business. It keeps answers current without retraining models, lets users verify every answer, and respects document permissions so nobody sees information they should not.

Problems we solve

• Staff spending hours searching shared drives, wikis and old emails
• Support agents giving inconsistent answers to the same question
• New hires waiting on colleagues for information that is written down somewhere
• A generic chatbot that confidently makes things up
• Customers unable to find answers in long help centres

What’s included

Why retrieval quality matters most

Most RAG failures are retrieval failures: the right passage was never found, so the model answered from the wrong context. We invest heavily in this step — parsing tables and PDFs correctly, splitting documents along meaningful boundaries, combining semantic and keyword search, re-ranking results and filtering by metadata such as product, region or date. Every change is measured against an evaluation set of real questions.

Keeping answers safe and current

• Freshness — scheduled or event-driven re-indexing when documents change.
• Refusals — the assistant says it does not know when sources do not contain the answer.
• Guardrails — off-topic, harmful and confidential requests are blocked or escalated.
• Feedback — thumbs up/down and comments feed back into evaluation and improvements.
• Observability — logs of questions, retrieved sources, answers, latency and cost.

Timeline and budget

Typical ranges to help you plan. Your written estimate comes after a free discovery call.

Preparing content for retrieval

A RAG assistant is only as good as the content it searches. We audit the knowledge sources first — wikis, PDFs, help centres, tickets, policies — and remove duplicates, outdated versions and documents nobody should rely on. Then we choose how to split documents into chunks: by headings and sections where possible, keeping tables intact and attaching metadata such as product, version, date and access level.

• A single source of truth for each topic, with superseded documents excluded
• Chunking that respects document structure rather than fixed character counts
• Metadata for filtering by product, region, audience or permission
• Automatic re-indexing when source documents change

Evaluating a RAG system

This evaluation set becomes a regression test: every change to chunking, embeddings, prompts or models is checked against it before release.

Permissions and access control

Employees must only receive answers drawn from documents they are allowed to see. We carry source permissions into the index and filter at query time, so a sales assistant never quotes an HR policy draft or another customer’s contract.

Choosing the right retrieval architecture

There is no single RAG design. The right one depends on how your content is structured, how questions are asked and how much answers must be traced back to sources. We usually start with the simplest design that meets the requirement and add sophistication only where evaluation shows a gap.

A typical RAG delivery plan

1. Question inventory1 week

   Collect 100–300 real questions from support tickets, search logs and staff, and agree what a good answer looks like.

2. Content audit1–2 weeks

   Map sources, owners, formats, permissions and how often each source changes.

3. Baseline pipeline2–3 weeks

   Ingestion, chunking, embeddings, retrieval and answer generation with citations, measured against the question set.

4. Tuning2–4 weeks

   Improve chunking, metadata filters, re-ranking and prompts based on failures, not guesses.

5. Pilot and rollout2–4 weeks

   Release to a small group, collect feedback, then integrate with the channels people already use.

Timelines are typical for a single knowledge domain; more sources, stricter permissions or multiple languages extend them.

Running costs to plan for

RAG systems have ongoing costs that are easy to underestimate at the pilot stage. Planning for them early avoids surprises when usage grows.

• Model usage — charged per token; long retrieved contexts multiply cost per question, so we keep context focused.
• Embeddings — a one-off cost for the initial index plus re-embedding when documents change or you switch models.
• Vector storage and search — managed services charge by data volume and queries; pgvector inside an existing PostgreSQL database is often cheapest for moderate volumes.
• Evaluation and monitoring — regular automated test runs and human review of a sample of answers.
• Content ownership — someone must keep source documents accurate; the assistant is only as good as what it retrieves.

Signs a RAG pilot is not ready for production

• Answers are judged by impressions rather than a fixed evaluation set
• Citations sometimes point to documents that do not support the answer
• Users can retrieve content they would not be allowed to open directly
• Nobody owns the source content or the update process
• There is no fallback when the assistant does not know — it guesses instead
• Costs per conversation have never been measured

RAG is one part of our generative AI development work and is often combined with AI agents that act on what they find.

Related services

RAG is often the first step into generative AI. To let the assistant take actions, see AI agent development. It relies on clean data from data engineering.

This page is part of AI Development & Data Engineering Services — see the full overview for related services, approach and pricing.