RAG Development Services Built on Retrieval You Can Measure

RAG development services build systems that retrieve information from your own content and use it to ground generated answers. Most quality problems in these systems come from retrieval rather than the language model. Pixel Web Solutions engineers the retrieval layer deliberately, with chunking, hybrid search, reranking, and evaluation that separates retrieval quality from generation quality.

Book a free retrieval quality call → See how to tell retrieval failures from generation failures

Get your free RAG quality assessment

Send us a set of questions your system gets wrong. A senior engineer will diagnose whether the failures are retrieval or generation, and what would fix them. 30 minutes, no cost.

  • A diagnosis of whether your failures are retrieval or generation
  • The specific fixes ranked by impact, not by effort
  • An honest read on whether your content can support the questions being asked

70

AI and Software Projects Delivered

6

Industries Served

12

Years of Production Engineering

6

End Users on Systems We Built

When RAG gives a bad answer, the model is usually not the problem

The common reaction to a poor RAG answer is to change the model, adjust the prompt, or conclude the technology is not ready. Far more often, the retriever never surfaced the passage containing the answer, so the model was asked to answer from material that did not contain it. It did what any system would do with insufficient context, and the fix is in the retrieval layer.

The chunk was never retrieved

If the right passage is not in the top results, no model can recover it. Poor chunking, embedding-only search that misses exact terms, and no reranking are the usual causes, and all three are measurable before you touch the prompt.

The content does not contain the answer

Some questions cannot be answered from the documentation that exists. This is worth discovering in week one, because no amount of retrieval engineering fixes a knowledge gap, and the honest answer is to write the missing content.

Nobody is measuring either half

Most struggling RAG systems have no evaluation at all, so quality is anecdotal and tuning is guesswork. Separating retrieval metrics from generation metrics turns a vague complaint into a specific, fixable defect.

Our RAG Development Services

Pixel Web Solutions builds and repairs retrieval augmented generation systems, with the retrieval layer engineered rather than assembled from defaults.

Custom RAG System Development

End-to-end builds covering ingestion, chunking, embedding, retrieval, reranking, generation, citation, and evaluation, designed around your content rather than a template pipeline.

RAG Audit and Rescue

Diagnosis and repair of an existing system that is not performing. Retrieval and generation measured separately, failures categorised, fixes ranked by impact. Usually cheaper and faster than rebuilding.

Document Ingestion and Parsing

Extraction from PDFs, scans, tables, spreadsheets, and structured sources, including OCR and layout-aware parsing, because retrieval quality is bounded by parsing quality.

Chunking and Indexing Strategy

Chunk size, overlap, and boundary strategy chosen per content type, with metadata enrichment and parent-child structures where whole-document context matters.

Hybrid Search and Reranking

Vector search combined with keyword search so exact terms, product codes, and names are not lost to semantic similarity, then a reranking pass that consistently produces the largest single quality gain in most systems.

Query Understanding and Rewriting

Query expansion, decomposition of multi-part questions, and routing between sources, so the retriever receives a query it can actually match.

RAG Evaluation Harnesses

Golden question sets with known correct sources, retrieval metrics and generation metrics scored separately, and regression detection on every change.

Permission-Aware and Multi-Tenant Retrieval

Filtering at query time by the requesting user's access rights, tenant isolation, and access logging, so a RAG system can never surface a document its user could not open directly.

Freshness, Scale and Cost Optimisation

Incremental indexing, update pipelines, caching, embedding cost management, and latency tuning as content volume and query load grow.

Have a RAG system that answers badly and no idea why?

Send us twenty questions it gets wrong. We will tell you how many are retrieval failures, how many are generation failures, and how many are content gaps that no engineering will fix. Free, and it usually reframes the whole problem.

Get my free RAG diagnosis →

Is it a retrieval problem or a generation problem?

This is the first question to answer and almost nobody asks it. The test is simple: look at what the retriever returned for a failed question. If the correct passage is not in the retrieved set, it is a retrieval failure and prompt changes will not help. If the passage was retrieved and the answer is still wrong, it is a generation problem.

Symptom Likely cause Where to fix
Answer is vague and generic Right passage not retrieved Retrieval: chunking, hybrid search, reranking
Answer confidently states something false Wrong passage retrieved and trusted Retrieval plus grounding constraints and citations
Answer is right but incomplete Passage retrieved but truncated, or context split across chunks Chunking strategy, parent-child retrieval
Fails on exact names, codes, or product numbers Semantic search cannot match exact tokens Hybrid search with a keyword component
Good on simple questions, poor on multi-part ones Single query cannot match a compound question Query decomposition
Answer contradicts a document you know exists Content not indexed, or stale index Ingestion coverage and refresh pipeline
Passage was retrieved, answer still wrong Generation problem Prompt, citation enforcement, or model choice
No document anywhere contains the answer Content gap Write the content, no engineering fixes this

