RAG on your catalog: why generic chatbots fall short

RAG on your catalog: why generic chatbots fail ecommerce

A generic chatbot can write a polished answer, but it does not automatically know your assortment. It does not know which variant is currently available, which accessory actually fits a model, whether a product page has been updated, or what return policy applies in your shop. For ecommerce, that difference matters. A natural-sounding answer that is not grounded in your catalog can send a shopper in the wrong direction at the moment they are ready to buy.

Retrieval-augmented generation, or RAG, is designed to address that problem. Rather than relying only on broad model knowledge, a RAG system first retrieves relevant information from approved sources. It then uses that information to answer the question. Fynd applies this pattern to ecommerce catalogs and related content, letting a bot use the sources you connect: sitemap pages, product feeds, APIs, articles, and maintained custom FAQs.

RAG is not a shortcut around poor data. It is a way to make catalog quality operational. It exposes vague product descriptions, stale campaign pages, conflicting facts, and high-value buying questions that your current content does not answer.

The limitation of a generic chatbot

Language models are useful because they can explain concepts, summarize text, and hold a conversation. None of that makes them an authoritative representative of your current store. Without connected, current sources, a model cannot safely know your present products, prices, availability, regional terms, or service policies.

Imagine a shopper asking: “Which coffee grinder is suitable for espresso, quiet, and has no plastic in the grinding mechanism?” A generic assistant can describe what to consider, but it cannot reliably identify which products in your inventory meet those constraints. It may blend features from separate models, mention a discontinued item, or make an unsupported inference from marketing language.

The consequence is not limited to a missed sale. Generic answers create friction when they are vague and damage trust when they sound confident but are wrong. Compatibility, dimensions, materials, care instructions, shipping, returns, safety, and regulated claims need a verifiable source. A product advisor must therefore be more than articulate: it needs relevant evidence to retrieve.

What RAG means in practical shop terms

RAG has two main stages. First, the shopper’s question becomes a search across your knowledge sources. The system retrieves relevant passages or records: product details, feed attributes, a buying-guide section, a policy page, or an FAQ. Second, the language model writes an answer using that retrieved context.

For a question like “I need a warm, lightweight jacket for wet bike commutes,” a well-prepared setup can retrieve suitable products, material details, and a guide to waterproofing or insulation. The answer can identify useful criteria, recommend relevant options, and link to product pages. If the sources do not establish an important fact, the advisor should say so instead of guessing.

That is different from a bot that claims to know everything. RAG helps an advisor find the right evidence and recognize when evidence is insufficient. The result is not omniscience; it is an experience that is more useful, auditable, and safe for a merchant to operate.

Design sources around real buying decisions

One source is rarely enough for a webshop. Product feeds are strong for structured facts, while pages and articles are better at explaining trade-offs. Combine them intentionally rather than importing every available URL without review.

Sitemap content: public product knowledge

A sitemap is an effective starting point for product pages, collections, buying guides, policy pages, and help content. Product pages supply use-case and feature context. Collection pages help with category discovery. Shipping and returns pages answer questions that often block a purchase.

Include blog posts that offer durable decision support. Pages marked with BlogPosting or Article structured data often contain size guidance, maintenance instructions, material comparisons, or beginner advice that does not belong in a product feed. Exclude low-value or volatile pages such as internal search pages, account pages, tag archives, expired promotions, and duplicate URL versions. Indexing more content is not the same as improving retrieval.

Product feeds: structured facts for recommendations

Use a feed for titles, brands, SKUs, prices, URLs, categories, variants, and availability. Enrich it where possible with dimensions, weight, material, capacity, compatibility, power, care instructions, and certifications. An advertising feed containing only a name, image, and price is normally too thin for meaningful product advice.

Review what blank fields mean. Is a missing size field intentional because an item is one-size, or is the data absent? Is compatibility stored only in an image or a downloadable PDF? Are measurements consistently in the same units? These distinctions determine whether a bot can make a safe recommendation. Normalize high-value attributes and put important facts in machine-readable or clearly written source text.

APIs: freshness and data control

An API connection can be the right choice when stock, prices, product details, or the assortment change frequently. It often gives a merchant greater control over fields and synchronization. It does not mean every internal field should be exposed. Share only what is needed and permitted for customer-facing advice.

Decide which source is authoritative when an API, feed, and public product page disagree. Otherwise a current availability record may conflict with an old product description. RAG can retrieve multiple sources, but it cannot make the organizational decision about which fact is true. That data governance is part of the implementation.

