How to Train an AI Chatbot on Your Business Data

Why chatbots invent answers

A language model is built to produce a plausible continuation of text. Left to itself, it has no way to distinguish between recalling something and constructing something that sounds like it. Ask it for your delivery terms and it will produce delivery terms — fluent, specific, and belonging to no company in particular.

This is not a defect that a newer model removes. It is what the model does. The fix is architectural: the bot must be given the relevant passage of your material and instructed to answer from it, and it must have a defined behaviour for the case where no relevant passage exists. Those two things — grounding and fallback — do more for accuracy than any model upgrade.

• No grounding: the model answers from general knowledge and produces confident, unverifiable text.
• Grounding without fallback: the model answers from your material when it can, and improvises when it cannot — which is worse, because the failures are now rare enough to be trusted.
• Grounding with fallback: the model answers from your material, and says it does not know when the material is silent. This is the only configuration safe to put in front of customers.

What 'training' actually means here

The word covers two very different things, and confusing them wastes both money and time.

1. 1Fine-tuningAdjusting the model's weights on examples. It changes style, tone and format reliably. It is a poor way to teach facts: the knowledge is baked in, cannot be inspected, and has to be redone whenever a price changes.
2. 2Retrieval — the one you wantYour material is stored, indexed, and searched at the moment a question arrives. The relevant passages are handed to the model with the question, and the answer is written from them. Facts stay editable, changes take effect immediately, and every answer can be traced to a source.

For a business chatbot, retrieval is almost always the correct architecture, and 'training the bot' in practice means building and maintaining the material it retrieves from. When a vendor says the bot will be trained on your business, this is the question to ask: is my price list a document you search, or a set of weights you have to rebuild?

What material to use, and in what order

The most common way a chatbot project stalls is a request to write two hundred question-and-answer pairs before anything works. Those answers already exist. Start with what is written down, in descending order of how current it is.

1. 1Your websiteService descriptions, terms and an existing FAQ are usually already there and can be crawled rather than retyped. This is the fastest first pass and it also shows you which pages are out of date.
2. 2Your product catalogue, with variantsThis matters more than it sounds. 'The red one in size 42' is a question about a variant. A flat product list cannot answer it; a catalogue with per-variant price and stock can. Photos belong here too, because that is what lets a customer's picture be matched to a product.
3. 3PDFs and documentsPrice lists, warranty terms, technical specifications, contract templates. These carry the answers that support staff currently look up by hand.
4. 4Past conversationsYour real customers' real questions. This is the best available guide to what to prepare, and it is usually more honest than an internal guess about what people ask.
5. 5The gaps, filled by handWhatever is left exists only in someone's head. This list is much shorter than anyone expects once the four sources above have been used, which is the point of doing them first.

A practical stopping rule: stop adding material when the remaining questions are ones your own staff answer inconsistently. Those are not knowledge-base gaps — they are business decisions that have not been made, and the bot cannot make them for you.

Preparing material so retrieval actually works

Retrieval fails in boring ways, and most of them are fixed in the material rather than in the software.

• One subject per passage. A page covering delivery, returns and warranty in three paragraphs retrieves badly for all three. Split it.
• Write the question into the text. Material that uses the words customers use is found; material written in internal vocabulary is not.
• Type your content — pricing, policy, product, opening hours, campaign. A typed base can be filtered, audited and switched off selectively.
• Categorise by structure that matters to you: branch, service line, season. This is what lets you deactivate one branch's material without touching the rest.
• Never store the same fact twice. Two versions of a price is not redundancy, it is a coin toss.
• Date anything temporary. A campaign that ended should be deactivated, not left to be retrieved for another six months.

The last point deserves emphasis, because it is the most common cause of a wrong answer in a base that was correct at launch: nothing was removed. Deactivating rather than deleting is the right pattern — the material comes back next season without being rewritten, and it stops being retrieved in the meantime.

The three controls that prevent hallucinations

Once the material is in place, three configuration decisions determine whether the bot is trustworthy. Ask to see all three demonstrated rather than described.

1. 1Answer only from retrieved materialThe instruction that governs every reply must confine the model to the passages it was given. This is not a slider; it is either the design or it is not.
2. 2Define what happens when nothing is foundThe correct behaviour is to say so plainly and offer a person. The incorrect behaviours are improvising, and answering a slightly different question that it does have material for — the second is harder to spot and does more damage.
3. 3Record the sources behind every answerEach reply should store which passages it was built from. This is what turns 'the bot said something wrong' from an argument into a five-minute fix, and it is the single most useful feature for anyone who has to maintain the thing.