Note that only one row in this table is a generation problem, and one is not a technical problem at all. That distribution matches what we see in practice, which is why we instrument retrieval before touching prompts. Teams that skip this step tend to spend weeks tuning the wrong layer.

How to measure a RAG system properly

RAG needs two sets of metrics, because it has two components that fail independently. Retrieval metrics ask whether the right material was found. Generation metrics ask whether the answer used it correctly. A single overall quality score hides which half is broken.

Retrieval metrics

Metric

Question it answers

Recall at k

Was the correct passage anywhere in the top k results

Precision at k

How much of what was retrieved was actually relevant

MRR

How high up the correct passage appeared

NDCG

Whether the ordering put the most useful material first

Hit rate

Share of questions where any correct source was retrieved

Generation metrics

Metric

Question it answers

Faithfulness / groundedness

Is every claim in the answer supported by the retrieved context

Answer relevance

Does the answer address the question that was asked

Citation accuracy

Do the cited sources actually contain what is attributed to them

Completeness

Did the answer use all the relevant retrieved material

Build the golden set first: real questions with the documents that should answer them identified by someone who knows the content. Fifty well-chosen questions are worth more than a thousand generated ones, because the value is in the correct-source labels, not the volume. Every change then gets scored against it, which turns tuning from opinion into measurement.

Naive RAG to advanced RAG, and when to climb

RAG architectures escalate in complexity and cost. Most systems that are performing poorly do not need the most advanced option, they need the second rung done properly. Reranking and hybrid search deliver more improvement per unit of effort than anything further up the ladder.

Rung What it adds When to move up
1. Naive RAG Chunk, embed, vector search, generate Baseline. Fine for small, clean, homogeneous content
2. Hybrid search and reranking Keyword search alongside vectors, then a reranking pass As soon as exact terms matter or precision is poor. This is where most gains are
3. Better chunking and metadata Structure-aware chunking, filters, parent-child retrieval When answers are truncated or context is split across chunks
4. Query understanding Rewriting, decomposition, routing between sources When multi-part or ambiguous questions fail
5. Agentic RAG Iterative retrieval, self-checking, multi-step lookups When single-pass retrieval genuinely cannot answer the question type
6. Graph RAG Entity and relationship graph alongside vectors When questions depend on relationships across documents rather than passages

Rungs five and six get the attention and are the right answer far less often than the discourse suggests. They add latency, cost, and failure modes. Before recommending either, we check that chunking is appropriate for your content, that hybrid search is in place, and that a reranker is running, because a large share of systems described as needing graph RAG were actually missing a reranker.

Our RAG development process

Six stages: content and question audit, golden set and baseline, ingestion and chunking, retrieval engineering, generation and grounding, then deployment with monitoring.

Content and Question Audit

Week 1 : What content exists, how it is structured, and what questions it will be asked. Deliverable: a coverage map identifying questions your content cannot currently answer.

Golden Set and Baseline

Weeks 1–2 : Real questions with correct sources labelled, plus a baseline measurement if a system already exists. Deliverable: an evaluation set and a starting score.

Ingestion and Chunking

Weeks 2–4 : Parsing, OCR where needed, table and layout handling, deduplication, metadata enrichment, and chunking chosen per content type.

Retrieval Engineering

Weeks 3–6 : Hybrid search, reranking, metadata filtering, query rewriting where needed, tuned against retrieval metrics rather than by impression.

Generation and Grounding

Weeks 5–7 : Prompt architecture, citation enforcement, refusal behaviour when context is insufficient, and generation metrics scored on the golden set.

Deployment, Freshness and Monitoring

Weeks 7 onward : Incremental indexing, refresh pipeline, permission filtering, latency and cost monitoring, and regression testing on every change.

Find out whether your retrieval is the problem before you change models

A 30-minute session on your questions, your content, and where the failures actually sit. You keep the diagnosis regardless of what you decide.

  • Senior engineer, not a salesperson
  • Written diagnosis within 48 hours
  • We will tell you if the answer is to write content, not code
Book my free retrieval quality call →

Key Benefits of Choosing Our RAG Development Services

We accelerate retrieval quality by measuring both halves of the system and being honest about what engineering can and cannot fix.

Retrieval measured before anything is tuned

Retrieval metrics and generation metrics scored separately from the first week, so effort goes to the layer that is actually failing.

Hybrid search by default

Pure vector search loses exact terms, product codes, part numbers, and names. Keyword search runs alongside it in every system we build, because those are exactly the queries users care most about getting right.

