Vector Search in Sales Catalogs: Why Semantics Alone Isn’t Enough

Because in a sales catalog, the costly mistake isn’t “not sounding semantic”—the costly mistake is recommending something real but incorrect.

That sentence sums up the problem with using AI in sales catalogs as if it were just a matter of semantic search.

When a user types “I need something to contain a spill” or “looking for running shoes for rainy weather,” the technical temptation is clear: generate embeddings, run vector search, and return the closest products. That can be a big improvement over exact keyword search, but it doesn’t solve the whole problem.

In a sales catalog, a good answer isn’t the one that sounds smart. It’s the one that returns real, available, suitable, traceable products—ready to be shown or purchased.

In summary

Vector search is useful for understanding intent, synonyms, and needs expressed in natural language. But in sales discovery, it shouldn’t work alone. It needs to live inside a hybrid architecture with exact search, business filters, stock and price validations, channel control, traceability, and evaluations.

The model can help interpret what the person wants. The backend must decide which products are valid to show.

The common mistake: confusing similarity with recommendation

Vector search answers a question like:

“What items in the catalog are semantically close to this query?”

A sales recommendation needs to answer a different one:

“What real products can I recommend to this person, in this channel, with these constraints, without making up data or creating commercial risk?”

They’re related problems, but not the same.

A product can be semantically close and still be a bad recommendation if it fails any of these criteria:

• Availability: it’s out of stock.
• Category: it belongs to a different category.
• Budget: it exceeds what the customer can afford.
• Channel or country: it’s not sold in that market or sales channel.
• Compatibility: it doesn’t fit the customer’s model, use, or context.
• Actual application: it has a similar description but serves a different need.
• Minimum data: missing image, URL, valid price, or enough information.
• Technical risk: requires a warning before recommending.
• Segmentation: it’s hidden for that sales segment.

If the system recommends that product, the problem isn’t style. It’s trust, conversion, and operational responsibility.

Why a catalog isn’t just a regular document database

In a classic knowledge base, RAG usually retrieves document fragments to help the model answer better. In a sales catalog, the goal is tougher: you have to return actionable entities.

A product isn’t a paragraph. It’s a combination of identity, variant, price, stock, image, URL, attributes, restrictions, and source.

That’s why a catalog prepared for agents needs structured fields:

Field	Why it matters
id	Stable product identity.
sku or reference	Exact search, traceability, and sales support.
title and description	Human understanding and semantic matching.
category	Intent filtering and navigation.
price	Actionable recommendation.
availability	Prevents recommending unsellable products.
image_url	Card or carousel rendering.
product_url	Detail or purchase action.
attributes	Sizes, measurements, materials, uses, compatibility, and restrictions.
source	Source record, sync date, and audit trail.

Embeddings can represent part of that product, but they don’t replace the commercial contract.

What the LLM should do

The LLM shouldn’t invent products, prices, images, stock, or URLs. Its job is to interpret intent and return a structured request.

For example:

{
  "catalog_discovery": {
    "action": "search_products",
    "query": "product to contain a hydrocarbon spill",
    "filters": {
      "availability": "in_stock",
      "use_case": "spill_containment"
    },
    "limit": 3
  }
}

That output doesn’t contain products. It contains intent.

Then the backend queries the catalog, applies rules, validates constraints, and returns cards:

{
  "type": "product_carousel",
  "items": [
    {
      "type": "product_card",
      "id": "prod_001",
      "title": "Hydrocarbon Spill Containment Kit",
      "price": "$89.00",
      "availability": "Available",
      "image_url": "/media/catalog/prod_001.jpg",
      "product_url": "https://store.example/products/prod_001",
      "reason": "Fits because it’s designed to contain hydrocarbon spills and is available."
    }
  ]
}

The difference is important: the model decides what to search; the system decides what can be shown.

Where vector search fits

Vector search makes a lot of sense when the user doesn’t know the exact product name.

Examples:

• “something to absorb oil in a workshop”;
• “a backpack for short trips in the rain”;
• “a product to safely store drums”;
• “running shoes for bad weather”;
• “a compact coffee maker with grinder”;
• “an accessory compatible with my old model”.

In these queries, literal search might fail because the user’s words don’t match the catalog’s. The catalog might say “hydrocarbon absorbent,” “spill pallet,” “waterproof membrane,” “secondary containment,” or “integrated grinder,” while the user speaks normally.

That’s where embeddings help connect need to product.

But there are queries where exact search is superior:

• internal references;
• SKUs;
• models;
• measurements;
• capacities;
• technical standards;
• sizes;
• brands;
• part numbers;
• product names.

If someone searches for “RIDGEPACK-25-BLK,” “XZ-400,” “25L,” “GTX,” “120 cm,” or a specific reference, semantic search shouldn’t improvise. The system needs lexical precision and structured filters.

The right architecture: hybrid

The practical solution isn’t choosing between keyword search and vector search. It’s combining them.

A healthy flow for a sales catalog would be:

1. The user expresses a need.
2. The LLM converts it into a structured intent.
3. The backend validates the capability and normalizes filters.
4. Hard rules are applied: channel, availability, country, permissions, price, and category if needed.
5. Lexical search retrieves exact matches.
6. Vector search retrieves semantic matches.
7. The system merges candidates.
8. A ranking orders by relevance, attribute fit, availability, price, and data quality.
9. Price, stock, URL, and image are revalidated.
10. The frontend renders cards, carousels, or fallback.

In pseudopipeline:

user intent
  -> structured LLM output
  -> hard filters
  -> lexical search
  -> vector search
  -> hybrid ranking
  -> commercial validation
  -> product cards

