RAG Development Services
RAG development services for answers that can show their work.
RAG connects an AI response to the private documents and records it should use. The difficult part is not adding a vector database. It is preserving source identity, retrieving the right evidence, respecting access, and knowing when the evidence is not enough. We build and repair that complete path.
Bring one repeated question and the sources that should answer it. Leave with a use search, configure, prove, build, repair, or stop recommendation.
The brief
Start with what is not working.
Good software decisions begin with the constraint, not a list of features or a preferred technology.
A RAG prototype answers the clean examples but fails on scans, tables, old versions, exact identifiers, or the questions real users ask.
When an answer is wrong, nobody can tell whether the source, parsing, retrieval, access rule, prompt, or model caused it.
Plain answer
Retrieval-augmented generation, or RAG, finds relevant evidence in approved sources before a language model writes an answer. A production RAG system also needs dependable parsing, source metadata, permission-aware retrieval, citations, refusal rules, separate retrieval and answer evaluation, monitoring, and an owner for changes. Every RaftLabs project starts at $10000 with a bounded first phase and written acceptance criteria.
What to remember
- Use RAG when an answer must draw from private or changing sources and the user needs to inspect the evidence.
- Evaluate retrieval separately from the final response so a failure can be traced to the source, parser, index, ranking, prompt, or model.
- Start with one audience, one question class, and a representative evaluation set before adding more sources or users.
RAG is one answer, not the starting assumption.
Choose the smallest system that can return a useful result without creating an operating burden the team does not need.
| Scenario | Recommendation | Reason |
|---|---|---|
| The relevant material is small and supplied with each request | Use direct model context | Avoid an index and retrieval layer when the application already has the complete permitted evidence. |
| People need to inspect several source items themselves | Improve search | Return ranked documents or passages when a generated synthesis would remove useful context or add risk. |
| A managed knowledge product fits the sources and access model | Configure it | Buy the maintained connectors, administration, and operations when the compromises are acceptable. |
| Answers must use private or changing sources and show evidence | Build RAG | Own the retrieval and answer path when product, data, identity, or evaluation requirements are specialised. |
| A prototype works sometimes but nobody can explain the misses | Audit and repair | Trace the failure before replacing the model, vector database, or entire application. |
Fit
RAG earns its cost when the evidence changes the answer.
The first release needs a repeated question, approved sources, a named audience, and people who can judge whether the evidence and response are useful.
Employees or customers repeatedly ask questions answered by private documents, records, tickets, policies, or product material.
The answer changes as sources, versions, accounts, products, or permissions change, and users need to inspect where it came from.
A wrong, unsupported, stale, or cross-permission answer creates measurable rework, delay, repeat contact, or decision risk.
The answer is a deterministic database lookup, calculation, or rule that conventional software can return more reliably.
The source material is contradictory or unowned and nobody can decide which version should govern.
The goal is to add RAG because it is expected in an AI product, without a question, user, baseline, or consequence attached.
If search, clearer content, or a managed platform is the better answer, the first call should make that visible before custom development begins.
A citation can make the wrong answer look safer.
A support assistant is asked whether a customer can cancel without a fee. The search layer finds a policy that contains the exact phrase. The model writes a clear response and links to the paragraph it used.
The citation is real. The answer is still wrong. That policy expired, the current contract overrides it for this account, and the newer document was parsed without its table headings. The system retrieved plausible words without retrieving the governing evidence.
Production RAG has to preserve more than text. It needs source identity, version, status, date, section structure, account context, access rules, and a way to say that the available evidence conflicts or is incomplete. A source link helps someone inspect an answer. It does not make the answer correct by itself.
RAG, search, direct context, or fine-tuning?
| Approach | Use it when | What the user receives | Main risk |
|---|---|---|---|
| Direct context | The necessary evidence is small and already available at request time | An answer from the supplied material | Requests become too large or omit important context |
| Search | People should inspect and choose among source items | Ranked documents, records, or passages | Relevant concepts or exact identifiers are missed |
| RAG | A response must use a larger private or changing source set and show evidence | A generated answer with source links, refusal, or escalation | Weak retrieval becomes a confident response |
| Fine-tuning | The goal is to change behaviour, style, format, or narrow task performance | Model behaviour learned from examples | Training examples are mistaken for an updatable factual source |
Scope
What a production RAG system needs around the language model
The model writes the response. The surrounding system decides what it may see, which evidence reaches it, how the answer is checked, and what happens when the evidence is not good enough.
- 01
Source intake that preserves meaning
Connect the approved files, pages, records, tickets, or APIs and test what actually arrives. Scans may need OCR. Tables need their headers and units. Structured records may need a validated query rather than being flattened into document chunks. - 02
An index that can be updated and undone
Store the text together with stable source IDs, links, sections, versions, dates, status, ownership, audience, and access metadata. Define how a changed, superseded, failed, or deleted source reaches the index. Keep retrieval inside the existing platform when it meets the evidence and operating tests; add a dedicated vector database only when the workload justifies another system to synchronise and own. - 03
Retrieval tuned on the questions people ask
Compare exact-term, semantic, filtered, hybrid, and reranked retrieval against representative questions. Product codes, names, dates, and policy clauses behave differently from conceptual questions, so one search method should not win by assumption. - 04
Access checks before model context
Map the signed-in user, tenant, role, or account to the source permissions available at query time. Remove unauthorised candidates before their content reaches the model and test changed, mixed, and revoked access explicitly. - 05
Answers that cite, clarify, refuse, or escalate
Assemble only the permitted evidence needed for the question. Show inspectable source links, ask for missing context, disclose conflicts, and route the case to a person when the evidence cannot support a safe answer. - 06
Evaluation and operation after release
Retain the question set, expected evidence, scoring, failures, model and retrieval configuration, latency, cost, source-sync health, feedback, corrections, release history, and rollback path. A system that cannot be inspected cannot be improved safely.
The source format decides more than the embedding model.
A clean help-centre article is straightforward to index. A scanned contract with footnotes, a product manual with diagrams, a spreadsheet with merged headers, and a database record joined across three systems are not the same retrieval problem.
For documents, the first question is whether parsing preserved the section, table, date, identifier, and relationship that made the passage meaningful. For structured data, the safer answer may come from a constrained database query followed by a plain-language explanation. For several repositories, the system may need to retrieve separately, preserve each source's access policy, and resolve which source is authoritative before generating anything.
This is why we test representative formats and questions before settling the architecture. Changing chunk size or embeddings cannot recover a table heading that was discarded during extraction, and a larger context window cannot repair an access rule that was never applied.
From demo to service
A production release has to survive the cases the demonstration avoided.
The useful change is not a more polished chat box. It is an evidence path the team can test, operate, and correct.
- Hand-picked documentsClean files and known questions make the first answers look stronger than the real source collection.
- One user sees everythingThe demo avoids role, account, tenant, and revoked-access cases.
- A good answer is successNobody records which evidence should have been found or why a plausible response is wrong.
- The index is refreshed manuallyUpdates, deletions, parse failures, model changes, cost, and rollback have no operating owner.
- Representative source familiesScans, tables, versions, exact identifiers, conflicts, and unsupported questions enter the test set.
- Permission-aware retrievalAllowed, denied, mixed, changed, and revoked access are tested before content reaches the model.
- Retrieval and answer scoresThe team can see whether the right evidence was found and whether the response stayed inside it.
- A maintained release pathSync, evaluation, monitoring, feedback, incidents, provider changes, and handover have named owners.
How it works
Close one retrieval risk before opening the next.
Each phase produces a decision the buyer can inspect. More sources and users are added only after the smaller boundary works on representative evidence.
- 01Understand
Define the answer and its evidence
Which repeated question is worth answering, and what evidence should support it?
Follow the question from the person asking it to the documents, records, systems, and people used today. Include the ambiguity, exception, and unavailable evidence that a clean brief usually leaves out.
Decision produced
One audience, question class, current path, approved sources, expected evidence, access rules, baseline, consequence, and owner.Risk closed
Building a general knowledge chatbot before anyone has defined the decision, source, or user it must serve. - 02Retrieve
Prove parsing and retrieval
Can the system find the governing evidence across the real formats and access boundaries?
Test the simplest credible parsing and retrieval approaches. Compare candidates only where the question set shows a real trade-off, and fix missing evidence before judging the wording of an answer.
Decision produced
A prepared source set, working index, permission model, representative evaluation, retrieval baseline, failure record, and architecture direction.Risk closed
Adding generation while damaged parsing, missing metadata, exact-term misses, stale versions, or cross-role retrieval remain hidden. - 03Answer
Add grounded answers and safe failure
Does the response use the retrieved evidence correctly and stop when the support is weak?
Test the generated response separately from retrieval. Include incomplete questions, conflicting sources, indirect prompt injection, missing evidence, provider failure, and the cases where a human must decide.
Decision produced
A working answer path with citations, clarification, conflict handling, refusal, escalation, latency, cost, and acceptance results.Risk closed
Treating a fluent response or a visible citation as proof that the conclusion is supported, current, and allowed for that user. - 04Operate
Release an operable boundary
Can the team keep the answer path current after users and sources begin to change?
Release to a bounded group. Review misses and corrections, rerun evaluation before material changes, and add another source or audience only when the first boundary remains understandable.
Decision produced
A controlled release, source-sync and quality signals, correction and incident paths, operating owners, documentation, rollback, and an evidence-based expansion gate.Risk closed
Launching a successful snapshot that quietly degrades as sources, permissions, models, questions, and usage move.
Diagnosis
A wrong RAG answer has more than one possible cause.
- Source
- The governing information is missing, outdated, duplicated, conflicting, inaccessible, or never recorded in a form the system can use.
- Parsing
- Text was extracted, but the table, heading, page, relationship, date, layout, image, or identifier that gave it meaning was lost.
- Retrieval
- The index contains the evidence, but query handling, filters, exact-term search, semantic matching, result depth, or reranking failed to return it.
- Access
- The right passage exists but is unavailable to this user, or an unauthorised passage crossed the boundary before generation.
- Answer
- The model received useful evidence but omitted a condition, combined incompatible sources, made an unsupported inference, or cited the wrong span.
- Operation
- The release worked, then source sync, permissions, evaluation, cost, latency, feedback, model changes, or incident ownership drifted.
Current managed-platform documentation also treats these as separate concerns. Amazon Bedrock distinguishes retrieve-only evaluation from retrieve-and-generate evaluation, with different measures for context, answers, and citations. That is useful as a design principle even when the final system uses another provider. See the Amazon Bedrock RAG evaluation metrics.
What should remain under your control
Put these conditions into the architecture, acceptance criteria, and handover instead of relying on a broad promise that the RAG system is accurate or secure.
- 01
Sources, versions, and parsing rules
Keep the approved repositories, stable IDs, links, owners, formats, parser choices, sections, dates, versions, authority, update events, deletion paths, failures, and reprocessing rules. - 02
Identity and permission tests
Retain the mapping from application users to source access, plus allowed, denied, mixed, changed, tenant-separated, and revoked-access tests. - 03
Questions, expected evidence, and scores
Own the representative queries, expected passages, essential facts, prohibited claims, refusals, reviewer decisions, segment results, and history needed to compare a change. - 04
Accounts, code, data, and providers
Use client-controlled source, identity, cloud, analytics, model, and vector-store accounts where practical. Document what each provider receives, retains, logs, licenses, and controls. - 05
Release, correction, and incident paths
Name who handles failed ingestion, access incidents, bad answers, source conflicts, user feedback, cost, provider changes, rollback, support, and expansion decisions.
Every project starts at $10000.
The first paid phase is deliberately bounded. It should close the most expensive open retrieval question before you commit to a broad source set or production rollout.
The 30-minute search, configure, prove, repair, build, or stop conversation comes first and costs nothing. If RAG adds complexity without improving the result, that can be the recommendation.
What the first phase can be
- 01
RAG failure audit
Trace representative misses through sources, parsing, metadata, permissions, retrieval, reranking, context, prompts, answers, citations, latency, cost, and current operations.
- 02
Question and evidence evaluation
Turn real questions into expected sources, essential facts, exact identifiers, access cases, conflicts, refusals, reviewer decisions, and a reusable retrieval and answer baseline.
- 03
Architecture and managed-service proof
Test whether a maintained knowledge platform, direct context, ordinary search, structured query, or custom RAG path best fits the sources, controls, product, and operating model.
- 04
One production retrieval path
Deliver one audience and question class with prepared sources, live access checks, retrieval, citations, safe failure, interface, evaluation, monitoring, documentation, and handover.
The riskiest unanswered question decides the first phase. Before it begins, you will know what result is included, how it will be judged, what remains outside scope, and what evidence would justify another investment.
Starting investment
$10000
Minimum project scope. The audience, question, sources, formats, permissions, evaluation, ownership, acceptance criteria, exclusions, price, and timing are written down before the phase starts.
Price held for the phase
Client-controlled assets
60-day launch warranty
Choose the next path from what the system must return.
A generated answer, ranked source list, governed knowledge workflow, and managed retrieval service create different product and operating responsibilities.
- 01
Managed RAG as a Service
Use a maintained retrieval service when ongoing ingestion, evaluation, monitoring, and operation are part of the engagement.
- 02
AI Knowledge Management
Improve how knowledge is captured, governed, found, corrected, and maintained across the organisation.
- 03
AI Search and Semantic Search
Return ranked documents, records, or passages when the user should inspect and choose the source rather than receive a generated answer.
- 04
AI Proof of Concept
Test the highest-risk source, retrieval, model, or workflow assumption before committing to a production system.
- 05
RAG versus fine-tuning guide
Compare retrieval, direct context, fine-tuning, and combined approaches before choosing the architecture.
Work with us
Bring one question your current search or RAG prototype cannot answer reliably.
In a 30-minute call, we will help identify whether the next move is ordinary search, a managed platform, a retrieval evaluation, a repair, a custom build, or no RAG at all.
- One audience, one question class, and the smallest source boundary that can answer it.
- Parsing, access, retrieval, citations, refusal, correction, and evaluation defined before expansion.
- Project code, evaluation cases, source accounts, and operating notes remain under client control.
- A 60-day warranty after release for defects in the agreed application scope.
Common questions
Retrieval-augmented generation retrieves relevant evidence from approved sources before a language model answers. It fits when the response must use private or frequently changing information and the user needs citations or source links. It is unnecessary when all required context already fits safely in the request, ordinary search is more useful, or the task is a deterministic lookup or calculation.
No. RAG can give the model better evidence, but the system can still retrieve the wrong passage, miss an important source, use an expired version, misunderstand the evidence, or write an unsupported conclusion. We test retrieval and answer support separately, preserve citations, include no-answer cases, and define when the application should clarify, refuse, or send the question to a person.
Use direct context when the required material is small enough to send with each request. Use RAG when the source set is larger, private, frequently changing, permissioned, or needs citations. Fine-tuning changes model behaviour, style, format, or narrow task performance; it does not provide a dependable way to update factual knowledge or identify the source behind an answer. Some products combine these methods, but each should solve a measured problem.
Configure a managed service when it supports the required sources, document formats, permissions, retrieval controls, evaluation, deployment, commercial model, and exit path. Build a custom layer when the workflow needs specialised parsing, identity rules, structured and unstructured data, product-specific interfaces, unusual retrieval, or operating controls that the managed service cannot provide cleanly. The first phase compares those compromises before recommending a build.
Not always. A smaller or strongly structured source set may work with direct context, PostgreSQL with pgvector, an existing search engine, or a managed knowledge platform. A dedicated vector database has to earn the extra synchronisation, access, backup, monitoring, and migration work by improving retrieval at the required scale. We compare a simple lexical or existing-platform baseline with semantic and hybrid options on representative questions before recommending another data system.
Potentially, but connector availability is only the first check. Each source has different permissions, identifiers, formats, rate limits, update events, deletion behaviour, and authority rules. We inspect the approved interface and representative content before promising coverage. A focused release normally starts with the smallest source group that can answer one valuable class of questions.
Yes, when the source identity and application architecture expose dependable access information. Retrieval must remove unauthorised candidates before their text reaches the model, reflect changed and revoked access, keep tenants or roles separate, and include positive and negative permission tests. Hiding a citation or interface element after generation is not an access control.
They change the ingestion and retrieval design. A scanned PDF may need OCR and layout-aware extraction. Tables need row, header, and unit relationships preserved. Images or diagrams may need multimodal parsing. Database questions may be safer as validated queries than embedded text. We test representative formats early because damaged input can look like an embedding or model problem later.
We build a representative question set with expected sources, essential facts, prohibited claims, access cases, ambiguity, and acceptable refusal or escalation outcomes. Retrieval is scored separately from the final answer. Depending on the workflow, the evaluation may cover context relevance and coverage, answer correctness and faithfulness, citation precision, refusal, latency, cost, and performance across important question groups.
Yes. We trace representative failures through source preparation, parsing, metadata, indexing, permissions, query handling, retrieval, reranking, context assembly, prompting, generation, citations, and monitoring. The result may be a targeted repair, a simpler architecture, a managed platform, or a recommendation to stop. A rebuild is not assumed.
Every RaftLabs project starts at $10000. The first phase may be a retrieval audit, evaluation-set build, architecture proof, prototype repair, or bounded first release. Timing depends on source condition, formats, connectors, permissions, evaluation depth, interface, deployment, volume, and assurance needs. The result, acceptance criteria, exclusions, price, and schedule are agreed before paid work begins.
Project-specific code, prepared data, evaluation cases, configuration, and operating notes remain under client control. Client-controlled cloud, source, identity, analytics, model, and vector-store accounts are used where practical and allowed by provider terms. Third-party services and open-source components retain their own licences. The handover records how the system syncs, evaluates, releases, rolls back, and handles incidents.
We need one owner for the question the system must answer, representative sources and queries, someone authorised to settle source authority, and identity or security input when access differs by user. Subject-matter reviewers judge disputed or high-consequence results. Your team should not need to manage developers daily, but it must own the business rules the software cannot invent.