How retrieval changes the answer
A plain language model answers from what it absorbed in training. It has never read your manual, so when asked about your product it produces something plausible and wrong.
Retrieval-augmented generation puts a search step in front: find the relevant passages in your documentation, hand them to the model, and require the answer to come from them. Every reply can then cite the page it came from, which your team can check.
What we build
- The retrieval layer over your manuals, help centre, tickets, product data or policy documents.
- The evaluation set: a graded list of real questions with correct answers, run against every change.
- The escalation path for when the assistant does not know, because "I could not find this, here is a human" beats a confident fabrication.
- The interface, whether that is a website widget, an internal tool or a channel inside your existing support desk.
Evaluation is the whole job
Anyone can demo a chatbot that answers three questions well. The engineering is in knowing it still answers two hundred correctly after you change the prompt, swap the model, or add a thousand new documents. We build that test set first and treat a regression in it as a build failure.
Where the data goes
We are explicit about which provider processes your content, what is retained, and which documents are in scope. If that has to stay inside your own infrastructure, we will tell you what that costs before you commit.
Where this connects
If the job is a narrow internal task rather than answering questions from documents, personalised AI tools is the better shape. Either way it needs somewhere to live, usually a web application.