Retrieval-Augmented Generation (RAG) for Commerce

Retrieval-Augmented Generation (RAG) is an AI architecture that pairs a large language model with an external knowledge base. Instead of relying only on what the model learned during training, the system retrieves relevant documents at query time and passes them to the model as context. The model then generates its response grounded in those retrieved documents rather than in its frozen training data.

The approach was introduced by Facebook AI Research in the 2020 paper "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (Lewis et al., NeurIPS 2020). It has since become the default architecture for enterprise LLM deployments because it solves three of the biggest problems with standalone LLMs: outdated training data, hallucination on specific facts, and the inability to access private or proprietary information.

In commerce, RAG is what lets an assistant answer "is this jacket in stock in my size?" from current data rather than from training memory. The major AI shopping surfaces, including ChatGPT Shopping, Google AI Mode, Perplexity and Amazon Rufus, retrieve from product feeds, indexed pages and the open web in some form before they generate.

A commerce RAG pipeline runs in four stages:

1. Ingestion. Product catalog, inventory, reviews, policies, and support docs are chunked, embedded (converted into vector representations), and stored in a vector database or hybrid retrieval index. For commerce, structured product attributes (SKU, price, availability, variants) are typically indexed alongside unstructured text (descriptions, reviews, Q&A).

2. Query embedding. When a shopper asks a question ("waterproof hiking boots for flat feet under $200"), the system embeds the query into the same vector space as the catalog and retrieves the top N semantically relevant products and documents.

3. Context assembly. Retrieved products, policies, and any relevant session context are assembled into a prompt. For shopping, this usually includes product cards, current prices, stock levels, shipping info, and any policies that affect the answer (return policy, warranty).

4. Grounded generation. The model generates its response from the assembled context. Because it is conditioned on retrieved data, it can cite specific SKUs, correct prices and current availability, and say "that is out of stock in your size, here are two alternatives" with confidence.

The answer can only be as good as what was retrieved. Missing attributes, thin descriptions and stale feeds produce confident-sounding but wrong recommendations, or no recommendation at all. That is why product data enrichment and structured product data matter so much: they are the inputs the retrieval step has to work with. Paz handles that side for ecommerce teams. A Paz expert finds the gaps in your product information, fixes them from your sources, our experts check the changes against agreed guidelines, and the fix reaches supported store and feed destinations. See how the product content service works.

Three architectural choices come up in commerce AI:

Plain LLM. Ask a model without retrieval "what laptops does Best Buy have in stock?" and it will produce plausible-sounding SKUs and prices that are wrong. Plain models cannot answer inventory, price or availability questions reliably, which is why serious shopping features retrieve first.

Fine-tuning. Training a model on a retailer's specific data can improve tone and domain-specific reasoning. It does not solve the freshness problem - inventory changes minute-to-minute and a fine-tuned model is stuck with whatever data was in its training set. Fine-tuning is expensive, slow to update, and gets worse over time unless constantly retrained.

RAG. The knowledge base can be updated continuously. A retailer can re-embed descriptions nightly and reflect inventory every few minutes without retraining the model. This is why RAG is the dominant pattern for enterprise deployments.

The practical answer for most commerce teams: use RAG as the primary architecture, layer a small amount of fine-tuning (or system prompts) on top if you need a specific voice or reasoning style. Do not bet on a plain LLM for anything that touches real product data.