A fourth control is worth adding where the question is time-sensitive. Stock levels, order status and availability change faster than any indexed document, so those answers should come from a live call to your own system rather than from stored material. A knowledge base that claims to know current stock is a knowledge base that will be wrong.

How to test before customers do

Testing a grounded chatbot is not the same as testing software, and asking it easy questions proves nothing. Build a test set that is deliberately hostile.

• Questions your material genuinely does not answer. Watch what happens. This is the single most important test and the one most often skipped.
• Questions whose answer changed recently — confirm the bot gives the new answer, not the one indexed last month.
• Follow-up questions that only make sense in context: 'and the red one?', 'what about for two people?'.
• Questions phrased in customer vocabulary rather than your own internal terms.
• Near-miss questions where two pieces of material are similar — a campaign price and a standard price, two branches with different opening hours.
• The awkward ones: refunds, complaints, and anything where an incorrect promise creates an obligation.

Run this set again after every significant change to the material, and keep the answers. A regression in a chatbot is invisible without a baseline, and the first person to notice it should not be a customer.

Keeping the base current after launch

A knowledge base is not a project with an end date. The maintenance burden is small if the design is right and unmanageable if it is not.

• Editing text should re-index automatically. If someone has to remember to press a button, the base will drift.
• One source of truth for a fact, shared by every channel including the phone line. Two bases guarantee two answers.
• A review triggered by the business, not by the calendar: a price change, a new branch, a campaign ending, a policy update.
• Periodic reading of real conversations, which is where you discover the questions you never thought to prepare for.

The conversations are the most valuable input and the most neglected. The questions customers actually ask drift over time, and a base that is only ever updated when a price changes will slowly stop covering what people want to know.

How Vexvon builds the knowledge base

Vexvon builds the base from five sources rather than from a blank document. Your website is crawled automatically and cleaned into text — up to 4,500 pages. PDFs up to 25 MB are extracted and made searchable. The product catalogue is stored as structured products, with each variant carrying its own price and stock, and product photos indexed so that an image a customer sends can be matched. A question-and-answer set can be generated from past Instagram conversations. Anything remaining is added by hand, in bulk if needed, up to 200 entries per request.

Material is organised rather than dumped: your own categories, and content types such as FAQ, pricing, product, catalogue, branch, campaign, schedule and policy, with the type detected automatically where it can be. Material can be deactivated rather than deleted when a campaign ends, and switched back on next season. When text changes, the search index updates itself.

Each answer records which passages of knowledge it was built from, so a wrong answer can be traced to its source and corrected once. When no relevant context is found, the bot does not invent one — it keeps the conversation going and hands it to your team. Where an answer needs live data, your own API can be called during the conversation. Each piece of material is targeted at the chatbot, the call agent, or both, which is what keeps a price identical in a WhatsApp reply and in a phone conversation.

Frequently asked questions

1. 1How do I train an AI chatbot on my business data?In practice you do not retrain a model — you build a searchable base from your website, catalogue, documents and past conversations, and the bot retrieves from it at the moment a question arrives. Keeping that base correct is the work.
2. 2What is a RAG chatbot?Retrieval-augmented generation: the relevant passages are searched for and handed to the model together with the question, so the answer is written from your material rather than from the model's general knowledge.
3. 3Can I stop a chatbot from hallucinating completely?You can reduce it to the point where it is a manageable risk, by grounding every answer in retrieved material, defining an explicit fallback when nothing is found, and recording the sources behind each reply. A guarantee of zero is not something to accept from a vendor.
4. 4How much material do I need to start?Less than most people assume. A website and a current catalogue or price list usually cover the majority of real questions. Volume matters far less than being current and unambiguous.
5. 5How do I keep prices from going out of date?Hold the price in one place that every channel reads, and make sure editing it re-indexes automatically. Most stale-price incidents come from a second copy nobody remembered.
6. 6Should the phone agent use the same knowledge base?Yes. Two bases for the same business will diverge, and a customer who is quoted one price in chat and another on the phone has found the problem before you did.

Bring your own documents to the test

The only demo worth attending is one built on your material. Bring a price list, one policy document and five questions — including two your material does not answer — and watch what the bot does when it runs out of knowledge. That behaviour, not the fluent answers, tells you whether the system is safe to deploy.