RAG development: AI answers grounded in your own documents
Retrieval-augmented generation (RAG) lets a language model answer from your documents instead of from memory. Webify.AI builds RAG systems, and you can hire our RAG developers to work inside your team.
Answers with sources
Each answer can point to the documents it came from, so people can check it.
Your data, your rules
Permissions applied at retrieval time, and on-premise options when data must stay inside your network.
From $45 an hour
RAG developers on our AI / LLM engineer rate, starting with a two-week trial.
What is retrieval-augmented generation (RAG)?
Retrieval-augmented generation (RAG) is a way to make a language model answer from your own information. When a question arrives, the system searches your documents, picks the most relevant passages and gives them to the model with the question. The model then writes an answer based on those passages, and can cite them.
Without retrieval, a model answers from what it learned in training. That knowledge stops at a cutoff date and never included your private documents. RAG deals with both problems without retraining the model.
RAG suits questions whose answers already exist somewhere in your content. It is less suited to totals and calculations across thousands of records. A database query does that better.
- A support assistant that answers from your help articles and product manuals.
- An internal search tool that answers staff questions about policies, processes and past projects.
- Contract and document review that finds the relevant clause and quotes it.
- A product assistant that answers questions from your product data and specifications.
- A knowledge layer for an AI agent, so it can look things up before it acts.
What does a RAG developer do?
A RAG developer builds the pipeline that lets a language model answer from your documents. They collect and clean the sources, split them into passages, create embeddings, set up a vector index and tune retrieval. They also write the generation prompt, add citations and access control, and measure answer quality with a test set.
The hard part of RAG is rarely the model. It is the data: scanned PDFs, duplicate versions, tables that lose their structure, and documents some users must not see. A RAG developer spends much of their time there.
When you hire RAG developers, look for these skills:
- Document processing. PDF and Office parsing, OCR for scans, and keeping tables and headings intact.
- Search. Vector search, keyword search and a hybrid of both, plus reranking.
- Embeddings. Choosing an embedding model, and re-indexing when it changes.
- Evaluation. Measuring whether the right passages were found, and whether the answer used them faithfully.
- Back-end engineering. Python or Node.js services, PostgreSQL, ingestion queues, and APIs for your front end.
- Security. Passing user permissions into retrieval, so people only see what they are allowed to see.
RAG developers at Webify.AI work on our AI / LLM engineer rate of $45 an hour. A senior AI engineer at $60 an hour can lead the design when the system is large or sensitive. For model choice and fine-tuning, see LLM engineers.
Our rates
Published prices in US dollars. Monthly plans are 160 hours, about 15% below the hourly rate.
Mid-level developer
3 to 5 years
$25 / hour
$3,400 a month (160 h)
Senior developer
6 or more years
$35 / hour
$4,750 a month (160 h)
AI / LLM engineer
Agents, RAG, IBM watsonx
$45 / hour
$6,100 a month (160 h)
Senior AI engineer
Leads AI architecture and delivery
$60 / hour
$8,150 a month (160 h)
Two-week trial with the developer you choose. No charge if you stop within the first five working days. US Eastern clients get 09:00 to 12:00 US Eastern time through an evening shift, at 15% extra. Full pricing and comparisons.
How is a RAG system built?
A RAG system is built in eight steps, each tested before the next. First define the questions and a test set. Then gather and clean the sources, split them into passages, and embed and index them. Build retrieval, then the answer step with citations. Finally, evaluate, deploy and keep the index fresh.
- 1
Define the questions and a test set
Write down who will ask what, and collect real questions with known correct answers. This test set is how every later step is judged.
- 2
Gather and clean the sources
Connect the document stores, wikis, tickets or databases that hold the answers. Remove duplicates and old versions, and record who may see each document.
- 3
Split documents into passages
Break documents into passages, often called chunks, that each make sense alone. Keep headings, tables and page numbers as metadata for filtering and citations.
- 4
Create embeddings and index them
Turn each passage into an embedding, a list of numbers that captures its meaning. Store it in a vector index with its metadata.
- 5
Build retrieval
Search by meaning and by keyword, filter by permissions and metadata, and rerank the results so the best passages come first.
- 6
Write the answer step
Send the question and the top passages to the model with clear rules. It should answer only from these sources, cite them, and say when the answer is not there.
- 7
Evaluate
Score retrieval and answers against the test set. Fix the weakest step first, then re-run the whole set to check nothing else got worse.
- 8
Deploy, monitor and keep it fresh
Put the system behind an API, log questions and sources, and collect user feedback. Re-index on a schedule, or whenever documents change.
Most quality problems trace back to steps two to five, not to the model. Better retrieval usually helps more than a bigger model.
Which vector database should you use: Pinecone, Weaviate or pgvector?
If you already run PostgreSQL, pgvector is often enough, and it keeps passages, metadata and permissions in one database. Pinecone suits teams that want a fully managed service. Weaviate suits teams that want open source, self-hosting or built-in hybrid search. Test each option with your own data before deciding.
Swipe the table sideways to see every column.
| Option | What it is | Good fit when | Things to weigh |
|---|---|---|---|
| pgvector | An open-source extension that adds vector search to PostgreSQL. | You already use PostgreSQL and want one database for passages, metadata and permissions. | You tune and scale it yourself. Very large indexes need careful planning. |
| Pinecone | A managed vector database offered as a cloud service. | You want no database servers to run, and usage-based pricing suits you. | Your passages are stored with a third party, and cost grows with usage. |
| Weaviate | An open-source vector database, available self-hosted or as a managed cloud service. | You want open source, built-in hybrid search, or the option to self-host. | One more system to run and learn, if you host it yourself. |
| Search engines with vector support | Tools such as Elasticsearch or OpenSearch, which added vector search to keyword search. | You already run one for keyword search. | Vector features and tuning vary by product and version. |
General, educational descriptions. We work with the vector database you already use, or help you choose one by testing on your own data.
Our own stack includes PostgreSQL, so pgvector is a sensible default when you have no existing choice. It is not the right answer for every system.
Other vector databases include Qdrant, Milvus and Chroma. The brand matters less than people expect. Chunking, metadata and evaluation decide answer quality far more than the database does.
Why do RAG systems give wrong answers, and how are they fixed?
Wrong answers usually start in retrieval, not in the model. The right passage was missing, split badly, outranked by a similar one, or hidden by a filter. Sometimes the model ignores good context or answers when it should decline. A test set shows which step failed, so each fix targets the actual cause.
| Symptom | Usual cause | Typical fix |
|---|---|---|
| Says the answer isn't in the documents, but it is | Poor chunking, or an embedding model that handles your terms badly | Re-chunk around headings, add keyword search, and test another embedding model |
| Quotes an old policy | Outdated versions still in the index | Remove replaced documents and store dates as metadata |
| Mixes up two similar products | Similar passages ranked equally | Add metadata filters and a reranking step |
| Adds details that are not in the sources | Loose instructions, or too little relevant context | Require citations, allow "I don't know", and check answers against sources |
| Shows a user something they shouldn't see | Permissions not applied at retrieval time | Filter by the user's access rights before passages reach the model |
| Slow or expensive answers | Too many passages sent with each question | Retrieve fewer, better passages, and cache common questions |
A system that admits it doesn't know is worth more than one that guesses well most of the time. Build the "I don't know" path on purpose, and test it.
How much does RAG implementation cost?
RAG implementation cost depends on your data more than on the model. The number and state of your sources, permission rules, accuracy needs and integrations decide the engineering time. At Webify.AI that time costs $45 an hour for an AI / LLM engineer, or $60 for a senior AI engineer. Running costs go to your providers.
There is no honest fixed price for "a RAG system". These are the things that move the cost up or down.
| Cost driver | Less effort | More effort |
|---|---|---|
| Sources | One clean source, such as a single wiki export | Many systems, each needing its own connector |
| Document formats | Web pages and text documents | Scanned PDFs, complex tables and images that need OCR |
| Permissions | Everyone may see everything | Document-level or row-level rules that retrieval must respect |
| Accuracy bar | An internal tool where a person checks each answer | Customer-facing, regulated or high-stakes answers |
| Freshness | Content changes monthly | Content changes hourly and must be searchable at once |
| Integration | A standalone chat page | Inside your product, your CRM or an AI agent |
| Hosting | A hosted model API and managed services | On-premise or air-gapped deployment |
Running costs sit outside our rates and go to the providers you choose. They include model usage per token, embedding your documents, vector database hosting, and GPU servers if you run an open-weight model yourself.
For engineering, a small pilot with one AI / LLM engineer on an hourly plan of 80 hours costs $3,600 a month. A full-time engineer on the monthly plan costs $6,100 for 160 hours. UK clients pay £36 an hour, which is £288 for an eight-hour day. Every rate is on our pricing page.
How do you keep a RAG system secure?
Apply each user's permissions at retrieval time, so passages they may not see never reach the model. Keep secrets and personal data out of prompts and logs where possible. Choose where the model runs: a hosted API under your account, IBM watsonx, or open-weight models on your own servers.
- Permission-aware retrieval. Store access rules with each passage, and filter on them for every query.
- Untrusted documents. A document can contain text that tries to give the model instructions. Treat retrieved text as data, and limit what the system can do with it.
- Careful logging. Log enough to debug, and remove personal data before logs are stored.
- Deletion. When a document is removed from the source, remove its passages from the index too.
- Where data goes. Know which providers see your text: the model API, the embedding API and the vector database host.
For data that must stay inside your network, Webify.AI builds offline and on-premise LLM systems, with private RAG on open-weight models. As an IBM Partner, we also deploy on IBM watsonx.
Our developers sign your NDA before the first call, and your code never goes into public AI tools. The security page sets out how we handle access, code and data.
Do you still need RAG when models accept long documents?
Often, yes. Long context windows let a model read a few large documents at once, which suits one-off analysis. RAG is still the better fit when your content is large, changes often, needs per-user permissions or must be cited. Sending less text per question also keeps answers faster and cheaper. Many systems use both.
A practical rule: if the whole knowledge base fits comfortably in one request and rarely changes, try long context first. If not, build retrieval. Your RAG developer can test both on your test set and show you the difference in quality and cost.
RAG also gives AI agents a working memory of your business. An agent that checks policy before it acts makes fewer mistakes. See AI agent developers for that side of the work.
What do we need to start a RAG project?
You need three things. First, a sample of the documents the system should answer from. Second, a list of real questions people ask. Third, someone who can judge whether an answer is right. With those, a RAG developer can build a first version and measure it. Production access can come later.
- Documents. An export of, or read access to, a representative set, including the messy ones.
- Questions. Real examples from support tickets, search logs or staff, with the answers you expect.
- An owner. A person who knows the content and can review answers each week.
- Rules. Who may see what, and any data that must not leave your systems.
- A destination. Where the answers will appear, such as your product, an internal tool or an agent.
Hiring a RAG developer works like hiring any Webify.AI engineer. You get two named profiles within 48 hours, interview them, then start a two-week trial. There is no charge if you stop within the first five working days.
Teams adding several AI roles at once can read about AI staff augmentation.
Frequently asked questions
Is RAG better than fine-tuning?
They solve different problems. RAG gives a model facts from your documents at question time. Fine-tuning changes how a model writes or classifies. For answers about your own changing information, start with RAG. Fine-tune later only if tests show a clear gain.
Does the model learn from our documents?
Not in RAG. Documents are retrieved and shown to the model for each question, and the model's weights don't change. Whether a hosted provider keeps the text it receives depends on its terms and your account settings.
What file types can a RAG system use?
Most text-based formats: PDF, Word, HTML, Markdown, spreadsheets, wiki pages, tickets and email. Scanned documents need OCR first. Tables and diagrams need extra care so their meaning survives.
Can a RAG system answer from a database?
Yes, in two ways. Rows can be turned into text passages and indexed. Or the system can write a database query and answer from the result. The second suits numbers and totals, and needs strict, read-only access.
Can answers cite their sources?
Yes, and they should. Each passage keeps its document name, section and link, so the answer can show where each statement came from. Citations let users check answers and help you spot retrieval problems.
How often is the index updated?
As often as your content changes. Some systems re-index nightly. Others update a document within minutes of it changing. Your developer sets this up to match how fresh the answers need to be.
Does RAG work in languages other than English?
Yes, if the embedding model and the language model both handle the language well. Multilingual embedding models exist, but quality varies, so test with real questions in each language you need.
Can a RAG system run on IBM watsonx?
Yes. Webify.AI is an IBM Partner and deploys on IBM watsonx, as well as on open-weight models on your own infrastructure. We also work with the hosted model provider you have already chosen.
Can RAG handle images and diagrams?
Partly. Text inside images can be extracted with OCR, and some models can describe images and charts. Test this on your own documents, because accuracy varies with layout and scan quality.
Can a RAG developer join our existing team?
Yes. They work as a member of your team, in your repositories and tools. UK teams get 09:00 to 13:00 UK time at no extra cost. US teams get 09:00 to 12:00 Eastern on an evening shift, at 15% extra.
Ask for two RAG developer profiles
Tell us the role and when you need someone. We'll email two named engineers with their experience and availability within 48 hours, and you choose who to interview.
- No cost to receive profiles
- Two-week trial with the developer you choose. No charge if you stop within the first five working days.
- Invoiced in USD or GBP; IP assigned to you.