Building an AI Product Catalogue Assistant With RAG and Product Relationships

An AI product catalogue assistant should do more than put a chatbot in front of an ecommerce search box. Customers, particularly in technical, trade and B2B catalogues, often do not know the exact product name or SKU they need. They describe a job, problem or desired outcome instead:

• “I need paint for an exterior wall.”
• “What primer should I use with this?”
• “I need everything for a small welding repair.”
• “What products can I use together?”
• “What can I use instead if this product is out of stock?”

That changes the problem from simple product search into guided product discovery.

It is a similar shift happening elsewhere in AI-assisted sales. An AI SDR becomes more useful when it can work with customer data, qualification rules and business systems rather than simply generating outbound messages.

I have been building a catalogue recommendation system around this problem. The architecture combines structured product data, semantic search, a cross-encoder reranker, product-document retrieval and explicit relationships between products.

The language model sits above those systems as the conversational layer. It helps interpret what the customer is trying to accomplish, but it does not become the source of truth for catalogue information. This distinction is important.

Why Ordinary Product Catalogue Search Is Not Enough

Traditional ecommerce search works well when the customer already knows what to type. If someone searches for an exact SKU, manufacturer, model or product name, conventional lexical search may actually be the best tool for the job. The difficult searches are contextual.

A customer may search for: “Paint for a damp bathroom wall.”

There might be no product containing that exact phrase. The relevant catalogue information could instead mention moisture resistance, interior surfaces, washable coatings, mould resistance or recommended preparation products.

The problem becomes even harder when the customer wants to know what goes with a product. Finding a suitable topcoat is one retrieval problem. Determining which primer, roller, cleaner or protective equipment should be used with it is a relationship problem.

An AI product catalogue assistant therefore needs to solve several different problems rather than relying on one large prompt.

The Architecture I Am Using

The catalogue system I have been building can be divided into seven layers:

1. Catalogue and document ingestion
2. Structured product data
3. Query interpretation
4. Semantic retrieval
5. Cross-encoder reranking
6. Product relationships
7. Conversational reasoning

Each layer is responsible for a different part of the recommendation process.

The design principle is simple: use AI where interpretation is useful, but keep authoritative product information in systems that can be validated.

That principle applies beyond ecommerce. In other AI implementations, the reliability of the overall system often depends more on the architecture, data flow and controls around the model than on the model itself.

1. Ingest catalogue information without destroying its structure

Product information rarely lives in one clean database. A business might have product titles and SKUs in Magento, technical specifications inside PDFs, application guidance on manufacturer websites and additional information inside descriptions or datasheets.

For the catalogue system I am building, I use a custom web crawler for webpage content alongside a PDF ingestion pipeline.

Rather than turning an entire PDF into one large text block, the document is broken down according to its structure.

The hierarchy is closer to:

Document → heading → paragraph

That matters because a paragraph under Surface Preparation means something different from a paragraph under Safety, Application, Coverage or Compatible Products.

Each paragraph can retain metadata identifying its source document and section before being indexed.

This gives the retrieval layer considerably more context than blindly splitting documents every few hundred tokens.

2. Keep structured catalogue facts structured

Not every piece of product information belongs in a vector database.

Fields such as:

• SKU
• product ID
• brand
• category
• pack size
• price
• stock
• product status

are structured facts. They should remain structured.

Embeddings are more useful for information such as:

• product descriptions
• use cases
• supported surfaces
• technical explanations
• application instructions
• compatibility language
• preparation requirements

This separation is one of the most important controls in the system. Semantic similarity can help discover a relevant product, but it should not determine whether something costs $20, whether 20 units are in stock or whether a customer receives a specific contract price.

Those values should come from the catalogue, ecommerce platform or ERP. The AI helps decide what information to retrieve. It should not manufacture transactional facts.

3. Interpret the customer’s actual task before searching

The current architecture also includes a small query-processing step before catalogue retrieval. The goal is not to ask a large model to rewrite every query into something elaborate. It is to identify the useful intent and constraints hidden inside normal customer language.

Consider: “I need white paint for the outside wall at the front of my house. Something that will last, preferably 20L.”

The important information is closer to:

Goal: exterior wall painting
Colour: white
Pack size: approximately 20L
Priority: durability
Surface: not yet known

That final missing constraint may be important. Instead of treating the entire customer message as one unstructured search string, the system can retain the goal and extracted constraints while removing conversational noise.

Those constraints can then influence retrieval, filtering and follow-up questions. This also creates a cleaner foundation for multi-turn conversations.

