Almost every company has one person who is the index. New hires ask them. Sales asks them before offering a discount. A customer asks about an uncommon model, and the question still lands on them. When they are out, several desks slow down. When they leave, the judgment leaves with them.
A company knowledge base is that problem, written down. Material that is scattered across a shared drive, a chat log, and one person’s memory becomes something any colleague can ask, the way they would ask that person. With a large language model, the knowledge base is no longer only a pile of folders. It can answer, and it can say which file the answer came from.
This page follows the order of an actual project: choose a scope, clean the documents, choose where it runs, test, put it where people already work, and name who maintains it. A knowledge base answers questions. If the job is to finish a task, such as matching a document, that is a skill, not a search box.
How an AI knowledge base differs from a shared drive
A traditional knowledge base (a wiki, a shared drive, a document system) answers “where is the file.” People have to know the keyword, open the file, and read it. An AI knowledge base answers “what is the answer.”
| Shared drive or wiki | AI answers over your files | |
|---|---|---|
| How you use it | Search a keyword, open a file, find the line | Ask in ordinary language |
| What you get | A list of files | A direct answer, with the source |
| A different wording | The wrong keyword returns nothing | It can follow a paraphrase |
| It is not in the files | No results | It should say it did not find it |
The usual design is retrieval-augmented generation. The system finds the few passages in your files that match the question, and the model may answer only from those passages. That is the difference from asking a public chat tool. The answer comes from your material, not from the model’s memory of the public web.
Step 1. One department, one kind of question
The usual failure is starting with “the whole company’s knowledge base.” Too many files, too many conflicting versions, too many owners. Every department is unhappy.
Start with one department and one kind of question people already ask:
- People and admin: leave, expenses, attendance, joining.
- Sales: who may discount, payment terms, quoting rules, clauses you reuse.
- Support: product specs, common faults, install steps.
- Production: work instructions, process cards, inspection standards.
The test is simple. Which question is asked every day, and always interrupts the same person? That is the first set the knowledge base should answer.
Step 2. Clean the documents. This takes the time
Most of the quality is the quality of the files. A model will not decide which policy is current, and it will not reconcile two documents that disagree.
| State of the file | What to do |
|---|---|
| Several versions of the same document | Keep the current one. Move the old versions out |
| Two documents contradict each other | One owner picks the rule, the files are edited, then they go in |
| The judgment exists only in someone’s head | Write it down as a short Q&A, even if that is all it is |
| Blurry scans and photos | Recognize the text and have a person check it. Important pages are better retyped |
| Personnel files, pay, and other private records | Leave them out, or lock them to a role |
A practical order: collect the questions people actually asked in the last month or two, then find the file that should have answered each one. What you clean that way is used on the first day.
Step 3. Choose where it runs
Deployment decides where the files sit, and how the bill works. Three patterns are common.
| Pattern | Fits when | You have to decide |
|---|---|---|
| A cloud model | The files are not highly sensitive, and you want a pilot soon | You pay per call. Read the provider’s data terms. For business in China, prefer a model service that has completed the required filing |
| On your own machines | The files are highly sensitive, or the network cannot leave the building | Servers or GPUs, a model that fits that hardware, and a person to maintain it |
| Split | Most files are ordinary, a few are sensitive | Ordinary files use the cloud. Sensitive files stay local. You need a rule for which question goes where, and who may ask |
A common path is a cloud pilot first, until you know people use it, and only then a private setup for the sensitive slice. That avoids buying hardware before you know the questions are real.
Step 4. Two rules the build does not get to drop
The build is: split the files into passages, index them, connect a model, and design the question and the answer. Which tool and which model depend on volume, deployment, and budget. Two rules do not depend on the tool:
- Every answer cites a source. Which file, which clause. People can open it. Without a source, they should not trust it.
- If it is not in the files, say so. “No rule found; ask this department” is a correct answer. A fluent invented answer is not.
Access belongs in the same step. Which department and which role can see which files is set before launch. Sales should not be able to ask for pay bands. An intern should not be able to ask for a customer’s floor price.
Step 5. Test with questions people have already asked
Before launch, write a few dozen questions, preferably ones staff have really asked, in three groups:
- Questions the files can answer. Is the answer right? Is the source the right passage?
- Questions the files cannot answer. Does it say it did not find a rule?
- Questions that look alike. Similar clauses (a travel allowance that differs by city, an approval limit that differs by amount). Does it attach the wrong one?
Ask the person who is interrupted most often to sit in. They know which questions are common, and they see a wrong answer immediately.
Step 6. Put it where people already work, and name an owner
The entrance should be a place people already open: a web page, or an app inside the company chat tool. Do not make someone learn a new system in order to ask one question.
After launch, the main risk is that the files go stale. Three habits are enough:
- One business owner updates the knowledge base when the policy changes.
- Once a month, read the questions that were not answered. That list is the next set of files to add.
- When someone leaves, one step of the handover is writing the job’s answers into the knowledge base.
What the price depends on
The range is wide, because the work is not “install a bot.” It depends on:
- How many files, and how much cleaning they need.
- Cloud or on your own machines, and if private, what hardware.
- The entrance: a web page only, or also the company chat tool or an existing system.
- Whether access has to differ by department and role.
- How many people ask, and how often. That is the ongoing model bill.
Ask for the build cost and the later model, server, and maintenance cost as separate lines. Our practice is a free look first, then a fixed quote. A knowledge base is the right shape when the job is questions. When the job is to finish a task under your own steps, read skills and rules before you buy a chatbot.
FAQ
How clean do the files have to be before we start?
Not all of them. Pick one department and one kind of question, take the current version of those files, and pilot that. The rest can be added as people use it.
Will it invent answers?
It can, which is why three constraints stay: it may answer only from your files; every answer cites a source; if the files do not contain it, the answer says so. Test those three on real questions before anyone depends on it.
Does a company knowledge base have to run on our own servers?
No. Ordinary files can use a cloud model, which is faster and cheaper to try. Highly sensitive files can stay on your machines, or you can split the two. Do not buy the hardware before the questions are proven.
How long does a first version take?
It depends on the files and the cleaning. Kept to one department and one kind of question, a version people can try on real material is usually a few days. Widening it comes after that trial, not before.
Start with the questions that interrupt one person
Bring the questions your team already asks, and the files those answers should come from. We look at whether a knowledge base is the right first job, then quote a fixed pilot on anonymized material.
Book a free look at the first question set →