Ask an LLM a question about your WordPress site’s actual content, your refund policy, your latest changelog entry, the exact steps in your onboarding guide, and it will answer confidently. It will also frequently be wrong, not because the model is broken, but because it was never given your content in the first place. This lesson is about that gap and the pattern that closes it: retrieval-augmented generation, RAG.
Course 1’s PHP AI Client SDK overview and Course 5’s Generating Embeddings lesson. No code runs in this lesson, it’s the conceptual foundation the rest of the course builds on.
Step 1: Why an LLM alone can’t answer questions about your site
A large language model’s knowledge comes entirely from what it saw during training, frozen at some cutoff date, plus whatever text you put directly in its context window for a given request. It has no live connection to your WordPress database. Ask it “what does my site’s shipping policy say,” and unless that exact text was somehow in its training data or you pasted it into the prompt, the model has nothing real to draw on.
That’s the part people underestimate: the model doesn’t know it doesn’t know. It doesn’t return an error or say “I have no data on that.” Language models are built to produce plausible, well-formed continuations of text, and a plausible-sounding wrong answer is just as easy for it to generate as a correct one when it has no real facts to ground the response in. That’s hallucination: not a glitch, but the default outcome of asking a model to answer from missing information.
Step 2: Two ways to actually give the model your content
There are really only two honest ways to make an LLM answer accurately about specific content it wasn’t trained on:
- Put the whole thing in the prompt. Paste your entire refund policy, or your entire knowledge base, into the request every time. This works, until your content is bigger than the model’s context window, or until you’re paying to re-send thousands of words of mostly-irrelevant text on every single question just to answer one line of it.
- Find only the relevant part, then put that in the prompt. Search your content for the few paragraphs that actually relate to the question, and send only those. This is retrieval-augmented generation: retrieve first, generate second.
RAG exists because option 2 scales and option 1 doesn’t. A site with ten posts can get away with stuffing everything into a prompt. A site with ten thousand posts cannot, and even if it could, most of that context would be wasted tokens the model has to wade through to find the one relevant paragraph.
Step 3: The retrieve-then-generate pattern, concretely
RAG splits answering a question into two distinct stages that don’t share the same mechanism:
The retrieval stage is the part most tutorials skip past or fake, and it’s the entire subject of this course. It requires: converting content into a form that can be searched by meaning rather than exact keyword match (embeddings, Lesson 2), breaking long content into searchable pieces (chunking, Lesson 3), storing those pieces somewhere queryable (Lessons 4 and 5), and actually running the search (Lesson 6). Only once all of that exists does the generation step, Lesson 7, have real material to ground its answer in.
Step 4: Why this matters more than the model you pick
It’s tempting to think accuracy is a matter of choosing a “smarter” model. It mostly isn’t. A state-of-the-art model given no relevant content will hallucinate just as readily as a small one, arguably more convincingly, since it’s better at sounding confident while doing it. A modest model given the actual correct paragraph from your site will answer correctly far more often than a flagship model given nothing. Retrieval quality, not model choice, is usually the ceiling on how trustworthy your assistant is.
That’s why this course exists as its own, deep unit rather than a single lesson tacked onto Course 5: everything downstream, the assistant in Course 3, the editorial automation in Course 6, any autonomous agent later in the track, inherits whatever retrieval pipeline sits underneath it. Build it carelessly and every one of those projects inherits confidently wrong answers.
A common mistake is treating a model correcting itself when challenged as evidence the underlying problem is minor. It isn’t. If a user has to already know the right answer to catch the model’s mistake, the assistant provided no value, and worse, it provided false confidence to anyone who didn’t already know better. RAG is what prevents the wrong answer from being generated in the first place, not a mechanism for cleaning it up after.
Test it: notice the gap yourself
Before writing any retrieval code, confirm the problem exists on your own content. Ask an AI assistant, any of them, a specific factual question about a page or post on your own site that was published recently or contains a specific number, date, or policy detail. Notice whether it answers with a plausible-sounding guess, admits it doesn’t know, or actually gets it right by coincidence. That gap between “sounds right” and “is right” is exactly what the rest of this course closes.
Recap
An LLM only knows what was in its training data or what you put in its prompt, and it has no way to signal when it’s answering from neither. RAG fixes this by splitting the work into retrieval, finding the actual relevant content, and generation, writing an answer grounded in what was retrieved. Retrieval quality, not model choice, is what determines whether an assistant is trustworthy, and building that retrieval pipeline properly is what the remaining eight lessons of this course do.
Resources & further reading
- PHP AI Client SDK repository, GitHub
- Introducing the WordPress AI Client SDK, make.wordpress.org
- AI Building Blocks for WordPress, make.wordpress.org