What 'Grounded' Actually Means for a Shopping Assistant

“Grounded” has turned into a tick box. Retrieve some relevant records, put them in the prompt, let the model write over them. As a diagram that is fine, and it is the reason retrieval-augmented generation works at all.

It also under-specifies the job. An assistant grounded in a documentation set can be vague and nobody is harmed. A shopping assistant that is wrong about a price, a stock level or a promotion has told a customer something they will act on. That becomes a support ticket, a refund argument, or a claim you have to honour.

Five things have to hold before the word means anything in commerce.

Freshness: a stale answer is worse than no answer

Most retrieval systems index on a schedule, often overnight. That is fine for a returns policy and wrong for a shop.

A product record has two halves that move at completely different speeds. Descriptive attributes (fabric, cut, dimensions, care instructions) barely change. Commercial state (price, stock, promotion, delivery estimate) changes all day.

So we split retrieval to match. Descriptive material is embedded and indexed like any document. Commercial state is read at answer time from the same feed the product page reads, on every answer. Where the index and the live read disagree, the live read wins, and the assistant will not state a fact it could not read fresh.

There is a quick test for any vendor demo. Change a price in your admin, then ask the assistant about that product. If the answer catches up tomorrow, the system is cached, not grounded.

Scope: the catalogue is the whole world

A language model has absorbed a great deal about your category. Treat that as the hazard, not the asset.

Ask it about a jacket it cannot see and it will produce a convincing one: a waterproof rating borrowed from a competitor, a sizing chart from a brand you do not stock, occasionally a product that has never existed. None of it looks like an error, which is what makes it expensive.

Closed-world retrieval is the fix. An answer may only be assembled from records that came back from your systems on this request. No fallback to model memory when retrieval is thin, and no quietly filling a gap in a sparse record with what the model believes about the brand.

The line we draw is between general and specific. General guidance (how to layer for winter cycling, what a denier rating measures) is safe. Any claim attached to a particular product has to come from a particular field.

That constraint makes an assistant less impressive in a demo and considerably more useful on a live site.

Attribution: show the product you answered from

Every factual sentence traces to a record, and the record is put on screen: real product cards, clickable, showing the price and availability the answer was built on.

That does three jobs at once. The shopper can check the claim instead of trusting it. The shopper can act on it, because the card is also the route to the basket. And your team can debug it, because a bad answer becomes an inspectable retrieval rather than a mystery about model behaviour.

The corollary matters more than the feature. If an assistant cannot name what it read, treat the answer as ungrounded no matter how well it reads.

Rules-awareness: the record is not the whole context

An assistant can retrieve a perfectly accurate record and still give a wrong answer, because trading rules are not attributes.

Promotion eligibility is the clearest case. Discounts carry exclusions, minimum spends, channel and region limits, stacking rules, membership tiers, end dates. When an assistant says “yes, that is in the sale and your code will work on it”, it has made a commitment on your behalf. If eligibility was inferred from a badge on a page rather than evaluated against the rule, you either honour a discount you did not offer or argue with the customer about it.

So the assistant queries the system that owns the answer, scoped to the actual basket and shopper, rather than summarising what a page appears to say. The same applies to age-restricted lines, postcode delivery limits, and items outside your free-returns terms.

Refusal: “I cannot confirm that, here is who can”

The last property is the hardest to accept, because a refusal reads like a failure. Set it against the alternative, which is a confident invention.

The assistant should decline when retrieval comes back empty or thin, when sources conflict, when the question needs an account-specific fact it cannot see, or when the answer would be a commitment no system of yours will underwrite.

A good refusal is not a dead end. It names what it could not confirm, offers the closest thing it can support, and routes the shopper somewhere useful: your support queue, a store, a callback.

Then measure it. Track refusal rate next to answer quality. Zero refusals means the assistant is answering questions it has no business answering, and a rising rate is usually pointing at a gap in your catalogue data rather than a fault in the model.

Grounding is measurable, so measure it

None of this is a setting you switch on. It is five properties, and each one can be tested against a fixed question set built from your real search logs and support tickets, scored on whether the answer is supported by the records retrieved rather than on how well it reads. Fluency is free now. Support is the thing worth grading.