Training a chatbot on your own data, not a generic script

"Trained on your data" gets thrown around loosely in this space. Here's what it actually means technically, and why the distinction changes what the bot can and can't do.

Fine-tuning versus retrieval — and why we default to the second

There are two fundamentally different approaches people mean when they say "trained on your data." Fine-tuning adjusts a model's internal weights using your data as training examples — expensive, slow to update, and prone to the model quietly forgetting general capabilities as it specializes. Retrieval-augmented generation (RAG) leaves the base model untouched and instead retrieves relevant chunks of your actual content at query time, feeding them to the model as context alongside the question. For nearly every business chatbot use case, RAG is the right choice: it's cheaper, updates instantly when your documentation changes, and — critically — it's auditable, because you can see exactly which source document informed any given answer.

What the pipeline actually looks like

Your source material — help docs, policy PDFs, past support tickets, product specs — gets split into chunks (typically 300-800 tokens, small enough to be specific, large enough to retain context), converted into vector embeddings using an embedding model, and stored in a vector database. When a customer asks a question, their message gets embedded the same way, and the system retrieves the most semantically similar chunks — not keyword matches, but conceptual matches, which is why a question phrased completely differently from your documentation can still retrieve the right source.

Those retrieved chunks get passed to the model with an instruction: answer using only this content, and say you're not sure if the answer isn't here. This constraint is what prevents hallucination on business-critical facts like pricing or policy — the model isn't drawing on its general training knowledge, it's restricted to what you actually indexed.

Why generic scripts fail differently than people expect

A decision-tree chatbot (the older "click a button to narrow down your question" style) fails by being rigid — it can't handle a question phrased outside its predefined paths. A generic LLM chatbot with no RAG grounding fails more dangerously: it sounds confident and answers fluently, but may be drawing on generic training knowledge rather than your actual current policy, which is worse than an obviously broken decision tree because customers trust the confident wrong answer.

The maintenance question nobody asks upfront

A RAG-grounded bot is only as current as its index. If your pricing changes and nobody re-runs the ingestion pipeline, the bot answers with stale data — confidently. We build automated re-indexing (triggered on document changes, or on a scheduled interval) as a standard part of every deployment, not an afterthought, because a bot that quietly drifts out of date is a worse liability than one that was never built.

How Ndakum approaches it

This RAG architecture is the foundation of every AI Chatbot we build — grounded in your actual current content, with automated re-indexing so it doesn't drift stale.