How to Build a Custom RAG Knowledge Base for E-Commerce Stores in 2026

A product catalog is not a document corpus, and treating it as one is the single most expensive mistake in commerce AI. The failure is predictable: a customer asks whether a jacket is warm enough for a Scottish November, the retriever returns three semantically adjacent descriptions that share the word "warm," and the model synthesizes a confident answer about thermal ratings the product does not have. Multiply that by 40,000 SKUs, hourly price mutations, and a returns policy that varies by region, and you have an LLM that is fluent, fast, and legally exposed.

The thesis of this article is that production-grade commerce RAG is a structured-entity retrieval problem wearing a semantic-search costume. The architectures that survive contact with real traffic are hybrids: a canonical entity plane for volatile facts, a semantic plane for narrative content, a deterministic filter layer for constraints, and a synthesis layer that is forbidden from inventing anything it did not retrieve or resolve through a typed tool call.

Why Generic RAG Degrades on Commerce Data

The standard "embed PDFs, cosine-similarity top-k, stuff into context" pattern fails on commerce for structural reasons, not tuning reasons.

• Mutation rate outruns index freshness. Prices, inventory, promotions, and shipping cutoffs change far more frequently than embedding pipelines can re-index. A vector embedding of "on sale for $89" is a stale fact with a 24-hour half-life.
• Attribute density exceeds natural language. Fitment, dimensions, materials, certifications, compatibility matrices. Prose descriptions flatten these into adjectives; retrieval needs them as discrete, filterable fields.
• Query intent is frequently underspecified or multi-hop. "Does this fit my 2019 Tacoma with a 2-inch lift and a bed rack?" is a constraint-satisfaction problem, not a similarity problem. No embedding model solves arithmetic on constraint sets.
• Negative queries dominate support traffic. "Why hasn't my order shipped?" has no semantic neighbor in a product catalog. It requires lookup, not retrieval.
• The cost of a wrong answer is asymmetric. A hallucinated warranty term generates refunds, chargebacks, and regulator attention. A hallucinated movie plot generates a shrug.

Architectural Note: The moment you allow an LLM to state a price, a stock level, or a delivery date sourced from a retrieved text chunk, you have built a system that is guaranteed to be wrong at scale. These fields must be resolved through deterministic reads and bound to the response with an explicit TTL.

The Four-Plane Knowledge Architecture

A durable commerce RAG deployment separates concerns into four planes that fail independently.

1. Canonical Entity Plane. The system of record: SKU, variant, price, inventory, fitment, warranty, locale-specific policy. Read live or near-live. Never embedded.
2. Semantic Plane. Vector and lexical indexes over narrative content: enriched descriptions, review summaries, manuals, FAQ pairs, comparison content. Rebuilt on a versioned schedule.
3. Retrieval Plane. The query planner, pre-filter resolver, fusion layer, and reranker. This is where relevance quality is actually won.
4. Synthesis Plane. The generation model, tool-calling layer, citation binder, and refusal policy. This is where trust is won or lost.

The critical property of this design is that the synthesis plane has two independent channels: retrieved narrative context and deterministically resolved facts. A price never arrives through the retrieval channel, because the retrieval channel is untrusted by construction.

The Ingestion and Enrichment Pipeline

Ingestion is where most teams underinvest and then spend six months blaming the model.

1. Change Data Capture. Subscribe to product, price, inventory, and content webhooks from Shopify, Medusa, BigCommerce, or your internal PIM. Emit every change to a durable queue with an idempotency key derived from (entity_id, content_hash, schema_version). Deduplicate aggressively — catalog updates arrive in storms.
2. Normalization. Map heterogeneous source payloads into one canonical entity schema. Normalize units, currencies, locales, and category taxonomies. Milestone: a single internal representation that survives a platform migration.
3. Enrichment. Use LLM workers to extract structured attributes from unstructured copy, summarize review corpora into constraint-relevant claims, and derive fitment rows from compatibility tables. Every enrichment output must validate against a JSON Schema before it is allowed into the index — free-text enrichment is an unkillable data-quality liability.
4. Entity Card Compilation. Compile the retrievable unit. One card per variant, not per product, with a strict size budget.
5. Dual-Write Indexing. Write simultaneously to the vector index, the lexical index, and the attribute store, all tagged with an index_generation identifier so you can roll back atomically.
6. Tombstoning and Deletion. Discontinued SKUs must be purged from all three planes, not just hidden. Retaining embeddings of deleted products is a GDPR surface and a hallucination vector.

