--- title: RAG System Development & Consulting source: https://rubradigital.com/services/rag-system-development site: Rubra Digital description: Design and delivery of retrieval-augmented generation systems over your own documents, data and knowledge bases, with evaluation built in from day one. updated: 2026-07-14 duration: 8–14 weeks starting_price: from €65,000 team: Two engineers plus a fractional architect --- # RAG System Development & Consulting **Summary:** Rubra builds production retrieval-augmented generation systems: document ingestion and parsing, chunking and embedding strategy, hybrid retrieval with reranking, grounded generation, and an evaluation harness that proves accuracy before launch. Typical engagements run 8–14 weeks and deliver a system your own engineers can operate. Most retrieval-augmented generation projects do not fail at the model. They fail at the boring parts: a PDF parser that silently drops tables, a chunking strategy that splits a clause from its heading, an index that returns plausible-looking passages that do not actually contain the answer. I build the boring parts properly. ## What I actually do ### Start with the corpus, not the model The first week is spent on your documents. I measure what your corpus really looks like: how many documents are scanned rather than digital, how much of the meaning lives in tables, and how often a single answer requires stitching two documents together. Those facts determine the architecture far more than the choice of model does. ### Build a labelled evaluation set before writing retrieval code I sit with your subject-matter experts and assemble a set of real questions with known-correct source passages. It is unglamorous work and it is the single most valuable thing in the project: without it, every subsequent decision is guesswork, and every "this feels better" is unfalsifiable. ### Tune retrieval against that set Chunk size, overlap strategy, embedding model, hybrid weighting between semantic and keyword search, reranking, metadata filters. Each of these is an experiment with a number attached. I typically run thirty to sixty configurations and report recall@k and mean reciprocal rank for each, so the final architecture is a decision you can audit rather than a preference you have to trust. ### Constrain generation and measure groundedness The generation layer cites the passages it used and declines to answer when the retrieved context does not support one. Refusal behaviour is a feature, and in regulated settings it is often the most important one. I measure groundedness and citation accuracy on every build. ### Hand it over properly You get the evaluation harness, the architecture decision records explaining why each choice was made, a runbook for the failure modes I found, and working sessions with your engineers. The goal is that the next change to the system is made by your team, not by me. ## Where this pays back Retrieval works best where the answer already exists in writing but is expensive to find: regulatory and policy libraries, technical documentation and service manuals, contract portfolios, historical support tickets, clinical or research literature, and internal knowledge that currently lives with three people who are always busy. It works poorly where the answer requires calculation, judgement under uncertainty, or data that was never written down. I will tell you which one you have during discovery, before you have spent a budget finding out. ## What you get - Document ingestion and parsing pipeline (PDF, Office, HTML, scanned assets) - Chunking, embedding and index strategy benchmarked against your corpus - Hybrid retrieval with reranking, tuned on a labelled evaluation set - Grounded generation layer with citations and refusal behaviour - Evaluation harness wired into CI, with regression gates - Runbook, architecture decision records and handover sessions ## Outcomes - Answers grounded in your own documents, with a citation for every claim - Measured retrieval accuracy instead of demo-day impressions - A system your team can extend without calling me back ## Frequently asked questions ### How long does it take to build a production RAG system? A focused production system over a single well-defined corpus typically takes 8 to 14 weeks. Roughly a third of that is document parsing and data preparation, a third is retrieval tuning and evaluation, and a third is the application layer, hardening and handover. Prototypes are much faster, at two to three weeks, but a prototype is not a production system, and the gap between the two is where most internal projects stall. ### What does a RAG project cost? My RAG engagements start at €65,000 for a single-corpus production build and typically land between €80,000 and €180,000 depending on document complexity, the number of source systems, and whether the system serves internal staff or external customers. Ongoing running costs are usually far smaller than clients expect: for most internal deployments, inference and infrastructure come to between €500 and €4,000 per month. ### Do we need a vector database? Not always. If your corpus is under roughly 100,000 chunks and you already run PostgreSQL, pgvector is usually the right answer and removes a system from your stack. Dedicated vector databases earn their place when you need very large scale, complex metadata filtering, or sub-50ms retrieval at high concurrency. I benchmark both against your actual corpus before recommending either. ### Can you work with our existing data platform? Yes, and I prefer to. I build on top of what you already run, whether that is Snowflake, Databricks, PostgreSQL, SharePoint, Confluence, S3 or Elasticsearch, rather than proposing a parallel stack. Introducing new infrastructure into a project that is already carrying model risk is a good way to make both harder. ### How do you stop the system inventing answers? Three mechanisms, all measured rather than assumed. Retrieval quality comes first, because most hallucinations are actually retrieval failures. Then the generation layer is constrained to cite retrieved passages and to refuse when the retrieved context does not support an answer. Finally, a groundedness evaluation runs against a labelled set on every change, so a regression is caught in CI rather than by a user. --- Source: https://rubradigital.com/services/rag-system-development Rubra Digital. Independent LLM and RAG consulting for regulated and document-heavy organisations in Europe and North America. Contact: hello@rubradigital.com