Almost every quote you'll get for a retrieval-augmented generation project is either a shrug or a suspiciously precise number pulled out of thin air. The truth is that RAG development cost has very little to do with the model you plug in at the end and almost everything to do with the state of the documents you're pointing it at. A clean, well-structured knowledge base is a weekend. A folder of scanned PDFs, contradictory versions, and tribal knowledge that lives in three people's heads is a quarter.
So instead of a single price, here's how the number actually gets built, what pushes it up, and roughly where the tiers land. Duskel prices RAG projects from $2k for a scoped build, with ongoing tuning and expansion running from $3k a month. Here's what decides where you sit in that range.
What you're actually paying for
A RAG system has four cost centers, and the model API is the cheapest of them. First, ingestion: getting your documents into a form the system can search. Second, retrieval quality: chunking, embedding, reranking, and the hybrid keyword search that stops it from fumbling error codes and product names. Third, the guardrails that let it refuse instead of inventing an answer. Fourth, evaluation: the test set and scoring harness that tells you whether it's actually right, because 'it looked good in the demo' is not a quality bar you can ship on.
Most of the engineering time goes into the middle two. Anyone can stuff the top three chunks into a prompt. Making the right chunk land in the top results, every time, across the weird questions real users ask, is the work. Skip it and you've paid for a system that confidently lies, which is worse than no system at all.
The cost tiers, honestly
Simple: a single, tidy source of truth. A help center, a product manual, a set of clean markdown docs. The structure is already there, the volume is manageable, and the questions are predictable. This is the from-$2k end. A few weeks of work gets you accurate retrieval, citations, and a system that says 'I don't know' when it should.
Mid: multiple sources that don't agree, mixed formats, and access rules. Now you're deduplicating, reconciling versions, tracking which document is authoritative, and filtering results by who's allowed to see what. Add metadata design, permission-aware retrieval, and a real evaluation set. This is where most business RAG projects land, and it's a monthly engagement rather than a fixed sprint because the corpus keeps moving.
Complex: high-stakes output, large or messy corpora, or answers that feed downstream automation. Legal, medical, financial, or anything where a wrong answer has a price tag. You need calibrated confidence thresholds, citation verification, human review loops, and regression tests that run on every change. This is ongoing retainer territory, and the cost reflects the fact that being wrong is expensive.
The hidden line items nobody quotes
Data cleanup is the big one. If your documents are inconsistent, out of date, or locked in formats that don't parse cleanly, someone has to fix that before retrieval means anything. Budget for it, because it's usually the single largest chunk of a first RAG build and it's the part vendors quietly leave out of the flattering quote.
Then there's ongoing cost, which people forget entirely. Your documents change. New products, new policies, retired features. A RAG system is not a thing you build once; it's a thing you keep accurate. Re-indexing, re-evaluating, and expanding coverage is why the retainer exists. The infrastructure itself — vector storage, embedding calls, model tokens — is real but usually the smallest number on the page, often tens to low hundreds of dollars a month at typical business volume.
Where teams overspend
The most common way to waste money on RAG is to reach for a fine-tuned or custom model before fixing retrieval. It's expensive, it's slow, and it fixes the half of the system that was rarely broken. Nine times out of ten the model was fine and the chunks were garbage. Fix retrieval first; it's cheaper and it's the actual problem.
The second is over-engineering the corpus you don't have yet. Building for a million documents when you have four thousand means paying for infrastructure and complexity that earns nothing for a year. Start at the tier your data is actually at, prove it works, and grow the system when the corpus grows.