When a chatbot makes things up, it is almost never because the model is broken. It is because the model was asked a question with zero useful context, so it answered from training data that may be three years out of date and never knew about your business. The RAG pattern (retrieval-augmented generation) fixes that by inserting the right pieces of your actual content into the prompt at request time. The trick is doing the retrieval well, in a way that fits how your data is shaped.

SleekAI implements RAG natively against the WordPress database. When a visitor asks a question, the plugin runs a retrieval step against the content you have mapped (posts, pages, custom post types, postmeta fields, taxonomies, custom tables) and selects the top matching chunks. Those chunks are inserted into the system prompt with their source slugs so the model can cite where each fact came from. Retrieval supports keyword, BM25, and vector modes; you choose per bot and you can plug in your own embedding model.

The reason most chatbot platforms struggle with RAG on WordPress is the indirection. They pull your sitemap, scrape rendered HTML, and end up indexing menus, footers, and cookie banners alongside the actual answer. SleekAI reads the database directly, so a product description is a product description, a docs page is a docs page, and a custom field labeled policy_text is exactly that. The retrieval is over real fields, not over noise. Citations point to specific posts and meta fields, so when the bot says it pulled an answer from your refund policy, you can click through to the row.

The case for retrieval-augmented generation is well understood at this point: hallucinations come from missing context, retrieval supplies the context, citations let the user verify. What is less understood is how much architecture you have to compromise on when the retrieval lives outside your CMS. External RAG services usually crawl your sitemap, render pages with a headless browser, parse the resulting HTML, strip out what they think is chrome, and feed the rest to an embedder.

By the time the chunks reach the vector store, they have been guessed at twice and updated last whenever the crawler last ran. The product description that changed at 9am is still showing yesterday's price at noon. The custom field for return windows is not even part of the page they crawled.

Reading the database directly is the only way to keep retrieval honest. SleekAI's RAG runs against the same rows the front end renders from. A post update means a fresh index entry, not a re-crawl.

A custom field is a first-class chunk with its own metadata, not buried inside scraped HTML. Citations point to actual post IDs, so when the bot says it pulled an answer from your refund policy, the link goes to that exact post. RAG is supposed to make answers verifiable.

Doing it inside WordPress is what makes the verification real.