Custom FAQs: controlled exceptions

Custom FAQs are useful for important answers that are not represented cleanly elsewhere: a specific compatibility rule, an installation detail, a business purchasing condition, or an explanation of a service. They should not become an unowned warehouse of vague statements. Give each FAQ an owner, a review date, and a clear scope.

For example: “This replacement part fits models X and Y from the 2023 model year onward; confirm the SKU on the package.” That gives the advisor a useful boundary. “Fits almost everything” does not. Precise content reduces the pressure to make assumptions.

Reducing hallucinations takes source work

A hallucination is an answer that sounds plausible but is not supported by available facts. RAG reduces this risk by supplying relevant context, but it cannot eliminate it. Duplicate pages, stale promotion content, weak product data, and conflicting sources can still lead to a bad answer.

Build several safeguards:

• Curate current sources instead of ingesting an uncontrolled URL list.
• Remove or exclude expired offers, duplicate variants, and obsolete product pages.
• Put critical facts explicitly in text or fields, not only in images.
• Require the bot to acknowledge uncertainty when it cannot confirm a specification or stock status.
• Define escalation paths for order status, legal questions, medical claims, and other sensitive topics.
• Test negative cases: questions where a responsible answer is not possible.

Do not ask only, “Did it answer?” Ask, “Which source supports this answer?” If your team cannot identify that source, the information is probably not ready to power a product advisor.

Measure knowledge gaps, not just chats

A RAG advisor creates a useful stream of actual shopper language. In Fynd analytics, look beyond conversation volume and leads. Review repeated intents, questions that do not receive a useful response, products frequently discussed together, and points where visitors have no clear next step.

Set a recurring review and classify gaps:

1. Missing product data, such as dimensions, care, or compatibility.
2. Missing explanatory content, such as a size guide or comparison.
3. Conflicting sources, such as an old article versus a current feed.
4. Requests outside the bot’s role, such as an individual order-status lookup.
5. Questions that reveal an assortment or merchandising opportunity.

Frequency matters, but it should not be your only priority. A less common question can be commercially important if it appears immediately before a high-value product decision or a lead form. Also inspect outcomes: does the advisor take the shopper to a relevant product, help them compare choices, or leave them with more research to do?

When RAG still fails

RAG will still fail when no source contains the answer, when retrieval does not find the relevant passage, or when the shopper’s question is too ambiguous. It can also struggle with complex reasoning over many variants, inconsistent attribute formats, or information that changes more quickly than synchronization.

For instance, an advisor may retrieve that an item is water-resistant but cannot responsibly conclude it is suitable for extended saltwater use. It may find a size chart but need a follow-up question about body measurements. It may retrieve a displayed price but should not promise a personal delivery date without live order and fulfillment context.

The solution is not to force an answer. Let the advisor ask a clarifying question, use cautious language, link to a policy, or hand the shopper off to a human team. RAG performs best when the line between known facts, reasonable suggestions, and unknown information remains visible.

A practical first rollout with Fynd

Start with a category that has adequate information and clear purchasing intent. Connect its sitemap pages and feed or API, include a small set of relevant articles, and prepare twenty to thirty real shopper questions in the Fynd playground. Test answer quality, product links, source coverage, follow-up questions, and uncertainty before embedding the advisor across the site.

Then add the Fynd script on product and collection pages. The 14-day Starter trial provides a practical window to observe conversations, leads, product interest, and knowledge gaps in a live storefront. Use that evidence to improve the highest-impact source, then test again. Do not make a large prompt your first response to every weak answer; missing catalog facts and unclear content are usually the root cause.

Starter is appropriate for validating an initial product-advice workflow. Growth fits a merchant expanding the operational program and reviewing insights regularly. Pro is suited to teams that need greater scale, additional bots, or more extensive governance. Plan choice should follow the value and operating model you establish, rather than replacing the work of maintaining sources.

Make product knowledge a living system

RAG on your catalog does not replace merchandising, content, or support expertise. It makes that expertise discoverable in the moment a shopper is comparing products. Treat it as a living system: update product data as the assortment changes, retire obsolete content, review analytics, and turn recurring questions into better fields, guides, or controlled FAQs.

That loop is the real advantage over a generic chatbot. Instead of hoping a broad model knows your business, you give Fynd a current, measurable knowledge layer and use shopper questions to improve it. The bot becomes a practical advisor because it is connected to the facts your team is willing to stand behind.