If the customer later says: “It is plaster.” the system should update the existing search context rather than start again.

The same general pattern applies to other business workflows where AI needs to interpret unstructured input before passing structured information into another system. Lead qualification is one example: an AI layer can interpret an enquiry while CRM fields and qualification rules remain authoritative.

4. Use semantic retrieval for candidate generation

The next stage is semantic search. I am using embeddings for product titles, descriptions and supporting product information, with vector retrieval handled through Qdrant. This makes it possible to retrieve products based on meaning rather than exact keyword overlap.

A customer asking for: “Something for a damp bathroom wall.” may retrieve products whose documentation discusses moisture resistance, washable interior coatings or relevant bathroom applications even if the customer’s exact wording never appears in the catalogue.

But semantic similarity is not treated as the final recommendation. It is only candidate generation. The first search should be fast and relatively broad because excluding the correct product too early is difficult to recover from later. The more important ranking decision happens in the next stage.

5. Rerank the candidate products

After semantic search produces a manageable candidate set, the system sends those candidates through a cross-encoder reranker. A reranker evaluates the customer’s query against each candidate more directly than vector distance alone.

The flow becomes:

Customer query → semantic retrieval → candidate products → cross-encoder reranking → confidence threshold

This gives the assistant a stronger signal for deciding which products genuinely match what the customer is trying to accomplish. 

The confidence threshold is equally important. A weak recommendation should not automatically become an answer simply because something has to appear in position one.

If the candidates do not meet the required confidence, the system can ask another question.

For example:

• “Is the surface interior or exterior?”
• “Is this bare metal or previously painted?”
• “What material is the wall?”
• “Do you need a 5L or 20L pack?”
• “Are you looking for the cheapest compatible option or the longest-lasting one?”

In a product assistant, clarification is a feature rather than a failure. A system that sometimes says “I need one more piece of information” can be much safer than one that confidently recommends whatever happens to rank highest.

6. Retrieve the evidence behind the product

Finding the right product is only part of the problem.

The assistant may also need to explain:

• why the product is suitable;
• how the surface should be prepared;
• what coverage to expect;
• whether a primer is required;
• what application method is recommended;
• what safety information is relevant.

That information may live inside a technical PDF rather than the product’s ecommerce description. Because the ingestion pipeline retains document, heading and paragraph structure, the assistant can search the supporting documents associated with a product.

Instead of loading an entire 30-page technical datasheet into the language model, retrieval can find the sections relevant to the current question.

For example:

Product → Technical Datasheet → Surface Preparation → relevant paragraph

or:

Product → Technical Datasheet → Coverage → relevant paragraph

This is where retrieval-augmented generation, or RAG, becomes particularly useful. The model receives the small amount of evidence required for the customer’s question rather than being expected to remember or infer the product specification itself.

7. Add a product relationship layer

Semantic search answers: “Which product best matches this request?” It does not necessarily answer: “What should I use with this product?” These are different problems.

Two products can be semantically similar because both are exterior paints while actually being alternatives rather than products designed to work together. This is why I am also building explicit product relationships.

Useful relationship types can include concepts such as:

• compatible with
• requires
• accessory for
• substitute for
• used before
• used after
• suitable for a particular surface
• complementary product

A coating might therefore connect to a primer, roller, brush, cleaner or safety product. Once these connections exist, the assistant can recommend a system of products rather than simply displaying ten similar search results.

Using a Small Local Model to Discover Possible Relationships

One experimental part of the system is a background product-pairing process. The process selects products from the catalogue and asks a small local language model whether two items can realistically be used together.

For example:

Product A: exterior masonry paint
Product B: masonry primer

The relationship model evaluates whether there is a useful complementary relationship and, where appropriate, creates a typed link with an explanation. The process then moves through products that have not yet been evaluated so that relationship coverage can gradually expand. I am deliberately treating these as discovered relationships, rather than immediately accepting them as verified product facts.

That distinction creates an important trust boundary. A model can help discover relationships worth investigating. Manufacturer data, business rules or human review can then establish which relationships should be treated as authoritative.

For high-risk compatibility questions, AI inference should not silently override technical documentation.

Why a Product Graph Is Different From Vector Similarity

It is tempting to assume embeddings can handle all of this. They cannot reliably represent the meaning of every product relationship.

Imagine three products:

Product A: exterior acrylic paint
Product B: another exterior acrylic paint
Product C: primer designed for Product A

