RAG development
A retrieval system is only as good as the passages it finds. We build the chunking, hybrid search, reranking and evaluation layers that decide whether your users get a verifiable answer or a confident invention.
What is rag development?
RAG development is the work of building a system that retrieves the right passages from your own documents and gives them to a language model, so answers are grounded in your data rather than in the model's training. Done properly it produces answers with citations a user can open and verify. Almost all RAG failures are retrieval failures, not generation failures — the model was simply handed the wrong context, so the fix is in chunking, hybrid search, reranking and evaluation rather than in prompting.
Why teams call us
Almost every engagement starts from one of these. If none of them sound familiar, you probably do not need us yet.
The system retrieves passages that are topically related but do not contain the answer, and the model summarises them anyway. To a user it reads as authoritative. This is the single most common RAG failure, and it is a search problem wearing a generation problem's clothing.
One confidently wrong answer to a customer or auditor can end internal support for the tool.
Without a labelled question set and separate retrieval metrics, accuracy discussions become anecdotal — someone tried six questions and formed an impression. There is no way to know whether last week's chunking change helped or hurt.
Blocks approval in any environment with a compliance review.
Vector search matches on meaning, which is exactly wrong for a part number, contract ID, drug name or SKU. Teams that went vector-only discover their system cannot reliably retrieve a document when the user quotes its reference code.
Fails the first realistic user test, which is almost always a lookup by identifier.
Documents are updated, superseded or withdrawn, but the index still holds the old chunks. The system keeps answering from a policy that was replaced four months ago, with a citation that looks legitimate.
Creates a compliance exposure that is worse than having no tool at all.
Scope
More final accuracy is decided here than anywhere else. We handle real-world source material — PDFs with tables, scanned documents, decks, spreadsheets, wiki exports — and chunk on document structure rather than on a fixed token count, so a retrieved passage arrives with the heading and context that make it interpretable.
Keyword search for exact terms, vector search for meaning, then a reranking model to order a wider candidate set. This combination is what makes the system work for both "what is our parental leave policy" and "clause 14.2 of contract AC-8871".
Every claim in an answer is tied to the retrieved passage that supports it, and unsupported claims are rejected before the user sees them. Refusal is treated as a correct outcome when the corpus does not cover the question.
We build a labelled question set from real user queries and score retrieval independently of generation, so when quality moves you know which stage moved it.
Incremental re-indexing on document change, supersession handling so withdrawn documents stop being cited, and deletion propagation that actually removes content from the index rather than just hiding it.
Permissions are enforced in the retrieval query, not filtered from results afterwards. A user cannot receive an answer synthesised from a document they have no right to read.
How it runs
Fixed checkpoints with a named deliverable at each one, so you can stop the engagement at any stage and still own something useful.
We inspect the actual documents rather than the description of them. Formats, quality, duplication, contradictions between sources, and how often things change all determine the architecture — and occasionally reveal that the corpus needs cleaning before any retrieval will work well.
Ingestion, chunking, embedding, hybrid index and reranking, tuned against the evaluation set. At this stage we optimise retrieval metrics alone, with generation deliberately held constant.
The answering step, citation enforcement, refusal behaviour and output formatting — then end-to-end scoring against the labelled set.
Wired into your product, portal or agent, with permission filters connected to your identity provider and a staged traffic ramp.
Results
When a RAG system answers badly, the instinct is to blame the model and start rewriting prompts. In our experience that is the wrong place to look roughly nine times out of ten. The model usually did its job faithfully — it summarised the passages it was given. The passages were simply the wrong ones.
This matters because it changes where the engineering effort goes. Prompt iteration produces small, unstable gains. Fixing retrieval — better chunking, adding keyword search alongside vectors, reranking a wider candidate pool, filtering on metadata — produces large and durable ones.
It also explains why so many teams plateau. They have built a single-stage vector search, they are measuring only end-to-end answer quality, and so they cannot see that their recall at k is 60%. No amount of prompt work recovers information that was never retrieved.
The most valuable instrumentation you can add is a retrieval metric that is independent of the answer. For a labelled set of questions, each with the passages that genuinely contain the answer, you can compute:
With those four numbers, a quality change becomes diagnosable. Without them, every discussion about accuracy is someone’s impression from six sample queries.
Dense vector search is good at meaning and bad at exact strings. That is not a tuning problem; it is what embeddings are. Ask for “contract AC-8871” and a vector index will happily return semantically similar contracts while missing the exact one, because the identifier carries almost no semantic signal.
Real users do both kinds of query constantly — conceptual questions and precise lookups — often in the same session. So the reliable architecture is:
Step three is where the cost savings come from. Retrieving broadly and reranking cheaply, then generating narrowly, gives better accuracy than dumping twenty passages into a frontier model’s context — and costs a fraction as much.
Teams spend weeks comparing vector databases and an afternoon on chunking. The weighting should be reversed. Any competent vector store will serve a mid-size corpus adequately; a bad chunking strategy caps your accuracy regardless of what is underneath.
The failure mode is splitting on a fixed token count. It cuts tables in half, separates a clause from the heading that scopes it, and produces passages that are meaningless out of context. What works better:
A system that always produces an answer is a system that invents one when the corpus is silent. For any use case where the answer has consequences, “this is not covered in the documents I have access to” is the correct output, and it needs to be treated as a scored behaviour in the evaluation set rather than as an embarrassing edge case.
This is usually the point where a compliance or clinical reviewer decides whether to approve the tool. A system that cites its sources and admits its gaps is auditable. One that answers everything fluently is not, no matter how high its average accuracy looks.
Next Step
A 30-minute technical call with an engineer who has shipped this before — not a sales qualification round. You leave with a feasibility read, a rough shape for the build, and an honest answer about whether it is worth doing at all.