Retrieval-Augmented Generation has a simple idea at its core: don’t make the model memorise your business, let it look things up. At question time, the system searches your data, pulls back the relevant pieces, and hands them to the model alongside the question. The model answers from what it was just shown.
That is exactly why RAG suits e-commerce. A store’s knowledge is large, it changes by the hour, and parts of it carry legal weight. You cannot retrain a model every time a price moves or a return policy is edited.
In Your Catalog Is Not a Pile of Documents I argued that commerce is four retrieval problems wearing one name: facts, semantics, relationships and policy. This post is the follow-up on where RAG itself belongs in that picture.
Where RAG earns its place
Live catalog facts. Price, stock and delivery estimates should be fetched at question time from the system of record, never remembered by a model. This is retrieval in its purest form: look it up, don’t guess it.
Policy with citations. Returns, warranties and shipping guarantees need a versioned, jurisdiction-scoped store. Retrieval returns the clause, the generator quotes it, and the answer can be audited. If retrieval comes back empty, the assistant says so instead of improvising.
Fresh reviews and Q&A. Customer language changes weekly. Retrieval keeps the assistant current without any retraining.
The proposed shape
Put a retrieval gateway between your agents and your data. Behind it sit three stores: a structured index for facts, a hybrid dense-plus-keyword index for product semantics, and a policy store with effective dates. The gateway routes each sub-question to the right store, reranks the results, and returns evidence with source references attached.
Where to keep RAG out
Do not use it for stable knowledge that every request needs, such as brand voice or the store’s fixed rules. You pay retrieval latency and retrieval error on every call for something that never changes. That is the job of the next post.