An AI assistant that knows your catalogue the way your best salesperson does

The Problem

Shoppers ask product questions the way they’d ask a salesperson: “Show me all bathroom lights under €300 with IP44.” “Is this driver compatible with my track system?” “How many ceiling lamps do you have in the brushed brass finish?”

A vanilla RAG chatbot, the kind most platforms ship, answers by pulling a few text fragments that look similar and pasting them into an LLM. That works for fuzzy FAQ questions. It breaks the moment the customer wants a count, a complete list, or a specific spec. You get a product back. You don’t get all of them, and you don’t get the right one when names are close (“Aurora 2L” vs “Aurora-2 LED”).

The cost shows up in two places. First, on conversion: customers ask one assistant question, get a vague answer, and bounce. Second, on support: every assistant failure becomes a ticket, an email, or a chat handoff. The whole point of the bot was to absorb those, and a weak one generates more.

What the Solution Does

An assistant that knows your catalogue structurally: categories, attributes, brands, collections, compatibility rules. It uses that structure to give exact answers, with citations.

1. Understand the question: the assistant maps the user’s phrasing to entities in your data model (“bathroom lights” becomes a category, “IP44” an attribute filter, “€300” a numeric constraint).
2. Plan retrieval: it decides whether to run a structured query (counts, filters, compatibility), a semantic search (FAQ, descriptions), or both. One vector search alone is not enough.
3. Execute: Cypher or SQL hits the catalogue graph; vector search hits long-form text; APIs fetch live data (stock, price).
4. Compose an answer: with explicit references (offer:12345, faq:42) so the result is traceable, never invented.
5. Hand off cleanly: when confidence is low or the customer asks for a human, the bot escalates with full conversation context.

Where It Fits

This makes sense if you…

• Run an e-commerce catalogue with 5,000+ SKUs and rich attributes
• Sell products with real compatibility logic (lighting, electronics, furniture, auto parts, parapharma)
• Already lose customers on the search/filter step, bounce rates spike at category pages
• Have a clear product/UX owner who’ll act on assistant analytics
• Want an assistant that can be audited, every answer with a source

This is probably not the right time if you…

• Have a small catalogue (< 1,000 SKUs), a good search bar is cheaper
• Sell commodity items where customers know the SKU before they arrive
• Don’t have structured product data, only PDF catalogues and free-text descriptions (Test phase will tell us if it’s tractable, but it’s a much longer project)
• Plan to integrate the assistant only on the checkout page, by then the customer already chose

Business Value

The Semantic RAG approach trades faster setup for higher accuracy. The trade-off is worth it for two reasons.

Accuracy where it matters. On structured questions (“show me all”, “how many”, “is X compatible with Y”, “what’s the IP rating of …”) we typically see 90-97% answer accuracy. Chunk-based RAG on that identical dataset sits at 60-70%. Both numbers are measured on our internal golden datasets across e-commerce, legal, and medical projects (2025-08 benchmarks).

Auditability. Every assistant answer ships with explicit sources: offer IDs, FAQ row IDs, document chunks. When a customer disputes a price or a spec, you can prove the answer was grounded in your data. This matters more than people expect, especially in regulated verticals (parapharma, B2B).

The downstream metrics vary a lot by baseline: ticket deflection, conversion lift on assistant-completed sessions. We give conservative ranges in expected outcomes and confirm them per project during the pilot.

How It Works

The approach is called Semantic RAG. We’ve published the full architecture under the codename Vedana; the short version is below.

1. Build a graph of your catalogue

Your catalogue gets loaded into a graph database (Memgraph by default). Each product, category, brand, collection, and attribute becomes a node. Compatibility rules, “belongs to collection”, “has driver”, and similar relationships become edges. We use the Minimal Modeling approach, anchors (nouns), attributes (their properties), and links (relationships between them), which maps cleanly onto LLM-friendly descriptions.

For e-commerce, most of this model can be generated automatically from your catalogue, including the human-readable descriptions of each entity and attribute.

2. Give the assistant a toolkit

The assistant has access to three classes of tools:

• Vector search, for fuzzy queries on long text fields (FAQ, descriptions, policies).
• Cypher / SQL queries, for exact retrieval: counts, filters, compatibility joins, “show all”.
• APIs, for live data: stock, price, delivery date, order status.

Each tool comes with an example query that the LLM uses as a few-shot template. This is what stops the assistant from inventing field names or generating broken SQL.

3. Teach it how to reason, the Playbook

For each typical question type, we write a 2-5-step playbook. Customer asks about product compatibility: first vector-search the catalogue to identify the product, then run a Cypher query along the IS_COMPATIBLE_WITH edge, then return the list with reasons.

Playbooks are the part product managers and category experts can write directly. They’re also where business rules live, “in this category, IP rating filter is mandatory before showing results”.

4. Verify with a golden dataset

