RAG Development: Process, Team and Timeline

What is RAG development?

RAG stands for retrieval-augmented generation. In software development it is an architecture pattern: when a user asks something, the application first searches a knowledge source for relevant content, then gives that content to a language model together with the question. The model answers from what it was handed, not from memory. That is how an assistant can answer from last week's policy update or a customer's contract without anyone retraining a model. If the concept is new to you, start with what RAG is in AI.

RAG development is everything needed to make that pattern work on your data for your users. It splits into six workstreams, and only one of them is about the model:

• Ingestion. Pulling content out of source systems, parsing it, splitting it into passages and keeping the index in sync when documents change or are deleted.
• Retrieval. Finding the right passages for a question. This is where most of the quality is won or lost.
• Generation. The prompt and the model that turn passages into an answer with citations, and that decline when the passages do not contain one.
• Access control. Making sure a user only gets answers built from content that user may open.
• Application. The interface, sign-in, integrations, feedback and admin tools.
• Evaluation and operations. A test set, quality metrics, monitoring and a routine for keeping the system correct over time.

This article is about the project. For the components and how they connect, see our RAG architecture guide. For budgets, see RAG development cost.

The RAG development process in nine phases

The order matters. Teams that start with the chat interface and a vector database usually come back to phases one and two later, after they have spent the budget meant for tuning. Each phase below ends with a deliverable you can review without reading code.

1. Data audit and scopeList the sources, formats, volumes, owners and update frequency. Open a sample of real documents and look for scans, tables, duplicates and outdated versions. Pick one use case and one user group. Output: a source inventory, a list of data problems and a written scope with the errors you cannot accept.
2. Test setCollect 50 to 200 real questions with the expected answer and the document that contains it. Include questions the system should refuse because the answer is not in the data. Domain experts write these, not engineers. Output: a versioned test set and the metrics you will track: whether the right passage was retrieved, whether the answer is correct, whether it is supported by the cited source.
3. Baseline pipelineBuild the simplest version end to end on a sample: basic parsing, fixed-size chunks, one embedding model, plain vector search, one prompt. Run the test set. Output: a first score and a breakdown of failures by cause, which tells you where to spend the next weeks.
4. Retrieval tuningFix the failures the baseline exposed. Typical moves: split documents by their structure instead of by length, attach metadata such as date and document type, combine keyword and vector search, add a reranking step, rewrite vague questions before searching, handle tables and scanned pages properly. Change one thing at a time and rerun the test set. Output: a retrieval configuration that meets the target, with the measurements behind each choice.
5. Answer step and citationsWrite the prompt so the model answers only from the retrieved passages, cites them and says so when they are not enough. Compare two or three models on quality, cost per answer and response time. Output: a prompt and model choice, a refusal behavior and an answer format with clickable sources.
6. PermissionsCarry access rights from each source system into the index and filter by them at query time, before anything reaches the prompt. Make deletions and permission changes propagate. For a multi-tenant product, isolate tenants at the index level. Output: an access model and tests that prove a user cannot get an answer from a document they cannot open.
7. Application and integrationsBuild what users touch: the chat or search interface, single sign-on, connectors with scheduled or event-driven sync, feedback buttons, an admin view of sources and failed documents, an API if other systems call it. This runs in parallel with phases four to six. Output: a usable application on the full data set.
8. LaunchStart with a pilot group. Test load, test prompt injection through documents and questions, set usage limits, add the test set to the release pipeline so a lower score blocks a release. Output: a production system with monitoring, a runbook and a known cost per answer.
9. OperationsReview a sample of real conversations every week, turn failures into new test cases, watch index freshness and cost, and rerun the test set before any change of model, prompt or parser. Output: a quality report on a fixed schedule and a named owner. This phase does not end.

Phases two and three are the cheapest insurance in the project. Our RAG evaluation guide covers how to build the test set and which metrics to use, and RAG hallucinations explains the failure types you will be sorting in the baseline phase.

A realistic RAG development timeline

The figures here are planning estimates, not measured results from specific projects. They assume one use case, two to four source systems, tens of thousands of documents at most, hosted models, a core team of three to five people (some of them part-time) and a business side that answers questions within a day or two. Change any of these and the ranges move.

