Prepare the knowledge
Choose authoritative sources, identify owners, extract usable text and resolve duplication. Scanned documents and conflicting versions need particular attention.
RAG development / UK & international
RAG systems.
Knowledge, not guesswork.
Custom RAG systems that help your team find and use the information your business already owns. Not Devs Ltd designs the sources, retrieval, permissions and answer experience—not just the chat window.
01 / WHAT YOUR BUSINESS KNOWS
Handbooks. Contracts. How-to.
Approved filesSource ownersAccess rules
02 / FIND THE RELEVANT EVIDENCE
Search with context.
The right passage. The right permissions.
03 / AN ANSWER YOU CAN CHECKLess “I think”.
↗ Evidence stays one click away
Less “I think”.
More “here’s the source”.
↗ Evidence stays one click awayRetrieval-augmented generation, in plain English
Find the evidence.
Then write the answer.
A RAG application searches an approved collection of information before asking a language model to respond. The retrieved passages give the answer business context; source links let a person check what it is based on.
That can be useful when knowledge lives across manuals, shared files and internal systems. It does not turn incomplete records into facts or make an AI assistant infallible.
Our plain-English guide to business RAG ↗End-to-end RAG engineering
The whole system.
Not a demo in disguise.
Each engagement is scoped to your sources and users. These are the building blocks we work through, from the first import to the day someone updates a policy.
Ingest, index, refresh
Structure passages with metadata and build a searchable index. Define how new versions arrive and how outdated or deleted material is removed.
Retrieve and rank
Combine keyword and semantic search where useful. Test which passages are retrieved and whether they actually contain the answer.
Answer with references
Design prompts, citations and source previews around the workflow. Show a clear fallback when the evidence is absent or ambiguous.
Respect access boundaries
Scope sign-in, document permissions and retrieval filtering. Agree providers, hosting, retention and data handling requirements before connecting private information.
Evaluate and operate
Check representative questions, sensitive cases, latency and usage costs. Establish feedback, monitoring and a maintenance plan for the system and its sources.
An answer should show its working
Ask something useful.
Check what comes back.
This small, interactive illustration uses a fictional service handbook. It is not connected to a model, private documents or live business records.
ILLUSTRATION / FICTIONAL SOURCES
How do I log a linen shortage?
Record the order reference, expected and received quantities, then flag the difference for the account lead to review before closing the job.
Source: Sample Service Handbook, §2Read the sample source
§2: Record expected and received quantities against the order reference. The account lead reviews shortages before the job is closed. §5: The account lead must approve changes to service terms or pricing before staff update the customer record.
Choose the question, not the hype
A focused place to start.
Customer service
Find approved product guidance, troubleshooting and service terms while keeping the source available to the person replying.
Internal knowledge
Make maintained policies and process documents easier for colleagues to find, without opening information to the wrong team.
Operational procedures
Help staff retrieve approved handling instructions or exception processes. Use a transactional system for current order status.
See the commercial laundry use case ↗RAG pricing & delivery
Know what you’re buying.
And what it takes to run.
We provide a project-specific proposal rather than an arbitrary package price. Your sources, access requirements, integrations and evaluation scope shape the build. Hosting, model usage and ongoing support are set out separately.
A useful brief, not a vague AI ambition.
Identify the recurring questions, people and source material. Agree the boundaries before choosing the technology.
- Source and access review
- Success measures and evaluation questions
- Written scope, exclusions and estimate
Put the difficult questions in early.
Test a limited source collection with the people who know what a good answer looks like.
- Ingestion, retrieval and answer interface
- References and insufficient-evidence handling
- Permission and quality checks
A system someone owns.
Connect agreed services, onboard the team and establish how sources, feedback and costs will be maintained.
- Identity, integrations and deployment
- Monitoring, source refresh and deletion
- Separately scoped support and care
No published subscription or fixed starting fee is implied. Scope and commercial terms are agreed before development begins.
Read the RAG pricing and value guide ↗A business case you can challenge
Start with time spent.
Not a promised ROI.
Estimate what less searching could mean for a team. The improvement is an assumption until a pilot measures it. Reclaimed time is not automatically a cash saving.
Questions before the build
Let’s be precise.
Is RAG the same as a general AI chatbot?
A RAG system retrieves information from a defined source collection before generating a response. A general chatbot does not necessarily have access to your current business knowledge. Neither approach removes the need to check consequential answers.
Does it mean our information stays private automatically?
No. Privacy depends on permissions, provider terms, deployment choices and operating controls. We scope these explicitly; the word “RAG” is not a security or regulatory certification.
Can it work with PDFs, SharePoint or our database?
Potential sources are assessed during discovery. Connectors, identity requirements, licences and source quality affect the scope. Live database answers need a carefully defined integration rather than reliance on a stale document export.
Does RAG remove hallucinations?
No. Search can retrieve the wrong passage and generation can misinterpret it. Evaluation, references, refusal when evidence is missing and appropriate human review remain important.
Can we commission a pilot first?
Yes. A defined source set, user group and question set make a useful pilot. Wider rollout should depend on measured usefulness, appropriate access and an agreed operating cost.
Make the first conversation practical
Bring a question.
We’ll start with the evidence.
Tell us who needs the answer, where the information lives and what makes the current process frustrating.
Talk to Not Devs ↗