# How do I train an AI chatbot on my own data? You mostly don't

> By Lawrence Dauchy, Founder, DFYe. Published 2026-07-17. 10 min read. Guides.
> Source: https://dfye.com/blog/how-do-train-ai-chatbot-own-data/
> Language: en

Fine-tuning is the wrong tool for this and it is the one most people reach for first. Here is what to do instead, and what it costs you to get wrong.

**TL;DR.** You do not train an AI chatbot on your own data in the sense people mean. You index it. Fine-tuning changes how a model writes, not what it knows, so a fine-tuned model asked about your delivery window will still invent one. Retrieval is the mechanism that makes it answer from your pages: split them into passages, match the question against those passages, and instruct the model to answer only from what it was handed.

You mostly do not train an AI chatbot on your own data. You index it, and the
difference is the whole answer. Training, in the sense of
[fine-tuning](https://platform.openai.com/docs/guides/fine-tuning), teaches a model
how to sound rather than what is true, so a model fine-tuned on your support
transcripts will still invent a delivery window when somebody asks. Indexing is the
other thing: your pages are split into passages and each passage becomes a list of
numbers, **1,536 of them** for one of the common OpenAI embedding models, so a
question can be matched against them at the moment it is asked.

Almost everybody asking the first question wants the second one.

## What does training actually mean here?

Three different mechanisms get called training, and they change three different
things. Picking the wrong one is the most expensive mistake in this area, because
fine-tuning costs real money and time and does not do what the person paying for it
expected.

| Approach | What it changes | When it is right |
|---|---|---|
| Prompt instructions | How it behaves in every reply | Always. This is the cheapest lever and the first one |
| Retrieval | What facts it can use | Whenever the answer lives in your own content |
| Fine-tuning | Its tone, format and style | When output shape matters more than output facts |

The middle row is the one you want and the bottom row is the one people buy. A model
fine-tuned on a thousand of your past support replies will answer in your house voice,
open with your greeting, and confidently state a returns window it has no way to
check. It learned the shape of your answers, not the contents of your site.

Facts change. A trained model does not. That single sentence decides the architecture.

## How do you point it at your own content?

In two steps, and both of them have a detail that gets skipped.

**Split, then embed.** Your pages are cut into passages, usually a few hundred words
each, and every passage is converted into a numeric representation by an
[embedding model](https://platform.openai.com/docs/guides/embeddings). The detail here
is where the cuts fall. Splitting on a fixed character count slices sentences in half
and produces passages that answer nothing; splitting on headings and paragraphs
produces passages that stand alone, which is what you actually want, because a
retrieved passage is read out of context by definition.

**Match, then instruct.** At question time the visitor's question is embedded the same
way, the closest passages come back, and those go to the model with an instruction to
answer from them and to say so when they do not contain the answer. That last clause
is not decoration. It is the difference between a system that declines and one that
guesses, and it belongs in the prompt whether or not the vendor put it there.

On WordPress the content usually arrives through the
[REST API](https://developer.wordpress.org/rest-api/), which is also why a plugin can
do this without you exporting anything.

## What should it never read?

More than you would guess, and getting this wrong is how a chatbot ends up quoting a
policy you retired two years ago.

| Page type | Index it | Why |
|---|---|---|
| Published pages, posts, products | Yes | This is the material the whole thing runs on |
| Drafts and scheduled posts | No | Unpublished means not yet true |
| Password-protected or members-only | No | Indexing it makes it public through a side door |
| Checkout, cart, thank-you pages | No | No answers live there, and they can carry order details |
| Retired campaign and old policy pages | Judgement | Usually no, and this is where the old returns window hides |

The last row is the one that bites. Every site that has traded for a few years has a
page somebody forgot to delete, stating terms that were true once. Nothing links to
it, so nobody thinks about it, and a retrieval system does not care whether a page is
linked. It will find that page, quote it accurately, and you will hear about it from a
customer.

If the exclusion control a product offers is a list of URLs you type in by hand, you
will forget one. Ask for pattern matching, and ask whether it respects noindex
automatically.

## What happens when you edit a page?

The passages built from it have to be rebuilt, and when that happens is a real
difference between products rather than an implementation detail.

Re-indexing on edit means your correction is live in seconds. Re-indexing nightly
means the price you fixed this morning is wrong to every customer until tomorrow, and
nothing anywhere reports that gap. Neither approach is dishonest, but only one of them
matches what a shop owner assumes when they hit update.

Deletion is the same question wearing a different hat. When a page goes, its passages
have to go with it. A bot answering from a page that now returns a 404 is citing a
source the reader cannot open, which is worse than declining, and it is the kind of
fault nobody notices until somebody quotes it back at you.

Ask both questions in these words: is re-indexing triggered by an edit or a timer, and
what happens to a passage when its page is deleted. Both are cheap to answer honestly.

## How does this work on a multilingual site?

Each language is indexed and retrieved separately, and the failure when it is not
looks exactly like success, which is why it survives so long.

Point an indexer at a whole multilingual site without telling it about languages and
it builds one pool of passages in several languages. A Dutch visitor asks a Dutch
question, the closest passage happens to be the English one, and the model obligingly
answers in Dutch from English source material. The answer reads fluently. The customer
cannot check it, because the page it cites is in a language they did not ask in. And
nothing in any dashboard reports a problem, because from the system's point of view
retrieval succeeded.

The correct arrangement is dull: every passage carries its language, retrieval filters
on the language of the question, and a question in a language with no matching content
gets a decline in that language rather than a translated answer from another one. On
WordPress the multilingual plugins already model translations as separate posts, so
the language is sitting there on each page waiting to be carried through.

There is a related temptation worth naming. Machine-translating your English pages to
fill the gaps in other languages produces an index that answers everything and is
trusted by nobody who reads it properly, because translated policy text goes subtly
wrong exactly where precision matters: cancellation windows, liability, sizing. If a
language matters enough to answer in, it matters enough to write in.

Two questions settle this with any vendor. Does retrieval filter by language, and what
happens when a language has no page covering the question. An answer of "the model
handles it" means no.

## How do you know it is working?

By asking it things you already know, and reading the answers properly rather than
skimming them.

Write down twenty questions your customers actually ask, with the correct answer
beside each one, before you test anything. Then ask all twenty. This takes an hour and
it is the most informative hour in the whole project, because it turns a vague
impression of quality into a list of specific failures you can fix.

Score three things per answer. Is it correct. Does it cite a page, and does that page
actually say it. And for the questions your site genuinely cannot answer, does it
decline or does it invent. That third column is the one that matters most and the one
nobody checks, because you have to deliberately ask something unanswerable to see it.

Then keep sampling. A standing half hour a week, reading twenty random conversations
rather than the escalated ones, finds the quietly wrong answers. The escalated ones
were already visible.

## When is your own data not enough?

When the answers are not in it, which is a more common situation than the tooling
implies.

A retrieval system can only find what exists. If your delivery cutoff lives in one
person's head, if sizing guidance is something your team says on the phone, if the
returns policy is three sentences in an email template, then there is nothing to
index and the honest outcome is a bot that declines a lot. That is the system working
correctly and reporting a content problem.

The fix is writing, not configuration. Three pages cover most of what a shop is
actually asked: delivery, returns, and sizing or compatibility for whatever you sell.
Writing them properly is an afternoon and it improves your site for every visitor who
never opens a chat window.

The other case is contradiction. If two of your pages disagree, retrieval will find
both and the model will pick one, and which one is not something you control. Before
indexing, search your own site for the phrase that matters most, the returns window
or the delivery cutoff, and see how many different answers come back. That search is
free and it is usually uncomfortable.

The free option worth starting from is [AI Engine](https://wordpress.org/plugins/ai-engine/),
and [OpenAI's own retrieval guide](https://platform.openai.com/docs/guides/retrieval)
covers the mechanism if you are building it yourself. What our version reads and
refuses to read is on [how it works](/how-it-works/), with the specifics in
[the docs](/docs/). For the category as a whole, start with
[what an AI chatbot for a website actually is](/blog/ai-chatbot-website/), and the
interface in front of it is in
[making a widget that fits your site](/blog/ai-widget-website/).

## Quick answers

### How do I train an AI chatbot on my own data?

In almost every case you do not train it, you index it. Your pages are split into
passages, each passage is converted into a numeric representation, and at question
time the closest passages are handed to the model with an instruction to answer from
them. That is retrieval, and it is what makes a bot answer about your business.
Training, in the sense of fine-tuning, is a different tool for a different job.

### What is the difference between fine-tuning and retrieval?

Fine-tuning changes how a model writes: its tone, its format, the shape of its replies.
Retrieval changes what it can say anything true about. If you fine-tune on your support
transcripts you get a model that sounds like your support team and still does not know
today's stock. The facts have to arrive at question time, every time, because facts
change and a trained model does not.

### What file formats can I use as training data?

For retrieval, the format matters far less than people expect: HTML pages, Markdown,
PDFs and plain text all reduce to passages of text in the end. What matters is whether
the content is current and whether one fact appears in only one place. A PDF price list
from last year is a worse input than a well-written page, whatever the file extension.

### How often should the chatbot re-read my site?

When a page changes, not on a schedule. A nightly rebuild means a price you corrected
this morning is wrong to customers until tomorrow, and the gap is invisible because
nothing reports it. Ask any vendor whether re-indexing is triggered by an edit or by a
timer, and treat a timer as a real limitation rather than an implementation detail.

### Can the chatbot read my PDFs and documents?

Usually yes, and you should think twice before letting it. Documents accumulate in a
way pages do not: superseded price lists, an old terms file, an internal note that was
never meant to be public. A retrieval system will quote any of those with equal
confidence. Index documents deliberately, one at a time, rather than pointing it at a
folder.

### Will my data be used to train somebody else's model?

That depends entirely on the arrangement and it is a question worth asking in writing.
If you hold the model key you are working under your own agreement with the provider
and can check the terms yourself. If the vendor holds it, you are relying on their
contract and their configuration, and the honest version of that answer appears in a
data processing agreement rather than on a pricing page.

## Sources

- [OpenAI: embeddings](https://platform.openai.com/docs/guides/embeddings)
- [OpenAI: fine-tuning](https://platform.openai.com/docs/guides/fine-tuning)
- [OpenAI: retrieval](https://platform.openai.com/docs/guides/retrieval)
- [WordPress REST API handbook](https://developer.wordpress.org/rest-api/)
- [AI Engine on the WordPress.org plugin directory](https://wordpress.org/plugins/ai-engine/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*