Reranking as standard, not an upgrade

A reranking pass is usually the single largest quality gain available and it is cheap to add. We include it rather than positioning it as an advanced tier.

Honest about content gaps

If your documentation does not contain the answer, we say so in week one. That is a content problem with a content solution, and no retrieval work will fix it.

Permission-aware from the start

Retrieval filtered by the requesting user's access rights at query time. Retrofitting this into a live index is significantly harder than building it in.

Full ownership

Pipelines, prompts, evaluation sets, index configuration, and documentation transfer to you. Your golden set in particular is a lasting asset, because it makes every future change measurable.

Chunking strategy by content type

Chunking decides what the retriever can find, and the right strategy depends on how the content is structured. A single chunk size applied across mixed content is a common cause of poor retrieval.

Content type Strategy Why
Structured documentation with headings Section-boundary chunks with heading metadata Sections are already semantically coherent units
Long-form prose and reports Semantic or recursive chunking with overlap Meaning does not align with fixed character counts
Contracts and policies Clause-level chunks with parent-document retrieval Clauses are the unit of the question, but context matters
Support tickets and QandA One chunk per exchange The unit is naturally self-contained
Tables and spreadsheets Row or logical-group chunks with headers preserved A row without its headers is meaningless when retrieved
Code and technical reference Function or block level with file path metadata Structural boundaries carry the meaning
Slides and mixed media Slide-level with extracted text plus caption context Visual layout does not survive naive text extraction

Where questions need broad context but retrieval works best on small units, parent-child retrieval solves both: match on small chunks, return the larger surrounding section to the model.

What we build RAG systems with

Vector and search :

Pinecone Weaviate Qdrant Pgvector Elasticsearch OpenSearch Hybrid BM25 plus dense retrieval

Reranking :

Cross-encoder rerankers Commercial reranking APIs Evaluated per corpus rather than assumed

Embeddings :

Commercial and open embedding models Selected by benchmark on your content rather than by leaderboard

Orchestration :

LangChain LlamaIndex Direct implementation where frameworks add overhead without benefit

Parsing :

Layout-aware PDF parsing OCR Table extraction Structured source connectors

Models :

OpenAI Anthropic Gemini Llama Mistral Self-hosted open-weight where data residency requires it

Evaluation :

Custom harnesses Golden sets Retrieval and generation scoring in CI

Infrastructure :

AWS Azure Google Cloud Docker Kubernetes

RAG systems delivering measurable improvement

42%

Higher Context Precision

Context precision improved by 42% over a BM25 baseline (MRR@5 from 0.54 to 0.77), reducing hallucination rates by 31% and enabling automated resolution for 68% of inbound developer tickets across 15,000+ technical docs over 6 months.

51%

Higher Retrieval Hit Rate

Hit Rate@3 increased by 51% following hybrid search and cross-encoder reranking, eliminating false positives in multi-clause lookups to enable legal analysts to perform contract audits 3x faster across 50,000+ filings in Q4 2025.

64%

Fewer Zero-Recall Queries

Zero-recall queries reduced by 64% using parent-document retrieval and query expansion, resolving context fragmentation to allow 10,000+ engineers to self-serve system architecture answers across internal wikis during a 12-month rollout.

RAG, fine-tuning, or a long context window

These solve different problems and are frequently confused. RAG supplies knowledge. Fine-tuning changes behaviour. Long context handles a large amount of material within a single request. Long context has not replaced RAG, for reasons of cost, scale, freshness, and permissions.

  RAG Fine-tuning Long context
Supplies new knowledge Yes Not reliably Yes, within one request
Handles changing content Yes, reindex No, requires retraining Yes, but resent every time
Scales to large corpora Yes Not applicable No, bounded by the window
Cost per query Moderate, scales with retrieved context Low after training High, you pay for everything sent
Supports citations Yes, natively No Weakly
Respects user permissions Yes, filter at retrieval No No, everything sent is visible
Best for Knowledge over a corpus that changes Tone, format, domain style, smaller models A handful of documents per request

The "is RAG obsolete" question comes up on most first calls. Long context is genuinely useful and it removes the need for RAG when a task involves a few documents at a time. It does not remove the need when the corpus is large, changes frequently, requires citations, or must respect per-user permissions, which describes most enterprise use cases.

For fine-tuning and foundation model work, see our generative AI development services. For training models on your own data, see our AI model development services.

How much does RAG development cost?

Cost is driven mostly by content condition. Clean, structured, text-based documentation is straightforward. Scanned documents, complex tables, mixed formats, and content requiring permission mapping add significant work before retrieval is even tuned. Running cost is separate and driven by embedding volume, retrieved context size, and query volume.