Products A and B may have extremely high semantic similarity. But the useful recommendation relationship may actually be between A and C. The graph makes that distinction explicit.

It can record:

A → alternative to → B

and:

A → compatible with → C

Those relationships can then be used independently of similarity scores. The graph can also help with multi-step recommendations.

For example:

Topcoat → requires → Primer → suitable for → Masonry

The assistant can use that path when answering the customer while still grounding each step in stored catalogue evidence.

What the Language Model Is Actually Responsible For

The language model sits above these retrieval systems. Its job is not to memorise the catalogue. Its job is to orchestrate the process.

This orchestration model is similar to the architecture behind an AI SEO monitoring system, where different data sources, analytics tools and decision layers can be exposed to an AI agent rather than asking one model to perform every part of the workflow itself.

A catalogue assistant can expose controlled tools such as:

search_products(query, filters)

get_product(product_id)

get_related_products(product_id, relationship_type)

search_product_documents(product_id, query)

The model can then decide which tool is required based on what the customer asks.

If someone says: “Do you have a 20L exterior paint for plaster?” the model may search products with those constraints. If the customer then says: “What primer should I use with the first one?” the assistant needs the selected product’s relationships rather than another general catalogue search.

If the customer asks: “How should I prepare the wall?” the assistant may retrieve the Surface Preparation section from the product documentation.

This approach is not limited to product catalogues. I have used a similar division of responsibilities in an AI editorial workflow, where specialised tools handle different parts of the publishing process while the AI layer coordinates the overall task.

This is a much more controlled architecture than giving the model thousands of products and asking it to work everything out inside one prompt.

What a Real Customer Interaction Could Look Like

Imagine a customer asks: “I’m repainting an outside wall and some of the existing paint is peeling. What do I need?”

The assistant first identifies the task as exterior repainting. It may determine that the surface material is important and ask: “Is the wall plaster, brick, concrete or another surface?” Assume the customer answers: “Plastered wall.” The system now has enough context to search.

Semantic retrieval returns relevant exterior coating products. The reranker selects the strongest candidates. Product documentation can then be searched for preparation requirements. The relationship layer identifies any primer or preparation products associated with the selected coating. Instead of responding with a long list of vaguely related catalogue results, the assistant could return something closer to:

Recommended coating

The primary product that best matches the surface and application.

Why it fits

A short explanation grounded in the retrieved product information.

Preparation

Relevant surface-preparation instructions taken from the technical documentation.

Primer

A compatible primer if one is required.

Application tools

Related rollers, brushes or other application equipment.

Alternative

A suitable substitute if the primary recommendation is unavailable.

That is much closer to the way an experienced trade-counter employee helps someone complete a job.

Recommendation and Transaction Should Remain Separate

Finding products and buying products are different trust boundaries. This becomes especially important once the catalogue assistant connects to ecommerce systems such as Magento.

The AI may be able to help assemble a proposed basket, but transactional values such as:

• live price
• customer-specific price
• available stock
• account rules
• minimum quantities
• shipping options
• final order totals

should be validated against the authoritative commerce system. My Magento integration work has reinforced this separation. Once an AI workflow begins creating or modifying carts, reliability requirements change significantly. Operations should be controlled, validated and auditable rather than treated like ordinary conversational output.

The same principle applies further down the operational chain. Predictive inventory reordering with AI may help identify what stock should be replenished, but live inventory levels, supplier details, purchasing rules and approved orders still need to come from authoritative business systems.

For larger B2B orders, that may mean final basket reconciliation, approval rules and explicit confirmation before the order progresses.

The catalogue assistant can therefore help answer: “What should I buy?” without automatically receiving unrestricted permission to answer: “Place the order.” This separation makes the system much easier to control.

How I Would Evaluate an AI Product Catalogue Assistant

The biggest risk with a system like this is building an impressive demo that performs poorly on real catalogue queries. A handful of successful conversations proves very little.

The system needs an evaluation set containing realistic customer questions with known expected behaviour. I would measure at least four components independently.

Retrieval Recall

Did one of the correct products enter the candidate set? If the right product is never retrieved, the reranker and language model cannot recover it.

Reranking Quality

Did the best products move toward the top of the candidate list? This tests whether the second-stage ranking actually improves over raw vector similarity.

Relationship Accuracy

Are products marked as complementary, compatible or substitutes actually related in the claimed way? This is especially important for model-discovered relationships.

Answer Grounding

