You Deployed AI Search and Relevance Got Worse — The Catalog Was Never Ready

The rollout follows a script by now. You replace keyword search with an AI-powered layer that understands intent instead of exact strings. The demo is excellent — it parses messy queries, surfaces products a keyword index would have missed, and feels like the upgrade everyone wanted. Then it hits production, and relevance quietly gets worse. Specific queries return loosely related items. Zero-result searches climb. Conversion flattens. And the most frustrating part is that the AI is doing exactly what it was built to do: faithfully interpreting the data it was handed.

The data is the problem.

This pattern was laid out clearly in Pavel Tsarikov’s Retail TouchPoints article, “You Deployed AI Search and Relevance Got Worse. Here’s Why It Happens”, and it matches what we see constantly in multi-supplier catalogs: AI search is a downstream consumer of catalog quality, not a substitute for it. The instinct when relevance drops is to assume the AI layer is broken, so teams spend weeks tuning prompts, swapping ranking models, adjusting embeddings, and changing retrieval logic. The same bad results persist because none of that touches the upstream cause.

Why AI search can feel worse than the keyword search it replaced

Old keyword search failed safely. It was constrained: it matched only what was explicitly indexed, so when a product did not show up, a merchandiser could trace the missing keyword and fix it. AI search removes that constraint on purpose, and that is exactly why it can degrade. It succeeds more often at matching something, even when that something is the wrong thing.

Strip out strict matching and the model needs reliable attributes to anchor its interpretation. Without them, it starts making connections on weak similarities, pairing two products because they share a vague descriptor while missing the functional requirement the buyer actually specified.

Picture a buyer searching M10 A4-80 stainless hex bolt, DIN 933.

With clean data, that query resolves to exactly the right part. With a typical catalog, the AI layer sees conflicting records, blank fields, buried specs, and near-duplicates. It confidently returns the wrong fastener — not because the model is weak, but because nothing in the data told it that grade, standard, and material were the constraints that mattered. Keyword search would have returned nothing and failed visibly. AI search returns the wrong bolt and fails silently, which is worse.

The real cause sits upstream

Enterprise catalogs are assembled from many independent systems: multiple PIMs, supplier feeds, ERP exports, enrichment passes, spreadsheets, and years of manual workarounds. Almost none of that was built with machine interpretation in mind. So the search layer inherits gaps, local exceptions, duplicated concepts, and category-specific quirks.

Attributes are complete for one brand and sparse for another. Variants are separate records in one category and grouped in another. The same concept is described three different ways depending on which source it came from. AI search cannot reason its way out of that. The belief that a big enough catalog and a smart enough model will “figure it out” is the core mistake: volume does not organize chaos, it amplifies it.

This is why teams need to treat product metadata management and product matching as relevance infrastructure, not housekeeping. If the same product is represented by competing rows, inconsistent units, and supplier-specific names, the search layer is ranking ambiguity.

The fix is preparing what search receives

The reliable approach is not to make the model smarter. It is to make its inputs less ambiguous.

That means doing the work before data reaches the search layer:

• Validate relevance-critical fields by category. Grade, standard, voltage, finish, capacity, compliance marks, and dimensions do not matter equally in every category. Search-ready product data defines which fields matter and checks whether they are present.
• Normalize values so filters and ranking agree. A4-80, A4 80, and stainless grade 80 should not behave like unrelated concepts. Units, spellings, casing, and allowed values need consistent representation.
• Harmonize first- and third-party sources. Supplier feeds, ERP records, PIM rows, and enrichment data need to resolve into one representation per product instead of competing for search authority.
• Expose business rules as structured inputs. Availability, compliance, regional restrictions, substitutions, and fulfillment constraints should not live only in prose, PDFs, or exception notes.

Give AI search clean attributes and explicit constraints to anchor on, and the same model that was failing starts performing.

This is exactly the layer Claro runs on top of your existing stack. We resolve the same product’s competing records into one canonical product record, normalize units and formats, harmonize supplier attribute names to a single schema, validate completeness against what each category actually needs, attach confidence and provenance, and write the trusted result back continuously as new supplier data lands. AI search then reads prepared, unambiguous data instead of interpreting conflicting signals from raw source systems.

The point is not a smarter search engine. It is a catalog that is ready to be interpreted by one.

Before and after

If you want to know whether your catalog is actually search-ready, watch the upstream signals, not just the search metrics: attribute completeness, duplicate rate, unit consistency, value normalization, and how consistently the same concept is represented across sources. Those predict product search relevance better than another round of model tuning.

For the broader operating checklist, use the AI-ready product data guide. For the step-by-step workflow behind canonicalizing messy supplier inputs, start with how product matching works at scale.

Ask the better question

When relevance drops after an AI search deployment, the useful question is not “did the AI fail?” It is “was the catalog ever ready to be interpreted by AI in the first place?”

Fix that, and the same search layer that was hurting you starts helping. The prepared data pays off everywhere else AI touches your catalog too: recommendations, agents, procurement workflows, enrichment, and merchandising operations.

Sources and article inspiration

This article was shaped by the same AI-search relevance problem catalog teams are now seeing in production:

Related Claro resources

FAQ

Why did our relevance get worse after switching to AI search? +

Keyword search was constrained — it matched only what was indexed and failed visibly. AI search interprets intent, so without clean attributes to anchor on it matches something even when it is wrong, pairing products on weak similarities. The cause is usually ambiguous catalog data, not the search model.

Can't the AI model compensate for messy catalog data? +

No. A large catalog and a capable model do not organize data chaos — they amplify it. The model faithfully interprets whatever it is given, so gaps, duplicates, and inconsistent attributes produce confident wrong results. The fix is preparing the inputs, not tuning the model.

What does search-ready product data mean? +

Search-ready product data means one canonical record per product, with relevance-critical attributes validated and complete, values normalized to consistent formats, first- and third-party sources harmonized, and business rules such as availability and compliance exposed as structured inputs.

Claro keeps multi-supplier product and supplier data clean, matched, enriched, and validated across your existing ERP, PIM, and procurement systems. Your catalog should get smarter every day.