RAG vs a classic recommender: which one you actually need

If you run a shop, you have both problems in the same week. A customer asks whether the winter jacket ships to Slovakia, and whether it comes in 42. Someone else lands on the homepage and needs to see the right ten products, not a paragraph.

Those are not the same system. I keep seeing them bought as if they were.

What each one is for

RAG (retrieval-augmented generation) takes a question, finds the passages that might contain the answer, and writes a reply from those passages. The useful version also cites them. In a store that usually means return policy, size charts, care instructions, shipping rules, and the long product text that never fits on the card.

A recommender takes a person (or a session) and a catalog and produces an ordered list. Homepage, category, “you might also like”, post-purchase, search rerank. The output is SKUs in an order, with a score you can A/B test.

A useful test: can there be one right answer, written down somewhere you own? That is RAG. Is the job “which of these N things should this person see next”? That is a recommender.

I spent a decade on the second problem at Seznam, at tens of millions of requests a day. The first problem showed up later, when teams started wiring an LLM to the same catalog and calling it personalisation.

The failure that looks good in a demo

The pattern I keep seeing is simple. Someone dumps product titles, a few attributes, and a slice of order history into a prompt. The model returns five “recommendations”. On Thursday afternoon, with three colleagues watching, it looks clever.

Then it hits a real catalog. A Shoptet shop with 8,000 SKUs, messy categories, and half the size fields empty. A Shopify store with variants that do not share inventory. Traffic on Monday morning, not a staged query.

Three things break, in this order:

1. You have no score you can trust. The model said “these feel right”. You cannot put that next to last week’s CTR in an A/B test and know which side won.
2. Cost follows every page view. A ranking model scores a candidate set in milliseconds. An LLM that “thinks about” the catalog on each request is a different invoice, and it gets worse as you add users, not better.
3. You cannot say why item 4 beat item 5, which means you cannot debug it when a merchandiser asks why the clearance SKU vanished.

Classic recommenders already solved the “too many products, pick a shortlist” part. The usual shape is two-stage: retrieve a few hundred plausible items (collaborative filtering, a two-tower, even a good search), then a ranker that scores them. That is retrieval plus ranking. It is not RAG. The retrieved objects are products, not paragraphs, and the last step is a score, not a sentence.

Vector search over product text can sit in that first stage. Fine. That still does not make the LLM the ranker.

The other mistake: asking the recommender a factual question

Less common, still happens. The widget is supposed to explain a return, confirm a size, or say whether an item ships to a given country. Someone points it at the same ranking scores, or at “similar items”, and hopes.

A recommender knows what correlated with clicks. It does not know what is true. “People who bought this also bought waterproof spray” is not an answer to “is this jacket machine washable”. That answer lives in the care text, the attribute, or the PDF from the brand. If you do not retrieve that text, the model will invent a confident yes.

For a shop, that is not a cute hallucination. It is a ticket, a return, or a customer who will not ask twice.

What a store actually needs

Most product-discovery setups need both, as two systems that share a catalog.

The recommender owns the list: homepage, category, cart, “complete the look”. You measure it like you measure anything else that touches revenue. Offline ranking metrics first, then an online A/B with a holdout. If you cannot name the metric before the build, do not start the build.

RAG owns the questions people type at a product, in search, or in a support widget. “Does this run small.” “What is the return window on opened electronics.” “Will this arrive before Friday if I order from Brno.” Those answers have to come from text you would stand behind in a dispute.

Keep the catalog as the shared source. Attributes, descriptions, stock, shipping rules. The ranker reads features. The retriever reads passages. If the size field is empty, both fail, just in different ways. That is a data problem, and it is usually the first week of the work.

A merchandising assistant for the team (missing attributes, duplicate titles, “what do we say about this SKU”) is RAG over the same catalog. It is not a customer-facing recommender. Do not sell it as one.

How I decide on a call

I ask what sentence the user is trying to finish.

• “Show me…” or “I might like…” → ranker.
• “Does this…” or “Can I…” or “What is…” → RAG.
• “Find me a running shoe under 3,000 Kč that I can use in winter” → search, then a ranker. An LLM can parse the query. It should not be the thing that orders 4,000 shoes.

If the catalog is small and the only job is answering staff questions about SKUs, I will not talk you into a recommender. If you already have decent search and the homepage is a graveyard of bestsellers, I will not talk you into a chatbot.

The expensive discovery is doing the demo-friendly one first and finding out, three months later, that the metric you care about never moved.

If you are not sure which situation you are in, that is a thirty-minute conversation, not a vendor bake-off.