An AI knowledge base is only ever as good as the documents behind it.
Somebody in your office answers the same question several times a week. What is the policy on a damaged item. Which form does a new dealer fill. What did we agree with that client two years ago.
A knowledge base assistant answers from your own files rather than from the internet. It quotes the policy you wrote. That is the whole value, and also the whole risk, because it will quote the wrong version of it just as confidently.
It is a search and answer system built on your own documents. Policies, manuals, contracts and old support replies are split into passages and indexed by meaning rather than by keyword. When somebody asks a question, the system finds the passages that fit. A language model writes the answer from those passages, with a link to the file it came from.
Where it earns its place.
What it is genuinely good at
- The same question asked by many people, each in slightly different words
- Documents too long for anybody to read before answering a customer
- Knowledge that lives in one person’s head and their old email
- New staff who do not yet know where anything is kept
- Finding the clause, rather than finding the document
Your documents decide your answers
This is where these projects succeed or fail, and almost none of it is a technical problem.
- Three versions of the leave policy, with no way to tell which is current
- A rule that changed in a WhatsApp group and nowhere else
- Scanned PDFs with no text in them, which need OCR before anything can read them
- Files nobody owns, so nobody can approve what the assistant says
- Contradictions a person resolves silently and a machine does not notice
We usually spend the first part of one of these projects on the documents themselves. That tidying is worth doing even if you never build the assistant.
Making the answers checkable
The way to live with a system that can be wrong is to make it obvious when it is.
- Every answer shows the passage and the file it came from
- The assistant says it does not know, instead of filling the gap
- Questions it could not answer are logged, and that list tells you what to write next
- A person signs off answers on anything with legal or medical weight
- Permissions respected, so a salesperson cannot retrieve an HR file
How we build one
- Collect
- Clean
- Index
- Retrieve
- Answer
- Review
- Gathering what exists and agreeing which copy is the truth
- Passages and embeddings stored in PostgreSQL with pgvector
- Retrieval tuned against a list of real questions your team writes down
- The answering layer, in a web chat, a staff portal or WhatsApp
- A review round after launch, because the first month shows the gaps
Where it goes wrong
- Asked to calculate something, such as a total across twenty invoices
- Asked about a record in your database rather than a document, which is a report
- Asked today about a rule that changed this morning
- Treated as the system of record instead of an assistant
- Rolled out without telling anybody that it can be wrong
A confident wrong answer is worse than no answer, so the checking goes in before the chat window does.
When this is the right choice.
- A pile of documents that people read in order to answer questions
- The same questions arriving repeatedly by email, phone or WhatsApp
- Policies and manuals somebody owns and keeps current
- Answers where a link to the source passage settles the matter
When it is not.
- Questions whose answers live in your database, where a report or a dashboard is the right build
- Documents nobody has updated in years, or that contradict each other
- Anything where a wrong answer carries a legal or medical cost and no one checks it
- A dozen files, where a shared folder and a search box already work
- Rules that change daily and are agreed verbally, which no index can keep up with
Questions we are asked about it.
Will it make things up?
It can, which is why we make it answer only from retrieved passages and show them. When nothing relevant is found, the right behaviour is to say so and hand the question to a person. We test that before launch, not after.
Do our documents leave our systems?
The documents stay in your database. Matching passages go to the model provider when a question is asked, unless you need a model running on your own servers. We write down exactly what goes where, so your compliance people can decide.
How current are the answers?
As current as the last document change and the last index rebuild. Where the files live somewhere we can watch, the rebuild is automatic. What no system can fix is a rule that exists only in a conversation.
Can it answer on WhatsApp?
Yes, through the WhatsApp Business API and within the template rules the provider applies. For internal staff a web chat is usually simpler. For customers, WhatsApp is where the question will actually be asked.
How do we know whether it is working?
By the questions it could not answer and the ones it got wrong, both logged from day one. If that list is shrinking and people keep using it, it works. If nobody opens it after a month, it did not.
Can we start with one department?
That is the sensible way in. One team, one set of documents, a few weeks of real questions. The first version tells you whether your documents are good enough, which is the question that decides the rest.
Services that use it.
What it sits with.
Not sure AI knowledge base is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private