Assistants that answer from your documents, with sources.
We build retrieval-augmented assistants that search your own documents, catalogues and databases, answer from what they find, and show where each answer came from. Permissions, freshness and testing are designed in, so staff and customers can trust the replies.
What is RAG, and why does it reduce wrong answers?
Retrieval-augmented generation lets a language model look up relevant passages from your approved documents before it answers, then write the reply from that evidence and cite it. It reduces invented answers because the model is working from supplied text instead of memory. It does not make answers correct by itself: sources must be current, search must find the right passage, and access rules must be enforced before any text reaches the model.
How one answer is put together.
Behind every reply is a short chain. A fault anywhere in it shows up as a confident, wrong answer.
What happens on every question
- Understand the question. The query may be rewritten, expanded or split so the search looks for the right thing, not just the same words.
- Search the sources. Keyword and meaning-based search run together, then results are filtered by what the user is allowed to see.
- Rerank the passages. A second step orders the candidates, so the best three passages reach the model rather than the first ten.
- Write with citations. The model answers using only the supplied text, links each claim to a source and says so when evidence is thin.
If nothing relevant is found, a well-built assistant says it does not know, and offers to hand the question to a person.
Sources a knowledge assistant can use.
Most businesses hold knowledge in several places. We decide which sources are worth including, and how each should be handled.
Policies and manuals
PDFs and documents with headings and tables, parsed so that structure and page references are kept.
Product catalogues
Specifications, compatibility notes and manuals that customers ask about every day.
Support history
Resolved tickets and macros, used with care for privacy, as a source of real wording and fixes.
Databases and APIs
Live records such as stock, order status or prices, fetched at question time instead of copied.
Website and editorial content
Articles, guides and help pages, kept in step with the live site.
Internal wikis and drives
Team notes and shared folders, with access rights carried over from the original system.
Where retrieval usually goes wrong.
When an assistant is wrong, the cause is almost always that the right passage was never found. Search quality is the real work.
What we tune
- Parsing. Tables, headings and scanned pages are read properly, because garbled text in means garbled answers out.
- Chunking. Documents are split along natural sections with overlap and titles, instead of arbitrary character counts.
- Metadata. Each chunk keeps its source, date, owner, product and access level, which allows precise filtering.
- Hybrid search. Exact terms, such as part numbers, are matched by keyword search, while paraphrased questions are handled by embeddings.
- Reranking. The top candidates are scored again against the question for relevance before generation.
Chunk size alone can change results a great deal, so we test several settings against your own questions instead of copying a default. Self-hosted models and vector stores are covered in our self-hosted AI models service.
Four ways to give a model your knowledge.
RAG is popular, but it is not the only option. We pick the simplest method that gives reliable answers.
| Criteria | Good for | Limitation |
|---|---|---|
| Long prompt | A few short, stable documents | Cost and limits grow quickly |
| RAG | Large, changing document sets | Needs search tuning and testing |
| Fine-tuning | Style, format or narrow tasks | Poor for facts that change |
| Plain search | Finding a document, not answering | User must read and decide |
Keeping private documents private.
A company assistant that shows a junior employee the salary file is worse than no assistant. Access rules come first.
How we protect content
- Filter before retrieval. The user's rights are applied to the search itself, so restricted passages never reach the model.
- Application-level checks. We do not rely on vector database filters alone, since a mistake there exposes data.
- Redaction. Personal or secret details can be masked in sources that are otherwise useful.
- Audit trail. Questions, retrieved sources and answers are logged for review, within your privacy rules.
Tokens and credentials sit in encrypted storage, and model providers are chosen to match your data policy. Before any private document is sent to an outside provider, we agree in writing what may leave your systems and what may not.
From document pile to working assistant.
A working prototype comes early, because the real learning happens when staff ask it real questions.
- 01
Pick the questions
We list fifty or so real questions users ask, and the sources that hold each answer.
- 02
Audit the sources
Duplicates, outdated files and conflicting versions are found and assigned an owner.
- 03
Build the pipeline
Parsing, chunking, search and a first answer format are connected and tried on the question list.
- 04
Test and tune
Failures are traced to retrieval, ranking or prompt and fixed one at a time.
- 05
Add the interface
A chat page, widget, Slack bot or tool inside your app is built with visible sources and feedback buttons.
- 06
Launch and monitor
Real questions are reviewed weekly, gaps in the content are listed and updates are scheduled.
What an assistant should remember, and forget.
Memory features help conversations feel natural, yet they raise privacy and accuracy questions. We decide what is stored deliberately.
Types of context we design
- Conversation history. Recent turns are kept so follow-up questions make sense, then trimmed to control cost.
- User profile. Role, language or product line may be stored, with consent, to personalise answers.
- Session summaries. Long chats are condensed, with key facts kept and noise dropped.
- Retention rules. What is stored, for how long and how users delete it is written down and enforced.
More autonomous behaviour, such as taking actions, is the subject of AI agent development.
What RAG cannot promise you.
We set expectations early, because the technology is often described as more magical than it is.
Perfect accuracy
Answers can still be wrong or incomplete. We reduce the rate and make uncertainty visible, but cannot remove it.
Knowledge you do not have
If the answer is not in your documents, the assistant cannot invent it responsibly.
No upkeep
Sources age. Without ingestion that spots changes and deletions, an assistant slowly quotes outdated rules.
Fixed running cost
Each question uses search and model calls, so cost follows usage. Caching and context limits keep it sensible.
Proving it works before and after launch.
Quality is tested with a fixed question set, not a demo that happens to go well. The same set is rerun after every change, so a fix in one area does not quietly damage another.
Retrieval recall
For each test question, was the right passage found among the top results? This is checked separately from the answer.
Answer correctness
Reviewers compare each answer with an approved reference and mark it correct, partly correct or wrong.
Citation quality
Cited passages must truly support the claim made, not only sit nearby in the same document.
Refusal behaviour
Out-of-scope or unanswerable questions should receive a clear refusal and a route to a person, not a guess.
RAG questions, answered.
Straight answers to what clients ask before they start.
What is the difference between RAG and fine-tuning?
RAG gives a model the right documents at question time, so answers can change when documents change. Fine-tuning adjusts the model itself, which suits style or narrow tasks but is poor for facts that update.
Which vector database should we use?
It depends on size, hosting rules and your existing stack. For many projects PostgreSQL with a vector extension is enough, while larger or specialised needs may justify a dedicated store. We choose after sizing the data.
Can it work with Urdu or other languages?
Yes, provided the chosen embedding and language models support them well. We test retrieval in each language separately, since quality varies.
How do you stop it making things up?
We restrict answers to retrieved text, require citations, allow refusals and test against known questions. We also tell you honestly that no setup removes errors completely.
How much does it cost to run?
Cost follows document volume, question volume, model choice and hosting. Caching, smaller models for simple tasks and context limits can reduce it. We estimate it with your expected usage.
Can it answer from live data such as orders or stock?
Yes. Live records are fetched through your API when the question is asked, instead of being copied into the search index, so they are never stale.
Which of our documents should go in first?
Start with stable, high-value material that people ask about constantly, such as policies, product manuals and price rules. Leave messy archives for later, once the pipeline has proven itself.
Do you build the chat interface too?
Yes. We build chat pages, website widgets and assistants inside tools your team already uses. See also our AI chatbot development.
Give your team answers they can check.
Send us ten questions your staff or customers ask often and tell us where the answers live. We will reply with a plan for the sources, the risks and a first test.