Every project ships with 20-30 example questions per playbook scenario, each with an expected answer and the source IDs that should back it up. We rerun this whenever the catalogue changes, the LLM changes, or the data model expands. Accuracy is measured against the source IDs the answer cites. The LLM is allowed to paraphrase the wording; the citations must match.

Stack

Memgraph (graph and vector store), Datapipe (incremental embedding updates), Grist (expert-editable structured data), Python / FastAPI, PostgreSQL for conversation history, Chatwoot for the operator workplace. LLM provider is pluggable, we run on OpenAI, Anthropic, and self-hosted models depending on data residency requirements.

What You Need to Make This Work

Data. Your catalogue export (CSV, API, or DB dump) with categories, attributes, and any structured rule tables you keep on the side. If your compatibility logic lives in spreadsheets or in the heads of category managers, that’s fine, we’ll codify it during the pilot. If it doesn’t exist anywhere, we have to build it first, which extends the pilot by 2-4 weeks.

Integrations. Read access to your PIM / ERP. A way to embed the chat widget (we ship a JS widget; we also integrate with Chatwoot, Intercom, and most operator platforms). For escalation: a queue your support team already monitors.

Hardware. Cloud-only by default. For regulated clients (parapharma, banking) we deploy on-prem; expect 16-32 GB RAM per instance because the vector store is in-memory.

Team. A product or category owner who knows the catalogue and can review playbooks (5-10 hours/week during the pilot). A tech contact on your side for the integration (~10-15 hours total). Optionally, an SME for compatibility logic if the rules aren’t already documented.

Implementation Roadmap

1. Test (2-4 weeks)

We connect to a slice of your catalogue (one category, or one brand line). Build the first version of the data model, the first 3-5 playbooks, and the golden dataset for those scenarios. Output: a written report with measured accuracy on your real data, a list of the gaps we found in the catalogue, and a clear scope for the pilot.

2. Pilot (1-2 months)

Full catalogue (or the agreed pilot scope) is in the graph. Full playbook coverage for the top 8-12 question types. The widget goes live to a sample of users, typically 5-20% of traffic, A/B against the existing search or no-assistant baseline. Output: a working assistant, dashboards for accuracy and business metrics, a go/no-go on full rollout.

3. Production (ongoing)

Catalogue updates flow through automatically (Datapipe handles incremental embedding). New question types get new playbooks. We stay on for retraining, expansion to new languages or categories, and quarterly accuracy reviews.

Keep in Mind

The Semantic RAG approach trades upfront work for downstream accuracy. Where it breaks:

• It needs a real data model. If your catalogue is mostly free-text product descriptions with no structured attributes, the test phase will be slower: we’ll have to extract the attributes first. This is doable, though it’s more than “plug in a vector DB and go”.
• Playbooks are not magic. Every new type of question that isn’t covered by a playbook falls back to vector search, which means the accuracy on it lives in the 60-70% range until we write a playbook for it. We measure this and surface it.
• It is not stream-of-consciousness fast. A complex multi-step playbook takes 2-6 seconds end-to-end. Most users don’t notice; some do. Streaming partial answers helps.
• It does not replace your search bar. Many users still want to filter and click. The assistant complements filtering and shines on questions filters can’t express (“which of these works for a kitchen with low ceilings?”).
• The LLM still hallucinates inside the answer text. What changes is that the facts the answer relies on are auditable. We’ve found this is the part that matters for B2B and regulated clients.

FAQ

How is this different from “just using ChatGPT plugins” or LangChain?

LangChain and ChatGPT plugins give you the plumbing, tool calling, prompt templates, vector search. What they don’t give you is the data model, the playbooks, or the verification harness. Semantic RAG is the pattern that sits on top of that plumbing. Without it, you can build a demo in a weekend and miss the 60-to-95% accuracy gap that matters in production.

Can the assistant make purchases or modify orders?

In principle yes, we’ve added tools for cart manipulation, order lookup, and reservation. Whether to let it write (vs. only read) is a per-project decision. Most clients keep the assistant read-only for the first three months and add write capabilities once accuracy and trust are proven.

Does this work in languages other than English?

Yes. We’ve shipped in Russian, English, Spanish, and Polish. The LLM handles the linguistic side; the data model is language-agnostic. We translate the assistant’s responses and store the original alongside, so analytics work across languages.

How do you handle catalogue updates?

Datapipe tracks data dependencies and incrementally recomputes embeddings only for changed rows. A daily sync is typical; near-real-time is possible if the underlying systems support it.

What happens if the LLM provider goes down or changes its API?

We design for provider portability. The data model, playbooks, and verification harness are LLM-agnostic. Switching providers is a 1-2 day exercise, far short of a rebuild.

Ready to Discuss?

If you’re considering an AI assistant for your catalogue and the vanilla-RAG demos haven’t been impressive, this is the conversation worth having. We’ll walk through your current catalogue, identify which question types Semantic RAG would clearly win on, and tell you whether the pilot is worth the upfront work for your specific case.

Discuss your project