· Feedbot team
RAG Chatbot: How to Train ChatGPT on Your Own Data
What a RAG chatbot is, how retrieval-augmented generation works step by step, and whether to build one with LangChain or buy a hosted tool.

TL;DR. A RAG chatbot answers questions from your own content. For each question it searches your documents, picks the few passages that match best, and asks a language model to answer using only those passages. That is what most people mean by “training ChatGPT on your own data”: the model isn’t retrained, it’s handed the right pages at the moment it answers.
- RAG has five moving parts: chunking, embeddings, retrieval, grounding and a fallback for when nothing relevant is found.
- Most bad answers come from retrieval, not from the model. Fix what gets retrieved before you touch the prompt.
- Build it yourself with LangChain or LlamaIndex and a vector database if the bot is part of your product or your data is unusual. Buy a hosted tool if you need a support bot on your site this week.
- Test it with real questions, including ones your docs can’t answer. A good RAG chatbot says “I don’t know” to those.
We make Feedbot, a hosted chatbot that works this way. This guide is mostly about the technique, and it applies whichever route you take.
What is a RAG chatbot?
Retrieval-augmented generation was named in a 2020 paper by Lewis and colleagues at Facebook AI Research. The idea is simple. A language model knows a lot in general but nothing about your refund policy, your API limits or the hours of your shop. Instead of trying to teach the model those facts, you look them up and paste them into the prompt every time.
A RAG chatbot is a chat interface built on that loop. It’s the standard way to build a support bot, a docs assistant or an internal “ask the wiki” tool, because:
- Facts stay current. Change a page, re-index it, and the next answer uses the new version. No retraining.
- Answers can be checked. You know which passages the model saw, so you can show sources and debug wrong answers.
- The model can admit gaps. If retrieval finds nothing relevant, the bot can say so instead of guessing.
How retrieval-augmented generation works, step by step
Here is the whole pipeline. The first three steps run when you add content. The rest run on every question.
- Collect. Gather the content: website pages, help center articles, PDFs, Markdown docs, FAQ lists. Strip navigation, cookie banners and footers so only real content is left.
- Chunk. Split each document into passages small enough to fit several into a prompt, usually a few hundred to a couple of thousand characters. Split on headings and paragraphs, not in the middle of a sentence, and keep the heading with each chunk so “Refunds” still means something when the passage is read alone.
- Embed and index. Run each chunk through an embedding model. It returns a vector, a long list of numbers where texts with similar meaning end up close together. Store the vectors, the chunk text and metadata (source URL, title, date) in a vector index.
- Embed the question. When a user asks “can I get my money back after 30 days?”, embed that question with the same model.
- Retrieve. Find the chunks whose vectors are nearest to the question’s vector. Many systems also run a keyword search in parallel, because embeddings are weak on exact strings like error codes, SKUs and product names, and merge the two result lists. Keep the top few results, often between 3 and 10.
- Ground. Build a prompt that contains instructions (“answer only from the passages below; if they don’t contain the answer, say you don’t know”), the retrieved passages and the conversation so far. Send it to the language model.
- Answer and cite. The model writes the reply. Good systems attach the source of each passage so the user, or you, can check it.
- Fall back. If no passage scored above a relevance threshold, or the model reports that the passages don’t answer the question, the bot says it doesn’t know and offers another route: a human, a contact form, a link to search.
That’s it. Everything else in RAG engineering is about doing one of those eight steps better.
Chunking: the step people underrate
Chunk size is a trade-off. Small chunks are precise but lose context: a passage that says “this is not available on the Basic plan” is useless if the chunk doesn’t say what “this” is. Large chunks keep context but dilute the match and eat prompt space.
Practical rules that hold up:
- Split by structure first (headings, list items, table rows), then by length.
- Prefix every chunk with its page title and nearest heading.
- Keep tables together, or turn each row into a sentence. A table split across two chunks answers nothing.
- Use one page per topic in your source content. A page that covers shipping, returns and warranty in one block of text produces muddy chunks.
Embeddings and hybrid search
Embeddings find “money back” when the page says “refund.” Keyword search finds “ERR_402” when the user pastes the exact error. Neither is enough alone for a support bot, which is why hybrid retrieval (semantic plus keyword, results merged) has become the default in most serious setups. Some teams add a reranker, a second model that rescores the top 20 or so candidates against the question before the best few go into the prompt.
Grounding, citations and “I don’t know”
Grounding is the instruction that turns a chatty model into a careful one. The prompt should say three things plainly: use only the provided passages, say when they don’t contain the answer, and never invent prices, dates, or policies. Then test that it obeys.
Citations make answers verifiable. Even if you don’t show them to users, log which chunks were used for each answer. When someone reports a wrong answer, the log tells you in seconds whether the problem was missing content, bad retrieval or the model ignoring good passages.
The “I don’t know” path matters as much as the answers. Every question the bot couldn’t answer is a gap in your content, and a list of those gaps, reviewed weekly, is one of the most useful outputs of a support bot.
How to train ChatGPT on your own data
There are five common ways, and only one of them is training in the strict sense.
| Approach | What it does | Good for | Limits |
|---|---|---|---|
| Paste content into a chat | You give the model the text in the conversation | One-off questions about a document | Doesn’t scale, nothing persists, not customer-facing |
| Custom GPT with knowledge files | OpenAI lets you upload files that a GPT searches when answering | Internal helpers for people who already use ChatGPT | Lives inside ChatGPT, not on your website; limited control over retrieval |
| Your own RAG pipeline | You run the eight steps above with an LLM API | Products where the bot is a feature, unusual data, strict control | You build and maintain chunking, indexing, evaluation and the UI |
| Hosted RAG chatbot | A service crawls your site and files and runs the pipeline for you | Support and sales bots on a website | Less control over internals; monthly fee |
| Fine-tuning | Trains the model on example inputs and outputs | Teaching a format, tone or classification task | Poor at storing facts that change; needs retraining for each update |
For a bot that answers customers from your docs, fine-tuning is almost always the wrong tool. Use retrieval. If you also want a specific tone, put it in the system instructions first and only consider fine-tuning if that fails.
Build or buy a RAG chatbot?
What a DIY stack looks like
A typical self-built RAG chatbot in 2026 has these pieces:
| Layer | Common choices |
|---|---|
| Orchestration | LangChain or LlamaIndex, or plain code calling an API |
| Embedding model | An embeddings API from your LLM provider, or an open-source model you host |
| Vector store | pgvector in your existing Postgres, Qdrant, Pinecone, Weaviate or Chroma |
| Ingestion | A crawler, PDF and DOCX parsers, HTML cleanup, a scheduler for re-indexing |
| LLM | Any chat model API |
| Evaluation | A test set of questions plus a framework such as Ragas |
| Front end | A chat widget, auth if users are logged in, conversation storage, a way to hand off to a person |
The first demo takes an afternoon. The tutorials ranking for “rag chatbot” will get you there. The work that follows is what takes months: parsing messy PDFs, re-crawling changed pages, deduplicating near-identical content, handling questions in other languages, building the handoff and the inbox, watching costs, and keeping quality from drifting when someone edits the docs.
Build it if the chatbot is part of the product you sell, your data lives in systems a hosted tool can’t reach, you need control over every step (for example, per-user document permissions), or you have engineers who want to own it.
What a hosted tool gives you
A hosted RAG chatbot runs the same pipeline behind a dashboard. You give it a URL or files, it chunks, embeds and indexes them, and you paste a script tag on your site. You also get the parts that aren’t RAG but that a customer-facing bot needs: a widget, conversation history, human handoff and analytics.
Buy it if the goal is a support or sales bot on your website, your content is public pages and documents, and you would rather spend the engineering time on your product.
As an example of what “hosted” means in practice, here is how Feedbot handles it, as described in our knowledge base docs: sources can be website pages, sitemaps, PDF, DOCX, Markdown, TXT or CSV files, plain text and FAQ. Each source is split into passages of about 2,400 characters, each prefixed with its nearest heading. For each reply it runs a semantic search and a keyword search, merges them, and gives the model the 5 most relevant passages, plus a business profile and your custom instructions, which are included in every reply. When it doesn’t know, it says so and the question shows up as a gap. Website import and file upload start on the $5 Starter plan; the free plan uses text and FAQ you type in. More on the knowledge base chatbot page.
Other hosted options include Chatbase, Intercom Fin and Tidio’s Lyro, each priced differently. Our AI chatbot pricing breakdown compares what they cost at real volumes.
How to evaluate a RAG chatbot
Don’t judge a RAG chatbot by chatting with it for ten minutes. Build a small test set and run it every time you change content, chunking or the prompt.
- Collect 30 to 50 real questions from your inbox, search logs or sales calls. Include easy ones, ones phrased oddly, ones in other languages and at least 10 that your docs can’t answer.
- Write the expected answer (or “should say it doesn’t know”) and the source page for each.
- Check retrieval separately. For each question, did the right passage appear in the retrieved set? This is often called context recall. If it didn’t, no prompt will save the answer.
- Check the answer. Is it correct, is every claim supported by the retrieved passages (faithfulness), and does it actually address the question?
- Check the refusals. For the unanswerable questions, did the bot decline and offer a next step, or did it make something up?
Ragas and similar tools automate some of these scores with an LLM as the grader. They’re useful for spotting regressions, but read a sample of answers yourself too. Automated graders miss tone problems and confidently wrong answers that sound plausible.
Common RAG failure modes and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| Says “I don’t know” when the answer is on your site | Page never indexed, blocked by robots.txt, or content rendered by JavaScript the crawler didn’t run | Check the source list; re-import; add the fact as text or FAQ |
| Answers with an old price or policy | Index is stale | Re-crawl after every content change; delete outdated pages |
| Mixes up two products or plans | Chunks lost their headings, or one page covers several products | Prefix chunks with titles; split pages by topic |
| Can’t find exact codes, SKUs or names | Embedding-only retrieval | Add keyword search (hybrid retrieval) |
| Right passage retrieved, wrong answer | Too many passages, conflicting content, weak instructions | Remove duplicates, tighten the grounding instruction, test a stronger model |
| Invents details not in your docs | No fallback rule, or the model fills gaps with general knowledge | Explicit “only from passages” instruction; test with unanswerable questions |
| Long, hedging answers | Prompt asks for completeness over brevity | Set a length and format in instructions |
| Good in English, worse in other languages | Docs and questions in different languages | Use a multilingual embedding model; check answers per language |
Notice that most rows are content and retrieval problems. In our experience the fastest way to improve a RAG chatbot is to read 20 bad answers, look at what was retrieved for each, and fix the content.
What a RAG chatbot can’t do on its own
Retrieval gives a bot knowledge, not abilities. A plain RAG chatbot can tell a customer your refund policy. It can’t check whether their order qualifies, issue the refund or know who they are. For that you need identity (the bot knowing which logged-in user it’s talking to), actions (calling your API), and a human handoff for everything else. If you’re planning a bot that does those things, our pages on the AI customer service agent and customer service automation cover how the pieces fit together, and ChatGPT for customer service covers where a general chatbot stops being useful.
Sources
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020): https://arxiv.org/abs/2005.11401
- OpenAI Help Center, Knowledge in GPTs: https://help.openai.com/en/articles/8843948-knowledge-in-gpts
- LangChain documentation: https://docs.langchain.com/
- LlamaIndex documentation: https://docs.llamaindex.ai/
- Ragas documentation: https://docs.ragas.io/
- pgvector: https://github.com/pgvector/pgvector