When AI Search and Your Filters Disagree About Your Own Catalogue
Shoppers filter for waterproof under 100 and the AI search box recommends something leather at twice the price. Two retrieval systems reading the same catalogue differently is a data problem, and it is measurable.
A store can now have two ways of finding products that contradict each other. The filter rail reads structured attributes: waterproof is true, price is under a threshold, size is in stock. The AI search reads titles, descriptions, tags, and whatever it inferred when it indexed the catalogue, and it ranks by semantic closeness to the query. Ask both for the same thing and you can get different catalogues, with the conversational one cheerfully recommending a product the filters exclude for a reason the shopper stated out loud.
That contradiction erodes trust faster than a poor result list does. A shopper who says under 100 and is offered 180 has not been given a worse match, they have been ignored. Retrieval research in ecommerce has been blunt about this for years: filters are treated as hard constraints by users, and results that violate them read as errors, not as suggestions.
Attributes are the shared contract
Both systems need the same source of truth. If waterproof lives in a metafield for filters but the AI index was built from an older export without that field, the assistant cannot respect it. Inventory the attributes shoppers actually filter and search by: price, size availability, material, waterproofing, compatibility, dietary flags, age rating, whatever fits the niche. Confirm each one exists in both indexes, with the same values, updated on the same schedule.
Units and synonyms are where the contract frays. A catalogue that mixes centimetres and inches, or lists one product as waterproof and its sibling as water resistant and a third as weatherproof, gives a language model three phrases to treat as near equivalents when the store means them as different claims. Normalise the vocabulary in the data, not in the prompt. Prompt instructions asking a model to be careful are weaker than a field that only allows approved values.
Test with constraint queries
Build test queries that carry explicit constraints, because those are the queries that expose disagreement: waterproof boots under 100 in size 9, a nut free snack box, a lamp that takes an E27 bulb, a dress available in a specific size today. Score the top results from search, filters, and the assistant against the constraint. A result that violates a stated constraint is a failure regardless of how relevant it otherwise looks.
Also test the negative space. Ask for something the store does not sell. A good assistant says so and offers the closest category it does stock. A poorly grounded one recommends an unrelated product with confidence, or describes a product that does not exist in the catalogue at all. Both behaviours show up in real deployments, and both are findable before a customer finds them, if anyone writes the query down and checks.
Deciding which system wins
When they disagree, the structured data should win for facts and the language layer should win for interpretation. Let the model parse a messy query into constraints and intent, then let the catalogue system retrieve against verified attributes, then let the model explain the results in plain words. That ordering gives you the fluency shoppers like without handing the model authority over price, stock, and specifications.
Log disagreements as a data quality feed. Every time an assistant's pick is filtered out by an attribute, something is missing or inconsistent in the product data, and merchandising can fix it once rather than per conversation. Stores that route those logs to the people who own product data get a cleaner catalogue as a side effect. Stores that only tune prompts get a better worded version of the same wrong answer.
Related reading: Glossary, About, AI Product Descriptions That Invent Claims: An Audit Workflow.
Frequently asked questions
Why does AI search ignore my price limit?
Often because price is treated as ranking context rather than as a hard filter, or because the index holds a stale or variant level price that differs from the product page. Price, stock, and stated attributes should be applied as constraints by the retrieval system, not left to the language model to respect in prose.
Should filters and AI search return identical results?
Not identical, since natural language queries involve interpretation, but they must not contradict on facts. A product excluded by an attribute should not be recommended by the assistant for the same requirement. Rank order can differ; eligibility should not.
How do I test an AI search tool before launch?
Write twenty to thirty real queries from your own search logs, half of them with explicit constraints, and score the top five results for each against the product data. Include queries for products you do not sell. Repeat the set after catalogue or model changes, and keep the failures.
Who should own catalogue data quality for AI tools?
The same people who own it for filters and product pages, with a feedback route from whoever runs the AI tool. Splitting ownership, with a separate AI team maintaining a separate export, is how the two systems drift apart in the first place.