An entity card is the contract between ingestion and retrieval. Conceptually:

entity_id: sku_8842_blk_m
identity: { brand, model, variant, gtin }
filterable: { price_band, in_stock, size, color, material, fitment_codes[] }
narrative: { enriched_description, review_claims[], manual_excerpt, faq[] }
provenance: { source_url, last_verified_at, index_generation }

The filterable block is what makes pre-filtering possible. If an attribute is not in that block, it cannot constrain retrieval — and a query that depends on it will silently degrade to pure similarity search.

Chunking Strategy Is the Highest-Leverage Decision

Chunking determines your recall ceiling. No reranker recovers from a chunk that never contained the answer, and no fusion algorithm recovers from a chunk that blends two products' attributes into one retrievable unit.

Milestone: every chunk in your vector index must be traceable to exactly one entity ID. If a chunk can be traced to two, your attribution layer is already broken.

Retrieval: Filter First, Fuse Second, Rerank Last

The retrieval sequence matters more than any individual component.

• Query planning. Classify the incoming query into intent classes: volatile-fact, constraint, discovery, comparison, post-purchase. Route each class down a different path. A single retrieval path for all intents is the most common architectural shortcut and the most common source of quality regressions.
• Pre-filtering, not post-filtering. Apply attribute constraints inside the index query. Post-filtering after top-k retrieval collapses recall to near zero on narrow constraint sets — a size-9, in-stock, waterproof boot query may return nothing after filtering because the unfiltered top-50 contained no size 9 at all.
• Hybrid fusion. Combine BM25 and dense retrieval with Reciprocal Rank Fusion. Commerce queries are unusually keyword-heavy — model numbers, part codes, dimensions — and lexical retrieval outperforms embeddings on exact identifiers.
• Cross-encoder reranking. Rerank the fused candidate set of 50–100 down to 5–8. This is the single highest-ROI latency spend in the pipeline; it typically lifts top-3 precision far more than upgrading the embedding model.
• Fact resolution as a parallel branch. Price, stock, ETA, and warranty resolve through typed tool calls to the commerce API, executed concurrently with retrieval, not after generation.

Production Caveat: Version your prompt, your model, your embedding model, and your index generation as a single deployable tuple. Changing the embedding model without a full re-index produces a silent relevance collapse that looks like a random quality dip and will consume a week of debugging.

Synthesis, Grounding, and Latency Discipline

The synthesis layer's job is compression and citation, not knowledge.

• Bind every factual claim to either a retrieved chunk ID or a tool-call result. Claims without a binding are dropped, not softened.
• Enforce a refusal policy. When reranker scores fall below a calibrated threshold, route to human support rather than generating a plausible answer.
• Inject volatile facts as structured JSON in the system context, never as prose, so the model treats them as data rather than retrievable text.
• Maintain conversation state explicitly: cart contents, viewed SKUs, locale, and prior tool results with timestamps, so follow-up queries inherit constraints without re-deriving them.

A realistic latency envelope for a streaming answer: query planning 30–80 ms, pre-filter resolution 20–50 ms, hybrid retrieval 60–120 ms, reranking 80–200 ms, tool calls 50–150 ms (parallelized), time-to-first-token 300–600 ms, full answer 1.2–2.5 s. If your p95 exceeds 3 s, the problem is almost always serialized tool calls or an oversized rerank candidate set — not the generation model.

Evaluation and Production Checklist

Offline benchmark scores correlate weakly with commerce outcomes. Build the harness before you tune anything.

• Golden set.