A chatbot that answers from your documents and shows its receipts
Retrieval-augmented chatbots grounded in your own help centre, policies, product docs, and ticket history. Every answer carries the passage it came from, weak retrievals escalate instead of guessing, and quality is a score against a real question set rather than an impression from a demo.
100%
Answers carry a source citation
1
Scored question set before launch
12+
Projects shipped end to end
Built on the retrieval stack that survives a real corpus
Why most company chatbots get switched off
The problem was never the model. It was the retrieval.
Nearly every abandoned internal chatbot I have been asked to look at failed in one of these five ways, and none of them are fixed by switching to a better model.
I build the opposite: ingestion tuned per source type, hybrid retrieval with re-ranking, citations on every answer, a scored evaluation set written before the bot exists, and a confidence floor that escalates to a human rather than inventing an answer.
What actually goes wrong:
- 01
Confident answers with nothing behind them
Without retrieval grounding, the model fills the gap fluently. One wrong answer in a policy or pricing question is enough for a team to stop trusting the whole thing.
- 02
Everything dumped into one index
A policy PDF, a ticket thread, and a product spec do not chunk the same way. One generic ingestion pass makes every source retrieve badly at once.
- 03
No citations, so no way to verify
If a reader cannot open the passage an answer came from, they have to re-check it manually — which is the work the bot was supposed to remove.
- 04
No evaluation set, so no idea if it regressed
Every prompt tweak is a guess. Quality drifts quietly until someone complains, and there is no number that says whether last week's change helped.
- 05
It never says 'I don't know'
Without a confidence threshold and an escalation path, the bot answers everything, including the questions your content genuinely does not cover.
1
Evaluation set before launch
100%
Answers traceable to a passage
0
Answers generated without retrieval
What a RAG build covers
From a pile of documents to an answerable knowledge base
Ingestion, retrieval, the answer layer, and the operational instrumentation. Every stage produces something you own and can inspect.
Content audit & ingestion
We start with what you actually have: help-centre articles, PDFs, wiki spaces, spreadsheets, and closed tickets. Each source type gets its own parsing and chunking strategy, because the wrong chunk boundary is the most common cause of a bad answer.
- Per-source parsing and chunking
- Metadata and permission tagging
- Deduplication and staleness handling
- Scheduled re-indexing on content change
The stack behind it
Retrieval quality is the whole game
Model choice matters less than most teams expect. Almost every quality gap I have closed on a RAG system was closed in the retrieval layer.
Where answers come from, and the part that decides whether the system is useful or just fluent.
What gets built
Chatbots people go back to a second time
The gap between a bot that gets adopted and one that gets quietly ignored is almost entirely in this list.
Citation-backed answers
Every response names the passage behind it, rendered as a link the reader can open. Verification takes one click, which is what makes the answer usable in a decision rather than a starting point for more checking.
- Inline citations on every claim
- Click through to the exact passage
- Source freshness shown with the answer
- No claim generated outside retrieved context
Retrieval tuned on real questions
Chunk size, overlap, hybrid weighting, and re-ranking are all tuned against a set of questions your users actually ask, not defaults copied from a tutorial.
- Per-source chunking strategy
- Hybrid weighting tuned per corpus
- Recall measured, not assumed
- Re-ranker scored against real queries
Knowing when to escalate
A confidence floor on retrieval quality, an explicit out-of-scope list, and a handoff that arrives with the transcript and retrieved context already attached instead of a raw chat log.
- Confidence threshold on every answer
- Explicit out-of-scope topics
- Warm handoff with full context
- Ticket raised in your existing tool
Knowledge-gap reporting
Questions the bot could not answer are logged and grouped, so the content team gets a ranked list of what to write next instead of guessing at documentation priorities.
- Unanswered questions clustered by theme
- Ranked by frequency
- Retrieval misses separated from content gaps
- Weekly digest to the content owner
Evaluation before every deploy
A scored question set runs in CI on every prompt, model, or index change. A regression fails the build rather than reaching a user, which is what lets you keep improving the system after launch.
- Retrieval and answer scored separately
- CI gate on quality regression
- Baseline scores from the prototype onward
- Per-case diff between runs
Not sure your content is good enough to build on?
That is the honest first question, and it is answerable in one call. Describe your corpus and the questions you want answered, and you will get a read on whether retrieval can support them, what would need writing first, and whether a simpler search page would win.
Real corpora. Real questions.
Retrieval systems I have shipped
Assistants running against real help centres, ticket histories, and product content. Problem, architecture, and my role on each.
Physical AI Robotics Book
AI and robotics learners lacked a structured, accessible documentation platform covering humanoid robotics fundamentals through advanced concepts in a cohesive learning path.
AI Chatbot Builder
Agencies wanted to embed branded AI assistants on client sites but lacked a platform to manage per-client knowledge bases and measure how the assistants actually performed.
Task Automation Engine
Incoming work items arrived unstructured, requiring manual triage, validation, and routing before anyone could act on them, a bottleneck that grew with volume.
Digital FTE Dashboard
Operations teams managing Digital FTEs across multiple clients had no single view of agent activity, approvals, or system health. Performance data lived in separate tools, Oracle for ERP records and Odoo for invoicing, so reviewing and approving agent work meant switching between several dashboards.
Where these bots run
Same pipeline, different cost of a wrong answer
Retrieval, citation, and escalation are constant. What changes is where the confidence floor sits and who has to sign off.
Customer support
Deflecting the repeat questions with grounded, cited answers, and handing the rest over with context already assembled.
- Grounded answers from your help centre
- Escalation with transcript attached
- Ticket deflection reporting
- Content gap feedback loop
How a RAG build runs
Write the test set before you write the bot
The order matters more than the tooling. Every step below exists to stop a quality problem being discovered by a customer.
Content audit
What exists, what state it is in, and which of your target questions it can honestly answer today. Some questions get ruled out here, which is the point.
Deliverables
- Source inventory
- Coverage assessment
- Gap list
Question set
Real questions with expected answers, written down and agreed before anything is built. This becomes both the acceptance criteria and the regression suite.
Deliverables
- Scored question set
- Acceptance thresholds
- Out-of-scope list
Ingestion & indexing
Per-source parsing and chunking, embeddings, metadata tagging, and a re-index schedule that matches how often the content changes.
Deliverables
- Ingestion pipeline
- Index schema
- Re-index schedule
Retrieval tuning
Hybrid weighting, chunk size, and re-ranking tuned against the question set until retrieval recall stops improving.
Deliverables
- Tuned retrieval config
- Recall scores
- Failure analysis
Answer layer & guardrails
Grounded generation with citations, the confidence floor, refusal behaviour, injection testing, and the escalation path.
Deliverables
- Answer prompts
- Guardrail suite
- Escalation flow
Deploy with instrumentation
Production deployment on your chosen surfaces, with tracing, token accounting, and the knowledge-gap report wired up from day one.
Deliverables
- Production deploy
- Tracing dashboards
- Gap reporting
Tune on real traffic
A tuning window against real questions, with the eval set extended by the cases production surfaces that nobody thought to write down.
Deliverables
- Tuning report
- Extended eval set
- Content roadmap
Why work with me
A bot your team still trusts in month three
Standing up a RAG demo takes an afternoon now. Keeping one accurate against a corpus that changes weekly is the actual engineering.
Retrieval first, model second
Time goes into chunking, hybrid weighting, and re-ranking, because that is where the quality gap almost always is.
Every answer is checkable
Citations are not a feature toggle. If a system cannot show its working, it will not be trusted with a real decision.
Measured, not asserted
A scored question set exists before the bot does, and runs in CI afterwards, so regressions fail a build rather than a customer.
It is allowed to refuse
A confidence floor and an explicit out-of-scope list, with escalation carrying full context. Silence beats a confident wrong answer.
12+
Projects shipped end to end
3+
Years in production software
100%
Answers carry a citation
1
Eval set before any launch
Frequently asked
Questions people ask before we start
Have a knowledge base your team keeps re-reading by hand?
Tell me what it contains and the questions people keep asking it. You will get an honest read on whether retrieval can answer them today, what content would need writing first, and roughly what the build looks like.