01: The Root Cause
Large language models predict language, not truth.
A language model generates text by predicting the most statistically likely next word, based on patterns learned from its training data. It has no built-in mechanism for verifying a claim, checking a live database, or recognizing that its training data is out of date. It also lacks a real concept of “I don’t know.” When the model lacks the right information, it still produces a fluent, plausible-sounding answer because its optimization rewards fluent output.
This is why prompt engineering hits a hard ceiling on factual accuracy. You can instruct a model to “only give verified answers,” but that instruction doesn’t hand it access to the facts it’s missing. Our software and AI engineering team sees this constantly in the RAG systems we ship: the fix was never in the wording of the prompt.
Telling a model to “be accurate” doesn’t give it access to the truth it’s missing. If retrieval never supplies the right context, no instruction can add it after the fact.
02: Failure Modes
Four hallucination types create four different business risks.
In practice, e-commerce hallucinations split into two categories: intrinsic, where the model contradicts the retrieved context, and extrinsic, where retrieval returns nothing relevant and the model fills the gap on its own. Across our work in retail and consumer platforms, four patterns account for nearly every customer-facing incident.
Price hallucinations
The vector index still holds an outdated price because the catalog updated but the index hasn’t refreshed. Result: cart abandonment, price-dispute tickets, and compliance exposure.
Availability hallucinations
The index still serves discontinued or out-of-stock items. Result: support tickets, negative sentiment, and customers who stop trusting the assistant altogether.
Attribute hallucinations
Retrieval surfaces a similar but wrong product, and the model confidently describes the wrong specs. Result: post-purchase returns and eroded trust in every future recommendation.
Recommendation hallucinations
Retrieval returns nothing relevant, so the model invents a plausible-sounding product that doesn’t exist. Result: dead-end journeys and customers who bounce straight to a competitor.
See how we’ve handled this class of problem for real platforms in our case studies.
03: The Fix
Retrieval-augmented generation gives the model a research assistant.
Retrieval-augmented generation (RAG) is an architecture where the model never has to rely purely on what it memorized during training. Before it generates a response, the system retrieves relevant documents, including product listings, policies, and live inventory, from an external knowledge base and injects them directly into the model’s context window. Training freezes a model’s knowledge on its final day, while an e-commerce catalog keeps changing. RAG is the architecture built to close that gap, and it’s a core part of the custom AI development work we build for clients.
Embeddings
The embedding model converts text into dense numeric vectors and places semantically similar content close together. A search for “breathable running shoes under $100” can retrieve “Lightweight Mesh Trainers” with zero keyword overlap.
Vector databases
These store embeddings at scale and run fast similarity search. The system embeds the incoming query, compares it with the index, and returns the most relevant catalog matches instead of relying on whatever the model remembers.
Semantic search
Retrieval works on intent, not keyword overlap. A query for “orange shoes” shouldn’t surface the fruit. Metadata pre-filtering by category matters as much as the embedding model itself.
04: Architecture
Six stages stand between a customer’s question and a grounded answer.
A production RAG pipeline is more than “embed the catalog and query it.” Each stage can improve or undermine accuracy.
-
1
Ingestion & chunking
The ingestion layer splits the catalog into smaller, embeddable units at the attribute level, not the page level. A price question then retrieves the price instead of a full product page.
-
2
Embedding
A speed-tuned embedding model converts each chunk into a vector that the system can compare and search.
-
3
Vector indexing
The indexing layer stores each chunk for fast lookup. The right indexing strategy depends on catalog size, latency targets, and the infrastructure it needs to run on.
-
4
Retrieval & reranking
The retrieval layer embeds the query and matches it against the index. A second, more precise pass reranks the top candidates before the model sees them and corrects mistakes from the fast search.
-
5
Context injection
The pipeline places the highest-confidence result first in the context window. Long contexts reduce model reliability when they bury key information in the middle.
-
6
Response generation
The model answers from the retrieved evidence, while guardrails force a fallback when the evidence cannot support an answer.
Talk to Our Team
Auditing or building a RAG-powered product experience?
05: The Hidden Trigger
The bug that passes every test and still embarrasses you in production.
The most common cause of hallucinations in live e-commerce AI isn’t a broken model. It’s a vector index that has quietly drifted out of sync with the actual catalog. Product data updates in the PIM, but the index only refreshes on a weekly batch job. The chatbot cites the old price with total confidence, because the stale record is still the closest semantic match.
A chatbot can score perfectly on standard faithfulness metrics while confidently citing a price that hasn’t been true in a week. Pre-launch tests rarely expose staleness. The support queue exposes it six weeks after launch.
Closing that gap takes three enforcement mechanisms working together:
- Event-driven re-indexing. PIM webhooks trigger chunk deletion and re-embedding within minutes when a product becomes discontinued, repriced, or out of stock instead of waiting for the next batch job.
- TTL metadata. Every indexed document carries a timestamp, and the retrieval layer filters out anything older than the freshness SLA before it ever reaches the model.
- Hard-delete on discontinuation. A retired product triggers an immediate index purge, instead of leaving a soft flag that retrieval can still query.
Our DevOps and platform engineering team builds this enforcement layer directly into the pipelines we ship, so freshness is a system property, not a manual process someone has to remember to run.
06: Choosing the Right Tool
Three architectures. Three different jobs.
Teams often lump RAG, fine-tuning, and agentic AI together, but they solve different problems. Most production systems end up using more than one.
| Approach | What it changes | Best for |
|---|---|---|
| RAG | Injects context per request while keeping model weights fixed | Facts that change often: pricing, inventory, promotions, return policies |
| Fine-tuning | Additional training changes the model’s weights | Tone, response format, and brand vocabulary, not fast-changing facts |
| Agentic AI | Calls APIs, executes workflows, and makes decisions | Multi-step tasks: processing a refund, updating an order, triggering a workflow |
Fine-tune for voice, use RAG for facts, and layer agentic capability in only where an action genuinely needs to happen. Add a human review gate for every high-stakes action.
07: Root-Cause Analysis
Identify retrieval failures and generation failures before you choose a fix.
Every hallucination traces back to one of two root causes. A retrieval failure means the system returned stale, semantically-adjacent-but-wrong, or simply no content, and the model generated from a bad or empty input. A generation failure means retrieval actually worked, but the model still distorts the correct content by misquoting a number, blending two chunks, or extrapolating beyond the evidence. The fixes for each are completely different, so separating them fast matters.
- Log every retrieved chunk on every request. You can’t diagnose what you can’t see.
- Measure context precision separately from faithfulness. High faithfulness with low context precision means the model accurately summarizes the wrong document.
- Run an LLM-as-judge pass on a production sample to flag grounded vs. ungrounded answers at scale.
- Watch similarity-score distributions by category. A confidence drop often precedes a spike in hallucination reports by a day or two. Treat that drop as an early warning, not just a postmortem.
- Turn every confirmed hallucination into a permanent regression test, and run it on every pipeline change going forward.
If this sounds like the kind of monitoring your current AI vendor isn’t doing, get in touch. We look for this gap first.
08: Measurement
If you’re not measuring these four numbers, you’re guessing.
Don’t treat hallucination monitoring as a pre-launch checklist item. Track it as an ongoing production metric, because failure modes drift as the catalog itself changes.
Faithfulness score
Does the answer contain only claims the retrieved content actually supports? Below 0.80 is a production incident, not a tuning note.
Answer relevancy
A response can follow its context perfectly and still fail to answer the user’s actual question.
Context precision
Did the top-ranked retrieved chunks actually contain the answer? Low precision with high faithfulness signals a retrieval config problem.
Retrieval recall
Did retrieval return the correct document? Low recall on one category usually points to a chunking or metadata-filtering gap.
09: What We’ve Learned
The details that separate a demo from a system customers trust.
Getting a RAG demo working is straightforward. Keeping it accurate for a live catalog under real traffic is where the engineering actually happens. A few things consistently matter more than teams expect going in:
- Freshness is a first-class requirement, not a nice-to-have. A weekly re-indexing job lets stale data sit for days. Event-driven re-indexing on high-churn fields such as price and stock keeps the index close to real time.
- Reranking earns its latency cost on synchronous chat. A cross-encoder reranker catches relevant matches that fast retrieval misses. Spend the extra milliseconds in a chat interface, but reconsider that cost for latency-sensitive autocomplete.
- Chunk at the attribute level, not the page level. A return-eligibility question needs the return-policy chunk directly, not a full product page that buries the answer in paragraph three.
- Language is metadata, not a similarity assumption. A query in one language shouldn’t retrieve descriptions in another. Filter language explicitly instead of relying on embedding similarity.
- Metadata governance belongs upstream. When a category taxonomy shifts mid-catalog, pre-filters break for every affected product. Fix the taxonomy in the PIM instead of patching the vector store.
Our engineering team solves these problems inside client platforms every week. See more in our case studies, or talk to us about your own AI stack.
10: FAQ
Common questions about RAG and AI hallucinations.
Does RAG completely eliminate AI hallucinations?
No. RAG prevents many hallucinations by supplying current knowledge, which addresses the most common cause in e-commerce. It doesn’t prevent faithfulness failures where the model distorts content it received correctly. Prevent those failures with prompt guardrails, temperature tuning, and output validation on top of RAG, not instead of it.
What’s the difference between RAG and agentic AI?
RAG retrieves documents and injects them into context so the model can read and respond. Agentic AI goes further by calling APIs, executing workflows, and making multi-step decisions. A product-advisor chatbot is a RAG use case; an assistant that initiates a refund is an agentic one. Most production platforms use both.
What’s the difference between RAG and fine-tuning?
RAG changes what the model reads on each request. Fine-tuning changes the model’s underlying behavior by adjusting its weights. Use RAG when catalog data, pricing, or policies change often. Use fine-tuning to shape tone and domain vocabulary. The two approaches complement each other.
Why do e-commerce AI systems hallucinate more than other use cases?
Three compounding reasons: catalogs change constantly and make retrieval indexes stale; customers ask for exact prices, return windows, and availability, so they notice every deviation; and without RAG, a chatbot relies on training data that never contained your product catalog.
