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. Examples are the policy on a damaged item, the form a new dealer fills, and what was agreed with a client two years ago.
A knowledge base assistant answers from your own files and not from the internet. It quotes the policy you wrote. That is its value and also its risk, because it can quote the wrong version 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
Documents decide whether these projects succeed, and few of the problems are technical.
- 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
The first part of a project is usually spent on the documents themselves. That tidying is worth doing even if the assistant is never built.
Making the answers checkable
A system that can be wrong should 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, using WhatsApp’s official 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?
Yes. Start with one team, one set of documents and a few weeks of real questions. The first version shows whether the documents are good enough, which 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
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements