What to put in a RAG development services RFP
What should a RAG development services RFP include?
A RAG development services RFP should include four things bidders cannot guess: a described corpus, a golden question set, numeric acceptance thresholds for retrieval and grounding, and the permission model answers must respect. Add ownership terms and an exit clause and the bids become comparable.
A RAG development services RFP should include four things bidders cannot guess: a described corpus, a golden question set, numeric acceptance thresholds for retrieval and grounding, and the permission model your answers must respect. Add commercial shape, ownership terms and an exit clause, and the bids become comparable.
Most RFPs for retrieval work fail before a single response arrives, because the document asks vendors to price a system whose hardest variables are undisclosed. This article gives you the fact pack to attach, the deliverables to demand back, the thresholds worth writing into the contract, and the point at which an RFP is the wrong instrument altogether.
The three facts every bidder is currently guessing at
Retrieval-augmented generation is a system that answers a question by first fetching the relevant passages from your own content and then asking a language model to write an answer grounded in those passages. The build cost is driven almost entirely by the shape of your content, not by the model. Three facts decide the price, and a typical RFP omits all three.
The first is the corpus. Ten thousand clean Confluence pages and ten thousand scanned contract PDFs are different projects by a factor of three. The second is the question distribution: policy lookups behave nothing like comparative questions that need evidence from four documents at once. The third is access control. If every answer must respect who is allowed to see what, the retrieval layer needs filters, and the effort is real. We cover that layer in permission-aware retrieval.
Bidders who do not know these things do one of two things: they pad heavily, or they quote low and raise a change request in week five. Neither gives you a comparable field.
There is a fourth fact worth stating even though it rarely appears in a requirement document: what happens when the system does not know. A retrieval system that answers every question confidently is a liability in a regulated business and an embarrassment in a customer-facing one. Say in the RFP whether you want refusal with a hand-off, refusal with a suggested contact, or a best-effort answer carrying a confidence marker. That single sentence changes the interface, the prompt design and the evaluation set.
The corpus fact pack you attach to the RFP
Attach a one-page annexe with the facts below. It is the single highest-leverage thing you can do to make quotes converge, and it takes an afternoon.
| Fact you disclose | Example value | Why it changes the price |
|---|---|---|
| Document count and total size | 18,000 files, 40 GB | Sets indexing, storage and embedding cost |
| Formats and how they were produced | 60% PDF from scans, 30% Word, 10% wiki | Scanned material needs OCR and layout parsing |
| Systems the content lives in | SharePoint, Zendesk, a Postgres table | Each connector is discrete engineering work |
| Update frequency | 400 documents change per week | Decides re-indexing design and running cost |
| Access model | Role-based, 14 roles, 3 confidential tiers | Adds filtered retrieval and audit requirements |
| Languages | English and Hindi, some mixed | Affects embedding choice and eval design |
| Expected query volume | 3,000 questions per month | Drives inference budget and caching strategy |
| Residency constraint | Data must stay in India | Restricts hosting and model options |
You do not need perfect numbers. An honest estimate with a stated tolerance is enough, and it tells bidders you have looked at the problem.
What should a RAG RFP ask bidders to return?
Ask for artefacts, not adjectives. A proposal that promises accuracy is worth less than one that shows how accuracy will be measured. Require each bidder to return the following, and score them on it.
- A retrieval design, in one page. Chunking approach, embedding model, whether they use hybrid keyword and vector search, and what reranking they propose.
- An evaluation plan. How they will build the golden question set, who writes the reference answers, and which metrics they will report weekly.
- A named integration list. Every source system, the authentication method for each, and who owns credentials.
- A running-cost model. Tokens per answer, monthly inference estimate at your query volume, and the re-indexing cost as content churns.
- Two reference architectures they have shipped, with the eval numbers they reached and what they did when a number failed.
- A staffing plan with named roles, including how much time your own people must give and in which weeks.
- An exit package definition. What you receive on day one after termination: code, prompts, index configuration, evaluation harness and documentation.
The acceptance criteria that make a quote hold
This is the section that separates a real RFP from a wish list. Write numeric thresholds and say plainly that the system is accepted when they are met on a held-out question set the vendor has not seen.
Four numbers carry most of the weight: retrieval recall at the top ten passages, the proportion of answers whose every claim is traceable to a retrieved passage, the proportion of unanswerable questions the system correctly refuses, and the ninety-fifth percentile latency. The open-source evaluation framework Ragas defines these retrieval and faithfulness metrics in a way both sides can implement identically, which removes an entire category of argument at acceptance. How the metrics behave in practice is explained in how to measure RAG quality.
Set the thresholds where your business actually needs them, not where they sound impressive. For an internal policy assistant, a high refusal rate on out-of-scope questions matters more than a marginal recall gain. For a customer-facing search feature, latency is a product requirement, not a nice-to-have.
Say who owns the held-out set. The cleanest arrangement is that your team writes the questions and reference answers with the vendor advising on format, and that thirty per cent of them are withheld until acceptance week. Vendors who object to a held-out set are telling you something useful about how they intend to hit the numbers.
What the commercial section should say
State the shape you want rather than asking vendors to invent one. Fixed price against a locked scope makes bids comparable; time and materials makes them theatre. Ask for the build, the first three months of support and the expected monthly running cost as three separate lines.
Give bidders a budget band. Serious vendors will tell you whether your scope fits it. Our own retrieval and knowledge engineering programmes run from $14,000 or ₹8.8 lakh for a single well-defined corpus with one or two connectors, to $49,000 or ₹32 lakh for multi-source retrieval with permission filtering, citations in the interface and an evaluation harness your team can run. Every starting figure is published on the pricing page, and what does a RAG system cost breaks down where the money goes.
Two clauses are worth more than any discount. The first is ownership: code, prompts, index configuration and evaluation data are yours, which is the position argued in who owns the code, prompts and models. The second is that model API usage runs through your own provider accounts, so you see the bill directly rather than through a markup.
When an RFP is the wrong instrument
If you cannot yet describe the corpus or name the twenty questions the system must answer, an RFP will produce guesses dressed as quotes. Run a short paid discovery instead and issue the RFP afterwards with real inputs. A ten-day discovery sprint at $3,250 or ₹2,00,000, credited to the build, produces the corpus audit, the question set and the thresholds, which then become the RFP itself.
An RFP is also the wrong instrument when the hard question is feasibility rather than vendor choice. If nobody knows whether retrieval over your scanned archive can hit a usable accuracy at all, buy the answer. A three-week ProofRun from $6,250 or ₹4,00,000 tests the worst subset of your content against the thresholds, and you either issue the RFP with confidence or stop spending.
Finally, if the scope is a single team, a single source and a few hundred documents, the procurement overhead can exceed the build. Buy a product and move on.
A worked example of a fact pack changing the bids
An NBFC we worked with had scanned identity and income documents in multiple regional formats. The first version of their requirement said only that the system should read documents accurately. When they added page counts, a scan-quality sample, the field list they needed extracted and a hard rule that nothing could leave their infrastructure, the quotes they received moved from a fourfold spread to a narrow one, because every bidder was pricing the same problem. That programme is described in the KYC document intelligence case study.
The lesson generalises. Every fact you withhold is priced as risk by the bidder, and risk is more expensive than work. Disclosing that forty per cent of your archive is poorly scanned costs you nothing in negotiation and saves you a change request that would have arrived anyway, with less goodwill attached to it.
A final pass before you issue
- Confirm the corpus annexe is attached and its numbers are honest
- Check that every acceptance criterion has a number and a measurement method
- Name the person on your side who owns content quality and access mapping
- State the residency and hosting constraint explicitly, not as a preference
- Ask for running cost separately from build cost
- Include the exit package clause and the ownership clause
- Set a question window so bidders can challenge your assumptions before pricing
Related reading
RAG development services cost in 2026 sets a realistic budget band, why basic RAG fails in production explains the failure modes your acceptance criteria are defending against, and what a fixed-price AI quote should contain covers the commercial section in more depth.
An RFP that discloses the corpus and states its thresholds gets comparable bids; one that does not gets creative writing.
Frequently asked questions
What should a RAG development services RFP include?
▾
It should include a corpus description, the question types the system must handle, numeric acceptance thresholds for retrieval and grounding, the permission model, integration list, residency constraints, the commercial shape you want, ownership terms and an exit package definition. Without the corpus facts, bids are not comparable.
How long should vendors get to respond to a RAG RFP?
▾
Three weeks is usually right. Serious bidders need time to review the corpus annexe, ask questions and model running costs. Anything shorter favours vendors who reuse a template, and anything longer tends to lose the internal momentum that made you issue the document in the first place.
Should the RFP name a specific vector database or model?
▾
No. Name your constraints instead: residency, latency, budget and whether self-hosting is required. Let bidders justify their retrieval stack against your acceptance criteria. Prescribing a vector database in the RFP narrows the field for no benefit and hides the reasoning you actually want to evaluate.