Does the final answer remain consistent with the product data and technical documentation retrieved by the system? The evaluation set should also contain queries where the correct behaviour is not to recommend a product.

Sometimes the expected answer should be a clarification question. This makes it possible to test whether confidence thresholds are actually reducing unsupported recommendations. I have intentionally not included performance percentages here yet because those should come from the evaluation dataset rather than a handful of hand-selected examples.

Why This Scales Better Than Putting the Catalogue Into One Prompt

A catalogue with hundreds or thousands of products quickly becomes unsuitable for a prompt-only architecture. Context grows. Costs grow. Updates become harder. Retrieval quality becomes unpredictable. And the model is still being asked to distinguish authoritative facts from conversational context.

The layered architecture avoids that problem. Structured catalogue systems hold transactional facts. Qdrant and embeddings narrow the product search space. The reranker improves relevance. Product-document retrieval supplies technical evidence. The relationship graph stores explicit connections between products. The language model interprets the conversation and orchestrates those systems.

Each component can then be measured and improved independently. That is the same principle behind many useful AI automation examples: the model is only one component inside a larger business system.

Start With One Category, Not the Entire Catalogue

I would not begin by trying to build an autonomous salesperson for every product a business sells. A much better first version is one category where customers regularly need guidance.

Paint is a useful example because the correct recommendation can depend on:

• interior or exterior use;
• surface material;
• previous coatings;
• preparation requirements;
• pack size;
• application method;
• primer compatibility;
• related tools.

Start there. Build a realistic test set. Ingest high-quality product information. Add semantic retrieval. Measure it. Introduce reranking. Measure again. Then add a small number of high-value product relationships.

Once recommendation quality is predictable, the same architecture can be expanded category by category.

Where an AI Product Catalogue Assistant Creates Business Value

The purpose of an AI product catalogue assistant is not to replace Magento, an ERP or the product database. It acts as an intelligence layer over those systems.

That can be particularly valuable for businesses with large or technical product catalogues where customers frequently need help understanding what to choose.

A well-designed system could help:

• customers find products without knowing exact SKUs;
• sales teams retrieve product knowledge faster;
• customers discover complementary products;
• businesses surface useful alternatives;
• technical documentation become searchable through natural language;
• ecommerce experiences move from search toward guided selling;
• future conversational-ordering workflows start with better product selection.

It also connects naturally to broader workflows such as automating WhatsApp orders, where the first challenge is often understanding what the customer wants before an order can be created.

This creates a natural workflow:

Customer describes requirement → AI identifies suitable products → customer confirms selection → order workflow validates and creates the transaction.

The important part is that conversational AI does not replace the business systems underneath it. It connects them.

Building an AI product catalogue assistant starts with the data

If customers need guidance rather than exact-SKU search, the first question should not be: “Which chatbot should we use?”

The first questions should be:

• How complete is the product data?
• Where does technical knowledge currently live?
• Which product attributes are structured?
• Which relationships between products are already known?
• What information needs to come from PDFs or manufacturer websites?
• Which recommendations require human or manufacturer verification?
• And what happens when the system is not confident enough to recommend anything?

Those answers determine the architecture long before the choice of language model becomes important.

Need Help Assessing Your Product Catalogue?

AIMEC can assess how your existing catalogue, technical documentation and ecommerce systems could support an AI product catalogue assistant.

The goal is to identify where structured search, RAG, reranking, product relationships and controlled AI reasoning can add value before committing to a larger implementation.

Talk to AIMEC about a product catalogue AI assessment.

Frequently Asked Questions

What is an AI product catalogue assistant?

An AI product catalogue assistant is a conversational system that helps customers find, compare and understand products using natural-language questions. More advanced implementations can combine structured product data, semantic search, retrieval-augmented generation, reranking and explicit relationships between products.

How does RAG work with a product catalogue?

RAG allows an AI assistant to retrieve relevant information from catalogue descriptions, technical documents and other product sources before generating an answer. This reduces the need for the language model to rely on its internal knowledge and helps ground recommendations in the business’s own product information.

Does a product recommendation system need a knowledge graph?

Not necessarily. Semantic retrieval may be enough for basic product discovery. A relationship graph becomes more useful when the system needs to understand explicit relationships such as compatible products, substitutes, required preparation products or accessories.

Can an AI product catalogue assistant connect to Magento?

Yes. Magento can remain the authoritative source for catalogue and transactional information while an AI layer handles natural-language discovery and recommendations. Price, stock, customer-specific rules and order operations should still be validated through Magento or the relevant backend system.