Service 03 / 06
Answers from your own data, with the source attached.
This is a chatbot that answers from your documents (your wiki, your Drive, your tickets, your PDFs) and links to where each answer came from so it can be checked. The technique is retrieval-augmented generation (RAG): find the relevant material first, then let the model answer from it, rather than from memory.
What I build
- It reads what you actually have: PDFs, spreadsheets, tickets, email threads
- Every answer links to where it came from, so it can be checked
- It says “I don't know” instead of inventing something
- It follows your permissions: nobody sees what they shouldn't
What you get
An assistant your team trusts enough to stop asking the one person who knows.
Good fit ifthe knowledge exists but nobody can find it.
Fine-tuning doesn't teach a model your documents: that's what RAG is for. If you've been quoted for fine-tuning, ask what it solves.
Do we need a vector database?
Often not, and it is the most expensive default in this field. For the knowledge bases most businesses actually have (hundreds of documents, not millions) keyword search over well-kept files routinely beats the embedding stack: cheaper, debuggable, and every answer traceable to a file you can open.
The embedding pipeline is never just the database. It is a re-embedding job for every document that changes, a chunking strategy that silently decides what can ever be found together, an index to host and version, and a bill that starts before the first question is asked. And when retrieval goes wrong it goes wrong opaquely: the wrong chunk came back because two vectors were close, and nobody can read a vector.
This site runs the honest version of that argument: its own knowledge base is plain markdown files with keyword search over them, no embeddings and no vector database anywhere in the stack. If your corpus genuinely needs vectors, the size and the shape of it will say so, and then we use them.
How do we stop it making things up?
By making "I don't know" a correct answer and citation mandatory. A retrieval assistant that must point at a source for every claim cannot invent one quietly: the failure becomes visible, which is the difference between a system your team corrects and a system your team stops trusting.
The second half is coverage. Most hallucinations in production are not the model being creative; they are the model being asked a question the corpus does not answer. Measuring which questions retrieve nothing is how a knowledge assistant gets better over time, and it is the part most projects skip.
What about permissions?
Retrieval has to respect who is asking, or it becomes the fastest data leak your company has ever built. If a document is restricted in your Drive, it must be unreachable through the assistant for the same people: enforced at retrieval time against the asker's identity, not filtered out of the answer afterwards.
This is the requirement that most often decides the architecture, and it is worth raising in the first conversation rather than the fourth.
Is fine-tuning the alternative?
No: fine-tuning does not teach a model your documents. It teaches a model a style, a format, or a behaviour. Facts that change on Tuesday cannot live in weights that were frozen on Monday, and a fine-tune has no way to cite where an answer came from.
If you have been quoted for fine-tuning to "train the model on our data", the useful question is which of those two things the quote is actually solving. Sometimes the answer is legitimate. Often it is a vector database problem wearing a more expensive hat.
Questions people ask
- What documents can it read?
- In practice: PDFs, office documents, spreadsheets, wiki pages, ticket histories and email threads, anything with extractable text. The real constraint is rarely the format, it is whether the content is current: a retrieval assistant built over documents nobody has updated in three years will answer confidently and wrongly, and no amount of engineering fixes that.
- How is this different from just using ChatGPT?
- A general assistant answers from what it learned during training; a retrieval assistant answers from your material and shows you which document it used. For questions about your own business, that difference is the entire product: one of them can be checked and the other cannot.
- Do we need a vector database for RAG?
- Not always, and for a few hundred documents usually not. Keyword search over well-maintained files is cheaper to run, far easier to debug, and traceable to a specific file. Vectors earn their place at scale or when questions and documents share no vocabulary, which is a question to answer with your corpus, not with a default.
- Will it leak information between teams?
- Only if permissions are bolted on afterwards. Done properly the assistant retrieves as the person asking, so a restricted document is invisible to anyone who could not already open it. This is an architectural requirement rather than a setting, which is why it belongs in the first scoping conversation.
- How long does it take to build?
- A working assistant over an existing, reasonably tidy document set is a week. When the documents are not ready (scattered, duplicated, or contradicting each other), the data work becomes the project, and it is more honest to price that separately than to discover it halfway through.