Grounding an Assistant in Your Own Content: What It Takes
A grounded AI assistant answers from pages you own, which means a wrong answer is fixed by editing a page. Getting there is mostly content work, and almost none of it is model work.
On This Page
A visitor asks your assistant a question and gets a confident, fluent, wrong answer. The policy it described was retired last year and appears nowhere on your site. The interesting question is not why the model did that. Models do that. The interesting question is what you are able to do about it on Tuesday morning, with the person who found it standing at your desk.
That is the case for grounding, and it is a smaller claim than the marketing around it. A grounded AI assistant does not answer from what a model absorbed during training. It retrieves passages from content you control, hands them to the model, and asks for an answer built only from those passages. The model supplies the language. Your content supplies the facts.
The consequence is the whole point: when the assistant is wrong, you edit a page. Not a prompt buried in a repository, not a fine-tuned checkpoint somebody has to retrain, not a spreadsheet of canned replies that drifted out of step with the site two quarters ago. A page. The people who write the pages fix the assistant, which means the assistant stays fixed.
Our position is that grounding is worth doing and is mostly not an AI project. It is a content project with a retrieval layer attached to the end of it, and teams that treat it the other way round build something impressive that is quietly wrong in the places nobody checks.
What a grounded AI assistant actually is
Three steps, in order. A question arrives. A retrieval step finds the passages most likely to contain the answer, from a corpus you assembled. Those passages go into the request alongside an instruction that amounts to: answer from this, cite where it came from, and say you do not know if it is not here.
Everything difficult lives in the middle step. If retrieval hands over the wrong passage, a very good model will write a very good answer that is wrong, and it will cite the wrong passage while doing it. The quality of a grounded assistant is set by what is in the corpus and how it was cut up, long before anyone picks a model. This is the part that gets skipped, because it looks like editorial work rather than engineering.
It is also the part that survives a change of vendor. Models will keep improving and keep being replaced. A well-prepared corpus is portable across every one of them, which is a decent argument for treating it as the durable asset in an AI integration rather than as preparation for the real work.
The corpus is the work
Most sites are not ready to be answered from, and the reasons are mundane. Two pages state the same policy differently because one was updated and the other was forgotten. A key detail lives only in a PDF. The clearest explanation of your process sits in a sales deck that has never been published. The pricing page is deliberately vague because the last conversation about it ended in a stalemate.
Indexing that as it stands produces an assistant that faithfully reproduces your contradictions, at speed, to customers. The retrieval layer is not a filter. It is an amplifier, and the first pass over a corpus is nearly always a content audit wearing a technical hat.
The pages that are not ready
- Duplicates that disagree. Two versions of one fact is worse than none. Pick the page that owns the answer, correct it, and remove or redirect the other before indexing anything.
- Answers that live in images and PDFs. A diagram with the answer inside it is invisible to retrieval. If it matters, it needs to exist as text on a page.
- Pages written to persuade, not to inform. A landing page that never states plainly what the product does gives retrieval nothing to hold. Marketing copy and reference copy do different jobs, and an assistant needs the second kind.
- Anything undated. If nobody can tell when a page was last confirmed as true, nobody can tell whether the assistant should still be quoting it.
- Internal material that was never approved. Support macros and onboarding decks are tempting because they are clear. They are also unreviewed, and an assistant will happily read them aloud to a stranger.
Every wrong sentence you index becomes a wrong answer you have to explain later. Correcting the source is cheaper than adding a rule to the prompt telling the assistant to ignore it, and unlike the rule, the correction also helps the humans reading the page.
What to deliberately leave out
A corpus is defined as much by its exclusions as its inclusions. Leave out anything you would not want quoted word for word to a stranger: unapproved drafts, legal grey areas, and anything containing personal data. Leave out the post from three years ago that contradicts current practice, or update it, because retrieval has no sense of which of two plausible passages is the current one. The editorial standards you already apply to published content are the right standards here too; the corpus is simply another audience, and a less forgiving one.
Chunk boundaries decide the answers
Retrieval does not fetch pages. It fetches fragments, and how you cut the fragments determines what the assistant can and cannot say. This is the least discussed and most consequential decision in the build.
Split on meaning, not on length
The naive approach slices text every so many characters. It is fast and it is wrong, because the qualifying sentence and the claim it qualifies end up in different fragments. Retrieval finds the claim, misses the qualifier, and the assistant states a rule without its exception. That is not a hallucination. It is a filing error, and it is entirely yours.
Split on structure instead: a heading and the passage beneath it, a list kept whole, a table kept whole, a step kept with its warning. Well-structured pages chunk themselves, which is one more reason the content work comes first. Pages built as one undifferentiated wall of text have to be restructured, or they will keep producing amputated answers.
What every chunk has to carry
A fragment on its own is ambiguous. "This is included in the standard tier" means nothing without knowing what "this" refers to. So each chunk needs its context travelling with it: the page title, the heading path above it, the canonical URL, and the date it was last reviewed. The URL is what lets the assistant show its working, and showing its working is what makes an answer checkable by the person reading it. An answer with a link is an answer someone can disagree with. An answer without one is a rumour with good grammar.
Overlap between adjacent chunks helps, within reason. A little repetition at the boundaries keeps sentences from being orphaned. Too much and retrieval returns five near-identical fragments, filling the request with the same paragraph five times and crowding out the passage that actually answered the question.
Freshness, and the answer that was true last quarter
An index is a photograph. The site keeps moving. Unless something reconciles the two, the assistant slowly becomes an archive of what you used to believe, and the drift is invisible because every answer still sounds current.
Reindexing on publish is the correct default: a page changes, its chunks are replaced, and the assistant is current within minutes. Nightly rebuilds are acceptable where publishing is slow. What does not work is a manual reindex that somebody remembers to run, because they will remember for about six weeks.
Deletion matters more than most teams expect. When a page is removed, its chunks have to go with it, or the assistant keeps answering from content the site no longer serves and citing a URL that now returns a 404. That is close to the worst failure mode available to you, because it is confidently wrong and impossible for the reader to verify at the same time.
Carry the review date into the answer where it matters. For anything that changes on a schedule, an assistant that says when a passage was last reviewed lets the reader judge for themselves, and gives your team a visible signal that a page has gone stale. This is the same discipline as designing the states nobody mocks up: the uninteresting condition, handled properly, is what makes a system trustworthy in ordinary use.
Refusal is a feature, not a failure
The single most valuable behaviour in a grounded assistant is its willingness to stop. A system that answers everything is a system that invents, and the inventions arrive in the same tone as the facts, which is exactly what makes them dangerous.
Refusal has to be designed, specified and tested like any other feature. There are three distinct cases, and they deserve three distinct behaviours.
The three kinds of not answering
Nothing retrieved: the corpus holds no passage above the relevance threshold. The assistant should say so plainly and offer the next step, which is usually a human. Partially retrieved: there is a passage, but it answers a neighbouring question. The assistant should answer what it can, name what it cannot, and link the page. Out of scope: the question concerns something you have deliberately decided not to handle in this channel, such as an account-specific or contractual matter. That is a routing decision rather than a knowledge gap, and it should end in a handover, not an apology.
None of this works if the visitor believes they are talking to a person, which is why disclosure and refusal are one design problem rather than two. The wording and the placement are covered in how a chatbot should tell visitors it is not a person, and our parent company has written about the underlying mechanics in why a chatbot gives wrong answers.
An assistant that says "I do not have that, here is who does" earns more trust in one exchange than a hundred fluent answers nobody ever checked.
Why grounding makes an assistant correctable
Compare the ways of making a system say the right thing, by the only measure that matters after launch: what happens when it says the wrong one.
| Approach | How you correct an answer | Who can do it | Main failure mode |
|---|---|---|---|
| Model knowledge alone | You cannot, directly | Nobody | Confident answers about a version of you that no longer exists |
| Instructions stuffed into the prompt | Edit the prompt, redeploy | Whoever owns the codebase | A prompt that grows until it contradicts itself |
| A hand-written answer list | Add another entry | Whoever maintains the list | Drifts away from the site within a quarter |
| Fine-tuning | Curate examples, retrain, evaluate | A specialist, on a cycle | Slow to correct and hard to explain |
| Retrieval over your content | Edit the page and reindex | The person who owns the page | Wrong passage retrieved, which is visible and fixable |
The bottom row is the argument. Correction moves from an engineering queue to an editorial one, and lands with the person who already knows the right answer. The loop closes in an afternoon instead of a sprint, and the fix improves the page for every human reader as a side effect.
That is what separates an assistant from a demonstration: it removes a handoff instead of adding a dashboard, in the sense described in automation that removes a handoff. A widget such as Flidu takes that shape: website-informed assistance sitting alongside contact and conversion actions, so a question the content cannot answer becomes a route to someone who can, rather than a dead end.
What it costs, honestly
Grounding does not make a model incapable of being wrong. It narrows the ways it can be wrong, which is a real improvement and a smaller one than the demonstration suggests. Retrieval still returns the wrong passage sometimes. The model still occasionally blends two passages into a claim neither of them made. Both happen less often with clean content and sensible chunks, and neither goes to zero.
There is standing maintenance too. Reindexing runs, embeddings get regenerated when the model behind them changes, and someone has to read the questions that produced refusals, because that log is the most useful content brief you will ever be handed. Free, in your customers own words, ordered by how often they ask. Most teams never open it.
And the honest concession: if your content is thin, this will not help. An assistant grounded in six pages is a search box with a longer response time. Write the pages first. Deciding which work belongs to a machine at all is its own question, covered in what to automate in a small team, and it is worth settling before anyone builds an index.
The order we would build it
Sequence matters more than tooling here. Each step makes the next one cheaper, and skipping one makes everything after it more expensive.
- Collect the real questions first. Sales emails, support tickets, the site search log. Fifty questions people actually asked beat any feature specification, and they tell you which pages must exist before anything is indexed.
- Fix and consolidate the pages those questions land on. One page owns one answer. Remove the contradictions. Date everything. This is the step that gets cut, and the step that decides the outcome.
- Chunk on structure, and store the context with each chunk. Title, heading path, URL, review date. Keep tables and lists whole. Read a sample by hand before trusting the pipeline.
- Write the refusal behaviour before the ordinary path. Decide what happens when nothing is retrieved, and where the handover goes. An assistant with no exit is an assistant that invents one.
- Build an evaluation set from those first questions. Expected answer, expected source page, expected refusal. Run it on every change. Without it, every improvement is a guess with a good feeling attached.
- Wire reindexing to publishing, deletions included. If this stays manual it will lapse, and the failure is silent until a customer finds it for you.
Ground it in one well-maintained section of the site rather than all of it. One area, properly prepared, with refusal working and an evaluation set attached, is worth more than everything indexed badly, and it shows you what the full corpus will need.
Getting from a working prototype to something you would put in front of customers is its own discipline, laid out in prompt to production. Publish what the assistant may and may not do while you are at it: our own responsible AI commitments exist because a system that answers on your behalf should have its limits written down somewhere a reader can find them. If you are weighing this up for a specific site, tell us what your visitors keep asking and which pages currently fail to answer it.
Common questions.
What does it mean to ground an AI assistant in your own content?
Grounding means the assistant retrieves passages from content you control and answers only from those passages, instead of relying on what a model learned during training. The model provides the wording while your pages provide the facts. Because every answer traces back to a source you can open, a wrong answer is corrected by editing that source and reindexing it.
How is grounding different from fine-tuning a model?
Fine-tuning adjusts a model using curated examples, which changes how it writes and is slow to correct. Grounding leaves the model alone and controls what information it receives at the moment of answering. For company facts, policies and documentation, grounding is usually the better fit, because that information changes often and corrections need to be immediate rather than scheduled.
How should content be split into chunks for retrieval?
Split on structure rather than a fixed character count. A heading with the passage beneath it, a list kept whole, a table kept whole, a step kept with its warning. Fixed-length slicing separates a claim from the sentence that qualifies it, which produces answers that state rules without their exceptions. Each chunk should also carry its page title, heading path, URL and review date.
How do you keep a grounded assistant up to date?
Tie reindexing to publishing so changed pages replace their chunks automatically, and make sure deleted pages remove theirs. Manual refreshes lapse within weeks and the failure is invisible, because outdated answers sound exactly like current ones. Carrying a last-reviewed date through to the answer gives readers a way to judge freshness and gives your team a signal that a page needs attention.
What should an assistant do when it cannot find an answer?
It should say so and offer a route to someone who can help. Three cases deserve different handling: nothing relevant retrieved, a partial match that answers a neighbouring question, and a question deliberately out of scope such as anything account-specific. Designing those responses before the ordinary path is what stops the system from inventing something to fill the silence.
Can a website be the knowledge source, or do you need a separate knowledge base?
The website works well as the source when it is accurate, current and structured, and using it avoids maintaining a second copy that drifts. Add a separate store only for material that genuinely should not be published, such as internal procedures. The moment you keep two sources for the same fact, you have created exactly the contradiction that grounding was meant to remove.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.