Engagement Scope Typical timeline
RAG audit and diagnosis Golden set, baseline measurement, failure categorisation, fix plan 2 to 3 weeks
RAG build Ingestion, chunking, hybrid retrieval, reranking, generation, evaluation 6 to 12 weeks
Complex content build Scanned or table-heavy sources, OCR, layout parsing 10 to 18 weeks
Permission-aware enterprise build Multi-source, access-filtered retrieval, audit logging 12 to 20 weeks
Optimisation retainer Retrieval tuning, index refresh, cost and latency work Monthly

Two ongoing costs to plan for: embedding and re-embedding as content changes, and inference cost that scales with how much context each query retrieves. Better retrieval reduces the second one, since sending less but more relevant context is cheaper and usually more accurate.

Book your free RAG consultation

Send us the questions your system gets wrong, or describe the content you want to make searchable. In 30 minutes, a senior engineer will diagnose where the failures sit and what would fix them.

  • Retrieval failures separated from generation failures
  • Fixes ranked by impact rather than by effort
  • An honest read on whether your content can answer the questions

Frequently asked questions

RAG development services build retrieval augmented generation systems, which retrieve relevant material from your own content and use it to ground a language model's answer. Scope typically covers document ingestion and parsing, chunking and indexing, retrieval engineering including hybrid search and reranking, generation with citations, evaluation harnesses, permission filtering, and the pipelines that keep the index current.

Usually because the correct passage was never retrieved, so the model was asked to answer from material that did not contain the answer. Common causes are chunking that splits or buries the relevant content, vector-only search that misses exact terms, and no reranking pass. Less often the answer simply does not exist in the content, which no engineering fixes.

Look at what the retriever returned for a failed question. If the correct passage is not in the retrieved set, it is a retrieval failure and prompt changes will not help. If the passage was retrieved and the answer is still wrong, it is a generation problem. In our experience the large majority of failures fall on the retrieval side, which is why we instrument that layer before touching prompts.

With two separate metric sets, because the two components fail independently. Retrieval is scored with recall at k, precision at k, MRR, and NDCG, asking whether the right material was found and ranked well. Generation is scored on faithfulness, answer relevance, and citation accuracy, asking whether the answer used the material correctly. Both are measured against a golden set of real questions with known correct sources.

It depends on the content structure. Documentation with headings suits section-boundary chunks, long prose suits semantic chunking with overlap, contracts suit clause-level chunks with parent-document retrieval, tables need headers preserved with each row group, and support tickets are naturally self-contained. Applying one chunk size across mixed content is a common cause of poor retrieval.

In almost every production system, yes. Vector search alone struggles with exact terms such as product codes, part numbers, and proper nouns, which keyword search handles well, so running both covers each other's weaknesses. A reranking pass over the combined results is usually the single largest quality gain available and it is inexpensive to add.

Agentic RAG performs multiple retrieval steps, checking and refining its own results rather than retrieving once. It genuinely helps for questions that cannot be answered from a single lookup. It also adds latency, cost, and failure modes, and it is frequently recommended for systems that would be fixed more cheaply by correcting chunking and adding a reranker. We check the simpler options first.

For many enterprise use cases, yes. Long context is genuinely useful when a task involves a handful of documents at a time. It does not help when the corpus is large, because you cannot send everything, when content changes frequently, because you resend it every query, when answers need citations, or when different users must see different material. RAG addresses all four, and many systems now use both.

RAG when the system needs to know your information, which covers most business use cases. Fine-tuning when you need consistent tone, format, or domain vocabulary, or acceptable quality from a smaller and cheaper model. Fine-tuning changes how a model responds rather than what it knows, so it is the wrong tool for a knowledge problem. Some systems use both.

Through incremental indexing triggered by content changes rather than periodic full rebuilds, with change detection on the source systems, deletion handling so removed content stops being retrieved, and monitoring for staleness. Full rebuilds are expensive at scale and leave a window where the index disagrees with reality.

By filtering at query time against the requesting user's own access rights, so a user can never retrieve a document they could not open directly. This is enforced at the retrieval layer rather than by instructing the model, and access is logged. Building it in from the start is considerably easier than retrofitting it into a live index.

Usually, and it is normally the cheaper path. Most underperforming systems have a sound architecture with an unengineered retrieval layer. An audit measures retrieval and generation separately, categorises the failures, and identifies the fixes with the largest impact. Rebuilding is recommended only when the ingestion or data model makes the existing system genuinely unfixable.

Ready to make retrieval the strong part of your system?

Bring the questions it gets wrong, or the content you want to make answerable. We will come back with a diagnosis, an evaluation set, a fix plan, a timeline, and a number.

Get in Touch