Introduction
A buyer sends your inside sales rep one line: “same as the 2-inch one we bought last year, but in stainless.”
No filter interface ever built can express that query. Answering it means knowing what they bought, which single attribute is being varied, and which attributes have to hold constant. Size, thread, pressure rating, fixed. Material, changed.
Your search box cannot do any part of that. So the question goes to a person, who goes to an order history file, who gets back to the buyer on Thursday.
Ask any vendor how their AI search handles that query and you will get a sentence like “it connects to your catalog and understands your product data.” We publish our own version of that sentence on our page for AI product search for B2B. It is accurate. It is also not an explanation. If someone is asking you to spend money on this, you are owed the explanation.
This is the version with the mechanism in it, failure modes included.
What is AI product search, in one sentence you could repeat to your boss?
AI product search is a search system that matches a buyer’s plain-language description to real products in your catalog, using meaning, exact strings, and structured specifications at the same time, and answers only from records that exist in your data.
That last clause is doing real work. Plenty of software will produce a confident paragraph about a product you have never stocked. A product search system is only useful if what comes back is something you can actually ship.
Now the boundary. This is not autocomplete, and it is not a synonym list somebody maintains by hand. It is not your existing filter interface with a nicer skin on it. It is also not the same problem as having a catalog with no search at all, which is what a passive catalog is and a separate conversation entirely. The topic here is why a catalog that already has a working search box still sends buyers away empty-handed.
Why does your search box fail when a buyer types "SS316 3/4 NPT"?
Because a keyword box matches strings, not meaning. Your catalog says “stainless steel 316.” The buyer typed “SS316.” To the search index those are two unrelated pieces of text, and no amount of effort on the buyer’s part will connect them.
The algorithm behind most classic search boxes is BM25, a ranking method that scores results by how well their literal terms line up with the query. It deserves credit rather than a strawman. BM25 is fast, precise on exact terms, cheap to run, and fully explainable. Those are not small virtues, and they matter later in this article.
What it cannot do is recognise that two different strings mean the same product. In B2B that limitation compounds in six specific ways.
The first is trade shorthand. Buyers type the abbreviation they use on the shop floor, and your catalog carries the full manufacturer description. The second is part-number formatting drift. “ABC-1234,” “abc1234,” and “ABC 1234” are one product to a human and three separate strings to a database, and whichever one your data team standardised on is the only one that will match. The third is competitor and OEM cross-references. A buyer arrives holding a rival’s part number, and most distributors keep their cross-reference tables in a spreadsheet that was never loaded into the search index in the first place.
The fourth is compatibility. “The seal that fits pump XY-2000” asks about a relationship between two products, and your catalog either stores that relationship implicitly or does not store it at all. The fifth is unit of measure. Your buyer thinks in feet and cases, your catalog is built in metres and eaches, and the query fails on arithmetic nobody performed. The sixth is substitution intent, the query that opened this article, which requires reasoning about which attribute changes and which stay fixed.
None of those are exotic. They are the ordinary traffic of an industrial catalog. Baymard Institute’s search benchmark, drawn from more than 170 sites and apps and over 10,000 performance ratings and updated in April 2026, found that 56% of sites fail to adequately support users’ search needs. Failing on this scale is normal, not negligent.
One caveat. If your catalog still lives in a PDF, none of this applies yet, because there is no index to fail against. Learn how to make a PDF catalog searchable first, then come back.
Are the searches B2B buyers rely on most the ones that fail most often?
On the best evidence available, yes. The three query types with the worst measured failure rates are the three a B2B buyer uses all day.
Baymard’s benchmark breaks failure down by what the buyer was trying to do. Abbreviation and symbol searches are the worst-performing category at 54% of sites having issues. Compatibility searches follow at 44%. Use-case searches come in at 43%. Those three sit at the bottom of the table.
Now line them up against the queries your inside sales team fields every morning.
| Worst-performing query type | The B2B query it maps to |
|---|---|
| Abbreviation and symbol searches, 54% of sites have issues | “SS316”, “1/2-13 UNC”, “3/4 NPT” |
| Compatibility searches, 44% | “fits pump XY-2000” |
| Use-case searches, 43% | “for an outdoor gate”, “for a caustic line” |
Be clear about what that table is and is not. Baymard’s benchmark measures general ecommerce, not B2B. There is no B2B-specific, independently audited study of onsite search failure that holds up to verification, and we looked hard for one. The mapping above is our argument from the data, not measured B2B data. We think it is a strong argument, because abbreviations, compatibility, and application are not edge cases in industrial buying, they are the default. But it is reasoning, and you should treat it as reasoning.
The stakes carry a similar caveat. Constructor’s “Beyond Relevance” study, which analysed 609 million searches across 113 retail sites between October and December 2024, found that searchers made up 24% of visitors but drove 44% of revenue, converting at 2.5 times the rate of non-searchers. That is retail data, not B2B data. The transferable point is not the exact ratio. It is that search is a revenue surface rather than a utility, and the people using it are the people closest to buying.
We are not going to hand you a figure for what failed search costs a distributor, because no such figure survives verification. If you want a number, build it from your own traffic and quote values and model the revenue impact yourself. An honest estimate you made beats a confident one we invented.
What actually happens when a system "learns" your catalog?
Nothing gets memorised, and no model gets retrained on your products. Every product’s text is converted into a long list of numbers called a vector, and those numbers encode what the product means.
Picture a warehouse with no aisles, no bin numbers, and one organising rule: every product gets placed according to what it means. Pipe fittings settle in one region. Fasteners settle somewhere else. Within the fastener region, hex bolts sit close to socket-head bolts and further from wing nuts. Nobody wrote those rules. The placement falls out of the language in the descriptions.
An embedding is that placement, written as coordinates. Two products whose descriptions mean similar things end up with similar coordinates, which is another way of saying they end up near each other in the warehouse.
When a buyer types a sentence, it gets converted into coordinates the same way. The system walks to that spot and picks up whatever is closest. “Closest” here is a real, measured distance between two sets of numbers, not a judgement call. That measurability is the entire trick. The software that stores those coordinates and finds the nearest neighbours quickly is called a vector database, and AWS’s own documentation describes exactly this: high-dimensional points, ranked by distance.
So when a vendor tells you their system “learns your catalog,” here is what that phrase is allowed to mean. It does not mean the model now knows your products by heart. It means your catalog was converted into a form the system can measure similarity against. Which has a practical consequence worth asking about: when your catalog changes, that conversion has to be redone. Ask any vendor how often, and how.
If meaning-based search is smarter, why do serious systems still run keyword search?
Because on a catalog full of part numbers, grade codes, and thread specs, meaning-based search on its own is often worse than the plain keyword box you already have.
That is not a hedge or a marketing caveat. It is the finding of the strongest benchmark in the field. BEIR (Thakur et al., NeurIPS 2021 Datasets and Benchmarks Track) evaluated ten retrieval systems across eighteen datasets and found BM25 to be a robust baseline that dense retrieval models often underperform in zero-shot, out-of-domain settings.
“Out-of-domain” is the phrase that matters to you, so here it is in plain terms: your specialist catalog is nothing like the general text the embedding model was trained on. Nobody trained it on your grade codes, your trade shorthand, or your supplier’s part-numbering scheme. That gap is the exact condition BEIR measures.
One honest caveat. BEIR is from 2021 and embedding models have improved considerably since. The takeaway is not “vectors do not work.” It is that this is why keyword retrieval never left, and why a vendor who says they replaced it should worry you.
The real answer is hybrid retrieval, and it is a design choice rather than a compromise. Run both searches in parallel. Then fuse the two ranked lists by position rather than by score, so two incompatible scoring scales never have to be reconciled with each other. The standard method is called Reciprocal Rank Fusion, and the plain-language version is simple: a result that placed near the top of either list gets pushed toward the top of the combined list. The weighting between the two sides is a dial, not a fixed setting, and it gets tuned to the catalog.
| Retrieval method | What it is good at | Where it fails | The B2B query it handles |
|---|---|---|---|
| Keyword / lexical (BM25) | Exact strings, speed, explainability | Different wording for the same thing | “ABC-1234”, “SS316” |
| Meaning-based / dense vectors | Paraphrase, description, application | Exact identifiers, out-of-domain jargon | “for an outdoor gate” |
| Hybrid, both fused | Both of the above in one ranked list | Still needs spec filters on top | “SS316 ball valve for a caustic line” |
Here is the takeaway to carry into every vendor conversation you have. Ask whether exact matching on part numbers still runs alongside the AI. If the answer is some version of “we use AI now,” that is a red flag, and you have just learned something about the catalog they built it for.
How does it handle "316 grade, 1/2 inch NPT" without guessing?
It does not rely on similarity for those at all. It pulls the specifications out of the sentence, turns them into filters, and applies them as hard rules.
The reason explains most of what is hard about B2B search. An embedding encodes approximate meaning. A specification is an exact fact. “Roughly similar” is a fine answer to “for an outdoor gate.” It is a wrong answer to “316 grade,” where the difference between 316 and 304 shows up as a corrosion failure six months later, on your customer’s line, with your name on the invoice.
So the query gets split in two.
- Hard constraints, applied as filters. Size = 1/2 inch. Thread = NPT. Material grade = 316. Pressure rating at or above 150. These are rules, not preferences. A product that misses one is not a weaker match, it is not a match.
- Soft meaning, handled by retrieval. “For a caustic line” implies chemical compatibility, service temperature, and seat material. No filter box on your website has ever had a field for that, and it is exactly what meaning-based retrieval is for.
Take a buyer asking for a 1/2 inch NPT ball valve in 316 stainless for a caustic line. The filters narrow the catalog to valves that genuinely are 1/2 inch, genuinely NPT, and genuinely 316. Retrieval then ranks what survives by how well it suits caustic service. Neither half works alone. Filters alone return every 316 valve you stock. Meaning alone returns something that reads right and threads wrong.
This is an active research problem rather than a solved one. The Query Attribute Modeling work (Menon et al., 2025) exists precisely because extracting structured filters out of free-form queries is treated as its own discipline in the field. Anyone who tells you it is trivial has not built one.
What stops it from inventing a part number that doesn't exist?
Retrieval first, then generation. The system finds real records in your catalog before it writes a single word, and it is constrained to answer from those records rather than from anything it absorbed during training.
The technique is called retrieval-augmented generation, introduced by Lewis et al. (NeurIPS 2020). The plain version: combining what a model learned in training with records fetched at question time produces answers that are more specific and more factual, and it makes provenance possible. Provenance is the real prize. Every answer traces back to a record you own, so it can be checked and corrected.
Now the honest half. Grounding reduces invented answers. It does not eliminate them. The hard case is the question your catalog simply cannot answer, where a model under pressure to be helpful will sometimes produce something plausible anyway. This is measurable, and people build test suites for it. The Know Or Not work with its PolicyBench evaluation (Foo et al., 2025) exists specifically to test whether a grounded system correctly refuses.
Four guardrails separate a system you can put in front of buyers from one you cannot.
- Retrieve before answering. Never answer from memory, always from a lookup performed at question time.
- Answer only from what was retrieved. If the records do not support the claim, the claim does not get made.
- Label a near match out loud. “This is 304, not 316” is a useful answer. Quietly returning the 304 is not.
- Refuse and hand off. When nothing supports an answer, say so and route the buyer to a person.
Which gives you a demo test that takes thirty seconds. Ask the assistant for something you deliberately do not stock. A system that says “I do not have that, here is the closest thing I do have, and here is who to ask” has passed. A system that invents a plausible part number has just told you what it will do to your buyers on a Tuesday afternoon.
Is AI product search the same thing as an AI catalog assistant?
No. Search is a layer inside the assistant. Retrieval finds the candidates. The conversation is everything that happens around it.
Retrieval answers one question: which products match? The assistant layer handles what comes next. The follow-up question. The quantity. The price tier that applies to this particular account. The move toward a quote.
That matters because buyers almost never stop at the first result. They ask about lead time. They ask whether the 304 version would do. They ask what 500 units costs. A search box that returns a flawless list and then goes silent is half a system, which is the argument for a B2B catalog chatbot as a category.
Worth saying once and then moving on: better discovery is not the same thing as better conversion, and we have argued elsewhere that AI search alone does not shift a B2B catalog conversion rate, because buyers still stall on pricing, minimum order quantity, and compatibility at the point of decision. That article makes the case properly. This one stays upstream, in discovery.
So where does ChatSKU sit in this. It is the assistant layer over catalog files you already have, whether that is a PDF, an Excel export, an ERP extract, or an existing store. Ingestion is file-based and configured with a human in the loop, not a magic pipe into your ERP. Answers come from your catalog records. Near matches get flagged as near matches rather than passed off as exact ones. It goes live with one line of code on your existing site, so nothing gets rebuilt. If you want the specifics of file formats and integrations, what ChatSKU connects to lists them, and you can see it on your catalog without a rebuild.
What we are not going to tell you is which retrieval architecture sits underneath any vendor’s product, including ours. Vendors change architectures, architecture claims are unverifiable from the outside, and a spec sheet you cannot check is worth nothing to you. What you can verify is behaviour. Ask whether exact matching still runs. Ask for something they do not stock. Those two tests tell you more than any diagram.
People also ask
Is AI product search the same thing as semantic search?
No. Semantic search is one component of it. AI product search in practice means semantic retrieval, keyword retrieval, structured specification filters, and grounding, all working together. A vendor selling you semantic search on its own is selling you the component that struggles most with part numbers.
Does AI product search need clean, structured product data to work?
It works with messy data and works considerably better with clean data. Duplicated SKUs, inconsistent units of measure, and missing attributes degrade results before retrieval is even involved. No retrieval method recovers an attribute that was never recorded. Fixing your worst 200 records usually beats changing search technology.
Can AI product search handle competitor and OEM cross-reference part numbers?
Only if those cross-references are in the data it can read. This is where most distributors lose the query. Cross-reference tables tend to live in a separate spreadsheet that nobody ever loaded into the search index, so the buyer types a rival’s part number and gets nothing back. The fix is a data fix, not a search fix.
How do you test whether an AI search tool actually works on your catalog?
Three queries, five minutes. Type an abbreviation your buyers use but your catalog does not. Ask a compatibility question about a product that fits another product. Then ask for something you do not stock. The first two show you whether retrieval works. The third shows you whether the system is honest.
Conclusion
The interesting thing about AI product search is not that it is smart. It is that a good one knows when to be literal.
Meaning-based retrieval handles the buyer who describes the job. Exact keyword matching handles the buyer who types the part number. Structured filters keep 316 from quietly becoming 304. Grounding keeps the answer tied to something you can actually ship.
Two questions will tell you more about any tool than a demo script will. Ask whether exact matching on part numbers still runs alongside the AI. Then ask the assistant for something you do not stock, and watch what it does.
Frequently asked questions
Filters require the buyer to know your attribute structure and click through it in your order. AI product search takes one sentence and works out which parts are hard constraints and which describe the job. Good systems use both. The filters still run underneath, applied as rules rather than clicked by hand.
An embedding is a product description converted into a long list of numbers that encodes what the description means, so that products meaning similar things end up numerically close to each other and “similar” becomes a distance you can measure rather than an opinion.
On exact identifiers, which is most of a B2B catalog. Part numbers, grade codes, and thread specs are strings with no meaning to interpret, and literal matching is the correct tool for them. The BEIR benchmark found keyword ranking to be a robust baseline that meaning-based retrieval often underperforms on specialist material it was never trained on. Your catalog is specialist material.
The query fails unless something converts it. A buyer thinking in feet and cases against a catalog built in metres and eaches is a silent failure: the search returns nothing and nobody records why. Unit normalisation belongs in your data preparation, not the search layer, and it is one of the highest-return catalog fixes available.
In a well-built system, three things. It says plainly that it does not have the item. It offers the nearest thing it does have, labelled as a near match with the difference named. Then it routes the buyer to a person if the near match will not do. A system that produces a confident answer instead has failed the only test that matters.
No. It removes the repetitive lookup work, the same five spec questions asked forty times a week, and the after-hours queries that currently go unanswered until morning. What reaches your reps arrives qualified, with the specifications already pinned down. The team spends its time on quoting and relationships rather than on catalog archaeology.
Turn your catalog into a 24/7 sales channel
Stop sending PDFs. Start capturing demand.
Try ChatSKU Free →