Set Up a RAG Chat Bot with VBWD: Answers Grounded in Your Own Content

A step-by-step guide to a retrieval-augmented chat bot on VBWD: retrieval rides the privacy-blocked search-provider registry, generation rides the LLM connection manager, and cost is bounded by tokens.

A chat bot that makes things up is a liability; RAG grounds its answers in your own content, and VBWD gives you the retrieval and generation seams to do it safely.

Most support chat bots either make things up or send your customers to a generic FAQ that answers nothing. A RAG chat bot fixes the first problem by refusing to answer from thin air: it retrieves passages from your own content first, then writes a reply based on those passages. This guide walks through standing one up on VBWD, where the retrieval and generation pieces are already wired as plugins on a self-hosted, source-available stack.

What RAG means here, and why grounding matters

RAG stands for retrieval-augmented generation. Instead of asking a language model to answer from whatever it memorized during training, you first retrieve relevant snippets from a content source you control, then hand those snippets to the model and ask it to answer using them.

The business reason to care is trust. An ungrounded bot will confidently invent a refund policy, a product spec, or an opening hour. A grounded bot answers from the pages you actually published, so its replies track your real content and change when you update it. For anything customer-facing, that difference is the whole point.

On VBWD the two halves of RAG map to two existing seams. Retrieval rides the search-provider registry. Generation rides the LLM connection manager. Both are core seams that plugins plug into, which is why you configure a bot rather than build one from scratch. You can see how the platform is organized on the architecture overview.

Step-by-step setup

The following sequence assumes you already run VBWD or are starting fresh. None of it requires touching core code.

1. Install VBWD via Docker. VBWD ships as a Docker stack: Python/Flask API, PostgreSQL, Redis, and a Vue 3 / TypeScript frontend. Bring it up the usual way:

./recipes/dev-install-ce.sh
# or, if you already have a checkout:
make up-build

This gives you the backend, the database, and the admin and user frontends running locally.

2. Enable the chat plugin and its LLM-bot variant. The chat surface (meinchat) is a plugin, and its LLM-bot variant is what turns a plain chat widget into an answering bot. Enable both from the admin plugins panel. Because VBWD keeps a single source of truth for plugin state, enabling here flips the bot on for the whole instance. If you want to see what else is available on the same platform, the plugin catalogue lists the rest.

3. Configure an LLM connection. The generation side reads from the LLM connection manager, where you set your provider, credentials, and model once, centrally. Every bot on the instance then draws from that single configuration, so you rotate a key or switch models in one place rather than editing each bot.

4. Register your content with a search provider. This is the step people skip, and then wonder why the bot has nothing to say. The bot can only retrieve from content that a plugin has exposed through the search-provider registry. CMS pages, catalogue and product entries, and datasets each get registered as searchable slices. If a knowledge source is not registered, it is invisible to retrieval no matter how good the model is.

5. Set token limits. Before you expose the bot, cap its usage (covered in the metering section below). Do this now so a public widget cannot run up an unbounded bill on day one.

6. Embed the chat widget on your site. Drop the chat widget onto your pages. From here the loop is: a visitor asks a question, VBWD retrieves matching snippets from your registered content, the LLM writes an answer from those snippets, and the reply comes back in the widget.

How retrieval and privacy work together

The search-provider registry is worth understanding because it does double duty. It is both how content becomes retrievable and how private data stays out of the bot’s reach.

Each plugin decides which slices of its data it exposes as readable and searchable. Public-facing content — CMS pages, catalogue, products, datasets — gets exposed. Privacy-sensitive slices such as user records and invoices are blocked at the seam. They are simply not reachable through the surface the bot queries.

That has a concrete consequence: the bot retrieves from your own content and structurally cannot leak personal data through that surface. It is not a filter you have to remember to switch on and hope holds; the sensitive slices never enter the retrievable set in the first place. For a GDPR conversation, “the retrieval surface has no path to invoices or user records” is a far stronger claim than “we told the model not to look.”

Self-hosting reinforces this. Because you run VBWD on your own infrastructure, your content and the conversations with the bot stay on hardware you control rather than passing through a third party’s chat product. The only data that leaves is what your configured LLM call sends to your chosen provider, and you decide who that provider is. More on how the pieces fit sits in the documentation.

Metering and cost control

Language model calls cost money per token, and a chat widget on a public page is an open invitation to spend it. VBWD treats bot usage as metered and bounded through its token and credit system, so consumption is measured and billable rather than open-ended.

Practical controls to set before launch:

Cap tokens per request so a single question cannot pull an enormous context or generate an essay.
Bound usage over a period so a spike in traffic — or an abuser — hits a ceiling instead of your credit card.
Watch the metered figures after go-live and tune limits against real conversation volume rather than a guess.

Because usage is billable through the same credit system, you can also treat the bot as a metered feature for your own customers if that fits your model, instead of absorbing every call as pure cost.

Honest limits

RAG grounds answers. It does not guarantee they are correct, and it is worth being clear about that before you put a bot in front of customers.

Retrieval quality depends entirely on what content you registered and how it is chunked and indexed. Thin, stale, or poorly structured content produces thin, stale answers. A page the bot never retrieves is a page it cannot use, so coverage is a content problem as much as a technical one.

Even with good retrieval, the language model can still be wrong. It can misread a snippet, blend two sources, or overstate a caveat. Grounding narrows the failure modes; it does not remove them. So build for it:

Cite sources in replies, so a reader can check the answer against the page it came from.
Keep a human path — a way to reach a person when the bot is unsure or the stakes are high.
Review real conversations and feed the gaps back into your content, since fixing the source page fixes every future answer that retrieves it.

Takeaway

A RAG bot on VBWD is an assembly job, not a build-from-scratch one: install the Docker stack, enable the chat and LLM-bot plugins, point the generation side at an LLM connection, register your content with a search provider so it is retrievable, set token limits, and embed the widget. The search-provider registry gives you retrieval from your own content while structurally keeping user records and invoices out of reach, and self-hosting keeps the whole exchange on your infrastructure. Set the limits, cite the sources, keep a human in the loop, and you get a bot that answers from what you actually published. The features overview is a good next stop for seeing how the chat, search, and billing pieces line up across the platform.