This design lets the system understand natural language without losing commercial control.

Hard filters before ranking

Some rules shouldn’t depend on a score.

If a product isn’t allowed, it doesn’t get ranked. It’s excluded.

Examples:

• wrong tenant;
• unauthorized channel;
• hidden product;
• country out of coverage;
• unavailable stock;
• invalid price;
• missing URL;
• required image missing;
• unproven compatibility;
• unmet commercial restriction.

After excluding invalid items, then it makes sense to rank.

A commercial ranking can combine:

Signal	What it adds
Semantic relevance	Fit with the expressed need.
Lexical relevance	Exact match with reference, brand, model, or attribute.
Attribute match	Meets requested requirements.
Availability	Preference for products sellable now.
Price	Fits the expected budget or range.
Data quality	Complete image, description, attributes, and URL.
Freshness	Recently synced data.
Business rule	Business priority when it doesn’t contradict the user.

Ranking helps choose among valid products. It shouldn’t rescue products that failed hard rules.

Enrichment isn’t just decoration

In an AI-powered catalog, enriching products doesn’t mean writing prettier descriptions. It means making each product more retrievable, evaluable, and renderable.

Useful fields for enrichment:

• recommended uses;
• problems it solves;
• equivalent commercial terms;
• normalized attributes;
• units and ranges;
• compatibilities;
• incompatibilities;
• usage restrictions;
• canonical category;
• buying signals;
• questions it helps answer;
• allowed recommendation reason;
• confidence level per attribute.

That enrichment can feed embeddings, filters, explanations, and evaluations. But it must be traceable: which model generated it, with what prompt, from which source data, and on what date.

If a recommendation fails tomorrow, you need to be able to reconstruct why the system got there.

How to avoid made-up recommendations

The main rule is simple:

The LLM does not create product cards.

It can:

• interpret intent;
• request a search;
• suggest filters;
• draft an explanation based on returned data;
• ask for clarification if information is missing.

It should not:

• create products;
• invent prices;
• fill in stock;
• deduce compatibilities without a source;
• generate URLs;
• promise availability;
• mix products from different catalogs.

When there are no results, the system should say so helpfully:

{
  "type": "no_results",
  "message": "No available products found that exactly match those criteria.",
  "suggested_next_steps": [
    "Expand price range",
    "See available compatible alternatives",
    "Check similar available products"
  ]
}

A good fallback is worth more than a convincing but incorrect recommendation.

Evals: what separates a demo from a real product

An AI-powered catalog needs specific tests.

It’s not enough to check if the answer “sounds good.” You have to check if the system returns correct products.

Useful metrics:

Metric	What it measures
top_1_relevance	If the first product fits the query.
top_3_recall	If there’s at least one correct product among the top three.
attribute_match_rate	If requested attributes are respected.
availability_accuracy	If shown stock matches the source.
price_accuracy	If the price matches the catalog.
hallucination_rate	If made-up products or fields appear.
fallback_quality	If it responds well when there are no results.
render_contract_validity	If the response can be rendered as a card or carousel.

For an MVP, 30 or 50 well-designed queries already reveal a lot:

• intent-based searches;
• SKU searches;
• out-of-stock products;
• max budget;
• compatibility;
• out-of-catalog queries;
• real ambiguity;
• similar but incorrect products.

That’s where you discover if vector search truly improves things or just adds pretty but risky results.

How I’d start for an MVP

The pragmatic sequence would be:

1. Create your own clean catalog database.
2. Normalize minimum fields: title, description, category, price, stock, image, URL, and attributes.
3. Enrich products with uses, canonical attributes, and equivalent terms.
4. Implement lexical search and hard filters.
5. Create manual evals with real queries.
6. Add embeddings as a complementary signal.
7. Compare results before and after.
8. Enable hybrid ranking only if it improves relevance without increasing errors.

I wouldn’t start with a complex vector database. I’d start by proving the system recommends real products without making things up.

Then yes: embeddings, hybrid search, reranking, MCP, or integration with external channels.

The core idea

A sales agent doesn’t need to “sound like a salesperson.” It needs to work with real sales data.

In catalogs, AI adds value when it helps translate human intent into actionable products. But that translation must go through contracts, filters, traceability, and evaluation.

The right architecture separates responsibilities:

• the user expresses a need;
• the LLM interprets intent;
• the backend queries and validates;
• the catalog provides commercial truth;
• the frontend displays cards;
• the team measures errors and improves the system.

Vector search is a very useful piece of that architecture. But it’s not the architecture.

Because in a sales catalog, the goal isn’t for the answer to sound smart. It’s for the recommendation to be correct.

Related reading

• Prepare a knowledge base for a sales AI agent
• Why a prompt is not a sales automation strategy
• Business rules in AI agents: asking, filtering, and routing
• Sales AI agent for discovery: what to ask before a call

Frequently Asked Questions

Is vector search useful for finding products in a sales catalog?

Yes, but it should complement exact search, filters, and business rules. It’s useful for semantic intent, not as a replacement for SKU, stock, price, compatibility, or channel validations.

Why aren’t embeddings enough for product recommendations?

Because a sales recommendation must be correct, available, traceable, and actionable. A vector can find similar products, but it doesn’t guarantee hard constraints like price, availability, category, compatibility, or permissions are met.

What’s the right architecture for an AI-powered catalog?

A hybrid architecture: the model interprets intent, the backend applies hard filters, search combines lexical and vector signals, and the system validates the response before rendering product cards.

Should the LLM create the product cards?

No. The LLM can propose a structured search intent. Product cards must come from the real catalog, with product, image, price, stock, URL, and traceability generated by the backend.