Phase by phase, with the factor that most often stretches each one:

The ranges overlap in the calendar, so do not add them up. Two things are worth knowing before you commit to a date. First, the schedule is set by the data, and you learn the state of the data in phase one, so treat any date given before the audit as a guess. Second, retrieval tuning has diminishing returns. Agree on the target score before it starts, or it will absorb every spare week.

RAG development team: who you need

A first version does not need a research team. It needs engineers who are careful about measurement and people from the business who know what a correct answer looks like.

The role teams most often leave out is the domain expert. Engineers can tell whether an answer is fluent. Only someone who does the job can tell whether it is right, and whether the cited document is the current one. If the business cannot commit those hours, the project will ship something nobody trusts.

The second gap is ownership after launch. Decide in the first month who reads the weekly quality sample and who can approve a change to the index or the prompt. In small teams this is the AI engineer plus the product owner.

Build, buy or outsource

There are three ways to get a RAG system, and many companies combine them: a bought platform for general internal search, a custom build for the use case that is part of the product.

Three rules decide most cases:

• Try buying first for internal, generic use. If employees need to search wikis, tickets and shared drives, test a platform on your own test set before you plan a build. Our lists of enterprise RAG platforms and RAG as a service providers are a starting point.
• Build custom when the answers are the product. If customers pay for the quality of those answers, or the data has structure a generic platform handles badly, you need control over every step of retrieval.
• Whatever you choose, own the test set. It is the only asset that lets you compare a platform against a custom build, check a vendor's work or switch models later. Keep it in your repository.

If you outsource, ask for the code and infrastructure in your accounts from day one, a failure analysis after the baseline phase and documentation of every tuning decision. Our list of RAG development companies covers vendors that do this work.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

5.0 ★on Clutch

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→E-commerce · AITaking an AI-built e-commerce SEO platform to production→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Why RAG projects stall between demo and production

A demo proves the pattern works on questions the team picked. Production is a different test. These are the common reasons the gap does not close:

• No test set, so no definition of done. Quality is judged by whoever tried it last. Every stakeholder finds a different bad answer, and the team tunes in circles. A fixed test set with a target score ends the argument.
• The demo ran on clean documents. The full corpus has scans, spreadsheets, three versions of the same policy and pages where the key fact sits in a table. Retrieval that scored well on fifty tidy PDFs drops on the real set. The data audit exists to find this before the plan is fixed.
• Permissions were left for later. Adding access control after the index is designed often means re-indexing and reworking the retrieval queries. Security review then blocks the launch, correctly.
• Ingestion is a one-time script. The demo loaded documents once. Production needs updates and deletions to reach the index within an agreed time, and a report of documents that failed to parse. Stale answers destroy trust faster than missing ones.
• The system answers when it should decline. Without a tested refusal path, questions outside the data get confident answers. Users notice once and stop relying on it.
• Latency and cost were never budgeted. Reranking, query rewriting and a large model each add time and spend. A pipeline tuned only for quality can take too long per answer for a chat interface. Set both budgets in phase one and measure them with every test run.
• Nobody owns it after launch. Content changes, the model provider retires a version, a new document type appears. Without a weekly review and a named owner, quality decays quietly.
• The scope grew before the first use case worked. Adding sources and user groups multiplies the data problems and the permission rules. Get one use case to the target, then expand.

RAG project readiness checklist

Tick what is already true. It shows whether you are ready to start the build or still have groundwork to do.

FAQ

Where Gilzor fits

Gilzor builds custom RAG systems, applications and chatbots, adds RAG to existing products, and consults on and evaluates RAG systems. If the plan in this guide is one you want to run with an outside team, our RAG development services cover the phases above, and a 2-week fixed-price Discovery Sprint is a way to scope the project before you commit to the full build. Our AI work so far includes an AI payroll platform that extracts data from PDFs and cut salary calculation errors by 17%, and QLode, an AI fashion commerce product with image and text search. We have launched 70+ products, and 85% of clients come back. The team works from Poland, with a partial overlap with the US working day.

Tell us the use case, the sources and who will use the answers. We'll help you turn that into phases, a team and a timeline with the assumptions written down.